How to Vet an AI Operations Consultant

Most lists of "questions to ask an AI consultant" were written for a different hire than the one you're actually making. They're built around picking a tool: what's your tech stack, what's your pricing, can I see a demo. Useful questions, if the problem is choosing software. They don't tell you much about whether the person across the table is going to fix how your business runs, or just install something on top of whatever's already broken.

That's the gap worth closing before you sign anything. A consultant who starts with the tool is optimizing for the demo. A consultant who starts with the operation is optimizing for what's still true six months later. The questions below are built to tell the two apart, not to rank software vendors.

Why the Standard Questions Don't Work Here

Ask ten "how to hire an AI consultant" guides what to ask, and they mostly converge on the same list: what's your pricing model, can you show me past work, what tools do you use day to day. Those are reasonable questions if you're buying a tool implementation. They tell you almost nothing about whether the person has actually looked at your operation, or whether they're going to wire AI into a process that was broken before they arrived.

The distinction that actually matters is the one covered elsewhere on this site: diagnosis before deployment, process redesign and not just software, and a number you can check at the end. A vetting conversation should be built around confirming those three things are real, not around comparing feature lists.

The 9 Questions

1. What will you measure before you touch anything?

If the answer is vague, "we'll see how it goes," that's the whole conversation right there. A consultant who's going to fix an operation needs a baseline: how long a task currently takes, how often it happens, what it costs. Without that number, there's nothing to compare the result to later.

2. Which problem are we actually solving, a demand leak or a capacity constraint?

Most operational problems a business considers AI for are one of two things: interest going cold before anyone follows up, or a team buried in work that isn't growing the business. A consultant who can't tell you which one you've got, specifically, hasn't diagnosed anything yet. They're guessing at a fix for a problem they haven't named.

3. What changes in the process itself, not just in the software?

Half of what breaks in AI projects isn't the AI, it's that nobody ever defined who owns a handoff or what "done" means. If the answer to this question is entirely about a tool and nothing about the surrounding process, the process stays exactly as broken as it was, with a tool bolted on top of it.

4. Who owns this after you leave?

A consultant who quietly becomes a permanent dependency hasn't fixed your capacity constraint, they've just moved it onto their own invoice. Ask directly who maintains the system once the engagement ends, and whether your team is trained to run it without them.

5. What's the first thing you'd build, and why that first?

A real diagnosis produces a sequence, not a single monolithic project. The first 30 days of a properly run engagement should be identifiable before it starts: what gets mapped first, what gets built first, and why that's the highest-leverage place to start rather than the most obvious one.

6. What would make you tell me not to do this yet?

This is the question most consultants hope you don't ask, because the honest answer sometimes is "nothing, not right now." If your processes are still changing every few weeks, or nobody owns the outcome you'd want fixed, AI work will scale the chaos that's already there instead of fixing it. A consultant willing to say that out loud, even when it costs them the engagement, is telling you something a sales-first consultant never will.

7. How will I know, in hours and in pounds, that it worked?

This is the measurement question from the start of the conversation, asked again from the other end. The answer should be specific: hours freed per week, money no longer draining through manual work, measured against the baseline from question one. The same calculation works for checking their claim as for spotting the problem in the first place:

8. Are you fixing my operation, or selling me a tool stack?

Ask it plainly. The honest version of this answer names the operational problem first and the tooling second, almost as an afterthought. A consultant who answers with a list of platforms before mentioning a single thing about how your business runs is, functionally, a tool vendor wearing an operations label. The two overlap in practice more than the industry admits, which is worth understanding before you sign with either.

9. What happens if it doesn't work?

Not a hypothetical, an actual answer. Is there a phased structure tied to milestones, or is the whole fee due upfront regardless of outcome? A consultant confident in the diagnosis should be comfortable being measured against it. One who isn't is telling you how much they actually believe their own plan.

Red Flags Worth Walking Away From

• They lead with tools before they've asked what the problem costs you. That ordering is the whole tell.
• They can't describe what they'll measure. No baseline means no way to prove anything changed.
• Nobody owns the system once they leave. That's not an engagement ending, it's a dependency starting.
• The proposal is full of "transformation" and empty of numbers. Confidence without a baseline is marketing, not diagnosis.
• The full fee is due upfront with nothing tied to outcome. A consultant who won't stand behind the diagnosis shouldn't expect you to fund it blind.

FAQ

Is vetting an AI operations consultant different from vetting a general AI consultant?

Mostly in emphasis. A general AI or tool consultant gets judged on their stack and their pricing. An AI operations consultant should get judged on whether they diagnose the operation before recommending anything, because that's the part of the job that determines whether the result holds up once the novelty wears off.

What if I don't understand the technical side well enough to ask good follow-up questions?

You don't need to. None of the nine questions above require technical knowledge. They're about measurement, ownership, and sequencing, which is exactly the point: a consultant who can't answer them in plain language for a non-technical founder isn't actually clear on the plan themselves.

Should I just ask for a free audit instead of committing to a full engagement?

That's often the more honest first step. An audit should answer the diagnosis questions above, where the demand leak or capacity constraint actually sits and roughly what it's costing, before either side commits to anything bigger.

Where to Start

The fastest way to use this list isn't to email it to a consultant and wait for written answers. It's to run the one-line calculation on your own numbers first, so you walk into the conversation already knowing roughly what the problem is costing you. Then these nine questions tell you whether the person across the table actually sees the same thing you do.