How to hire an
AI consultant.
Written by one, which you should factor in. It's still the guide I'd want if I were on your side of the table, because most bad AI engagements were decided in the first two conversations, before anyone signed anything.
Write the brief before
you meet anyone.
The most common mistake in hiring an AI consultant happens before the first call. A company decides it needs help with AI, takes three meetings, and lets the consultants define the problem. Each one defines it as the thing they sell. You end up comparing three answers to three different questions and picking on rapport.
One page fixes this. Write down the business outcome you want, in numbers if you have them: quotes out in four hours instead of three days, back-office headcount flat while volume grows thirty percent, a governance position you can defend to your largest customer. Write what you have already tried. Write your real budget range and your real deadline. Then send the same page to everyone.
That page does two jobs. It makes proposals comparable, and it changes who responds. A consultant who reads an outcome-shaped brief and comes back saying the outcome is unrealistic, or that a cheaper approach would get you most of the way, has told you something useful about how they will behave once you're paying them.
Also known as: hiring an AI consultant, choosing an AI consulting firm, AI consultant selection, how to find an AI consultant, AI consulting RFP.
Nine that separate
operators from presenters.
Ask every candidate the same nine. The differences in the answers will be stark, and they will not be the differences the pitch decks emphasize.
"What would you need to see in our data before you'd commit to that outcome?"
A good answer names specific fields, coverage thresholds and a way to check them in week one. A weak answer says data quality is important and moves on.
"What will this cost to run per month, at our volume?"
Anyone who has operated a production AI system answers with a structure: inference, monitoring, evaluation, human review. Anyone who has only built pilots gets vague.
"Who owns this after you leave?"
The answer should include a named role on your side, a handover plan and a runbook. "We'd stay on for support" is a subscription, not a plan.
"How do you measure whether the output is good?"
You're listening for an evaluation set built from your historical cases, scored on a cadence. If quality is monitored by waiting for complaints, the engagement has no feedback loop.
"Tell me about an engagement that went badly."
Everyone senior has one. The answer reveals whether they diagnose their own failures or blame the client's data, which is the most reliable predictor of what happens when yours gets hard.
"What would you tell us not to build?"
A consultant who cannot name anything they'd decline will happily sell you the thing that shouldn't be built. This question costs nothing and is remarkably discriminating.
"Who is actually doing the work?"
At a firm, the person pitching is often not the person delivering. Ask to meet them. Ask what else they'll be staffed on during your engagement.
"What happens if we want to stop?"
Notice period, what you keep, whether the code and configuration are yours, and what an exit costs. Negotiate it now, because you'll have no leverage later.
"Can we talk to a client where it didn't go smoothly?"
Polished references prove nothing. A consultant willing to connect you with a difficult engagement is telling you something about their relationship with the truth.
Four answers that should
end the conversation.
Not judgment calls. Each of these is a structural problem you will pay for later.
A solution before a diagnosis
A named platform or architecture proposed in the first meeting, before anyone has looked at your data or counted your volume.
Run cost treated as a detail
"We'll work that out during implementation." It's the number that decides whether you still own the system in two years.
Undisclosed vendor economics
If they're a reseller or take referral fees, that's fine when it's disclosed. When you find out later, every recommendation they made becomes suspect.
Refusing a small first engagement
Anyone confident in their work will take a fixed-scope diagnostic. Insisting on a twelve-month retainer up front is a sales position, not a delivery requirement.
A firm, or one
senior operator?
Both are legitimate. Which is right depends much more on your size and situation than on the sales pitch either one makes.
Scale and coverage matter
- , The program needs several workstreams running at once
- , You need a brand your board already recognizes
- , Procurement requires a vendor with an audited security posture
- , You have the internal leadership to manage a delivery team
Judgment is the constraint
- →The problem is that nobody senior owns AI
- →You need decisions made, not hours delivered
- →Budget is real but not enterprise-scale
- →You want the person who wrote the plan to build it
Start small. Make it fixed.
Agree the exit.
However good the shortlist looks, the first engagement should be small, fixed in scope and fixed in price. Two to four weeks with a defined deliverable tells you more about a consultant than four reference calls will. You see how they work, how they handle disagreement, and whether the questions they ask are better than the ones you were asking yourself.
Make the deliverable yours regardless of what happens next. A diagnostic, an assessment, a ranked portfolio: these should be documents you keep and can hand to someone else. If a consultant's first deliverable is only usable while they remain engaged, that is a commercial design choice and you should notice it.
Then agree the exit before you extend. Notice period, what transfers, who owns the code and the configuration, and what documentation comes with it. Engagements that end well were structured that way at the start, and I write the handover into the scope of my own work for exactly this reason. If you want the version of this from the other side of the table, the AI Diagnostic framework is published in full and you can run it yourself before hiring anyone.
Ask what they'd tell you not to build. It costs nothing, and the ones who can't answer it are the ones who will sell you anything.
About hiring.
How do I hire an AI consultant?
Write a one-page brief describing the business outcome you want, what you've already tried, your real budget range and your deadline, and send the same page to everyone you're considering. Ask each candidate the same questions, especially what they'd need to see in your data, what the system costs to run per month at your volume, and who owns it after they leave. Then start with a small fixed-scope engagement of two to four weeks rather than a retainer, and agree the exit terms before you extend.
What qualifications should an AI consultant have?
Credentials matter far less than a record of production systems. What you want is someone who has run something in production, at a company roughly your size, and who can describe how it was evaluated and what it cost to operate. For strategy and governance work, having actually held an executive seat matters, because the hard part is organizational rather than technical. Certifications are close to meaningless in this field right now.
Should I hire an AI consulting firm or an independent consultant?
Hire a firm when you need several workstreams at once, when procurement requires an audited vendor, or when your board needs a recognizable name. Hire a senior independent when the constraint is judgment rather than capacity, when budget is real but not enterprise-scale, and when you want the person who writes the plan to be the one who builds it. Most mid-market companies running their first serious AI work are in the second situation and buy as though they're in the first.
How long should a first AI consulting engagement be?
Two to four weeks, fixed scope and fixed price, ending in a deliverable you keep. That's long enough to produce something genuinely useful, such as a readiness assessment or a ranked use-case portfolio, and short enough that a bad match costs you a month rather than a year. Anyone unwilling to take a first engagement in that shape is telling you something.
What should be in an AI consulting contract?
Scope with a named deliverable, a fixed fee for that scope, and who owns the output. IP assignment covering code, prompts, configuration and documentation. A notice period on any ongoing work, usually thirty days. Disclosure of any vendor relationships or referral fees. And for implementation work, a commitment on what happens if the system doesn't meet the agreed quality bar, since a service-level agreement on uptime says nothing about whether the output is right.
How do I know if I need a consultant or a hire?
If the work is a defined project with an end, hire a consultant. If the work is an ongoing agenda that needs an owner with decision rights, you need a seat filled, and the question becomes whether to fill it fractionally or permanently. A useful test: if you can write down what "done" looks like, it's a project. If you can only write down what "owned" looks like, it's a role.
Related reading.
What AI consultants cost
Hourly rates, project fees and retainers in the US and Canadian market.
AI Vendor Diligence
The same discipline applied to buying a product rather than hiring a person.
Run the diagnostic yourself
The published framework, free, so you know what you need before you hire anyone.
Send me your brief.
Even if you end up hiring someone else. I'll tell you whether the outcome you've written down is realistic, and what I'd ask the other candidates.