What breaks in enterprise AI transformation programs.

Enterprise AI programs rarely fail in the model layer. They fail in the joints — between the working pilot and the org that has to absorb it. Five failure modes show up almost every time. Knowing them in advance is most of the fight.

1. The pilot succeeded against the wrong metric

The team picked a metric the pilot could move (accuracy on a held-out set) instead of the metric the business cares about (handling time, first-contact resolution, refund rate). The pilot lands; the business doesn't notice; funding evaporates at re-budgeting.

Get the operating metric agreed in writing before the first sprint. The sponsor signs it.

2. There is no operator owner

Programs led entirely from a transformation office, with no line owner whose KPI moves, get euthanised quietly. The fix isn't a steering committee — it's making sure a real operator's bonus depends on the outcome, and making sure they know it on day one.

3. Procurement and security arrive last

The program assumes a green light from InfoSec, Privacy, and Procurement and discovers in week 11 that the chosen vendor is unapprovable, the data residency is wrong, or the contract terms are not negotiable. The program loses a quarter rebuilding around constraints that should have framed the design.

• Bring InfoSec to the design review, not the launch review.
• Pre-clear the data classes the system will touch, not the system itself.
• Treat procurement as a stakeholder with veto, not a back-office function.

4. Evals were a launch artefact, not a habit

The eval suite was built once, run at go-live, and never opened again. Three months in, behaviour has drifted, complaints are up, and nobody can answer "is the system getting worse?" with anything other than a guess. Evals only count if they run continuously, against real traffic samples, with regression alerts.

5. The change story was a launch email

Operators were told the system existed; they weren't shown how it changes their day, what they're now responsible for that they weren't, and what is now off their plate. Adoption stalls. The program is judged on usage — usage was a change-management problem, not a model problem.

Every program we've shipped that stuck had a named change owner with the same authority as the technical lead. None of the programs that died did.

The pattern under the pattern

All five failures share a shape: the technical work succeeded; the operating system around it didn't change to absorb the success. AI transformation is, mostly, an operating-model project that happens to ship some software. Get the operating model right and the model layer is easy. Get the operating model wrong and no model will save you.