Most implementations stop before the last step. MIT NANDA's July 2025 report "The GenAI Divide" found that sixty percent of organizations evaluated enterprise-grade AI systems, but only 20 percent reached the pilot stage and just 5 percent reached production. The five steps below are built to close that gap, one process at a time.
What is AI implementation, and why does it stall so often?
AI implementation is everything between deciding to use AI on a piece of work and having that work run on an AI system every day. It includes the model, and the model is the smallest part. The rest is understanding the process, redesigning it, connecting the system to the software the process runs on, building the path for cases the AI should not decide, putting controls around it, and operating it after launch.
That distinguishes implementation from two neighbors. An AI strategy decides where AI should go across a business; implementation makes it work in one place. AI adoption usually means people using AI tools in their own work; implementation changes how a process runs.
The research on failure points away from the technology. RAND's 2024 report on why AI projects fail cites estimates that more than 80 percent do, and its first root cause is a misunderstood problem: models "optimized for the wrong metrics" or that "do not fit into the overall business workflow and context." MIT NANDA concluded that most enterprise systems "fail due to brittle workflows, lack of contextual learning, and misalignment with day-to-day operations." BCG's 2024 research found that about 70% of AI challenges come from people and process issues, with technology accounting for 20% and algorithms only 10%.
The method that answers those findings has five steps. Each one has a question, an output and an owner.
| Step | The question it answers | What it produces | Who leads |
|---|---|---|---|
| See | How does the work run today, case by case? | A process map from real cases, an exception catalog, a baseline | Engineers, with the people who do the work |
| Rethink | What should the process become once AI takes the routine? | A redesigned flow with every exception type assigned | The process owner, with the engineers |
| Engineer | Can we build it inside our systems and prove it on real cases? | A working AI system, an exception queue, a live pilot with its limits and fallback already on | Engineers, with the process team testing |
| Harden | Will it hold up at full volume, on the worst day? | Complete limits, approvals, audit trail, fallbacks and monitoring, and the move from pilot share to full volume | Engineers, with risk and IT |
| Run | Does it keep performing as conditions change? | Operating reviews (weekly at first, then monthly), numbers against baseline, rule updates | Engineers and the process team, together |
The steps are sequential for one process, and their sequencing across a business is covered in the AI implementation roadmap.
How do you see a process before building anything? (See)
Start with cases, not interviews. Ask a team to describe its process and you get the official version. Pull two or three hundred recent cases, follow each one through every system it touched, and sit with the people who handled them, and you get the real one: the re-keying between screens, the spreadsheet that tracks what the ticketing tool cannot, the supervisor who approves anything over a certain amount by email.
Three outputs come out of this step.
A case-level map. Where each case enters, which systems it passes through, who touches it, how long each step takes and where it waits. System logs help here. Process mining reconstructs the flow from event data, and process intelligence adds the context around it; the difference between seeing a process and automating it is covered in process mining vs RPA.
An exception catalog. Every case type that does not follow the main path, how often it occurs, how long it takes and who resolves it. In many operations this is where a large share of the hours goes, which is why the challenges of AI implementation are mostly exception problems.
A baseline. Cycle time, cost per case, backlog, error and rework rates, measured before anything changes and agreed with finance. Without it, nobody can show later that the system made a difference, a point developed in the post on AI ROI as an operations metric.
How should the process change before AI goes in? (Rethink)
Automating a process as it stands locks in its workarounds. Many steps exist only because an old system could not do something, or because two teams never agreed who owned a field. The Rethink step removes them before anyone writes code.
Business process reengineering made this argument long before generative AI: redesign the work around the outcome, not around the existing steps. Process redesign is the more incremental version most operations use. With AI in the picture, the redesign answers specific questions:
- Which case types can the AI system handle end to end, and which does it prepare for a person?
- Which system is the source of truth for each piece of data, and where may the AI write?
- What does the AI need to know to recognize that a case is outside its limits?
- Who receives each exception type, with what context, within what service level?
- Which approvals stay with people because of risk, regulation or customer impact?
Consider a hypothetical field service company whose rescheduling requests pass through four teams: the contact center logs the request, dispatch checks technician availability, a planner decides, and billing adjusts the visit fee. Redesigned, the AI system gathers the job history and the technician calendar at intake, reschedules the requests that match a written policy, and sends the rest to one planner with the options already assembled. Three hand-offs disappear, and the planner's time goes only to the cases that need a decision.
The answers turn the process into management by exception: the system runs the routine, and people see the cases that need judgment. Some of the work may turn out to need no AI at all. Fixed rules on clean inputs are cheaper with conventional automation, as AI vs automation explains, and the wider case for redesigning whole processes is made in the business process automation guide.
What does engineering the AI system involve? (Engineer)
Engineering builds the redesigned process as a working system. Four parts get built together.
The integrations. The AI system reads cases from the tools the process already uses and writes results back to them, so nobody works in a separate window. This is often the largest single piece of the build, covered in AI integration services.
The AI workflow. The steps, tools, decisions and stop conditions the AI follows for each case type. Some of it may be an agent that takes actions across systems; the AI agents for business guide covers what an agent can own and what it must hand off, and an AI agent workflow defines the structure.
The exception path. The queue, the routing rules and the context package each person receives. This is the human in the loop, designed as a role with a service level.
The evaluation set. Real cases with known correct outcomes, including the hard ones, used to test every change before it reaches production.
Build for change in the model layer as well. Models improve every few months, and a system whose rules, integrations and evaluation set sit outside the model can adopt a better one after a test run instead of a rebuild.
Proof comes in two stages. A proof of concept tests whether the AI can do its part on real historical cases against pass marks set in advance. A pilot then runs the whole system on a controlled share of live volume, inside the real tools, with exceptions going to real people. The pilot runs with its limits, approvals, logging and fallback already on; Harden takes it from that controlled share to full volume. The pilot should be scoped as the first month of an operation, for the reasons argued in why AI pilots stall. Where the process is specific enough that no product fits, the build is custom; custom AI solutions explains which parts should be custom and which should not.
How do you harden AI and run it in production? (Harden and Run)
Harden prepares the system for its worst day and takes it from the pilot's share of volume to all of it. The pilot already ran with basic controls in place; hardening makes them complete. That means written limits on what it may do (amounts it may credit, records it may change, messages it may send) enforced in code as well as in instructions; approvals for sensitive actions; an audit trail that records inputs, decisions and actions in a form auditors can follow; fallbacks that route work to people when a connected system is down; and monitoring on accuracy, volume and drift. AI guardrails covers the controls in detail. Risk teams can review this against the NIST AI Risk Management Framework, released on January 26, 2023 and intended "to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems."
Run begins at go-live and does not end. Google engineers wrote in 2015 that "developing and deploying ML systems is relatively fast and cheap, but maintaining them over time is difficult and expensive," and the same holds for today's AI systems in operations. Inputs drift, policies change, vendors upgrade the tools the system connects to. Running means a standing rhythm:
- a review of the numbers against the baseline and of a sample of the AI's decisions, weekly in the first weeks after go-live and monthly once the system is stable;
- exception patterns turned into new rules or new handling, so the queue shrinks over time;
- connector maintenance when a connected system changes;
- a named owner with the authority to pause the system or switch it to a fallback.
What changes on the first day of production is covered under AI deployment. The people side of running, where roles and targets change around the system, is argued in AI change management. Keeping the engineers who built the system involved in running it shortens the path from a problem to a fix, which is the logic of forward-deployed engineering carried past go-live.
Where should you start, and who should do the work?
Start with one process: manual, critical, specific to your business, with real volume and an owner who wants it fixed. The AI for business operations guide covers how to pick it, and the roadmap covers the decision gates from selection to production and how to add the second process.
On who does the work, one survey points toward outside partners. In MIT NANDA's self-reported sample, "external partnerships with learning-capable, customized tools reached deployment ~67% of the time, compared to ~33% for internally built tools." Its authors note that these figures "reflect self-reported outcomes and may not account for all confounding variables," so read it as a direction, not a law. An internal team with engineers and process owners who have time to run the system can do all five steps. Whichever route you choose, settle early who will own Run, because it is the step with no end date.
Before the first conversation with any partner, have three things ready: the name of the process and its owner, a recent export of cases with their outcomes, and the operating numbers the owner already tracks. Those three items turn a sales meeting into a working session on your process.
Manthle's AI engineers work through all five steps on one process and then keep running it with the client's team; a pilot that works becomes a monthly operations contract. How that engagement is structured is on the AI implementation services page.