Hiring an AI consultant should make a business decision clearer and a delivery easier to manage. A strong candidate can explain which part of your workflow needs AI, which part needs ordinary software, and how the finished system will be evaluated. A list of model names is not enough to establish that capability.
The most useful first conversation starts with a task your team already performs. Bring a real input, a representative finished output, and an explanation of what makes the work slow or unreliable. You can redact confidential details while keeping the workflow recognizable.
Decide what responsibility you are buying
An assessment, an implementation, and ongoing support are different engagements. An assessment should produce an actionable decision and its supporting evidence. A build should produce working software within agreed boundaries. Support should define who responds when a tool, source, or model changes.
Ask who owns architecture, integration access, evaluation, deployment, and handover. A consultant may handle all of them or work alongside your existing team. Either arrangement can work, provided there is an accountable owner for each part.
My portfolio organizes this into Assess, Build, and Support. The Artebello case study explains the readiness approach; The Contractors Toolbox provides a different kind of evidence through business software delivery.
Look for relevant implementation evidence
Review a case study against the problem you have. A useful project record states the engineer's role, the system's current status, important decisions, and the evidence available for its results. A live product establishes that a product exists; it does not, by itself, establish a claimed business improvement.
Ask the candidate to explain a failure path. What happens when an API is unavailable, a document is contradictory, or the proposed action needs approval? The quality of that explanation often reveals more than a polished demonstration.
You do not need a candidate who has used every framework. You need someone who can connect your constraints to an understandable architecture and explain the tradeoffs.
Compare proposals using the same questions
Scroll sideways to view the full table.
| Proposal question | A useful answer contains |
|---|---|
| What is the first workflow? | Inputs, actors, output, and a completion condition |
| What can the system access? | Named integrations and permission boundaries |
| What requires a person? | Approval, review, and escalation responsibilities |
| How will we accept the work? | Representative examples and explicit failure checks |
| What will we receive? | Application access, source code arrangements, deployment notes, and operating guidance |
| What is outside the scope? | Named exclusions and a process for changing scope |
These questions make proposals comparable without forcing every provider into the same implementation. They also expose dependencies that would otherwise become surprises after the project starts.
Use a fictional pilot to test the proposal
Imagine a small distributor wants an assistant to prepare responses to stock enquiries. A reasonable pilot might retrieve approved product information, draft a response, and send it to a salesperson for review. Inventory changes and customer messages remain separate authorized actions.
The pilot needs examples with missing products, conflicting stock records, and an unavailable inventory API. Its purpose is to establish whether the workflow is useful and controllable. It should not quietly expand into an autonomous purchasing system.
This is an illustrative example, not a claim about a client engagement. The same scoping method applies to document retrieval, intake processing, and internal operational assistance.
Agree the operating relationship before launch
Ask who holds provider accounts, where configuration lives, how access is revoked, and how a maintainer can reproduce a failure. Confirm the arrangements for code ownership and ongoing support in the engagement itself.
NIST's AI Risk Management Framework offers a voluntary reference for organizing AI risks. It does not replace the delivery-specific controls or acceptance criteria in your agreement.
If you are choosing a consultant, begin with the business problem, the available systems, and the decision you want a pilot to answer. Discuss a project to establish a useful starting scope.
Prepared with AI assistance using Paul’s documented project work and the linked sources. Examples are illustrative unless identified as project records.