Every list of AI implementation challenges names data, skills, integration and change management. The list is right. What it misses is where those problems become visible in an operation: almost always in the cases that do not fit. A system that handles the routine and fumbles the exceptions has automated the part of the job that was already quick.
The standard list of challenges is accurate and incomplete
Some of the most useful public evidence on why AI projects fail comes from interviews with the people who build them. RAND's 2024 report "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed" cites estimates that more than 80 percent of AI projects fail, "twice the already-high rate of failure in corporate information technology (IT) projects that do not involve AI." Its interviews with 65 data scientists and engineers produced five root causes: a misunderstood problem, missing data, chasing the latest technology over the real problem, inadequate infrastructure to manage data and deploy models, and problems too difficult for AI to solve.
MIT NANDA's "The GenAI Divide" (July 2025) adds the view from the business side. Its survey of executive sponsors and users found "a predictable leader" among barriers to scaling, "resistance to adopting new tools," followed by concerns over model output quality, poor user experience, lack of executive sponsorship and challenging change management.
Read those lists from an operations seat and a pattern appears:
| Challenge on the usual list | How it shows up in a live process | What it traces back to |
|---|---|---|
| The wrong problem was solved | The system handles the cases nobody struggled with | Nobody catalogued where the time goes, which is mostly the odd cases |
| Poor data quality | Missing fields, conflicting records, stale accounts | Those records are the exceptions; clean records flow fine |
| Weak infrastructure | The system stops when an upstream tool is down | Outages and bad inputs are exceptions the design never handled |
| Output quality concerns | Agents redo the AI's work | The system guessed on cases it should have handed off |
| Low adoption | People route work around the system | They do not trust what it does with the hard cases |
Each challenge is real. Each one first appears in the cases that do not fit.
Routine cases are the easy half of any process
In most operations, the routine cases are fast already. A clean invoice that matches its purchase order, a billing question answered by the last statement, a change of address with a valid form: experienced people clear these in seconds, and many are already handled by rules or simple automation.
The time goes elsewhere. It goes to the invoice that matches two purchase orders, the customer disputing a charge from a plan they changed mid-cycle, the claim with a missing document and a deadline. Those cases need context from three systems, a judgment call, sometimes an approval. They are where backlogs form and where customers call twice.
An AI program that measures itself on routine accuracy will look excellent and change little. RAND's authors summarize the trap: "Too often, trained AI models are deployed that have been optimized for the wrong metrics or do not fit into the overall business workflow and context."
Exceptions need a design of their own
Treat exceptions as part of the product; the method in the AI implementation guide builds an exception catalog in its first step for this reason. Designing them means answering, before anything is built:
- Which kinds exist? Catalog them from real cases. Most processes have a handful of recurring types and a long tail.
- How does the system recognize one? Rules, confidence thresholds, missing data, amounts above a limit, a customer flagged as vulnerable.
- Who gets it? A named role, in a queue inside a tool they already use, with a service level.
- What arrives with it? The case history, what the system found, what it would have done and why it stopped.
- What happens to the decision? It is recorded, and recurring decisions become new rules so the same exception stops recurring.
This is management by exception applied to AI: the system runs the routine, and people see only what needs them. The design of the person's role is covered under human in the loop, and the back-office version of the queue is described in exception management.
Data and integration problems arrive as exceptions
RAND found data problems were the second most common cause of failure, and that "Many interviewees (30 of 50) discussed persistent issues with data quality," a count taken from the 50 industry interviewees. In production those issues do not show up as a bad dataset. They show up one case at a time: an account with two owners, a contract missing its renewal date, a ticket that references an order the billing system cannot find.
Integration failures behave the same way. A system that reads from billing, the CRM and ticketing will meet outages, timeouts and changed formats. Google engineers wrote in 2015 that "the external world is rarely stable. This background rate of change creates ongoing maintenance cost." Each of those events is an exception the system has to recognize and route, or it fails quietly. The engineering of those connections is its own discipline, covered in AI integration services.
Adoption follows how the system treats the hard cases
People who run a process judge a new system by its worst moments. If it confidently mishandles a dispute, the team stops trusting it on the easy cases too. If it says "this one needs you" and hands over a well-prepared case, trust builds, because the system behaves like a good colleague who knows the limits of what they know.
That is why low adoption is so often misdiagnosed as a training problem. What looks like resistance is usually people protecting the customer from a system that does not know when to stop.
What to do about it
- Catalog the exceptions in the first weeks, from real cases, before choosing what to build.
- Put the exception queue, its owners and its service levels in the pilot from day one.
- Measure the hand-off rate and the quality of hand-offs alongside routine accuracy.
- Review exception decisions weekly while the system is new, monthly once it is stable, and turn the recurring ones into rules.
- Plan for outages and bad inputs as named exception types, with a fallback.
None of this needs a better model. It needs the process designed around the fact that the exceptions are where the work is, which is also why pilots that filter them out stall on the way to production.