How to Hire an AI Consultant
There is a big reason why so many AI consulting engagements fail in 2026, and it has very little to do with the technology. It has to do with how companies hire. Most have never bought this kind of work before. They evaluate AI consultants the way they would evaluate a web design agency, which is mostly a portfolio of demos.
So let's talk about how to actually hire an AI consultant without throwing money away.
What you're really buying when you hire an AI consultant
Companies usually think they're buying a deliverable: A chatbot, a RAG system, an automation.
What you're actually buying is judgment. Someone who has watched enough of these systems hit production to know what breaks first, what the failure modes look like, and how to design around them before they happen. The deliverable is the byproduct of that judgment. If you hire someone who has only built demos, it’s no surprise that you will get a demo. If you hire someone who has built things beyond showcases and demos, you get something that survives Monday morning.
The interview problem is that both kinds of consultants sound the same in a sales call.
The demo is not real work
A good demo is easy. You pick a clean dataset, you scope the use case narrowly, you run it three or four times with simple interactions, and you record the one where it behaves best. And that’s important, I'm not accusing anyone of dishonesty. Every consultant who shows you a demo has done some version of this.
Real work is different. The work is what happens when the dataset is messy, when the user types something the prompt did not anticipate, when the API rate-limits at 2 a.m., or when a customer asks why the system gave them a wrong answer, and somebody has to explain it. If the person who built the chatbot is testing the chatbot's answers, they won’t ask a real question that will make the AI hallucinate.
When you're evaluating a consultant, the question is not "is the demo good?" The demo is always good, that’s kinda the point. The question is whether this person can tell you, in detail, what happened the last time their work hit production.
Ask them, and demand specific details. What broke first? What did they have to add that wasn't in the original scope? What did the client complain about three months later? What they would do differently now, with all lessons learned.
If the answers are vague, you're talking to someone who has built demos. If the answers are specific and slightly uncomfortable, you're talking to someone who knows the pain of putting a system in production.
Questions that surface the difference
A few questions consistently separate the two kinds of consultants, and they don't require you to be technical to ask them.
"Walk me through the worst bug you shipped to production." No one, absolutely no one, has worked for more than six months in tech without screwing up. A real consultant will tell you what it was, how it got past their testing, how the client found out, and what they did about it. The person who has only demoed will say something like "I always do thorough testing" and pivot to their process.
"Who owns the system after you leave?" This one is critical, and almost nobody asks it. The answer you are seeking is "you do, and here's the documentation, training plan, and handoff schedule we'll use." The bad answer is anything that sounds like the consultant expects to be there forever. AI systems that depend on the consultant who built them are not assets. You are leasing a critical part of your company.
"What are you not going to do?" A good consultant has things they don't take on. The shape of the no tells you the shape of the yes. If they say yes to everything, they are either lying or subcontracting the parts they can't do, and you won't know until it's too late.
"How do you price this work, and why?" Hourly is fine for discovery. Fixed price after a paid discovery call is fine for scoped work. "We'll figure it out as we go" is a huge red flag. If the pricing model doesn't survive a five-minute conversation, there’s no way the billing will survive the first month.
Red flags that don't look like red flags
A few patterns predate bad engagements:
- The consultant has a strong opinion about which model you should use. Models change every six months. A consultant who builds their pitch around a specific model is selling you their own preferences, not your problem. The right answer to "which model" is "depends on the constraints, let's talk about the constraints first."
- The proposal doesn't mention failure modes. Every production AI system fails in predictable ways: hallucination on edge cases, rate limits, cost overruns when usage scales, and latency under load. If the proposal reads as if nothing will ever go wrong, the consultant has either never shipped or is hoping you don't ask.
- There's no mention of who maintains the system. Maintenance is the unsexy part of AI work, and it's where most of the actual value lives. A consultant who treats maintenance as an afterthought is building you something with a one-year half-life.
Everything is custom. Sometimes custom is the right answer. Often it isn't. A consultant who can't tell you when an off-the-shelf tool would have served you better is either inexperienced or selling hours.
Contract clauses that matter
I'm not a lawyer. Get one, because I have one. But these are the clauses that have come up in every engagement I've seen go sideways, and they're worth raising with whoever drafts the contract.
- Ownership of the code, the prompts, and the data. All three. Period. You should be the owner of what you paid for.
- A defined handoff at the end of the engagement. Documentation, runbooks, credentials, and a transition period where the consultant is available to answer questions. Without this, you are paying for a black box.
- An exit clause that doesn't require cause. You should be able to end the engagement with reasonable notice, for any reason or none. If the consultant resists this, you've found out something important about how they think of the relationship.
- A clear definition of "done." "Working RAG chatbot" is not a definition. "Handles X queries per minute with Y latency, returns answers grounded in the indexed corpus, and passes the test suite defined in section 4" is a definition.
- A maintenance arrangement separate from the build. Don't bundle them. The build is a fixed scope. Maintenance is ongoing. Bundling them creates incentives that work against you, because the consultant has no reason to make the system easy to maintain by anyone else.
The discovery call is the interview
Most consultants offer a free discovery call. I don't, and I'd be skeptical of consultants who do for anything beyond a fifteen-minute scoping conversation. Free discovery is sales. Paid discovery is work.
A paid discovery call has a different shape. The consultant comes in with questions. They ask about your current systems, your team, your data, your customers, your budget, your timeline, and your previous attempts at this kind of work. They tell you what they think the actual problem is, which is sometimes different from the problem you described. They give you a written summary at the end with a recommended scope, a price, and the assumptions on which both depend.
If the discovery call ends with a proposal that looks identical to what you described in the first email, the consultant didn't do discovery. They did a sales call.
When you don't need a consultant
You don't need an AI consultant if the use case is well-understood and a SaaS tool already exists that does it. You don't need one if your team has the technical capacity and just needs a few weeks to ramp up. You don't need one if the project is small enough that the cost of the engagement exceeds what you'd save. You probably don't need one if you're hiring them to "explore what AI can do for the business" — that's a strategy problem, not a build problem, and it's usually cheaper to solve internally with a couple of pilot projects than externally with a discovery engagement.
You do need a consultant when the problem is specific, the stakes are high enough that getting it wrong costs more than getting it right, and your team doesn't have someone who has shipped this kind of work before. Those are the engagements that pay for themselves. The rest are usually a way to spend money looking productive.
If your AI project is stuck somewhere between "the demo was great" and "production is two months away and we're not sure why," that's the kind of engagement I take on. The discovery call is paid, the scope is written down, and the handoff is part of the deliverable.