- 01
Value concentrates in document-heavy, exception-driven processes — not in the processes with the most steps.
- 02
Document intelligence with citation to the source page is the foundation every other workflow reuses.
- 03
Straight-through processing rates below roughly a third mean the workflow belongs in assist mode, not full automation.
What AI business automation actually changes
Traditional automation industrialised the deterministic parts of enterprise processes: structured data moving between systems along paths that never varied. What it could not touch was the unstructured majority — the emailed invoice with the supplier's own layout, the contract clause that needs interpreting, the claim file missing one document, the exception that a human resolves by reading three systems and applying judgement. Those steps are where processing time, error rates and headcount concentrate, and they are the reason large shared-services operations remained labour-intensive despite years of workflow investment. AI business automation addresses that residue directly. Document intelligence reads and extracts from unstructured input with a citation back to the source page. Retrieval grounds decisions in the policy content that governs them. Orchestration sequences the work across systems, deciding when to proceed and when to route to a human. The change is not that automation becomes possible, but that the boundary of what is automatable moves from structured to semi-structured work, and that the exception queue — historically the most expensive part of any process — becomes something a system can prepare rather than something a human must assemble from scratch. Understanding this correctly matters commercially, because it means the return comes from a different place than most business cases assume: not from eliminating the simple steps, which were already cheap, but from compressing the exception handling that consumed the majority of the cost.
Selecting processes that will actually pay back
Process selection determines outcome more than any technology decision. Score candidates on five dimensions. Volume: enough annual instances that a fixed engineering investment amortises, which in most enterprises means tens of thousands rather than hundreds. Document dependency: the more the process turns on reading unstructured input, the larger the gap AI closes relative to existing tooling. Exception rate: processes where a meaningful share of instances fail first-pass are where the current cost sits. Decision reversibility: workflows where an error is caught downstream and corrected cheaply can go live sooner than those where an error reaches a customer or a regulator. System access: whether the data and write paths exist through interfaces with acceptable latency and entitlement propagation, because a process that requires screen-scraping a legacy system will consume the entire budget in integration. Then apply a filter that most business cases omit — ask whether the process should exist at all. A substantial share of enterprise back-office volume exists because an upstream system produces incomplete data, a form is unclear, or a policy is ambiguous. Automating that work industrialises a defect. The strongest first candidates are typically invoice and remittance processing, claims or application intake, supplier and customer onboarding documentation, and internal service desk request handling — high volume, document-heavy, reversible, and already instrumented enough to establish a credible baseline.
The reference architecture
A durable implementation has five layers, and enterprises that build them once serve every subsequent workflow at marginal cost. The ingestion and document intelligence layer classifies input, extracts fields against a defined schema, validates against reference data, and attaches a citation — document, page, coordinates — to every extracted value so a human reviewer can verify in seconds rather than re-reading the file. The knowledge and retrieval layer indexes the policies, procedures and reference content that govern decisions, with metadata for jurisdiction, entity and effective date so the system reasons over the version in force. The tool layer exposes the systems of record through interfaces that enforce the caller's entitlements, apply authority limits in code rather than in prompt instructions, and behave predictably when a dependency is slow. The orchestration layer sequences steps, decides between straight-through processing and human routing, handles retries and partial failure, and preserves state so an interrupted case resumes rather than restarts. The evaluation and observability layer holds golden test sets, runs them in the deployment pipeline, traces every case end to end, and reports accuracy, straight-through rate, cost per case and human review time. Skipping the fifth layer is the most common architectural mistake: without it the operation cannot tell whether a change improved anything, and quality regressions surface as complaints from the business rather than as signals in a dashboard.
Human-in-the-loop design that stays economic
Almost no enterprise process runs at full straight-through processing, and designing as though it will is how programmes lose their business case. The right question is what the human does when the system routes to them. Poor designs hand a reviewer the same raw file the system received, so the human repeats all the work and the only saving is the small share of fully automated cases. Good designs hand the reviewer an assembled case: extracted values with citations, the policy passages that apply, the specific reason for routing, the actions available, and a one-click path to confirm or correct. Measured review time on well-designed workflows typically falls by more than half even when the straight-through rate is modest, and that reduction — not the automation rate — is usually where the majority of the benefit sits. Design the correction path to feed the evaluation set, so every human override becomes a test case rather than a lost signal. Set confidence thresholds per field rather than per document, since a system may be highly reliable on invoice totals and unreliable on line-item descriptions. And keep authority limits explicit and enforced in the tool layer: the value at which a payment, adjustment or approval requires a human should be a configuration item with an audit trail, not a sentence in a prompt.
Controls, audit and the evidence regulators expect
Automated decisioning in finance, insurance, healthcare and regulated services attracts scrutiny proportionate to consequence, and the evidence must be produced as the workflow runs rather than reconstructed afterwards. Retain, per case, the input received, the configuration and model version in force, the retrieved policy content, the extracted values with their citations, the decision or routing outcome with the reason, the human action if any, and the timestamps. Tier workflows by consequence so a low-risk internal classification task does not require the evidence pack of a customer-facing eligibility decision. Test for disparate outcomes across customer segments where the process affects individuals, and document what was tested and what was found. Treat every retrieved or ingested document as untrusted input for prompt-injection purposes, since documents supplied by third parties are an obvious attack surface for any system that acts on what it reads. Define what constitutes an incident, who can suspend a workflow, and how a suspended workflow falls back to a manual path without stranding in-flight cases. Enterprises that build this into the platform layer answer an audit request in hours; those that treat it as documentation produce a project for every request and eventually restrict the programme rather than the risk.
Unit economics and the scaling curve
Attribute cost to the workflow from the first production case: inference by model and step, document processing, platform consumption, storage, and the human review time the workflow still requires. Compare against the fully loaded baseline cost per case measured before launch. Two patterns recur. First, cost per case usually falls with maturity rather than at launch, because the early configuration over-uses expensive models and retrieves more context than the task needs; teams that instrument from day one typically find substantial reduction available through routing simpler steps to smaller models, caching stable retrievals and trimming context. Second, the marginal cost of the second and third workflow should be far below the first, because ingestion, retrieval, tool layer, evaluation and audit are already built. If the third deployment costs what the first did, the organisation built three projects rather than a platform, and the programme's economics will not survive scrutiny at scale. Report both numbers to the sponsor: cost per case by workflow, and the deployment cost curve across workflows. The second number is the one that justifies continued platform investment, and it is the one most programmes never produce.
A twelve-month sequence
Quarter one: select one workflow, establish the baseline with the operations team, build the ingestion and document intelligence layer properly, and run in shadow against live volume while comparing outputs to human results. Quarter two: release to production on a limited share of volume with daily exception review, ramp as the exception rate stabilises, and instrument cost and review time from the first case. Quarter three: deploy the second workflow reusing the platform layers, and measure the deployment cost curve deliberately — this is the quarter that proves or disproves the platform thesis. Quarter four: extend to a third and fourth workflow, automate governance evidence collection, publish the unit economics, and review which processes on the backlog should be eliminated upstream rather than automated. Throughout, keep a named business owner per workflow who accepts the metric, a platform team that owns the shared layers, and a quarterly review that retires what is not working. Enterprises that follow this sequence have a capability at the end of the year. Those that run four parallel pilots with four different vendors have four demonstrations and no platform, which is the most common and most expensive outcome in this category.
- Value concentrates in document-heavy, exception-driven processes — not in the processes with the most steps.
- Document intelligence with citation to the source page is the foundation every other workflow reuses.
- Straight-through processing rates below roughly a third mean the workflow belongs in assist mode, not full automation.
- Attribute inference and platform cost to the workflow from day one or the unit economics will surprise you at scale.
- The second and third deployments should be materially cheaper than the first; if they are not, you built a project rather than a platform.
Questions leaders ask us
- How is AI business automation different from RPA?
- RPA industrialises deterministic steps on structured data along fixed paths. AI business automation extends into unstructured input and judgement-dependent steps — reading documents, applying policy, deciding when to route to a human. In practice the two coexist: RPA still moves data reliably between systems, while AI handles the ingestion, interpretation and exception preparation that RPA could never address.
- What straight-through processing rate should we expect?
- It varies widely by process and data quality, so treat any vendor benchmark with caution. Validate it yourself: take a hundred real cases and count how many are genuinely resolvable end to end with the data, authority and policy clarity available today. If the answer is below roughly a third, the workflow will deliver more value in assisted mode, where a human reviews an assembled case, than in full automation.
- Where should we start if the process landscape is large?
- Start with one high-volume, document-heavy, reversible process where system access already exists and a credible baseline can be measured. The purpose of the first deployment is to build the reusable platform layers and prove the operating model, so choose for learnability and measurability rather than for the largest theoretical saving.
- How do we keep automated decisions auditable?
- Retain per case the input, configuration and model version, retrieved policy content, extracted values with citations, the outcome and its reason, and any human action, with timestamps. Build this into the platform layer so evidence accumulates automatically. Tier the requirement by consequence so low-risk workflows are not burdened with the controls a customer-facing eligibility decision needs.
- What team is needed to run this in production?
- A named business owner accountable for the outcome metric, platform engineers who own the shared ingestion, retrieval, tool and evaluation layers, an evaluation specialist who maintains golden sets and reviews drift, and an operations owner who runs the exception queue and triages incidents. This is a permanent run function, not a project team that disbands at go-live.
Sources
- [1] Generative AI's largest measured productivity effects concentrate in knowledge work involving unstructured content and exception handling. The economic potential of generative AI: The next productivity frontier — McKinsey & Company, 2023
- [2] Enterprise AI programmes stall most often on operating model, data access and governance rather than model capability. Gartner research on AI adoption and implementation barriers — Gartner, 2024
- [3] Risk management for AI systems should be proportionate to consequence and evidenced continuously through the lifecycle. AI Risk Management Framework (AI RMF 1.0) — NIST, 2023