How to Hire an AI Consultant: 7 Questions to Ask Before You Sign
I have been on both sides of this conversation — as the consultant being evaluated and as the architect assessing other consultants for clients. These are the seven questions my best clients ask me, and what their answers reveal about the person sitting across from you.
Hiring an AI consultant is one of the highest-leverage decisions a company makes — and one of the easiest to get wrong. The gap between a consultant who ships production systems and one who delivers polished slide decks is enormous, but from the outside they can look identical. Both have impressive websites. Both drop the right buzzwords. Both will tell you they can deliver.
I have been on both sides of this. I have sat in rooms being evaluated by CTOs, founders, and procurement teams. I have also been the person clients call after their first consultant delivered something that fell apart in production. After 12+ production AI systems, I have noticed a clear pattern: the clients who ask the best questions end up with the best outcomes. Not because the questions are trick questions — but because they force the consultant to reveal what they actually know versus what they have memorised from a marketing page.
Here are the seven questions my best clients ask me. I am going to tell you exactly why each question matters, what a strong answer sounds like, and what should send you running.
1. “Show Me a System You Built That's Still Running in Production”
This is the single most important question you can ask, and it should come first. Not “show me your portfolio” or “tell me about your experience.” Specifically: show me something still running, serving real users, in a real business.
Why It Matters
Building an AI demo takes a weekend. Building an AI system that survives contact with production data, handles edge cases gracefully, scales under load, and keeps running reliably for months or years — that is an entirely different discipline. The gap between demo and production is where 80% of AI project budgets get burned, and it is the gap that separates experienced consultants from enthusiastic experimenters.
When I built a 12-component RAG system that achieved 96.8% accuracy, the demo version worked in week one. The production version — with custom chunking, hybrid search, citation tracking, error recovery, and monitoring — took another six weeks. That is normal. That is what production means.
What a Good Answer Looks Like
A strong consultant will name specific systems, describe their architecture, explain the hard problems they solved, and ideally show you something live or offer a reference client who can confirm the system is running. They will talk about the unglamorous parts — monitoring, error handling, data pipelines — because those are the parts that keep systems alive.
Red Flags
- They only show demos, prototypes, or proof-of-concept work that never shipped.
- Every example is “confidential” with no way to verify any claims.
- They cannot explain how their system handles failures, edge cases, or unexpected inputs.
- Their portfolio is all GitHub repos and Jupyter notebooks with no deployed URLs, case studies, or reference clients.
2. “What Does Your Discovery Process Look Like?”
This question tells you whether the consultant builds solutions around your problem or sells you a pre-built hammer and calls everything a nail.
Why It Matters
Every meaningful AI project starts with understanding the problem deeply — the data landscape, the business constraints, the existing workflows, the success criteria, and the failure modes. A consultant who skips this phase will build the wrong thing efficiently, which is worse than building the right thing slowly. I have written extensively about why AI projects fail, and insufficient discovery is near the top of that list.
My discovery process runs 90–120 minutes minimum for a focused engagement, and often spans multiple sessions for complex projects. That is not because I enjoy meetings — it is because the questions I need answered before I can responsibly propose a solution require that depth.
What a Good Answer Looks Like
The consultant should describe a structured process: how they assess your data, how they understand your business context, how they identify risks early, and how discovery feeds directly into architecture decisions. They should mention looking at your actual data — not just hearing you describe it — because data is always messier than the description suggests.
Red Flags
- They quote a price and timeline before understanding your problem, data, or constraints.
- Discovery is a 30-minute sales call where they mostly talk about themselves.
- They do not ask to see your data, existing systems, or current workflows.
- The “discovery” output is a proposal template with your company name swapped in.
3. “How Do You Handle It When AI Isn't the Right Solution?”
This is the honesty test. It separates consultants who are invested in your outcome from those who are invested in selling you AI regardless of whether you need it.
Why It Matters
Not every problem needs AI. Sometimes a well-designed database query, a simple rules engine, or a better-structured spreadsheet solves the problem at a fraction of the cost and complexity. I have talked clients out of AI projects — genuine, paying engagements — because the simpler solution was clearly better. That is not charity; it is professional integrity, and it is why those clients come back when they do have a problem that genuinely needs AI.
An AI consultant who has never recommended against AI either has not done enough engagements to encounter the situation, or they are not being honest with their clients.
What a Good Answer Looks Like
They should have a specific example — a time they recommended against AI and what they suggested instead. They should be able to articulate their decision framework: what conditions need to be true for AI to be the right approach, and what signals suggest a simpler solution. They should frame a negative recommendation as a success, not a lost sale, because saving the client $50,000 on a system they do not need builds more trust than any deliverable ever could.
Red Flags
- They have never recommended against AI. Every problem they encounter happens to need exactly what they sell.
- They get uncomfortable or defensive when you ask this question.
- Their answer is theoretical (“we would, hypothetically”) rather than experiential (“last quarter, we told a client…”).
4. “What's Your Approach to Data Privacy and Compliance?”
AI systems process your most sensitive data — customer records, financial documents, internal communications, proprietary business logic. How a consultant handles that data tells you everything about their professionalism and production experience.
Why It Matters
A data breach or compliance violation from an AI system you deployed is your liability, not the consultant's. If your AI chatbot leaks customer PII because the consultant did not implement proper data sanitisation, you are the one explaining it to regulators and customers. This is not a theoretical risk — I have seen production AI systems built by other consultants that sent raw customer data to third-party LLM APIs with no anonymisation, no data processing agreements, and no awareness that this might be a problem.
What a Good Answer Looks Like
They should walk you through their data handling practices at each stage: what data leaves your environment, what gets sent to LLM providers, how they handle PII, what their approach to data retention is, and how they ensure compliance with regulations relevant to your industry (GDPR, PDPA, SOC 2, HIPAA, or whatever applies). They should mention specific technical controls — data anonymisation pipelines, private deployment options, audit logging — not just policy statements.
Red Flags
- They have not thought about where your data goes when it hits an LLM API.
- “We use OpenAI” is their entire data privacy strategy, with no mention of enterprise agreements, data processing addendums, or regional hosting.
- They cannot name the specific regulations that apply to your industry.
- They brush off the question as “handled by the cloud provider.”
5. “Can You Break This Into a Pilot Before We Commit to the Full Build?”
This question tests whether the consultant is optimising for your risk reduction or their revenue maximisation.
Why It Matters
The pilot-first approach is the single biggest cost-saving strategy in AI implementation. I have written about this in detail in my AI consulting cost guide — starting with a $5,000–$12,000 pilot instead of committing to a full build upfront typically saves 60–80% in total project cost. The pilot proves feasibility on your actual data, identifies the real challenges, and gives you a precise scope for the full engagement.
Any consultant who resists breaking work into a pilot phase is either afraid their approach will not survive contact with your real data, or they are optimising for a larger initial contract rather than your best outcome.
What a Good Answer Looks Like
“Absolutely. Here is how I structure pilots” — followed by specifics on timeline (2–4 weeks), deliverables (working prototype on your data, technical assessment, precise scope for full build), cost ($5,000–$12,000), and clear go/no-go criteria. The best consultants proactively suggest pilots rather than waiting for you to ask.
Red Flags
- They push for a full engagement upfront and resist phased delivery.
- The “pilot” is just phase one of a pre-determined plan with no real off-ramp if it does not work.
- They cannot define what “success” looks like for the pilot in measurable terms.
- The pilot costs more than $15,000 — at that point, it is not a pilot; it is a project with a different label.
6. “What Happens After You Leave? Who Maintains This?”
This is the question that separates a consultant building a long-term asset for your business from one building a dependency on themselves.
Why It Matters
AI systems are not “build and forget.” LLM providers release new models quarterly. Your data changes. Your business requirements evolve. Security vulnerabilities emerge. Someone needs to maintain, monitor, and improve the system after the consultant's engagement ends. If your AI project does not have a clear architecture and handover plan, you are one resignation or contract expiry away from a system nobody can maintain.
When I deliver a system, my explicit goal is to make myself unnecessary. That means comprehensive documentation, training for your team, clean architecture that your developers can understand and extend, and a handover period where I am available for questions. This is what a fractional AI CTO engagement is designed around — building capability, not dependency.
What a Good Answer Looks Like
They should describe a structured handover process: documentation standards, knowledge transfer sessions, a support window after delivery, and clear ownership transfer. They should ask about your internal team's capabilities and tailor the handover to your actual situation. If you do not have internal AI expertise, they should discuss options for ongoing support without locking you in.
Red Flags
- The system requires their proprietary tools, frameworks, or platforms to operate.
- Documentation is an afterthought or an optional add-on at extra cost.
- Their answer to “who maintains this?” is essentially “you will need to keep paying us.”
- They have no plan for knowledge transfer and assume their involvement is permanent.
7. “What Will This Cost, and How Do You Charge?”
This sounds basic, but the way a consultant answers this question reveals more about their experience and integrity than almost anything else.
Why It Matters
AI project costs are genuinely complex. The build cost is only part of the picture — there are ongoing LLM API costs, infrastructure, maintenance, and change management to account for. A consultant who gives you a single number without context is either simplifying dangerously or deliberately hiding the full cost picture. I break all of this down in my complete AI consulting cost guide, but here is what to listen for in the conversation.
What a Good Answer Looks Like
Transparency and structure. They should explain their pricing model (fixed-price, time-and-materials, or hybrid), what is included, what is not, and what the ongoing costs will look like after delivery. They should break costs into phases — discovery, pilot, build, handover — so you can make informed decisions at each stage. They should proactively mention LLM API costs, infrastructure, and maintenance rather than waiting for you to ask.
A strong answer sounds like: “The pilot will cost $X over Y weeks. Based on what we learn, the full build will likely fall in the $A–$B range. Ongoing costs after delivery will be approximately $C per month for LLM APIs and infrastructure, plus $D annually for maintenance and updates. Here is how I arrive at those numbers.”
Red Flags
- They quote a suspiciously low number with no mention of ongoing costs. A “$2,000 AI system” is a ChatGPT wrapper with a system prompt, not a production solution.
- They give a firm price before understanding your data, requirements, or constraints.
- The pricing model is opaque — you cannot tell what you are paying for or why.
- There is no mention of LLM API costs, infrastructure, or maintenance in the proposal.
- They resist phased pricing and want full payment commitment before discovery is complete.
How to Use These Questions Effectively
These seven questions work best when you treat them as a conversation, not an interrogation. The goal is not to catch a consultant out — it is to understand how they think, how they have handled real challenges, and whether their approach aligns with what your project needs.
A few practical tips from being on the receiving end:
- Ask them early in the conversation. Do not wait until you are emotionally committed to a consultant before doing due diligence. These questions belong in the first or second meeting, not the final negotiation.
- Listen for specifics, not generalities. “We handle data privacy very seriously” means nothing. “We use Azure OpenAI with a data processing addendum, implement PII detection before data leaves your environment, and deploy within your cloud tenancy” means something.
- Watch for discomfort. Good consultants welcome hard questions because they have good answers. If someone gets defensive, evasive, or tries to redirect to a sales pitch, that tells you something important.
- Compare answers across consultants. If you are evaluating multiple options, ask everyone the same seven questions. The differences in depth, specificity, and honesty will become obvious very quickly.
The Meta-Question: Does This Consultant Make Me Smarter?
Beyond the seven specific questions, there is one overarching test I would apply to any AI consultant: after talking to them for an hour, do you understand your problem better than you did before?
The best consultants do not just sell you a solution. They educate you. They help you see your problem more clearly, understand the trade-offs, and make better decisions — even if you ultimately hire someone else. That is because their value is not in hoarding knowledge; it is in applying it to your specific context in a way nobody else can.
If a consultant leaves you more confused than when you started, or if their explanation of your project relies heavily on jargon you cannot verify, they are either not as experienced as they claim or they are deliberately keeping you in the dark to maintain leverage. Neither is acceptable.
The right AI consultant will feel like a trusted advisor from the first conversation — someone who is genuinely trying to figure out whether they can help you, not someone trying to close a deal. That is the person you want building your AI systems.
See How I Answer These Questions
Book a free 30-minute discovery call. Ask me all seven — and anything else on your mind. No pitch, no pressure. If I am not the right fit, I will tell you.
Book Your Free Discovery CallRead Next
Ready to discuss your AI project?
Book a free 30-minute discovery call to explore how AI can transform your business. Or if you already have a codebase, get an instant architecture report at SystemAudit.dev — no technical knowledge needed, results in 3 minutes.