Why most company AI rollouts fail

Most companies that fail with AI do not fail for the reason they think. The model was fine. The demos were great. Six months later nobody opens the thing, and the postmortem blames the technology because the technology cannot argue back.

I run the AI function at a manufacturer, I have shipped four production systems for four businesses, and I have watched the same two failures kill rollouts everywhere: context failure, the system never actually knew the company’s facts, and trust failure, nobody believed the output enough to send it without redoing it. Everything else is a symptom of those two. Here are three failures I can show rather than describe, each with the mechanical fix it produced.

Failure one: the tool nobody asked for

When I built my first company brain, I was the only marketer supporting more than fifty internal requesters. The temptation was to build what demos well: a chatbot that answers questions about the company. Tools like that die at single-digit adoption, because answering questions is not anyone’s job. Producing the Tuesday deliverable is.

So the system was built around the requests actually eating the team’s week: the one-pagers, the account briefs, the collateral. Skills that copy an approved gold standard and swap the content. An intake that turns a vague ask into a buildable one. An approval chain that matches how the company already approves things.

The mechanical fix: build for the request queue, not the demo. Adoption followed the work: more than a hundred people now open that system every day, and it has produced over a thousand pieces of collateral. Not because it is clever. Because it does the Tuesday thing.

Failure two: the output that looked wrong

A review round on one of my product builds flagged the page spacing as a taste problem, the kind of feedback that usually triggers a round of nudging values until someone stops complaining. It was not a taste problem. The margins were a CSS bug, and the changelog entry that recorded it carries the lesson in its title: root-caused the margins instead of adjusting them.

This is the trust failure in miniature. When AI output looks wrong, teams do one of two things: quietly fix it by hand every time, which means the system now costs more than it saves, or stop using it. Both are rational responses to a system whose failures are mysterious.

The mechanical fix: treat wrong-looking output as a defect with a cause, find the cause, and log it where the next person will look. A system whose corrections are visible gets trusted. A system that gets silently patched gets abandoned.

Failure three: the control that reported clean

This one is mine, and it is published on this site in full. The build gate protecting confidential terms here, the most important control in the project, was wrong twice. It scanned only HTML while a forbidden term shipped inside a CSS comment. And it stripped script blocks before checking, which exempted the riskiest content on the site. Both times it reported clean, and I believed it, because I wrote it.

An independent audit found both faults. The fix was not a patch. It was widening the scope until there was nowhere left to hide, then planting a violation and watching the build die, because a control nobody has watched fail is a belief, not a control.

The mechanical fix: verification has to run in a different head than production. In my systems that is literal: verifiers run in fresh contexts, never shown the worker’s reasoning, because a model shown its own reasoning nods along with it. The same rule applies to me.

The pattern under all three

Rules that live in documents are preferences. Rules that live in pipelines are guarantees. Every failure above became structure: the request queue became skills, the wrong-looking output became a root-cause discipline, the broken control became a wider gate with a tested failure mode. The companies whose rollouts survive are not the ones that bought the best model. They are the ones where the system knows the company cold, refuses what it cannot source, and fails loudly instead of shipping quietly wrong.

The model was never the problem. The model is fine. Feed it the company’s actual facts, wire the rules into the build, and let humans keep the judgment, and it stops being a demo and starts being a colleague.