The 7 questions to ask before signing with an AI provider
Seven questions are enough to separate an AI provider who knows what they deliver from a tool reseller: where your data goes, a comparable delivery already made elsewhere, what happens when the model gets it wrong, the running cost once the project is delivered, who owns what has been built, who will really use it, and what the provider refuses to do. None of them takes technical expertise to ask. They only take listening to the answer — and noticing which one gets none.
An artificial intelligence project rarely fails on the technology. It fails because the data was not where people thought, because no one planned how the system would behave when it gets things wrong, because the monthly running bill had not been costed, or because the tool delivered was never used by the people it was meant for. All four causes can be seen before signing, provided you ask the question that uncovers them.
The seven questions below are ordered by how much damage they do if the answer is missing. Each comes with what a good answer contains, and with the signal that should make you slow down. They apply to a freelancer as much as to an agency — the choice between the two is made beforehand, on other criteria.
Most AI services send your data outside your company: it goes through the programming interface of a model publisher — Anthropic, OpenAI, Mistral, Google — hosted somewhere, operated under terms you have not signed. That is not a problem in itself. It becomes one when no one can say so.
A good answer contains the name of the model publisher, the hosting region, the retention period, an explicit statement of whether or not your content is used to train the model — on the major publishers’ business offers, it generally is not — and the list of subcontractors involved along the way.
The warning sign: “it’s secure”, “it’s hosted with us”, without a single name being mentioned. Many tools sold as in-house are resold layers on top of someone else’s; ignoring that means discovering mid-project that your documents pass through a fourth party you had never heard of.
This is not a request for references in the sales sense. It is a request for a comparable delivery: a system of the same kind, in service, somewhere, for long enough to know what it has changed.
A good answer contains a client name, or — if a confidentiality agreement forbids it — a live demonstration on a real case, with the go-live date, the number of people using it, and what has been measured since. A provider who has delivered can tell you what did not work the first time.
The warning sign: screenshots, an anonymous case study, a demo built for the meeting. Our directory publishes 399 profiles; of the 150 we collected up to 1 September 2026, 18 show at least one named client reference — we only list it when the provider displays it publicly themselves, never on their say-so. That is exactly the level of proof you can demand.
A system built on a language model gets things wrong. Not sometimes: by design. So the question is never “does it get things wrong”, but “what is planned for when it does”. It is the question that most clearly separates a provider who has put a system into production from a provider who has given demos.
A good answer contains an error rate measured on a set of test cases you can review, the planned behaviour when in doubt — handing over to a human, declining to answer, flagging uncertainty rather than making something up — and who monitors all of this once the project is delivered.
The warning sign: “our model doesn’t make mistakes”, or “we have a very solid prompt”. The second is more worrying than the first: it confuses tuning an instruction with a control system.
The quote prices the build. It almost never prices what the system costs afterwards: usage of the programming interface, hosting, monitoring, and the rework needed when the model publisher releases a version that changes its behaviour. On projects that go off the rails, that is the line people discover in the third month.
A good answer contains an estimated monthly cost with the volume assumption that goes with it, and what that cost becomes if the volume doubles. Our budget simulator keeps those two lines separate; on a time-and-materials basis, the day-rate benchmark runs from €300 to €700 excl. VAT depending on seniority, detailed in our day-rate barometer.
The warning sign: a build quote with no running-cost line at all, or an “all-inclusive” monthly fee whose contents no one can spell out.
An AI project leaves behind code, written instructions, sometimes a model tuned on your data, and a series of accounts opened with publishers. Knowing who owns all of that is a matter of contract, not of trust — and it has to be raised beforehand, because afterwards you raise it from a position of weakness.
A good answer contains: it is written into the contract, the accounts with the publishers are opened in your name, and there is an exit procedure — data export, handover of the code, transfer of access — that the provider can describe without hesitating.
The warning sign: the accounts are in the provider’s name, the work lives “on our platform”, and no export is planned. You are no longer renting a service: you become dependent on an intermediary to access your own data.
The most common cause of failure is not technical. It is a tool that works and that no one opens, because it was designed with management and delivered to teams who had never heard of it. A provider who never asks about usage is selling a delivery, not a result.
A good answer contains the roles concerned, by name; training planned and costed in the proposal; and a way of checking adoption at three months — number of active users, time actually saved, anything countable. Training your teams is a deliverable in its own right, not an end-of-project courtesy.
The warning sign: the schedule stops at delivery.
It is the shortest question and the most revealing. A provider who has been practising for a while has turned down requests: because AI was not the right tool, because the data did not exist, because the budget did not allow the work to be done properly. If they have never turned anything down, there are only two possibilities — they are just starting out, or they accept everything.
A good answer contains a specific case, with the reason for the refusal. The best answers often begin with “we get asked for that a lot, and we say no because…”.
The warning sign: “we can do everything”. No one can do everything, and AI is precisely the field where you will be promised it most readily.
“Which model do you use?” It sounds technical, it reassures the person asking, and it teaches you almost nothing. Models change every few months, a good provider switches when it is justified, and the name of the model says nothing about the quality of what is built around it — which is most of the work. The useful question, if the subject interests you, is number 1: who is the publisher, and where does the data go.
If your project is about visibility — organic search, being cited in the answers of ChatGPT or Perplexity — six more questions apply, specific to that field: we set them out in our explainer on the term “AI SEO agency”.
- Where does my data go, and who can read it?
- Show me the same thing, already delivered elsewhere.
- What happens when it gets things wrong?
- How much does it cost to run, once delivered?
- Who owns what is built, and how do I take back control?
- Who is going to use it, and who trains them?
- What do you refuse to do?
Asked in this order, they fit into a first meeting. The one that goes unanswered says more than the other six put together.
Do you need a specification before consulting an AI provider?
Not in the traditional sense, and trying to write one before talking to anyone often delays the project by several months. What you need at the first meeting: the problem described on one page, the data you actually have, who will use the result, and a budget envelope. A competent provider builds the scoping with you — if they insist on a detailed specification before answering, they are selling execution, not advice.
How many providers should you consult?
Two or three are enough, and the point is not to compare prices. Three proposals for the same need mainly reveal that the need is not understood in the same way: it is that gap that teaches you something, far more than the gap between amounts.
How do you check that an AI provider is serious?
By what they have delivered, not by what they announce: a named, verifiable project, a precise answer on data handling, and a refusal they stand by somewhere in their track record. Publisher certifications can be checked at the source. Each profile in our directory shows what we were able to observe publicly, and our transparency page says what we do not check.
Can a provider guarantee a result on an AI project?
On a deliverable, yes: a system in service, an integration that works, a trained team. On a quantified performance — “30% time saved” — be wary of a commitment made before your data has been seen. A serious commitment is made after a short, paid scoping phase, on test cases you have approved.
You have the project, but not the provider?
Describe your project in a few lines: we identify the providers in the directory whose deliverables match, and we introduce them to you. Free for the company, whether you hire someone or not.