The short answer: Before you hire an AI consultant, ask who will own the accounts and data once the work is done, who maintains it after launch, whether training is included so your team isn't dependent on the consultant, and how success will be measured. A good consultant answers all of this specifically, in writing, before you commit to anything larger.
Hiring an AI consultant comes down to a short list of questions that separate someone who will help from someone who will bill you. Ask about ownership of your accounts and data, who maintains what gets built, what happens if you part ways, and how success will be measured, before you talk about anything else. Below are fourteen questions, why each matters, and what a good versus a bad answer sounds like.
If you want the broader picture first, including when hiring anyone at all is the wrong move, read consultant, agency, fractional, or nobody. This post assumes you have decided to talk to someone and want to walk into that conversation prepared.
Ownership and access
1. Who owns the accounts, logins and data once this is built?
Why it matters: If the automation lives in the consultant's own accounts rather than yours, you are renting your own operations. Losing access to a system you paid to build is one of the most common regrets business owners report after a bad engagement.
Good answer: "Everything is set up under your business's own accounts, from day one. I never hold the only login." Bad answer: "It's easier if I manage it under my agency account, and we'll transfer it later" - later rarely arrives on the terms you expect.
2. What happens if we part ways?
Why it matters: This question tells you whether the relationship is designed around your independence or their retention. A consultant confident in the value of ongoing work should not be afraid of this question.
Good answer: "You keep everything that was built, and I'll do a clean handoff so someone else, or your own team, can maintain it." Bad answer: Any hedging, or a contract clause that disables what was built if you cancel.
Maintenance and reliability
3. Who maintains this once it is live?
Why it matters: Automations break quietly. A tool integration changes, an API key expires, a form field moves. Someone has to be responsible for noticing.
Good answer: A specific name or plan - either an ongoing retainer with defined response times, or a clear statement that your team owns maintenance after handoff and here is how. Bad answer: "It should just keep working" with no owner named.
4. How will I find out if something breaks?
Why it matters: The worst version of a broken automation is one that fails silently for weeks while you assume it is working. Push past "we monitor it" to how, specifically.
Good answer: A concrete mechanism - alerts, a regular check-in, a dashboard you can look at yourself. Bad answer: "We'll let you know" with no described process.
5. What is your response time if something goes wrong?
Why it matters: A missed-call system or a customer-facing agent that breaks during business hours costs you real leads. Know what you are actually getting.
Good answer: A stated timeframe, even an approximate one, tied to how the work is set up. Bad answer: No answer, or "whenever I can get to it."
Scope and approach
6. What will you tell me not to automate?
Why it matters: Anyone who cannot name something has either not thought carefully about your business or is unwilling to say something that costs them scope. A good consultant has opinions about where AI should not be used yet.
Good answer: Something specific - "the first response to a new client," "anything touching medical records," "a price quote nobody double-checks." Bad answer: "AI can handle pretty much anything with the right setup."
7. What does the first two weeks actually involve?
Why it matters: This tells you whether the engagement starts with real discovery or goes straight to selling you a package. See what a real workflow audit looks like for comparison.
Good answer: Interviews with your actual team, review of real workflows, a written roadmap at the end. Bad answer: A generic onboarding call followed immediately by a sales proposal.
8. Who specifically will be doing the work?
Why it matters: This is the single biggest gap between what gets sold and what gets delivered. If the person on the sales call is not the person doing the work, you need to know who is.
Good answer: A name, and an offer to meet them before you commit. Bad answer: "Our team" with no one identified.
Measuring success
9. How will we know this is working?
Why it matters: Without an agreed measure up front, "working" quietly redefines itself after the fact. Set it before the engagement starts, not after.
Good answer: A specific, checkable outcome tied to your business - fewer missed calls, faster response time, a task that used to take an hour now taking minutes. Bad answer: Vague language about "efficiency" or "transformation" with nothing measurable attached.
10. Can you show me an example of past work, even anonymized?
Why it matters: Real work leaves a trail. A consultant who has actually delivered should be able to describe at least one engagement in specific, checkable terms, even without naming the client.
Good answer: A described situation, what was done, and an honestly stated outcome, such as those in published case studies. Bad answer: Big round numbers with no context, or refusal to describe any past work at all.
Training
11. Is training included, or is this build-only?
Why it matters: A build nobody on your team can run or adjust becomes a permanent dependency rather than a system you own. Ask directly, because it is often left out.
Good answer: A clear statement of what training is included, and for whom - see what team training actually covers. Bad answer: "You won't need to touch it" as if that is reassuring rather than a red flag.
12. Will my team actually be able to use what gets built?
Why it matters: Adoption is the actual point. A tool that only the consultant or the owner understands is not really adopted, and the reasons a team stops using new tools are worth understanding before you build anything - see why your team isn't using AI.
Good answer: A plan for walking your actual staff through their actual tasks, not a generic slide deck. Bad answer: No plan for anyone but you to learn it.
Security and client data
13. Where does our customer data go, and who can see it?
Why it matters: Any tool that touches customer information is a data handling decision, not just a workflow decision. This matters even more for regulated fields like healthcare, legal or finance.
Good answer: A specific description of what tools are used, what data flows through them, and how access is limited. Bad answer: "It's all secure" with no detail.
14. What is your approach to approval before something reaches a customer?
Why it matters: Automations that message customers directly without a review step can go wrong in front of the people you least want to see it go wrong. Human-in-the-loop by default is the safer starting posture: you decide what runs automatically and what waits for your approval, and a well-built agent produces a draft for review before anything reaches a customer.
Good answer: A description of what waits for a human and what runs automatically, with the choice explained. Bad answer: Everything set to run unattended from day one with no review step offered.
References
Ask for at least one reference you can actually contact, and ask them the same questions above from their side: did they end up owning their accounts, was training included, did anything break and how was it handled. A consultant with real, repeat clients should not hesitate here.
For a wider view of how consultants compare to agencies, fractional hires and other options, see consultant, agency, fractional, or nobody. And if you are still working out whether you need outside help at all, start with what does an AI consultant do and the free what to automate first tool.
Frequently asked questions
What is the single most important question to ask an AI consultant?
Who owns the accounts and the data once the work is done. If the answer is anything other than an unqualified "you do," stop there. Everything else in an engagement can be renegotiated later; ownership usually cannot.
Should I ask an AI consultant for references?
Yes, and ask to actually talk to one, not just read a quote. A consultant who has done real work for small businesses should be able to connect you with at least one past client, even if anonymized details are involved for privacy reasons.
Should the first call with an AI consultant be free?
A short first call usually is, and it should be about your business rather than a pitch. By the end you should know whether the consultant understood your problem, what they would do first, and what you would get at the end of it, in writing, before you commit to anything larger.
How do I know if an AI consultant actually understands security?
Ask what happens to your customer data and where it lives once a tool touches it. A consultant who understands security will have a specific answer about data handling and access controls, not a vague reassurance that "everything is safe."
Should training be included in an AI consulting engagement?
Ask directly, because it is often left out of build-focused engagements. A build with nobody on your team able to run or adjust it creates a permanent dependency on the consultant rather than a system your business owns.