There is a specific kind of failure that AI projects have. It is not that the technology does not work — the demo usually works beautifully. It is that the demo and the production system are different objects, and almost all the cost is in the second one. A pilot proves that a model can do something once, under conditions someone chose. Production requires it to do that thing forty times a day, on inputs nobody chose, while a business depends on the result.
Below are five checks we apply before calling anything ready. They are unglamorous, and they are the difference between a project that ships and one that quietly stops being mentioned in status meetings.
1. Does it have an evaluation set built from real cases?
The single most reliable predictor of whether an AI system reaches production is whether anyone can say how well it works. Not "it looks good" — a number, on a fixed set of cases, agreed before launch.
Twenty to fifty real cases with known correct answers is enough to start. Build it from the messy inputs, not the clean export: the scanned invoice at an angle, the email with the question buried in the third paragraph, the record with the field somebody used for something else. Then re-run it on every change. Without this you cannot tell whether last week's prompt tuning helped or hurt, and neither can anyone else.
2. Is there a designed path for the cases it gets wrong?
Every AI system is wrong sometimes. The question is what happens next. Pilots typically have no answer, because in a demo the interesting cases are the ones that work.
We design the exception path first: a confidence threshold, a review queue, and a person who sees the uncertain cases before they cause anything. Then we automate the volume around it. Roughly speaking we aim for the large majority to run straight through and a single-digit percentage to reach a human — but the exact split is a dial you own, and starting conservative costs almost nothing.
A system that is allowed to say "I do not know" is far more useful than one that is confident all the time, and it is also far easier to get approved.
3. Does it live where the work already happens?
A tool your team has to leave their actual tools to use will be used for two weeks. Integration is not the boring part after the AI part — for most projects it is the majority of the engineering, and it is where the value actually lands.
Concretely: the output has to arrive in the CRM, the ERP, the ticketing system or the shared inbox that people already open. That means authentication, permissions, rate limits, retries, idempotency and an audit trail. None of it is glamorous and all of it is load-bearing.
4. Will it tell you when it stops?
A silent automation is worse than a manual process, because a manual process visibly stops and a silent one does not. We have inherited systems that had been failing for weeks with nobody aware, and in every case the fix was five lines of alerting that were never written.
- Retries with backoff on every external call
- Idempotency, so a retry cannot double-post a record
- An alert when the queue stops draining, not just when the process crashes
- A dashboard someone actually looks at, or a message in the channel they already read
5. Is the first release narrow enough to survive?
The instinct after a successful pilot is to widen scope. It is almost always the wrong move. Real usage surfaces cases the test set missed, and it surfaces them fastest when the surface area is small.
We ship the narrow version — one document type, one intent, one team — and spend the following weeks on what reality exposes. Most systems improve substantially in the six weeks after launch, and that improvement is only possible if the thing is live and small enough to change quickly.
The uncomfortable check
There is a sixth question, and it is the one that saves the most money: should this be built with AI at all?
A meaningful share of the problems brought to us are better solved by a scheduled job, a fixed integration or a corrected process. Those are cheaper to build, cheaper to run, and far less likely to surprise anyone. A pilot that ends with "this should be a database view" is a successful pilot, and it is a great deal cheaper than the alternative.
“The distance between something that works in a meeting and something that works on a Tuesday afternoon with real data is where most AI budgets disappear.”
Questions this raises
- How long should an AI proof of concept take?
- Days, not quarters. If a narrow proof against real data cannot be built in about a week, the scope is too wide or the data is not available yet — and both of those are worth discovering before a budget is committed.
- What accuracy is good enough to go live?
- It depends entirely on what happens when the system is wrong. A system with a confidence threshold and a review queue can go live at an accuracy that would be unacceptable for one making decisions unsupervised. Design the failure path first, then the accuracy target follows from it.
- Should we fine-tune a model or use retrieval?
- For most business use cases, retrieval first. It is cheaper, the sources are auditable, and updating knowledge means updating documents rather than retraining. Fine-tuning earns its place when you need a consistent format or behaviour that prompting cannot hold reliably.
Related services
Next note
The EU AI Act in practice: a compliance checklist for businesses that use AI
Most of what the Regulation asks for is engineering, not legal work. Here is the checklist we run before any AI system we build goes live — and the reason each item is cheap now and expensive later.