When an AI project dies, it is almost never because of the AI

When an AI project dies, the autopsy almost always blames the technology: the model, the vendor, the AI that wasn't ready. It is a comfortable conclusion, because it puts the blame outside the company. And it is almost always false.

If you sort the causes by their origin, three piles appear. One holds problems that AI truly brought. Another holds integration problems RPA taught us fifteen years ago. The third, the biggest, holds management failures that have been sinking change projects since long before anyone said "agent".

The AI pile is the smallest. That changes the conversation: it stops being about choosing a better model and becomes about implementing better.

What AI really did bring

Two things: trust and accountability.

A public model, on its own, does not reach the accuracy transactional work demands, and it cannot show where your data travels or how it is protected. So compliance, legal and security stop it before production, and they are right to.

Earning that trust doesn't mean convincing anyone the model is smart. It means preparing it for your context, with historical examples, business rules and testing before launch, and then running it with a record and controls.

The other one is quieter: after going live, nobody owns the result. The vendor blames the integrator, the integrator blames the data, performance slowly degrades and model spending climbs without anyone watching. Agents make it worse, because they keep running and changing after launch, so accountability has to last as long as the operation does. These two are the tax that belongs to AI.

What RPA had already taught us

Integration and real volume. AI changed the technology, not the ground conditions of an implementation.

Integration is the same wall RPA hit. The ERP, the warehouse system, the transport system and the old portals all have to be read and written in real time and without failing, and most companies never cross that line. It is engineering, and no model solves it for you.

Real volume is its twin. The system works beautifully on test data and collapses the day the real volume arrives, with bad scans, half-finished purchase orders and every supplier with a slightly different format. That is why real production samples, orderly testing and clear success criteria matter, long before launch. Swapping the automation for a model does not change the nature of the mess. It only raises the stakes.

What has nothing to do with AI

None of these causes is specific to AI, and they are the most common, because they decide everything before the technology can prove itself.

Nobody in management owns it. Without an executive who decides, trade-offs stay open, decisions drag on and a team without authority ends up driving strategic work. Behind every fast implementation there is an executive who stays present after approving: resolving, removing obstacles and pushing to simplify the process before automating it. Sponsorship gets a project started. The executive's presence gets it there.

The requirements keep moving. There is no closed agreement and no real sample data. The business and the experts are not aligned, indicators and rules are defined late, and the scope slides without anyone announcing it. AI faithfully executes the process you give it. If the process is incomplete or misunderstood, the technology just multiplies those assumptions.

Access takes too long. Credentials, environments and test setups take weeks instead of days, and the project starts before it can run. Permissions become the hidden critical path, and AI takes the blame for delays that belong to an organization that wasn't ready.

Chasing one hundred percent. In almost any operation, a few suppliers or case types account for most of the volume. Even so, teams wear themselves out chasing rare cases and mistake perfectionism for progress. The ones that get there fastest treat going live as the beginning, automate the highest-volume work first and expand little by little, under control.

Read that list again. There is no model, no token, no benchmark. These are the failures of any complex change program, documented for decades. Almost everything that makes an AI project fail is an organizational discipline problem dressed up as a technology problem.

Two projects, the same engine

Picture two implementations with the same technology.

The first reaches production ahead of plan because the executive who approved it stays. Scope and trade-offs are agreed early, the team starts with the highest-volume work, obstacles are removed quickly and the process is simplified before it is automated. The technology doesn't change. The speed of decision-making does.

The second takes the opposite path. Requirements keep changing, representative data and test environments arrive late, and attention goes to low-volume exceptions before the most valuable work has been proven. When the schedule slips, AI is the obvious target, even though the brake was somewhere else.

Neither outcome was decided by the model. One sped up because the organization supported the technology. The other slowed down because the organization expected the technology to cover for its own execution failures.

How to review your own project

If AI accounts for only one pile out of three, choosing a smarter model solves, at best, a small part of the risk. The rest is decided before the first digital collaborator goes to work: an executive who stays present, closed requirements with real data, infrastructure ready and timely decisions. And it is decided afterwards, depending on whether the integration survives production and whether someone owns the result.

The five conditions we require of any digital collaborator before it goes to work serve just as well to review your project:

• A role. What work it does has to be written down, with closed rules, real data and the big volume first. If that is missing, the problem is requirements and focus.

• A manager. A named person reviews, signs and resolves trade-offs. If there is none, the problem is sponsorship.

• Evidence of everything. It is written down what it did, with which data and in which system. If it isn't, legal and security are right to stop it.

• Evidence that can be audited. Someone outside the project can review that record without asking permission. If they can't, trust doesn't arrive.

• Someone who answers for it. There is a name for when it fails, six months after launch. If the answer is "it depends", the problem is accountability.

Integration and access are not on that list because they are engineering, and engineering is tested before launch, with real volume.

If what fails is in the evidence and in who answers for it, you have a challenge that belongs to AI, and it is solved with design, control and someone who operates the result. If what fails is the role or the manager, technology is probably not your biggest obstacle. The same disciplines that have decided the fate of change projects for decades will decide the fate of yours.

Before asking whether AI is ready for your company, ask whether your company is ready to put it to work.