A demo that works in a meeting and a system your team relies on every Tuesday are two different products. The first one needs the model to be impressive once. The second one needs it to be predictable, permissioned, affordable, and connected to the tools people already have open.

Most AI work stops between those two points. That is not a reason to avoid the work. It is a reason to make four specific decisions before anyone starts building.

What the research says

MIT's Project NANDA published The GenAI Divide: State of AI in Business 2025 in July 2025. The authors label it preliminary findings, and it is worth reading with that label in mind. The research covered January to June 2025 and combined a review of more than 300 publicly disclosed AI initiatives, structured interviews with 52 organizations, and survey responses from 153 senior leaders.

Its headline claim is that despite roughly $30 to $40 billion in enterprise investment, 95% of organizations were getting zero return. The number that matters more for planning sits further down the report. Among organizations that evaluated enterprise-grade custom or vendor-sold systems, 60% evaluated, 20% reached a pilot, and 5% reached production. The report attributes most of the failures to brittle workflows, systems that do not learn from context, and misalignment with day-to-day operations.

Deloitte's Tech Trends 2026 found a similar shape in its 2025 Emerging Technology Trends study: 38% of surveyed organizations were piloting agentic solutions, 14% had something ready to deploy, and 11% were actively running these systems in production. In the same report, Deloitte cites Gartner's forecast that more than 40% of agentic AI projects will fail by 2027 because legacy systems cannot support what the AI is being asked to do.

Two research teams, different methods, same shape. Piloting is common and production is rare. Here is where the gap tends to open.

Four reasons the work stops

1. The pilot answered a question nobody needed answered

A pilot usually proves that a model can do a task. That was rarely in doubt. The question that decides whether the project survives is narrower: can this run on our real inputs, including the malformed ones, without a person checking every result?

The MIT report found that the buyers who succeeded evaluated tools on business outcomes rather than software benchmarks. A pilot scoped to a clean sample of twenty documents has not tested the thing that will break it. The fiftieth exception is where the cost lives.

2. Integration was treated as the last step

The MIT authors note that custom solutions stall on integration complexity and lack of fit with existing workflows. In practice that means the AI works and the surrounding plumbing does not. The output has nowhere to land, the source data sits behind a login nobody wants to automate, or the result arrives in a format the next system rejects.

Integration is not the last 10% of an AI project. On most operational workflows it is the majority of the build, and a plan that schedules it as a final sprint has mis-scoped the whole project.

3. Nobody decided what the system was allowed to do

Give a system credentials and it will use them. An assistant with access to calendars, mail, storage, and admin APIs can take an action nobody intended, because nothing in the setup said it could not. That is a design gap rather than a model defect.

The controls that prevent it are unglamorous and well understood. Restrict which tools the system can call. Cap how many times it can call them. Keep sensitive or irreversible actions behind a person. Log what happened so a bad run can be explained afterwards. None of that is exotic engineering, but it has to be decided during design rather than patched in after an incident.

4. The running cost showed up after the demo

Pilot budgets cover the build. They frequently do not cover what the system costs to operate at real volume. A unit cost that looks trivial per document stops looking trivial at ten thousand documents a month, and an unbudgeted invoice is one of the few things that can kill a system which is otherwise working.

Model the running cost at full volume during design, and decide then whether the workflow still pays for itself.

Questions to answer before development starts

Each of these is cheaper to answer on a call than to discover in month three.

  • What does the current process cost today, counting hours, salary, software, delay, and rework? Without that number there is nothing to compare a result against.
  • Who owns the process? A workflow with no owner has nobody to define the exceptions or accept the new version.
  • Which decisions have to stay with a person? Answer this early, so the review queue gets designed as part of the system instead of bolted on when accuracy disappoints.
  • What does the system connect to, and who controls those systems? Every integration has an owner, a credential, and a rate limit. Find all three before scoping.
  • What does it cost to run at peak month volume rather than pilot volume?
  • What measurement will prove it worked? Agree the metric and the baseline before the build, because the baseline disappears the moment the new process starts.

If those answers do not add up, the right outcome is a smaller build, an existing product, or a process change with no AI in it. That is a good result from a discovery phase, not a failed one.

What working should mean

Useful measures are specific to the workflow: time returned to the team, fewer manual handoffs, lower software spend, faster turnaround, higher completion rates, or capacity added without hiring. Our law firm platform case study and construction reporting case study each set that measure at the start and reported against it at the end.

One more finding from the MIT report is worth repeating, including the part where it happens to flatter a firm like ours: external partnerships reached roughly twice the success rate of internal builds. Read that as a signal about focus and accountability rather than proof that hiring help guarantees anything. An internal team that owns the process, controls the integrations, and measures the result will beat an outside partner who does none of those things.

Across both reports, the projects that reached production were scoped as operational changes with an owner, a boundary, a budget, and a number to hit. The ones that stalled were scoped as demonstrations. The technology was rarely the deciding factor.