An enterprise AI adoption playbook that survives contact with reality
30 June 2026 · 8 min read · Nintech Advisory
Most enterprise AI programmes do not fail because the models are bad. They fail because the organisation started with a technology and went looking for a problem, then discovered eighteen months later that nobody could say what the technology was for. The playbook that survives contact with reality inverts this: it starts with a business problem that has a number attached, and it treats the model as the least interesting part of the system.
Start with a number, not a model
A viable AI project begins with a sentence like this: our claims handlers spend forty minutes per claim on document triage, we process 900 claims a week, and each minute costs us roughly £0.80 in fully loaded staff time. That sentence gives you a baseline, a volume, and a unit cost — which means you can compute, before writing a line of code, what a 50% reduction is worth and therefore what the project is allowed to cost. Compare that with the more common starting point, 'we should be doing something with LLMs', which gives you no way to know when you are done or whether it worked.
The discipline this imposes is unglamorous but decisive. It forces you to pick problems where the current process is measurable, which usually means high-volume, repetitive work with an observable output: triage, extraction, classification, first-draft generation, routing. It also rules out the seductive projects — the strategy copilots and insight engines — where nobody can articulate the counterfactual. If you cannot describe what the team does today in numbers, you will not be able to prove the AI version is better, and 'we cannot prove it is better' is how budgets die.
Pilot purgatory and the data gate
The characteristic failure mode of enterprise AI is not the failed pilot; it is the successful pilot that never ships. The demo works on fifty hand-picked documents, the steering committee applauds, and then the project stalls for a year because production means touching the real document store — the one with seven formats, no consistent metadata, PII scattered through free-text fields, and an access model nobody fully understands. The pilot succeeded precisely because it was allowed to skip all of that. Pilot purgatory is what happens when an organisation keeps funding demos to avoid confronting its data.
Data readiness is therefore the real gate, and it should be assessed before the pilot, not after. The questions are concrete: where does the input data actually live, who owns it, what fraction of records are complete enough to process, what is the retention and residency position, and can a production service get access under the existing security model or does that require a six-month exception process? A useful heuristic: if the answer to 'can we get a representative sample of 10,000 real records into a test environment within two weeks' is no, you do not have an AI project yet — you have a data engineering project, and pretending otherwise just defers the cost.
Evaluate before you roll out, not after
Traditional software either passes its tests or it does not. Model-backed systems are probabilistic: the same pipeline that extracts invoice totals correctly 96% of the time will confidently produce a wrong number the other 4%, and no amount of code review will find those cases. The only defence is a written evaluation harness — a held-out set of real inputs with known-correct outputs, scored automatically, run on every prompt change, model upgrade, and retrieval tweak. Without it, every change is a guess, and vendor model updates become silent regressions in production.
The harness also answers the question executives actually care about: what error rate is acceptable, and what happens when the system is wrong? A 4% error rate is fine when a human reviews every output and correcting a mistake takes seconds; it is catastrophic when the output feeds straight into a payment run. This is where the human-in-the-loop design gets decided — not as a philosophical stance, but as arithmetic on error cost times error frequency. Teams that skip this step discover their risk appetite empirically, in production, which is the expensive way.
Trust is an operational property
The staff who are supposed to use the system can kill it faster than any technical failure, and they usually have good reasons. If the tool is wrong in ways that embarrass them in front of customers, they will quietly stop using it and revert to the old process, and your adoption metrics will show usage collapsing around week six. The fix is not an internal comms campaign. It is designing the system so that its confidence is legible — showing sources, flagging low-certainty outputs for review rather than presenting everything with the same synthetic authority — and giving users a one-click way to correct it that visibly feeds back into the system.
It also means being honest about what changes for people's jobs. If the stated plan is 'this frees you up for higher-value work' but the actual plan is headcount reduction, staff will work that out long before the town hall, and they will train the system to fail. Organisations that have adopted AI successfully tend to have made a specific, credible commitment about what happens to the time saved — and then kept it for long enough that the second and third projects inherit trust rather than starting from suspicion.
Measure honestly, kill ruthlessly
ROI measurement for AI projects has a strong pull towards theatre: counting 'time saved' from self-reported surveys, valuing every generated draft as if it replaced a consultant, ignoring the review time humans now spend checking outputs. The honest version goes back to the baseline number from the start of the project and measures the same thing again: minutes per claim, cost per ticket, cycle time per contract. Include the new costs — inference, the platform team, the review overhead, the evaluation harness maintenance — because a system that saves £200k of handler time while consuming £150k of engineering attention is a much more modest success than the slide deck claims.
And some projects will simply not clear the bar. A portfolio approach only works if the failing projects actually get killed: a review every quarter against the original number, with a pre-agreed threshold below which the project stops. This is culturally hard, because by the time a project is failing it has an executive sponsor, a team, and a narrative. But the alternative is worse — a growing museum of half-adopted AI tools, each consuming maintenance and licence spend, collectively poisoning the well for the projects that would have worked. The organisations getting genuine returns are not the ones with the most AI projects. They are the ones with the fewest zombies.
Working on something like this? Talk to an engineer.