Everything that worked in your industry is already in the training data. Everything that broke is not. Why the record of local failure, produced almost entirely after the signature, is becoming the only proprietary asset in enterprise software, and why almost nobody is collecting it.

Ninety-five percent. That is the share of enterprise generative AI pilots that produced no measurable profit-and-loss impact, according to MIT's Project NANDA in its July 2025 report The GenAI Divide, drawn from more than 300 public deployments, 52 executive interviews and 153 leadership surveys, against an estimated 30 to 40 billion dollars of enterprise spending.

The number deserves a caveat that most decks citing it leave out: it measures pilots with no documented pre-deployment baseline as failures, so it is partly a verdict on measurement discipline rather than on the technology. The direction survives the caveat, and the diagnosis underneath the headline is more interesting than the headline. The report attributes the divide not to model quality, talent or regulation, but to what it calls a learning gap: systems that do not learn from context, retain feedback or adapt to the workflow they were bought to change.

Read that as an executive rather than as a technologist and it says something uncomfortable. The models are fine. What is missing is the information that would make them fit your business, and that information is not in the model because it never existed anywhere in a usable form. Your organisation does not have a technology problem. It has an empty corpus.

When a factor of production gets cheap, value moves to its complement

In 2002 Joel Spolsky described the strategy that has governed the software industry ever since: smart companies commoditise their complement. Make the thing next to your product cheap and abundant, and demand flows to whatever you sell that remains scarce.

The frontier labs are doing this to intelligence itself, deliberately and effectively. Reasoning is becoming abundant, metered and interchangeable. Your competitors buy it from the same handful of suppliers, at falling prices, on similar terms, and it improves on a schedule none of you control.

The strategic question is therefore not what the model can do for you. Every company gets that same answer. The question is what remains scarce and complementary to a commodity that thinks.

I count three things. Proprietary evidence of where that commodity fails on your specific terrain. Accountability, meaning a name on the outcome when it does. And the customer relationship in which both are tested. All three live on the same side of the business, and it is not the side receiving the AI budget. It is post-signature.

The intern who wrote down the failures

Last year one of my directors forwarded me an internship application with a note attached: read the last paragraph. The candidate came from one of France's grandes écoles, the sort of profile with four offers by November, and the last paragraph carried a condition. He would join provided he spent the internship writing code by hand rather than orchestrating tools that wrote it for him.

I found the request mildly irritating. We were in the middle of a company-wide push to put AI into everything we sold and everything we did internally, and my entire leadership narrative that quarter was acceleration. His reason was one sentence: I want to be able to tell when it is wrong.

For three weeks he was visibly behind. A senior with a good assistant produced in an afternoon what took him two days, and there was some gentle mockery of the sort teams reserve for whoever insists on the difficult route.

What none of us noticed was the parallel exercise. Every time he solved something himself, he also asked the model, and when the two answers diverged he wrote down what had happened. Not the answer. The failure mode. Where the model had been confidently, fluently, plausibly wrong. By September the notebook held more than forty entries: library behaviour the training data no longer described, business logic in our domain that the model simplified in the same direction every time, edge cases in customer data producing code that ran perfectly and computed the wrong thing.

His final project, chosen freely, was a set of internal assistants that write code. The person who had refused to use the assistants built the best ones in the building, not because he was the strongest engineer, but because he was the only one holding tested evidence of where the machine breaks on our terrain. His notebook became the evaluation set. His forty failures became the guardrails. Everyone else's assistant was built on an intuition of what the model does well; his was built on a record of what it does badly.

We paid an intern stipend for it, and we nearly did not hire him.

Your successes are in the training data. Your failures are not.

Here is the asymmetry that follows, and it is the part I would put in front of a board.

Everything that worked in your industry has been published. Your best practices, reference architectures, delivery methodology, the playbook a consulting firm spent a decade codifying: all of it derives from the same public corpus of things that worked, which is exactly why frontier models handle it competently. Whatever advantage those artefacts once conferred has been socialised into a service anyone can rent.
What has not been published is the specific, local, faintly embarrassing record of how things fail in your product, with your customers, on their data. Nobody blogs an implementation that computed the wrong number for six weeks. It appears in no benchmark. It cannot be scraped, and it cannot be generated by the system it is meant to test, because a model cannot reliably tell you where it is confidently wrong.
That inverts twenty years of knowledge management. We built entire functions to capture and reuse the half of our knowledge that has since become free, and we systematically discarded the half that has since become the only defensible thing we own.
And the discarded half has an address. Failure surfaces where the product meets a customer who did not build it: implementation, support, escalation, renewal. Which means the function most software companies still run as a cost centre is the factory for the one asset the company cannot buy.

Five moves for the executive committee

If I were structuring this for a leadership team this quarter, five moves.

• Give the failure corpus an owner, a budget and a version number. Structured capture at the friction points, held as an asset with someone accountable for its quality and coverage. Retrospectives and Slack threads are not a corpus. If nobody owns it, it is not an asset, it is exhaust.
• Keep a share of work unassisted, as instrumentation rather than pedagogy. This is the move most often mistaken for nostalgia. Unassisted work is the only instrument that generates uncontaminated observations of where the model is wrong. If everyone works with the assistant on, the organisation loses the ability to see the assistant, in the same way a scale cannot be calibrated using only itself.
• Contract for ownership of what delivery produces. Implementation agreements are precise about deliverables, IP in the code and data protection, and silent about who owns the evaluation data, failure logs and prompt sets generated while making the product work in that customer's environment. That silence was harmless when the artefact was worthless. It is now the difference between an implementation that earns a fee and one that compounds.
• Report production, not just consumption. Board packs measure seats, adoption, deflection and hours saved, all of which describe how fast you are absorbing someone else's capability. Add one line describing what this organisation produced: volume and coverage of new documented failure modes, and the share of them now encoded in guardrails or evaluations.
• Ask the diligence question, of yourself first. Not what is our AI strategy, which returns a supplier list. What can this company prove it knows about its own domain that a frontier model does not, where is it written down, and who owns it. If the room goes quiet, the silence is the strategy discussion.

I learned the underlying lesson long before any of this, leading Professional Services at Adobe. We industrialised delivery around reusable assets rather than headcount, and delivery costs fell by 35 percent. What is easy to miss in that figure is where the accelerators came from. Every one was designed by someone who had done the manual version, badly, on a real customer, at least once. We thought we were building automation. We were converting accumulated failure into a product, and we never once described it that way on a slide.

The knowledge management objection

Experienced executives will say this is knowledge management with new branding, tried in 2004, and that it produced expensive repositories nobody opened.

They are right about the history and wrong about the conclusion, for two reasons. What we tried to capture then was best practice, which generalises, decays and is now free. What matters now is failure, which is specific, local and does not generalise, which is precisely why it stays valuable. And the reader has changed. The repository failed because its consumer was a human being with no time on a Thursday afternoon. Its consumer is now a system with infinite patience that measurably improves when you feed it.

The repository nobody read has become the training signal everybody needs. That is also, read carefully, what MIT's learning gap describes: not a shortage of intelligence, but a shortage of the local evidence that would let intelligence learn your business.

The reframe

Stop treating AI as a capability you are acquiring. Capability is arriving anyway, on everyone's terms, at a price that keeps falling. Treat it as a utility, and ask the question you would ask about any utility: what do I own that makes it worth more in my hands than in a competitor's.

The answer is the record of where it fails on your terrain. That record is produced only where your product meets a customer who did not build it, at the moment something breaks, by the people most companies are currently trying to make redundant.

An intern understood this before my leadership team did, and he built it in a notebook while everyone else was learning to prompt.

The model already knows everything that worked. Only you know what broke. Stop harvesting your best practices. Start harvesting your failures.


This article is adapted from edition #17 of my LinkedIn newsletter, Professional Services & Tech. Subscribe on LinkedIn to receive future editions.

Sources:

MIT Project NANDA, "The GenAI Divide: State of AI in Business 2025" (July 2025), on pilot outcomes and the learning gap;
Joel Spolsky, "Strategy Letter V" (2002), on commoditising your complement.

---

Mathilde HENRY
Executive Leader in Enterprise Software & AI Transformation. 20 years working at the intersection of software, consulting and business transformation.