The AI pilot worked. The rollout and adoption didn't.

The demo was flawless. Someone stood at the front of the room, asked the tool a question about a contract, and it answered in seconds with a summary that would have taken an analyst most of a morning. Heads turned. The CFO asked about pricing. The pilot was approved before the meeting ended.

Eight months later the useful question for that room is a different one: who's still using it? In most organizations I've seen, the honest answer is three people, one of whom runs the pilot. The sponsor has moved on to the next initiative. The licenses renew quietly, because canceling them would mean admitting something.

The post-mortem, when anyone holds one, usually blames the technology. The AI wasn't accurate enough. It made things up. Security had concerns. Sometimes that's true. More often it's an alibi, because the alternative is admitting that the organization changed nothing except the technology and software.

The technology wears more than one face, too. The assistant that answers questions from your documents is only the most visible one. The same arc plays out with agents that act rather than simply answer, carrying a task across systems end to end, and with AI used to write the automation itself, where the model builds the code or the rules and what runs in production is ordinary deterministic software. The machinery differs. The graveyard doesn't.

I've sat on both sides of this. I've run the operation that approved these tools and signed the alibi at least once, and I build these systems now. The difference between the pilots that scale and the ones that don't has never once been the model, the engine underneath that everyone rents from the same few companies.

The pilot was designed not to fail

Nobody rigs a pilot deliberately. But look at what a pilot actually tests.

It ran on curated data. Somebody, usually the one person who genuinely cared, hand-picked the good examples: the right contracts, the current policies, the answers that were easy to trust. Production means the data as it actually lives, and it doesn't live in one place. Some of it is documents, and as much again sits inside the systems where the work happens: the CRM, the finance system, the ticketing queue, years of email, spreadsheets nobody owns. Three versions of the truth, no note saying which is current, behind permissions nobody has fully understood since the last reorganization. Ask people who build these systems and most will tell you the model is a small fraction of the work; getting the right data to it, from everywhere it lives, is the rest. When the rollout meets that landscape, the model gets blamed for answers the data and the process made impossible.

It ran with no stakes. During the pilot, nobody's job changed. People poked at the tool with curiosity because nothing depended on it. Rollout means someone's working day changes without their consent, and that is a change-management problem that appeared in nobody's job description and on no line of the budget. The training, where there is any, teaches the tool. Nothing teaches the change.

It had an owner. The pilot belonged to someone who wanted it to work, who fed it good data and forgave its bad days. The rollout got a steering committee, and a steering committee is where accountability goes to be shared until it disappears.

And it ran on borrowed plumbing. A pilot lives in a sandbox: a vendor's environment, a clean export, one enthusiast's laptop. A production system needs pipes that feed it current, permitted data, monitoring that notices when answers degrade, and a route that carries outputs into real work and feedback back out of it. When RAND interviewed 65 experienced data scientists and engineers about why AI projects fail, model capability came last of the five root causes they surfaced. Underinvestment in exactly this infrastructure sat above it, alongside leadership misunderstanding the problem to be solved. The pilot never needed any of that, so nobody learned it existed, and nobody budgeted for it.

The software used to bring the process with it

There's a reason the process work gets skipped, and it's not laziness. For thirty years, changing the core systems usually changed the process too. You bought the ERP, the CRM, the ticketing system, and the workflow came baked in: the screens, the fields, the approval chain, the order of the steps. The vendor had opinions, and installing them was the process redesign, whether you enjoyed it or not. Organizations learned a habit from that. Pick the software, roll it out, and the new way of working arrives in the box.

AI arrives with far fewer opinions. It isn't the first tool to do that; nobody's spreadsheet ever shipped with an approval chain either. What's different is that it's being bought and rolled out through the habit the opinionated generation taught. A chat box imposes nothing. An agent will do whatever the process around it permits, which means someone has to decide what that process is. Even AI-written automation only encodes the process you can describe to it, and at that moment many organizations discover their process was never written down. It lives in habits, inboxes and the heads of the two people who've been there longest.

So the old reflex, change the technology and the process will follow, quietly fails here. The process change is the project. The work has to be given an explicit shape (what arrives, who decides, what happens next, what done looks like) before any face of the tool can take a step of it. Decorate the current process with AI and you keep the current process, with its current costs, plus licenses.

Building doesn't buy readiness

Buying is not the only path this story takes. The other door is build, and it's more walked than ever. The models are rentable, the components are on the shelf, and a credible internal prototype now takes one motivated person a couple of weeks. That person is no longer necessarily an engineer, and that matters: the analyst or the operations manager who actually lives inside the workflow can now build for it directly. Plenty of teams are already building, some with permission, some without. The market is tilting the other way (Menlo Ventures' late-2025 survey of roughly 500 US enterprise decision-makers put purchases at 76% of AI use cases, up from a nearly even split with internal builds a year earlier), but the build door stays crowded.

Build fails the same tests in different clothes. The prototype ran on the builder's own tidy corner of the data. Nobody's workflow changed, because the builder was the user, right up until the tool spread to people who never asked for it. Ownership looked solved while the builder was in the room, and then they left, and the organization discovered it owned software instead of a license. Software can't be canceled, only abandoned.

The seduction of building is that the first stretch is now nearly free, which hides where the cost always lived: the edge cases, the permissions, the maintenance, the person who has to keep caring after the demo. A bought tool comes with someone paid to care. A built one hands the caring to whoever drew the short straw. When MIT's NANDA project reviewed some 300 enterprise AI initiatives in 2025, with 52 organizational interviews and 153 executive surveys behind it, internally built tools reached deployment about a third of the time, half the rate of tools brought in with an external partner. The authors say plainly that the sample is limited and the link isn't proof of causation. It's still a number worth reading out at the budget meeting.

None of this makes build the wrong answer. Sometimes it's the only honest one, when the workflow is genuinely yours and no vendor will ever understand it. The point is that buy versus build is a delivery question, and readiness isn't. Both doors open onto the same wall, and choosing build means meeting it twice: once in the organization the tool lands in, and once in a codebase somebody now has to own and keep understanding.

Wrong answers, wrong actions, wrong rules

AI makes ordinary change management harder, not easier, because the tool is probabilistic. Traditional software fails the same way every time, so people learn its edges and route around them. A probabilistic tool fails confidently and occasionally. The first confidently wrong answer becomes the story the whole floor repeats, and I have watched a single bad answer in front of a client undo months of investment, with leadership responding by banning the lot.

Agents raise the stakes, because a wrong answer waits to be read and a wrong action has already happened. The email went out, the record changed, the process kicked off. Scaling an agent is less about making it smarter and more about deciding its blast radius in advance: what it may touch, which steps fire on their own and which wait for a person, what can be rolled back, and whether there is a trail of what it did and why. The teams that run agents well treat reversibility as a requirement, not a courtesy.

AI-written automation fails differently again. When the model writes the code or the rules and the runtime is deterministic, you trade the occasional confident error for a consistent one: a mistake in what was built repeats on every run, quietly and at volume. The verification moves upstream. You don't check each output; you review and test the thing that was built, like any other software the process depends on, because that is exactly what it is.

Across all three, the teams that survive designed for failure before they scaled. They decided what gets verified or approved, and by whom. They told people plainly what the tool is not allowed to decide or do on its own. They made reporting a bad answer or a bad run normal, so the first one arrived as feedback rather than scandal. None of this is technical work, and all of it decides whether the technical work matters.

The readiness checklist

Readiness lives in four layers, and a pilot can be green while every one of them is red. Before you scale anything, answer these honestly.

The data

• Has the tool run against your messiest data, not a hand-picked sample?
• Can it see what it needs under the permissions it will actually have in production?
• When two copies of the same information disagree, does anything decide which one is true?

The process

• Does the process have a written shape at all (what arrives, who decides, what happens next), or does it live in habits and inboxes?
• Is there a named step in a real workflow where the tool now does the work, or is it a general-purpose box on the side?
• Has the workflow been redesigned around what the tool does, or just decorated with it?
• Can the person checking an output verify it faster than they could have done the work themselves?

The plumbing

• Is there a budget line for the pipes themselves: the data feeds, the permissions work, the monitoring?
• Does anything watch answer quality in production, or will a client be the first to notice?
• When a better model arrives next year, can you swap it in without starting again?

The people

• Is there one named owner whose own job improves when this works?
• Does everyone using it know what it is not allowed to decide?
• Is there a plan for the first confidently wrong answer?
• Has anyone been trained inside their own task, on their own documents, rather than in a course?

If it acts, not just answers

• What is the worst thing it can do with the permissions it holds, and did you choose that on purpose?
• Which steps fire on their own, and which wait for a person's sign-off?
• When it does the wrong thing, can you roll it back, and will the trail show what happened and why?

If you built it

• Who owns it the day its builder resigns?
• Has what the AI built been reviewed and tested like any other software the process depends on?
• Does anyone besides the builder understand it well enough to change it safely?
• Knowing what two years of edge cases and maintenance will cost, would you still choose build?

If the named-owner question has no answer, stop there. Nothing else on the list survives without it.

What I'd do differently

Run the pilot against your worst data and your most skeptical team. A pilot that survives the skeptic and the mess has told you something; a pilot that impresses the willing has told you nothing you didn't already want to hear.

Budget the rollout as a change program that happens to include technology and software, because that's what it is. The licenses, or the two weeks of prototype time, are the cheapest lines in it. The expensive lines are the data work nobody scoped, the plumbing nobody itemized, the workflow redesign nobody owned, and the training that has to happen inside the work rather than beside it. Write the process down before you shop, because this time the software won't do it for you.

And when someone asks you to fund the AI, ask them who owns the workflow. When someone shows you a working prototype, ask the same question in different clothes: who owns this in a year? If either answer is a committee, you already know how this ends. You've been in the room where it started.