AI pilots don't fail on the model. They fail at the integration boundary.

Everyone has now watched an AI pilot demo beautifully and then quietly die. The board approved a budget, the vendor showed something impressive, and eighteen months later nothing is running. The usual post-mortem blames the model — it wasn't accurate enough, it hallucinated, the technology isn't ready.

That is almost never what happened.

The number that gets quoted, and the one that matters

You will have seen the headline that 95% of generative AI pilots deliver no measurable return. It comes from MIT's GenAI Divide research and it has been repeated everywhere, including by people selling the cure. It has also been challenged fairly robustly, so we would rather not build an argument on it.

The more useful finding is about causes rather than counts. A 2026 survey of 650 enterprise technology leaders asked what actually stopped their AI pilots reaching production. The most cited reason, at 63%, was integration complexity. Output quality at scale came second on 58%, monitoring infrastructure third on 54%.

Read that ordering again. The top three causes are all about the machinery around the model, not the model.

The same research puts it more bluntly than we would dare:

The integration layer was underestimated by an order of magnitude. The gap is the compounding complexity of connecting AI to the actual systems of record, ticketing platforms, ERP layers and knowledge bases that the pilot deliberately avoided.

That last clause is the whole problem. The pilot deliberately avoided them.

Why pilots avoid the hard part

This is not incompetence. It is what every guide to running a proof of concept recommends.

Search for how to scope an AI POC and you will be told, consistently, to keep it narrow, keep it time-boxed, and to put broader integrations explicitly out of scope. That advice is not wrong on its own terms — it keeps the exercise small and cheap.

But follow it and you have designed an experiment that deliberately excludes the number one reason these projects fail. You will learn whether a model can classify your tickets. You will learn nothing about whether it can classify your tickets, at your volume, against your ticketing system, with your categories, when someone forwards an email chain with six replies and a photograph of a screen.

The first question is interesting. The second is the one worth six figures.

What "integration" actually means in practice

It is not an API key. Three examples from our own work:

Bank statements. We built a system that turns client bank statements into structured transaction data. A generic extraction pass handles a clean sample beautifully. Run it across real statements from real banks and it falls apart — every bank lays out its columns differently, handles multi-line descriptions differently, and puts the running balance somewhere else. The solution was a separate extraction pipeline tuned per bank. Unglamorous, and the entire reason the system works.

Support triage. We built a classifier that reads inbound support mail, categorises it by issue and urgency, filters the spam, and drafts a reply. The interesting engineering was not the classification. It was that the output had to land in the ticketing system the engineers already lived in, with the categories they already used, without them changing how they worked. Response time went from hours to minutes at 92% categorisation accuracy — but only because the last mile was built.

Multilingual documentation. We built a system generating product user guides in six languages for a financial services firm. Getting a model to produce good German is easy. Getting it to produce the same financial terminology in German every time, consistent with the English source and the compliance-approved glossary, across hundreds of documents, is the actual job.

In each case the model was the least interesting component. In each case the system is still in daily use, which is the only measure that counts.

What this means if you are about to spend money

Three things follow.

A proof of concept that touches nothing has proved nothing. If the prototype runs on exported sample data on somebody's laptop, it has tested the easy half. Insist that it connects to at least one real system — your sign-on, your ticketing platform, your document store — before you accept the result as evidence.

Ask what happens after the pilot succeeds. Research consistently finds that pilots fail not because the technology underperformed but because nobody defined the path to production. Who owns it. What it costs to run. Who gets the call when it breaks at 2am. If nobody can answer that before the pilot starts, the pilot is a demo.

Be suspicious of a verdict from whoever wants the build. A proof of concept from the firm bidding for the implementation carries an obvious incentive, and everyone in the room knows it. That does not make them dishonest — it makes their conclusion unfalsifiable.

The uncomfortable version

If integration is where projects die, then the cheapest thing you can do is find out early whether your integration is the kind that kills projects. That is a small, bounded piece of work. It costs a fraction of the build and it occasionally concludes that you should not build at all.

We would rather deliver that answer in a month than watch you find it out in eighteen.