Why most AI programmes stall before production
The failure is rarely the model. It is that the workflow was never written down, or the data the model reasons over disagrees with itself. An AI system reading inconsistent records does not hesitate the way a person does — it produces a confident answer built on the inconsistency, faster than anyone can check it.
The second common failure is scope. Teams pick the interesting problem, and interesting almost always means variable. Variance is exactly where AI systems fail publicly: the demo works because the demo used the clean case, and production contains the other forty percent. The workflows that survive are high volume and low variance, which sound boring and are the ones that reach production.
The architecture decision that determines everything after it
The choice is not public model versus private model. It is whether you build a routing layer at all. Committing the whole organisation to one provider means the next price change, terms change or capability change is a migration rather than a configuration edit — and in this market those happen on a timescale measured in months.
The architecture that survives a contract review sends each request to the appropriate model based on what the data is, not on what was decided at kickoff. Public frontier models for anything that could appear in a press release; private or self-hosted for regulated and contractually restricted material. The classification takes an afternoon and it is the thing that makes the decision reversible.
| Public frontier model | Strongest reasoning, lowest cost to start, no infrastructure. Right for public and internal-only data. Switching cost is low behind a routing layer. |
|---|---|
| Private or self-hosted | Behind the frontier but closing. Data never leaves your boundary, which makes it defensible by construction rather than by a vendor's current terms. Right for regulated or contractually restricted material. |
| Routing layer across both | The decision made per request rather than per company. Costs one engineering component and converts every future provider change from a migration into a configuration edit. |
| Single-provider commitment | Fastest to stand up and the most expensive to unwind. Defensible only when one provider is the requirement rather than the convenience. |
What has to be true before the first deployment
- The workflow is written down as steps a new hire could follow. If it cannot be written down, it cannot be automated — the ambiguity does not disappear, it just moves into the model.
- The data the workflow depends on has a known error rate. Pull fifty records and count the missing, stale and contradictory fields. Above roughly ten percent, fix the data first.
- There is a baseline: what the workflow costs in hours today and how often it goes wrong. Without both numbers the pilot cannot be shown to have worked, and a pilot that cannot be shown to have worked does not get funded into production.
- Someone owns consumption spend. Usage-based pricing has no natural ceiling, and an unowned budget is the most predictable way for a successful pilot to become an unpleasant invoice.
- A stop condition is written down before go-live. Programmes without one consume budget well past the point the evidence stopped supporting them.
- Every output reaching a customer, a financial record or a regulated artefact passes a person. That is the design, not a maturity stage to graduate out of.
What the first ninety days look like
Weeks one to three: pick the workflow and measure it. Not the interesting one — the high-volume, low-variance one with a number attached. Record the current cost in hours and the current error rate, because everything afterwards is judged against those two figures.
Weeks four to eight: build narrowly and instrument heavily. One workflow, explicit tool boundaries, human review at every consequential step, and logging that records what the system decided and why rather than merely that it ran. The goal at this stage is evidence, not coverage.
Weeks nine to twelve: measure against the baseline and decide honestly. Expand only where the evidence supports it. A programme that expands on enthusiasm rather than measurement is how organisations end up with six pilots and nothing in production.
Where we tell clients not to use AI
When the underlying data is unreliable and nobody is willing to own fixing it. The system will apply every inconsistency at machine speed and with more confidence than a person would, which converts a data problem into a customer-facing one.
When the goal is to demonstrate AI capability rather than to move a specific number. That is a demo, and demos do not survive contact with a budget review.
When the workflow has more exceptions than rules. Agents amplify ambiguity; they do not resolve it. A process with a long tail of special cases needs the process fixed first, and often the process fix delivers most of the value on its own.
When there is no appetite for the review step. AI that acts without human review at consequence points is not a faster version of the same process — it is a different risk profile, and it should be chosen deliberately rather than arrived at.