AI makes it easier to produce the outward signs of expertise: a fluent article, a strategy deck, an architecture diagram and a confident proposal. None of those artifacts proves that the person selling the work can handle incomplete data, difficult integrations or a deployment that fails its business case.
You do not need to determine whether an adviser is exaggerating deliberately. You need evidence that they can perform the work you intend to buy, recognize when it is going wrong and leave your organization able to operate what they deliver.
These are the seven questions I would use before committing a substantial budget.
The Problem
1. Which business problem would you start with, and why?
An adviser who recommends an agent or chatbot before understanding the process has already chosen the answer. Ask what they need to learn about the business before they can make a recommendation.
They should investigate where work waits, which errors recur, what the current process costs and who can change it. A credible initial response can contain uncertainty. It should identify what is known, what remains untested and which missing information could alter the recommendation.
Ask what they would improve if you funded only one intervention. “Efficiency” is too vague. A useful answer names a process and a result: fewer reopened cases, a shorter quotation cycle or less manual reconciliation.
The Evidence
2. What have you delivered that people actually used?
A workshop, a prototype and a system in daily use are different deliverables. Any of them may be worth buying, but evidence of one does not establish the ability to deliver the others.
Ask for a relevant example and separate the person’s contribution from the team’s. What did they design or decide? Who did the integration? What did the client have to supply? What happened after the demonstration?
The difficult parts matter most. Missing records, unclear ownership and user resistance reveal more about delivery capability than a rehearsed happy path.
Confidentiality may prevent naming a client. It need not prevent discussion of the problem, the work performed or an appropriately anonymized artifact. Evidence should match the proposed engagement; a good presenter is not automatically a capable implementation lead.
Accountability
3. When do we discuss data, controls and accountability?
These questions belong in discovery because they can change the feasibility and cost of the work.
The adviser should ask whether the data can be used for the intended purpose, who may access it, what errors are acceptable and who can stop the process. If a customer-facing system is proposed, they should be interested in what it is allowed to say and how a person takes over when needed.
“The platform handles compliance” is insufficient. A platform’s features still have to be configured, integrated and operated within your business.
The proposal should distinguish responsibilities retained by your team from work the adviser will perform. Our article on why AI pilots fail to become products develops the ownership problem: someone has to fund and maintain the data, the operation and the changed workflow after the project team leaves.
The Incentives
4. When would you recommend that we do not use AI?
This question tests whether the adviser can recognize a solution that does not create a sale for them.
Ask for a concrete situation in which process simplification, conventional automation or a better connection between existing systems would be preferable. Then ask what would have to change for AI to become worthwhile.
Understand how the adviser makes money. Subscription commission, implementation fees, proprietary software and ongoing support can influence a recommendation. These are legitimate business models, but the incentives should be visible.
THE THROUGH-LINE
Independence is something to examine in the engagement, not a quality established by the word “independent” on a website.
The Failure
5. Tell me about a project that went wrong
An experienced adviser should be able to discuss a material assumption that failed or an approach that had to change. They may protect identities while still explaining the decision.
Ask when the problem became visible, what evidence challenged the original plan, how it was communicated and what spending was stopped. Listen for their own responsibility rather than an account in which the client, the technology and the users were always at fault.
An adviser with limited experience can say so honestly. The concern is a universal success claim that cannot survive a definition of success.
For your project, you need someone who will tell you that a promising direction has become a poor investment before the entire budget has been spent.
The Delivery
6. What exactly will be ready by the date you promise?
“Working in a month” is ambiguous. It could mean a demonstration, a limited trial, a connected production system or a service your own team can operate.
Ask the adviser to separate those milestones. Each should have a deliverable, an owner, dependencies and a condition for acceptance. Your team’s time and access requirements belong beside the supplier’s commitments.
Define the point at which evidence justifies further spending. If the first stage cannot test the assumption that makes the investment worthwhile, an early delivery date may offer little protection.
Speed has value when you know what is becoming usable and what remains unfinished.
The Handover
7. What will we control when the engagement ends?
Ask who will hold the accounts, documentation, configuration and operational knowledge. Establish who can monitor quality and cost, respond to failures and engage another supplier if necessary.
Ownership of source code is only part of the answer. A system can remain difficult to operate without the original adviser because nobody else understands its data transformations, prompts, evaluation examples or undocumented exceptions.
The handover should be planned as work, with evidence that your team can perform its responsibilities. A folder of documents delivered on the final day is not a demonstration of operational readiness.
Ongoing support may be the right commercial choice. It should be chosen knowingly, with clear scope and exit terms, rather than discovered as an unavoidable dependency after delivery.
The Call
Turn the answers into terms you can review
Good answers in a meeting are a starting point. Put the material commitments into the scope of work and the appropriate agreement.
Record the result to be delivered, what is excluded, the baseline and acceptance method, responsibilities on both sides, conditions for further spending and the handover. Have the contractual allocation reviewed for the engagement; a generic template cannot settle every ownership or liability question.
Where evidence remains thin, a bounded paid assessment may be a better first purchase than a full implementation. It should produce a decision you can use even if you choose not to retain that adviser.
The strongest candidate is the one whose explanation helps you judge the work before you buy it. By the end of the conversation, you should understand what could improve, what could fail, what evidence is still missing and what the company will have to own.