There are two numbers in the MIT NANDA report that are almost never quoted together, because a different one took the headline. 60% of organisations evaluated custom or vendor-sold enterprise AI tools. 20% reached pilot. 5% reached production.
The fall from sixty to twenty explains itself: far more gets evaluated than gets tried. The interesting one is the other. Between pilot and production, three out of every four projects are lost after they had already shown they worked.
The authors themselves write that the divide "does not seem to be driven by model quality or regulation, but seems to be determined by approach", and note that custom solutions stall due to "integration complexity and lack of fit with existing workflows". Gartner arrived at the same place by another route when it predicted in June 2025 that more than 40% of agentic AI projects would be cancelled before the end of 2027: its analyst attributes this to organisations being "blinded" to deployment complexity, with projects stalling before they reach production.
This piece is about where exactly that boundary sits and the four questions you have to answer to cross it. Not about the engineering of going to production, which we've covered, but about something narrower and more stubborn: the point where an agent stops reading a file and starts talking to the system where your business lives.
The pilot worked because it crossed nothing
Almost every pilot I've seen works on an export. A CSV, a folder with two hundred copied documents, a six-month-old test database. Still data, no permissions, no concurrency, nobody else writing at the same time, and no consequences if something goes wrong.
That's not a shortcut by the team: it's the sensible way to test a hypothesis. The problem is what gets concluded from the result. When the pilot goes well, the conclusion drawn is "the model can do this". And it's true. But the question that decided the project was never asked, because the export sidestepped it entirely.
Production means reading the live system. With its permission model, its half-filled fields, its duplicate records, its history of decisions nobody documented, and other people modifying it while the agent reads. Everything that made the pilot easy is, literally, the absence of that boundary.
The boundary has three degrees, and you cross them one at a time
The most expensive planning error is treating "connect to the ERP" as one thing. It's three, with different costs and different approvers, and putting them in the same phase is what turns an eight-week project into an eight-month one.
| Degree | What the agent does | Who has to sign it off | What happens if it gets it wrong |
|---|---|---|---|
| Read | Queries records to answer, summarise or draft something a human signs | IT, with a data protection view | A bad answer somebody catches on reading it. Reversible and cheap. |
| Write | Creates or modifies records: a contact, a line, a status, a field | The process owner, not IT | False data inside the system, carrying the authority of an automated process. Usually surfaces weeks later. |
| Write with side effects | The write triggers something outward: an email to the customer, a payment, a journal entry, a shipment | Leadership, and often finance or legal | The error has already left your building. It isn't undone: it's compensated. |
The three degrees of commitment in an integration. The distinction between the last two is the one most often missing from the proposals we've reviewed.
The practical rule that falls out of that table is boring and it works: don't mix the three degrees in the same phase. Weeks in read-only, with the agent proposing and a human executing, teach you more about the real system than any up-front analysis — and by the time writing comes around, you already know which fields are dirty, which permissions are missing and which exceptions actually occur.
Question 1 · What identity does it act under?
It's the first one to answer and the one most often answered by accident, in a twenty-minute technical meeting, by picking whichever option unblocks development.
There are two shortcuts and both are expensive. The first is impersonating an employee: the agent uses a person's credentials, usually those of whoever is driving the project. It works on day one and breaks the audit trail forever — from then on the system log says that person did things at three in the morning, and when someone audits the process there will be no way to separate what they did from what the agent did.
The second is inheriting a service account that already existed. This is worse than it looks, because those accounts were created years ago for integrations nobody remembers and tend to accumulate more permissions than any human on the team. The agent doesn't get the permission it needs: it gets everything that account was dragging along.
The underlying mess has been measured. The Cloud Security Alliance's report on non-human identities puts the median at 45 non-human identities per human user in a typical enterprise, and up to 144 in cloud-native environments. But the figure that really describes the problem isn't that one: it's that 51% of organisations report no clear ownership of AI identities, and 16% do not even track when one is created.
It's worth saying where those numbers come from: that report aggregates research published by third parties rather than measuring directly, so it serves to size the mess, not as a census. The direction, though, matches what you see on any project: nobody knows how many automated accesses their company has open.
The answer that works is dull: its own identity, named, with the minimum permission the specific process needs and a human owner with a name. Plus an expiry date, because the integration nobody renews is the one still running three years after the project was cancelled. How those permissions get bounded when the agent also uses tools is something we develop in the piece on prompt injection: an agent's security lies in what it can do, not in what it is asked.
Question 2 · What gets written down, and in which log?
Every serious system of record has an audit trail. The problem isn't that one is missing: it's that there are two and they don't join up.
The ERP's log records what happened: which account modified which field, when, with what previous value. It's what a financial auditor needs and it's been solved for decades. The agent's log records why: what it was asked, which documents it read, what reasoning it followed, with what confidence. And it lives in another system, with another format, another retention period and often another vendor.
When someone asks "why was this order approved automatically?", the answer is split across the two, and joining them is manual work unless it was designed beforehand. The cheap version is a correlation identifier that travels from one to the other; the expensive version is reconstructing it six months later from screenshots.
The EU AI Act turns this into an obligation for high-risk systems: its Article 12 requires that they "technically allow for the automatic recording of events (logs) over the lifetime of the system", with logging capabilities sufficient to identify risk situations and facilitate post-market monitoring. Not every process in a company falls into that category — it's worth checking case by case rather than assuming the worst — but the design that satisfies the obligation is the same one you need to be able to explain yourself to an angry customer. The piece on designing agents that pass an audit develops that layer.
Question 3 · What happens at the next upgrade?
This is the one that never appears in the business case, and the one that turns a closed project into a standing liability.
Odoo, the most widespread ERP in the Spanish mid-market, says it in its own documentation with welcome clarity: "if a change introduced by a new version breaks a customization, it is the responsibility of the maintainer of your custom module to make it compatible with the new version of Odoo". And further up, on the upgrade page: "if your database contains custom modules, it cannot be upgraded until a version of your custom modules is available for the target version of Odoo".
Read that again with your agent in mind. The integration you're about to approve falls into that category. It's not that it might break: it's that it blocks the ERP upgrade until someone fixes it. And that same sentence, under another name and in different small print, sits in the terms of every serious system of record — Odoo's own documentation, when it lists what to test before upgrading, starts with "integrations with external software (EDI, APIs, etc.)".
The practical consequence isn't technical, it's budgetary and it's governance: whoever approves the integration is also approving its maintenance at every major version, for as many years as it runs. If that line isn't in the business case, the business case is incomplete, and the day the bill arrives the conversation will be about why nobody said so.
There's an architectural decision here with long consequences: the more the integration leans on the system's internal model — tables, fields, custom modules — the more it breaks. The more it leans on the system's public, stable interface, the less it can do, but it survives versions. There is no correct answer; there is a choice worth making with your eyes open and writing down.
Question 4 · And if the system is wrong?
The first three questions have an owner: someone in IT, someone in the process, someone holding the budget. This fourth one has no owner, and it's the one that costs the most money.
An agent reading the CRM assumes the CRM is right. It has no way not to: it's its only source. A human who sees an impossible renewal date, or a contact with a job title from three roles ago, raises an eyebrow and asks. The agent uses it, builds an immaculate answer on top of it, and writes it down.
The failure mode, therefore, doesn't look like an error. There's no exception, no red trace, no alert. There's a plausible output built on false data, signed by an automated process — which is precisely what lends it authority with whoever reads it.
It's the same mechanism we described in relation to generated tests: a system that can only learn from the current state describes that state, it doesn't judge it. A dirty CRM doesn't produce an agent that fails; it produces an agent that lies with confidence. And that is why minimum viable data preparation is not an optional preliminary phase: it sets the ceiling on what can be automated without supervision.
| Question | Who answers it | What it costs not to answer it up front |
|---|---|---|
| What identity does it act under? | IT + a named human owner | A useless audit trail and permissions nobody knows how to revoke. Discovered at the first audit, when there are already months of contaminated history. |
| What gets written, and where? | Process + whoever owns compliance | Reconstructing by hand why the system did something, from screenshots, six months later, in front of someone in a bad mood. |
| What happens at upgrade? | Whoever approves the budget | An integration that blocks the ERP upgrade, and a recurring cost that wasn't in the business case. |
| And if the data is wrong? | Nobody, by default — it has to be assigned | Plausible, false outputs with no exception and no alert, propagated at machine speed and signed by an automated process. |
The first three have a natural owner in any organisation. The fourth doesn't, and it's the one to assign explicitly before starting.
The order, which matters more than the answers
None of the four questions has a universal answer: they depend on the system, the sector and how much risk leadership is willing to carry. What is transferable is the sequence.
One process before one platform. The temptation is to build the good integration layer, the one that will serve everything. It's more expensive and slower, and above all it defers the learning: until a process reaches production, everything you know about the real system is assumption. Start with one specific, boring process — there are plenty documented, and what they share is that the current cost can be measured without arguing about it.
Read before write. Not out of generic caution, but because during those weeks the agent teaches you for free which fields are dirty, which permissions were missing, and which exceptions exist in reality rather than on the diagram. That knowledge cannot be bought and appears in no up-front analysis.
The exception path before the happy path. Who receives the doubtful case, with what context it arrives, and how quickly it has to be resolved so the process doesn't jam. If you can't answer who receives the exception, the process isn't ready, however well the demo runs. It's the part that decides adoption and the part almost always designed last.
And minimum permission from day one, even if it costs a week. Widening permissions is a ten-minute conversation; narrowing them, once processes hang off them, is a project. It's the same logic we apply to the minimum required in governance: the cheap moment is before.
What this is not
This is not an argument against agents. The same MIT report documents that the 5% who cross extract real, measurable value, and that those who manage it do so not with better models but by demanding customisation around specific processes and evaluating on business outcomes rather than benchmarks.
Nor is it an argument for standing up a nine-month integration programme before touching anything. That would be the opposite error with the same ending: the project dies of governance instead of dying of engineering.
And the figures deserve the same honesty their authors gave them, which is more than you'll find in almost any deck that cites them. The MIT report presents itself as preliminary findings, is not peer reviewed, collected its 153 survey responses across four industry conferences — a place where nobody brags about failure, and which attracts people already in the conversation — and warns on its own pages that its numbers are "directionally accurate based on individual interviews rather than official company reporting" and "may not represent broader market patterns". One further check almost nobody makes when citing it: MIT Media Lab's official Project NANDA page does not host the report, even though its principal investigator is one of the four authors. None of this invalidates it, but it fixes what it's for: describing a shape, not calculating a ROI or being carried into a committee as though it were a census. The shape, in any case, matches what you see on every project: the model is almost never the problem, and the boundary almost always is.
If your company already has people using AI on their own — and it does — this conversation is already happening without you, with data leaving the system through the clipboard and none of the four answers written down. Answering them isn't up-front bureaucracy: it's what separates a pilot that impresses from a process that stays.
Frequently asked questions
Why did the pilot work and the deployment didn't?
Because the pilot almost never crosses the boundary. It works on an export, a folder of copied documents or a test database: still data, no permissions, no concurrency and no consequences. Production means reading the live system, with its permission model, its half-filled records and other people writing at the same time. Everything that made the pilot easy is the absence of that boundary. The MIT NANDA report measures it in the drop-off: 60% of organisations evaluated enterprise AI tools, 20% reached pilot and only 5% reached production — and the authors write that the divide does not appear to come from model quality or regulation, but from approach.
What identity should an agent use on the ERP or CRM?
Its own, named, with the minimum permission the specific process needs — never impersonating an employee and never inheriting a generic service account that already existed. Impersonation breaks the audit trail: the system's log will say a person did something when they weren't there. Inheriting an old service account usually gives the agent more permissions than any human on the team, because those accounts were created for integrations nobody remembers. The Cloud Security Alliance's work on non-human identities puts numbers to the mess: 51% of organisations report no clear ownership of AI identities and 16% do not even track when one is created.
Is writing harder than reading for an agent?
It is a different project, not the same project slightly larger. Reading is solved with read permissions and a technical conversation. Writing opens three fronts that are not technical: who approves an automated process modifying an accounting or commercial record, what happens to the wrong write nobody catches until close, and how it gets undone. And there is a third degree often confused with the second: writing with side effects, where the entry triggers an email to the customer, a payment or a journal entry. At that point the error has left your building. The practical rule is not to mix the three degrees in the same project phase.
What happens when we upgrade the ERP?
The integration is a standing liability, not a project that closes. Odoo's documentation says it plainly about its own product: if a change introduced by a new version breaks a customisation, it is the responsibility of the maintainer of your custom module to make it compatible with the new version, and a database containing custom modules cannot be upgraded until a version of those modules exists for the target version. That sentence, under another name, sits in the terms of every system of record. The budget consequence is what matters: whoever approves the integration is also approving its maintenance at every major version, and that almost never appears in the business case.
What if the system's data is wrong?
The agent has no way of knowing, and that is the most expensive failure mode of all because it doesn't look like an error. A human who sees an odd field asks; an agent reading the same field uses it. The result is not a visible exception but a plausible answer built on false data — and it gets written back into the system with the authority of the automated process. That is why data preparation is not an optional preliminary phase: it sets the ceiling on what can be automated. And it is why you should start with processes where the input can be checked against something, not with those that depend on fields nobody maintains.
Where do you start without setting up an integration programme?
With one process, read-only, and the exception path written before the happy path. A specific, boring process — not the most visible one — whose current cost can be measured. Read-only for the first weeks, so mistakes stay reversible while you learn how the real system behaves. And the exception path decided before you start: who receives the doubtful case, with what context, and within what time. If you cannot answer who receives the exception, the process is not ready to be automated, however well the model performs in the demo.
Sources cited
- Challapally, A., Pease, C., Raskar, R. and Chari, P. — The GenAI Divide: State of AI in Business 2025 (MIT NANDA, July 2025; preliminary findings across 300+ publicly disclosed initiatives, 52 organisations interviewed and 153 senior-leader responses collected at four conferences; the 60% → 20% → 5% funnel and the attribution to approach rather than model quality). Link to a PDF copy of the document: MIT Media Lab's official Project NANDA page does not host the report, although its principal investigator is credited as an author.
- Cloud Security Alliance, AI Safety Initiative — The Non-Human Identity Governance Vacuum: AI Agents and the Fastest-Growing Unmanaged Attack Surface (20 May 2026; a median of 45 non-human identities per human user and up to 144 in cloud-native environments; 51% with no clear ownership of AI identities, 16% not tracking their creation. Aggregates research published by third parties rather than measuring directly)
- Odoo — Upgrade — Odoo 19.0 documentation (official documentation; the custom-module maintainer's responsibility, the upgrade block with custom modules, and the list of integrations to test)
- European Union — AI Act, Article 12 · Record-keeping (automatic recording of events over the lifetime of the system for high-risk systems)
- Gartner — Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (25 June 2025; Anushree Verma; escalating costs, unclear business value and inadequate risk controls, with organisations "blinded" to deployment complexity)
Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.
LinkedIn →