How to Choose an AI Consultant: The Questions That Actually Separate Them

The short version: choose the consultant who asks about your operation before proposing anything, who tells you plainly who maintains the work after they're gone, who can show you something actually running rather than a slide about it, and who is willing to say what they'd tell you not to automate. Everything else is a detail. Those four things separate a useful engagement from an expensive one almost every time.

The longer version matters too, because most owners hiring for this are doing it for the first time, and the market is crowded with people who learned the vocabulary six months ago. Here's how to tell the difference in a single conversation.

First, decide what kind of help you're actually buying

"AI consultant" covers at least four different jobs, and a lot of bad fits come from a buyer wanting one and hiring another.

Advisory. Someone helps you form a point of view: what's worth doing, in what order, what the risks are, what your policy should be. The deliverable is a decision, not software. Useful when you have people who can build but no agreement on what to build.

Build. Someone designs and ships a working system: an agent, an automation, an internal tool, an integration. The deliverable is a thing that runs. This is what most small businesses actually want when they say "AI consultant," even when they open with a strategy question.

Training and enablement. Someone teaches your team to use tools that already exist. The deliverable is capability inside your own staff. Frequently the highest-return option for a business that hasn't tried anything yet, and frequently skipped because it sounds less impressive than a build.

Staff augmentation. Someone works inside your team for a stretch. The deliverable is throughput.

These have different price shapes, different timelines, and different failure modes. If you don't know which one you want, say so on the first call and let the answer be part of the conversation. A good consultant will tell you when you're asking for a build and what you actually need is two hours of training. A bad one will sell you the build.

The five questions that do the most work

Ask these in any order. What you're listening for is whether the answers are specific, and whether any of them cost the consultant something to say honestly.

1. What happens to my data?

This is the real adoption blocker in almost every business, and it isn't a question about model capability. You want to know where your data goes, whether it's retained, whether it trains anything, and what the contractual answer is rather than the marketing answer.

A weak response is reassurance. A strong response names the specific service, the specific setting, and what happens if that setting is wrong. It should also acknowledge that a policy depending on your staff remembering to redact things by hand is not really a policy at all.

2. Who maintains this after you leave?

The single most useful question in the whole conversation, and the one most consultants avoid because the honest answer can cost them money. If someone on your team can maintain it, the right engagement is a build and a clean handoff. If nobody can, the honest offer is a retainer, priced and named as a retainer.

What you don't want is a one-time project that quietly becomes a subscription nobody agreed to. Ask it out loud and see whether the proposal changes shape based on your answer.

3. Can I see something you built, running?

Not a case study. Not a percentage. Something you can click, or a screen share of a real system doing a real thing. Small consultancies often work under NDA and genuinely can't show client systems, which is a fair answer, but a fair answer comes with a substitute: a redacted workflow export, an internal tool they built for themselves, a demo they can hand you a link to.

Be actively suspicious of large outcome numbers with no named source. "We cut processing time 40%" with no client, no method, and no way to check is a claim manufactured for a deck. A real project described plainly is worth more than a fabricated statistic, and a consultant who fabricates one in a sales call will fabricate one in a status report.

4. What does it cost to keep running?

Almost every first-time buyer thinks about the build cost and nothing else. The ongoing cost is the part that surprises people: model API usage, the automation platform's monthly fee, whatever SaaS the integration touches, and the human time to watch it. None of these is usually large. All of them are usually unmentioned.

Ask for the monthly number alongside the build number. If the consultant hasn't thought about it, that tells you something about whether they've ever operated what they built.

5. What would you tell me not to automate?

The trap question, and the most revealing one. Someone who has actually done this work has a list. Things where the verification costs as much as the task. Things touching money or a client relationship where a small error is expensive. Things that happen twice a year. Things where the process changes every month and the automation would be stale before it shipped.

If the answer is that everything can be automated, you're talking to someone selling a category rather than solving your problem.

The red flags, compressed

• The pitch starts with a tool. If the first ten minutes are about a platform rather than about how your business actually runs, the shape of the engagement was decided before they met you.
• Numbers with no origin. Percentages, ROI multiples, and industry statistics presented as facts about your future.
• No failure mode in the design. Ask what happens when the model gets something wrong. If there's no answer, there's no approval step, and an approval step is usually the difference between a system you can trust and one you can't.
• A demo that is a slideshow. Slides are fine as context. They're not evidence.
• Refusal to discuss how they price. Worth a careful distinction here: plenty of good consultants won't publish a flat number, because the value of automating a task varies enormously depending on who does it today and how often. That's defensible. What's not defensible is refusing to explain the method. "I can't quote you before I understand the work, and here's exactly how I'll build the number once I do" is a good answer. "Let's discuss that later" three times in a row is not.

What to bring to the call

You'll get a dramatically better conversation if you show up with two things.

A list of tasks that eat time, with rough frequency and rough duration. Not polished. "Someone re-types invoice data into two systems, maybe five hours a week" is enough to work with, and it's more than most prospects arrive with.

And an honest read on who inside your business would actually adopt this. In nearly every company there are one or two people already quietly using AI while everyone else works the way they always have. Knowing who those people are changes what's worth building, because they're the ones who will make it stick.

Then test cheaply before you commit

If two candidates both clear the questions above, don't decide on the proposal. Buy something small from each: a paid discovery session, a single narrow automation, a training block. You'll learn more about how someone works from one small paid engagement than from three sales calls, and the cost of learning it that way is a rounding error against the cost of a bad six-month build.

One more thing worth knowing before you talk to anyone: you can get a real number for your own situation without being in anyone's funnel. The 7-minute Automation Assessment takes what eats your team's time, how often it happens, and who does it today, and returns price bands calculated from your own inputs, ranked by how fast each one pays for itself. Free, and yours whether we ever work together or not. Walking into a consultant conversation already holding your own numbers changes the conversation considerably.