Choose an AI consultant by what they have already put into production, not by how well they present. Before you sign, ask them to show you a system that is running, to tell you who will actually do the work, how success will be measured, what you get at the end, and where your data will live. The ten questions below separate, in practice, an engineer from a slide salesman.
Since founding Sapio AI in 2021, I have sat on the other side of the table: I am the one answering these questions. Below is each one, what a good answer sounds like, and the red flag to watch for.
Why choosing an AI consultant is hard right now
"AI consultant" is not a regulated profession. Anyone can put the title on LinkedIn tomorrow, and after ChatGPT launched, many did. And the buyer is usually exactly the person who has no way to check the expertise, which is why they are looking for a consultant in the first place.
The figures say the same thing. Among European companies that considered AI and did not go ahead, 70.3% cite a lack of expertise as the reason (Eurostat, statistical report KS-01-26-009, Table 7, reference year 2025). In Romania, only 5.2% of companies with 10 or more employees used AI in 2025, against 20.0% across the EU (Eurostat). The need for expertise is high, and expertise is hard to verify. In that situation, good questions are the only filter you have.
There is also a trap specific to AI. An impressive demo is easy to make: a few carefully chosen documents, a prepared question, an answer that sounds intelligent. Any effect can be mimicked even in the absence of the cause. A system that answers correctly on your real data, month after month, is the cause. The first you can copy in an afternoon. The second you have to understand, and it is usually where AI projects stall (why AI is not delivering results).
The 10 questions
1. What have you put into production, and can I see it working?
Not a PDF case study, but something that runs today and that you can try. The client's name can be confidential; the problem, the approach and the result cannot. A good answer comes with a link or a person you can call. Red flag: only demos, only logos, only "confidential projects" you learn nothing concrete about.
2. Who will actually do the work?
The person selling is often not the person building. Ask for the name of whoever will write the code and talk to your team, and ask to meet them before you sign. Red flag: "our team", with no names.
3. What do you want to know about my data?
A good consultant asks about data before talking about models: where it lives, in what format, how clean it is, who keeps it up to date. If in the first ten minutes you hear the name of a model or a platform and no questions about data, you are being sold a solution looking for a problem.
4. How will we know it worked?
Ask for a measurable number, agreed in advance: processing time, error rate, hours saved, how often the system is used. And ask for today's value to be written down, or you have nothing to compare against. "It will be more efficient" is not an acceptance criterion.
5. What should we not build?
My favourite question, because it is hard to answer for someone who only wants to sell. Sometimes the solution is a better form, a cleaner spreadsheet or a written rule. A consultant who never tells you "this isn't worth it" cannot help you find out what is.
6. What do we buy off the shelf, and what do we build?
Transcription, generic chat, standard SaaS features: that is where you buy. You build only where the value comes from your own data or process. Red flag: everything gets built from scratch or, at the other extreme, everything is solved by a licence for a platform the consultant resells. Ask directly whether they take commission from any vendor.
7. What do I get at the end, and who owns it?
The code, the trained models, the documentation, access to the infrastructure and, where relevant, the training pipeline. All of it written into the contract. A system you cannot move, change or retrain without the supplier still belongs, in practice, to the supplier.
8. Where will my data live, and who can access it?
Which servers the solution runs on, what data reaches a model provider and in which country, who on the consultant's team can see it. For sensitive data, ask whether the solution can run on your own infrastructure with no internet access. If you are in a regulated field, also ask how the use case fits under the EU AI Act. For law firms and the public sector, this is usually the first question.
9. What does it cost to keep running after launch?
Hosting, the model's per-request cost, keeping the data current, maintenance. Ask for three usage scenarios, not a single figure. I wrote separately about what actually moves the price of an AI project: what an AI consultant costs.
10. What happens if we stop after the first step?
A well-structured project has exit points: after the conversation, after the audit, after each delivery stage. Every step should leave something usable behind, either a roadmap someone else can pick up or a piece of system that works. Red flag: a long contract with monthly payments and no intermediate deliverables.
An example: what a good handover looks like
In 2021–22, working as an ML engineer, I trained what was then the best-performing Romanian speech-to-text model for a client. The model is the part people remember. For question 7, it is the smaller part.
What a client needs in order to carry on without the supplier is the rest: the training pipeline, automated so it can be rerun; the evaluation data that says whether a new version is better; the documentation; and a step-by-step guide the client's own team can follow. Ask for each of those by name, in the contract. A simple test, hypothetical but useful: if the supplier disappeared tomorrow, could your team retrain the system and ship the next version? If not, you bought a dependency, not a system.
To me that is the most honest test of a consultant: are they working towards the moment they are no longer needed?
Any effect can be mimicked even in the absence of the cause. A demo is the effect. A system that works on your data, month after month, is the cause.
AI consultant or AI development company?
If you are really looking for how to choose an AI development company, the questions above apply just the same. The difference is in what you buy. A classic consultant recommends and stops at the roadmap. A development company builds what it is asked to, usually from a specification. Between the two there is often a gap: a roadmap written by someone who does not build, and a specification executed by someone who was not in the room when the problem was discussed.
The safer option is for the person who defines the problem to also understand the implementation. That is how I work: the consulting, and when the answer is "we build", the implementation through Sapio AI. If you would rather your own team built it, the roadmap has to be written so they can pick it up, and the people prepared for it (AI workshops for teams).
The red flags, in short
- A guaranteed ROI percentage, before anyone has seen the data.
- A platform recommended on the first call, before any question about the process.
- Demos only on their data, never on yours.
- No name for the person doing the work.
- A long contract with no intermediate deliverables and no exit points.
- They cannot explain simply what they will build. Usually, someone who cannot explain it does not know it either.
The one question I would keep
If I could keep only one question out of ten, I would keep the fifth. Someone who can tell you what not to build has understood the problem well enough to see where it ends. The rest you can check in the contract.
The paradox is that the best consultant you will ever meet will cost you, at least once, a project: the one they talked you out of.
If you want to put the ten questions to me: vladtudor.com/consulting.