Roughly four in five enterprises have adopted AI agents in some form. About one in nine runs them in production. That gap — reported across several 2026 surveys, including Accelirate's agentic AI statistics — is the single most useful number in this field, and it is not explained by which industry you are in.
It is explained by what you tried to automate.
Sector matters enormously for what you are allowed to build. It matters far less than people expect for what works. The automations that survive contact with production share the same four properties in a hospital, a law firm and a plumbing company, and the ones that die in pilot fail the same way everywhere.
Why do so many AI automation projects never reach production?
Because the pilot proved the model worked, not that the workflow did. The failures cluster around three causes — the data underneath was not ready, the automation had no owner in the business, and nobody agreed a baseline before starting, so nobody could say afterwards whether it helped.
The published figures disagree with each other, and the disagreement is informative. RAND puts AI project failure above 80%. MIT's widely-cited study found 95% of enterprise pilots delivered zero measurable P&L impact. Gartner expects organisations to abandon 60% of AI projects through 2026 for want of AI-ready data.
Those are not the same measurement. "Failed", "no measurable P&L impact" and "abandoned" are three different bars, which is exactly why the numbers range from 60% to 95%. What they agree on is the direction and the cause: the binding constraint is almost never model capability.
One breakdown of stalled agent deployments attributes them to infrastructure gaps (41%), governance and security barriers (38%) and ROI measurement failures (33%). Note that none of those three is "the model wasn't good enough."
What do the automations that survive have in common?
Four properties, and they hold across every sector we work in. The work is high volume, rule-heavy, low-judgement, and has a natural human checkpoint where a person was already reviewing the output. Automations missing any one of these tend to stall; automations with all four tend to ship.
High volume matters because the fixed cost of building, evaluating and maintaining an automation is roughly constant. Something that happens forty times a day pays that back. Something that happens weekly does not, however annoying it is.
Rule-heavy means a competent new starter could be trained on it with a written procedure. If the procedure exists, the automation has a specification. If it does not, you are not automating a process — you are trying to codify disagreement.
Low-judgement is the property people most often get wrong. The test is not whether the task is hard; it is whether two experienced people would produce the same output. Extracting a payment term from a contract is low-judgement. Deciding whether to enforce it is not.
A natural human checkpoint is what makes the whole thing deployable. If someone was already reviewing this work, you can ship at 90% accuracy and route the rest to them. If nothing was being checked, you need near-perfect accuracy before launch, and near-perfect is where projects go to die.
Which automations actually ship, sector by sector?
The same four shapes recur, wearing different clothes. What follows is the first thing we would build in each sector, chosen because it passes all four tests rather than because it demos well.
| Sector | First automation that ships | Why it passes |
|---|---|---|
| Healthcare | Prior authorisation assembly | Daily volume, payer rules are written down, a human already submits |
| Financial services | KYC and onboarding document extraction | Enormous volume, rule-bound, an analyst already reviews the file |
| Legal & professional | Contract and disclosure extraction | High volume per matter, schema-defined, a fee-earner already checks |
| Manufacturing | RFQ requirement extraction and quoting | Repetitive, spec-driven, an estimator already prices it |
| E-commerce | Catalogue and schema regeneration | Vast volume, template-driven, quality gate replaces the reviewer |
| Field service | Inbound call answering and booking | Constant volume, scripted triage, transfer to a human on request |
| B2B SaaS | Inbound qualification and routing | High volume, ICP is a written rule, an AE already qualifies |
Read down the "why" column and the pattern is more striking than the differences. Every one of them is document-heavy or conversation-heavy work, with a written procedure and someone already checking the output.
This is why we describe our AI automation work as a single practice rather than seven industry products. The engineering is substantially the same; the domain knowledge sits in the specification and the evaluation set.
What actually changes between sectors?
The constraint changes, not the use case. Every sector has one rule that determines what can be built and how — and getting that rule wrong is more expensive than picking the wrong use case, because it usually surfaces during a security review rather than during design.
In healthcare it is that PHI must never reach an unbound model, and that anything touching diagnosis or triage stays decision support with a named reviewer. In financial services it is that every automated decision must be reconstructable months later, which pushes you toward using models for extraction and retrieval while keeping decision logic deterministic.
In legal and professional services it is privilege: access control has to be enforced at the retrieval layer against matter permissions, never left to a prompt instruction. In manufacturing it is frequently the network — plant environments are segmented or air-gapped for good reasons, so on-premise inference is a design input rather than a preference.
Notice that none of these constraints changes which workflow to automate. They change the architecture around it. That is why sector expertise is worth paying for at the design stage and worth very little at the idea stage.
Does the sector affect how fast it pays back?
Yes, and mostly through regulatory drag rather than technical difficulty. Banking and insurance lead production adoption at around 47%, while healthcare sits near 18% and government near 14% — figures compiled from 2026 enterprise surveys that track approval burden far more closely than they track the difficulty of the underlying automation.
Payback periods follow the same logic. Sales operations shows the shortest reported payback at around 3.4 months, which is unsurprising: it has volume, a written qualification rule, an existing human checkpoint, and almost no regulatory approval layer.
Document-heavy automation is where the largest cost reductions are reported — figures in the 60–80% range appear across several 2026 analyses. Treat those as directional. They are typically self-reported by the organisations that succeeded, which is a survivorship problem, and they rarely state whether the baseline was measured before the project or estimated afterwards.
The honest version: reported production-stage returns are real but the sample is biased toward winners, and the projects that quietly stalled are absent from every one of these datasets.
How can you tell in advance whether yours will ship?
Score the candidate against the four properties before writing any code, then check that you can answer three questions. If you cannot answer all three, the project is not ready regardless of how good the use case looks.
What is the baseline? How long does this take today, how many touches does it need, what is the current error rate. Measured, not estimated. Without this you cannot prove value later, and ROI measurement failure accounts for roughly a third of stalled deployments on its own.
Who owns it after launch? A named person, not a department. Automations without an owner degrade quietly — the upstream form changes, accuracy drops, and nobody notices until someone complains.
Where does the data come from, and is it trustworthy today? This is the one that kills most projects. If the CRM disagrees with billing and nobody can say which record is right, an agent built on top will confidently act on the wrong one. Fixing that first is the whole reason business systems and data foundations exists as a separate practice.
Add a fourth if the automation touches people — hiring, credit, pricing, benefits, clinical care. Those carry oversight and evidence obligations that are cheaper to design in than to retrofit, which is what AI governance and assurance covers.
The short version
The question "what AI automation applies to my industry?" is the wrong one. The useful question is "which of our workflows is high-volume, rule-heavy, low-judgement, and already has someone checking the output?" — and the answer to that is usually sitting in your support queue or your document backlog, regardless of what sector you are in.
Pick one. Measure it before you touch it. Build the smallest version that a human still reviews. That sequence is what separates the one in nine from everyone else.