Intelligent Document Processing: 4 Tiers of Autonomy

Intelligent document processing use cases divide cleanly into four tiers, and the tier is set by what happens after the extraction, not by which department owns the document. Tier 0 reads and files. Tier 1 proposes a value a person confirms. Tier 2 writes to a system of record on its own. Tier 3 covers documents an agent should not process without a named human in the path at all. Sort your workflows that way and the automation question answers itself.

Our position at LeapForce is that the industry's standard framing, a long list of use cases grouped by function with finance here, HR there and logistics below, is the reason so many document projects stall after the pilot. Grouping by department tells you nothing about risk. Extracting a delivery date from a shipping manifest and extracting a diagnosis code from a discharge summary are the same technical task and completely different corporate exposures. The list you actually need is sorted by blast radius, and almost nobody publishes one.

The problem shows up in practice long before it shows up in a policy document. On Hacker News, in a thread about document extraction, the engineer posting as visarga, who says they build LLM-based information extraction and runs their own evaluation sets, put the real constraint in six words: extraction runs about 90% accurate in real scenarios, and "you can't reliably know which 90%." That is the whole design problem. If you knew which fields were wrong you would fix them. You do not, so you have to decide in advance what a wrong field is allowed to do.

The short answer: Tier every document workflow by what a silently wrong field can reach (read-only, propose-and-confirm, commit-to-record, or restricted) and only Tier 0 and Tier 2 workflows with an independent reconciliation check should run unattended.

Last updated: July 30, 2026.

The four tiers of document autonomy, sorted by what a silently wrong field can reach.

One disclosure before the substance: we have not run a controlled extraction benchmark of our own for this article. Every accuracy figure below comes from a named published source, and where the published sources disagree we say so rather than picking the flattering one.

What Intelligent Document Processing Actually Automates

Intelligent document processing is the practice of turning documents into structured records a system can act on: classifying the document, locating the fields that matter, extracting their values, checking those values against something, and handing the result to a downstream system. The field abbreviates it to IDP, and vendors sell it under that label alongside "document data extraction" and "end-to-end workflow automation". Optical character recognition is one stage inside that, not a synonym for it. Robotic process automation is the delivery mechanism at the far end, not the interpretation.

The distinction matters commercially because the three technologies fail differently. Character recognition fails visibly: garbled text is obvious. Rule-replay automation fails visibly too: the screen layout changed and the robot stopped. Field extraction fails invisibly. It returns a plausible date, a plausible amount, a plausible vendor name, and nothing in the output signals that the plausible value is wrong. That asymmetry is why document workflows need a governance model that click-replay automation never needed.

It is also why the vocabulary in most buying conversations is unhelpful. Teams describe the problem as "we retype things", so they shop for a typing replacement. The actual problem is that a document arrives, someone decides what it is, someone decides which numbers on it are authoritative, someone checks those numbers against a second source, and someone commits the result somewhere it becomes true for the rest of the company. Only the middle steps look like typing.

What it is not

Intelligent document processing is not a search index. Making every contract findable is a retrieval problem, and it is a good one to solve, but it does not extract obligations or renewal dates into fields anything can act on.

It is not a rules engine either. The reason a human still touches most invoice exceptions is not that the amount was unreadable. It is that the amount was readable and did not match the purchase order, and resolving that mismatch requires knowing whether this vendor habitually splits shipments. That is reconciliation logic, and it is separable from extraction.

The practitioner view lines up with this. Writing on Hacker News in March 2026 about logistics document automation, michelderijk described the split plainly: "the OCR angle is only half the problem", with the real bottleneck in matching extracted line items to cost centres and vendor master data across carriers that all format their invoices differently. Their estimate: recognition accounts for roughly 70% of the perceived effort while relationship extraction and reconciliation is where teams underestimate the work.

The three questions a use case has to answer

Before a document workflow is a candidate for automation at all, it has to have answers to three things:

1. What is the authoritative field? Not the fields you could extract — the ones a decision depends on. Most documents have between two and six.
2. What does the extracted value get checked against? A purchase order, a master data record, a prior version of the same document, a total that must sum, a second document. If the answer is "nothing", the workflow cannot leave Tier 1.
3. What becomes true downstream? A file moves. A ticket routes. A ledger entry posts. A payment releases. A person is scored. The further down that list you go, the higher the tier.

The 30-Day Wrong-Field Test

Here is a diagnostic you can run over your whole document estate in a single working session, and it is the step most intelligent document processing business cases skip. We call it the 30-Day Wrong-Field Test, and it replaces the usual volume-times-minutes business case with a consequence question.

For each document workflow, ask: if one authoritative field came out wrong and nobody noticed for thirty days, what would we have to do about it? Answer in one sentence, then place the workflow:

Thirty days is not arbitrary. It is roughly the interval at which most reconciliation cycles close, which means it is the point after which an error stops being a correction and becomes a restatement. Errors caught inside the cycle are cheap. Errors caught after it involve other people, and often a lawyer.

Two rules make the test honest:

• Answer for the worst field, not the average field. A workflow that extracts fourteen fields is tiered by the most consequential one. Vendor bank details sit on the same page as a delivery address; the page is tiered by the bank details.
• Answer for silent failure, not loud failure. "The system would have thrown an error" is not an answer, because the failure mode under discussion is the one where it does not. Extraction returns a confident wrong value far more often than it returns nothing.

Run this against twenty workflows and the shape of your programme appears immediately: a large Tier 0 population nobody is arguing about, a Tier 1 middle where most of the labour actually sits, a small Tier 2 set worth real engineering, and a Tier 3 set that should be taken off the roadmap and put in the policy.

Tier 0: Read-Only Document Use Cases

Tier 0 covers every document processing use case where the output is a pointer, a label, or a summary, and nothing is written to a system anyone treats as authoritative. A wrong field here costs someone a search. That is all. This is where unattended automation is genuinely uncontroversial and where most organisations should start.

Best for: teams with a large unstructured backlog and no appetite for a governance fight in quarter one.

What it covers: classification and routing of inbound mail and shared inboxes; splitting multi-document PDFs into their constituent files; tagging and indexing scanned archives; extracting metadata for retention scheduling; deduplication across ingest channels; building a searchable layer over contracts, policies, and manuals; summarising long documents for a human who will read the original before acting.

Why it is safe: the extracted value is never the basis of a decision on its own. A misclassified document is recoverable by anyone who searches for it. Nothing posts, nothing pays, nothing scores a person.

What still goes wrong: two things. First, retention. If your classifier assigns retention categories, a wrong category can cause a document to be destroyed on schedule when it should have been held, and that failure is not recoverable — it graduates the workflow to Tier 2. Second, access. A routing agent that can read every shared inbox has a read footprint far larger than any individual employee, and that is an access-control question, not a document question.

Verdict: run unattended, log everything, and check whether any of your "read-only" classifiers are secretly deciding a retention or access outcome. If one is, it is not Tier 0.

Tier 1: Propose-and-Confirm Document Use Cases

Tier 1 covers use cases where extraction produces a draft value that a person confirms before it takes effect. The agent does the reading; the human does the committing. This is the largest tier in most organisations and the one that delivers the majority of realised savings from intelligent document processing, because the expensive part of manual data entry is locating and transcribing values, not approving them.

Best for: any workflow where a wrong value would be caught by the next human who looks, and where that human was going to look anyway.

What it covers: invoice coding proposals; expense report line extraction; purchase order matching where the match is presented rather than applied; CV and application parsing into a review queue; onboarding paperwork field capture; customer support attachment triage; contract clause extraction into a redline queue; insurance claim intake; loan document collection and completeness checks; supplier onboarding forms.

The design rule that makes Tier 1 work: the confirmation step has to be cheaper than the extraction it is confirming, or the automation nets to zero. If your reviewer has to open the source document and read it end to end to confirm three fields, you have moved the work rather than removed it. Good Tier 1 interfaces show the extracted value, the exact region of the page it came from, and the check it passed or failed — so the reviewer confirms in seconds and only opens the document on a flag.

The failure mode nobody budgets for: automation bias. When ninety-something percent of proposals are right, reviewers stop reading them. This is not a hypothetical concern invented by vendors; it is written into regulation. Article 14 of the EU AI Act requires that people assigned to oversee a high-risk system "remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)", and that they be able to "disregard, override or reverse" the output. A confirmation step that has decayed into a click is not oversight, and after a while it is not a control either.

The practical counter is to sample. Route a small random percentage of proposals to a blind second review where the reviewer does not see the extracted value, and track the disagreement rate over time. There is no published standard for the rate, and we are not aware of a study that sets one. Pick a rate that gives you a usable number of disagreements per month rather than a round percentage, and raise it whenever the disagreement rate moves. The measurement matters; the specific percentage is a convention you should set from your own volume. If it climbs, your reviewers have stopped reviewing. This is the one measurement that tells you whether Tier 1 is still Tier 1.

For a fuller treatment of when an approval step is a genuine control and when it is theatre, see our earlier analysis of human-in-the-loop automation.

IBM's technical channel published a useful overview of how human-in-the-loop design is actually structured in AI systems, and it is worth ten minutes before you design your review queue.

Verdict: default here for anything financial, personal, or contractual until you have a measured error rate on your own document mix.

Tier 2: Commit-to-Record Document Use Cases

Tier 2 covers use cases where the extracted value is written to a system of record without a human confirming that specific document. A ledger entry posts. A shipment releases. A policy updates. A payment queues. A wrong field here produces a correction, a reversal, or a restatement. This is what accounts payable teams mean by straight-through processing. These document processing use cases are automatable, and the qualifying condition is narrow: there must be an independent check that does not depend on the extraction being right.

Best for: high-volume, low-variance document classes where a second data source already exists.

What qualifies: three-way matched invoices below a threshold, where the purchase order and goods receipt supply the check; remittance advice applied to open invoices, where the total must reconcile; shipping documents where the manifest reconciles against the booked order; utility statements where consumption sits inside a historical band; recurring subscription invoices with a stable amount; bank statement import where the closing balance must equal the sum of the movements.

What does not qualify, even at high volume: anything where the document is the only source. A one-off invoice from a new vendor has nothing to match against. The extraction is the sole authority, so the only available check is a human, and the workflow is Tier 1 no matter how routine it looks.

The threshold question. Every Tier 2 programme ends up with a value threshold below which documents post unattended. Set it by consequence rather than by convenience: the threshold should sit below the amount at which a reversal requires anyone outside the team to be told. In most finance functions that is materially lower than the number initially proposed, and it is worth writing down why it was set where it was, because that reasoning is the first thing an auditor asks about.

The vendor bank detail exception. One field breaks the tier logic entirely. Payment destination changes extracted from an inbound document should never post unattended regardless of amount, because the failure is not an error. It is the target of an attack. Business email compromise accounted for $3,046,598,558 in reported losses in 2025 according to the FBI's Internet Crime Complaint Center annual report, placing it second among cyber-enabled fraud types by total loss. A document-processing agent that reads a bank detail change out of a PDF and writes it into vendor master data has automated the most profitable step of that attack. Route bank detail changes out of band, to a channel the document cannot reach.

Verdict: automate where an independent reconciliation exists, cap by consequence, and carve out payment destination changes permanently. Our analysis of governing the commit step in AI-powered workflows goes deeper on why the write is the control point rather than the read.

Tier 3: Restricted Documents

Tier 3 covers document classes where a wrong extraction affects a person's rights, health, employment, credit, or legal position. These are not "hard" use cases to be attempted later with better models. They are use cases where the regulatory obligations attach to the decision the document feeds, and where full autonomy is either prohibited or so heavily conditioned that it stops being autonomy.

The EU AI Act's Annex III lists eight high-risk areas, and several of them are, in practice, document-processing workflows. Point 4 covers systems "intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates" — that is CV parsing plus a ranking, which is exactly how most HR document automation is sold. Point 5(b) covers systems "intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud" — which reaches loan document processing the moment the extracted values feed a score. The other areas named in Annex III include education and vocational training, law enforcement, migration and asylum, and administration of justice: each of them a domain that runs on documents.

The distinction that matters here is one buyers routinely get wrong. Whether the system makes the final decision is not the test. A parser that produces an input a human underwriter or recruiter then uses is still inside the scope, because the scope attaches to purpose, not to autonomy level.

What belongs in Tier 3: patient records and clinical documents; anything feeding a credit or underwriting decision about an individual; CV screening where the output ranks or filters candidates; immigration and visa documentation; documents forming part of legal proceedings; benefits and eligibility determinations; disciplinary and termination files; signed contracts where the extracted term becomes the operative term.

What Tier 3 does not mean. It does not mean no automation. Classification, redaction, completeness checking, and routing of these documents are all Tier 0 activities and they remove real labour. What Tier 3 forbids is the unattended commit and the unattended judgement. Our guide to EU AI Act compliance for deployers covers the obligations that follow once a workflow lands here.

The residency question that comes with it. Tier 3 documents usually carry constraints on where the bytes may travel. That makes model routing a compliance control rather than a cost control: a document class that may not leave a jurisdiction cannot be sent to whichever endpoint is cheapest this week. If your extraction layer cannot express "this document class routes only to these endpoints", it cannot serve Tier 3, and no amount of accuracy fixes that. Masking sensitive values before they reach a model helps for some classes; we have written separately on inline data loss prevention at the gateway, and it is a partial control, not a permission slip.

Verdict: automate the handling, never the determination, and write the boundary into policy rather than into a prompt.

The Use-Case Map: 32 Document Workflows by Tier

The enumeration most articles lead with is more useful once it is sorted by consequence. Below are thirty-two common document use cases with their tier and the check that governs them. Tiers assume the default configuration described in each section; a workflow moves up a tier the moment its output starts feeding a decision about a person.

Two entries in that table usually cause an argument, and both are deliberate.

Retention tagging sits at Tier 2, not Tier 0, because scheduled destruction is the one read-only-looking workflow whose error is permanent. If your classifier's output eventually causes a document to be deleted, the classifier is committing to a record.

CV parsing appears twice, at Tier 1 and Tier 3, and the difference is a single design choice. Parsing an application into fields a recruiter reads is a productivity tool. Parsing it into a score that orders the queue is a filter, and a filter that "analyses and filters job applications" is named in Annex III. Same model, same document, different regulatory position.

What the Accuracy Numbers Actually Say

Vendor pages routinely quote 99%-plus extraction accuracy. The published evidence does not support that as a production expectation on difficult documents, and the gap between the two numbers is where document automation programmes die.

The most directly relevant recent measurement is CC-OCR V2, a benchmark published in May 2026 by a team including Zhipeng Xu, Zhenghao Liu and Dayiheng Liu, built specifically around "practical enterprise document processing tasks" and deliberately loaded with hard and corner cases: 7,093 high-difficulty samples across five tracks, evaluated on 14 advanced multimodal models. Its conclusion is blunt — "current models fall short of real-world application requirements" and "even state-of-the-art LMMs exhibit substantial performance degradation across diverse tasks and scenarios."

The per-track breakdown is the part worth internalising, because it explains why demos succeed and rollouts fail:

Reading is close to solved. Extracting the specific fields a business process depends on is not, and neither is grounding — the ability to say which region of the page a value came from, which is precisely the capability a Tier 1 review interface needs to make confirmation fast. Reading is not the bottleneck. Pointing is. The paper notes that grounding "emerged as the most challenging track: many models achieve low grounding accuracy even when they perform strongly on recognition or QA." A model that reads well but cannot point is a model whose output cannot be cheaply checked.

The human baseline is better than most people assume

The comparison that should anchor a business case is not "machine versus perfect", it is "machine versus the process you run today". A systematic review and meta-analysis of error rates in clinical research data processing by Garza and colleagues, published through PubMed Central and covering 84 manuscripts after outlier exclusion, reports pooled error rates of 0.14% (95% CI 0.08–0.20) for double data entry, 0.29% (0.24–0.35) for single data entry, and 0.74% (0.21–1.60) for optical scanning. It is a preprint and it comes from a clinical research setting rather than a finance back office, so treat it as an order-of-magnitude reference rather than a benchmark for your invoices.

Read against the extraction numbers, it says something uncomfortable and useful. Careful humans working with a verification step operate at roughly one error per seven hundred fields. Automated optical processing in those same studies was several times worse than careful humans and roughly twice as bad as unverified single entry. The reason automation still wins is throughput and cost, not accuracy — which means the correct design goal is not to match human accuracy but to make errors cheap to catch. Tiering is how you do that.

Why the "which 90%" problem is the design constraint

Return to the practitioner quote from the top of this article. If extraction is 90% accurate and you cannot tell which 10% is wrong, then every consuming process needs one of three things: a check that does not depend on the extraction, a human who was going to look anyway, or a consequence small enough that being wrong is survivable. Those three things are Tier 2, Tier 1, and Tier 0 respectively. There is no fourth option, and confidence scores are not one — a confidently wrong extraction reports high confidence, which is what makes it dangerous.

We could not independently verify the market-sizing and adoption figures that circulate widely in this category. Gartner's Peer Insights market page returned a 403 to every fetch method we tried, and the "99% accuracy" and "reduces processing time by 70%" figures that appear in dozens of vendor guides trace back to vendor pages rather than to a published methodology. They are excluded here rather than repeated.

What a Document-Processing Audit Trail Has to Contain

"Audit-ready" is the most common unearned claim in intelligent document processing marketing. An auditor does not ask whether your system is audit-ready. They ask you to reproduce a specific decision on a specific document on a specific date, and to show that the controls you described were operating at that moment. That is a records problem with a fixed shape.

A defensible document-processing trail answers seven questions per document:

The fifth row is the one most implementations miss, and it is the most valuable. The diff between what the machine extracted and what a human corrected is simultaneously your accuracy measurement, your model-drift alarm, and your evidence that oversight was real. Systems that overwrite the machine value with the corrected one destroy all three.

Log retention is not a matter of preference either. Under Article 26 of the EU AI Act, deployers of high-risk systems must keep the automatically generated logs "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months", subject to other applicable law. Six months is a floor set by the AI regulation, and it sits underneath, not instead of, whatever your sector's record-retention rules already require.

Article 26 also imposes something more demanding than logging: deployers must "assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support". Authority is the operative word. An oversight role that can flag but cannot stop is not oversight in the sense the regulation means, and it is not much of a control in the sense your auditor means either. We have written at length on what it takes to make agent action audit trails actually provable, including why recording what was refused matters as much as recording what ran.

What Document Processing Costs Per Page

Unit costs in this category are public and low, and the published prices are almost never what determines the total. Here are real figures fetched on 30 July 2026 from two of the major cloud vendors, listed so you can do arithmetic rather than accept a range.

Google Cloud Document AI pricing, fetched 30 July 2026:

Amazon Textract pricing for the US West (Oregon) region, fetched 30 July 2026: $0.0015 per page for plain text detection on the first million pages, $0.015 per page for table extraction, $0.05 per page for form extraction, and $0.025 per page for identity document analysis up to 100,000 pages.

Run the arithmetic on 100,000 invoices a year and the extraction line is roughly $10,000 on Google's invoice parser or a few thousand dollars on Textract's form API. That is not the number that decides the project.

The three costs that actually decide it

Exception handling. At a 10% exception rate on 100,000 documents, you have 10,000 human touches a year. At five minutes each that is roughly 830 hours — comfortably more than the extraction spend, and it is the number that moves when accuracy moves. A programme that improves accuracy from 90% to 95% halves this line; a programme that improves it from 99% to 99.5% barely touches it. Know which regime you are in before you buy.

Reconciliation engineering. Tier 2 is only Tier 2 because an independent check exists, and building those checks against real master data is the work practitioners consistently describe as underestimated. Budget it as integration work, not as configuration.

The per-document review interface. If confirming a Tier 1 proposal takes ninety seconds instead of ten, you have paid for the extraction and kept the labour. The grounding scores above are the technical reason this is harder than it sounds: a system that cannot point at where a value came from cannot make review fast.

Assembled, a 100,000-invoice year at a 10% exception rate looks roughly like this: about $10,000 of extraction on Google's invoice parser, plus $438 a year per deployed processor version, plus roughly 830 hours of exception review, plus a one-off reconciliation build measured in weeks of engineering rather than in pages. Put your own loaded hourly rate against the 830 hours and the ranking of the three lines will not change: the human line dominates, and it is the only one that moves when accuracy moves.

There is a fourth cost that only appears at Tier 3: the cost of proving, months later, that a control was operating. That cost is close to zero if the trail described in the previous section exists from day one and close to unbounded if it does not.

Choosing Where to Start

Most intelligent document processing programmes pick their first workflow by volume. Pick by tier instead, and pick with an eye to what the first result has to prove internally.

Choose a Tier 0 workflow first if your organisation has never run an AI system against corporate documents, if security review is the binding constraint rather than technical feasibility, or if you need a result inside a quarter. Classification and splitting produce visible relief quickly and generate no governance argument, which buys you the credibility to attempt Tier 1.

Choose a Tier 1 workflow first if you already have a defined review team and the labour you want back is transcription rather than judgement. Invoice coding and claim intake are the canonical entries. Insist on a review interface that shows provenance, and instrument the disagreement rate from the first day rather than adding it later.

Choose a Tier 2 workflow first if you have a document class with high volume, low variance, and an existing independent check — three-way matched invoices under a threshold being the obvious one. Do not choose Tier 2 first if the reconciliation logic still has to be built; that is a six-month integration project wearing a document-automation costume.

Do not choose a Tier 3 workflow first, even if it is where the pain is loudest. Start with the Tier 0 handling around those documents — classification, redaction, completeness checks — and leave the determination alone until the trail from the audit section exists and has been tested by someone who did not build it.

A sequencing note that generalises beyond documents: our platform's rollout guidance for the AI gateway is "Observe first. Enforce second. Optimize third." — point traffic at a controlled path in observe mode, learn what is actually happening, then turn on rules, then tune. The same order works for documents. Run extraction in shadow against a live human process, measure the disagreement, and only then move a workflow up a tier. Teams that enforce before they observe end up setting thresholds by intuition and defending them by anecdote.

When Manual Processing Still Wins

Not every document processing workflow should be automated, and saying so is not modesty. Four situations where the manual process is the correct answer:

Low volume with high variance. Fifty documents a month, each formatted differently, is a configuration burden that never amortises. The exception rate on genuinely varied low-volume documents approaches the document count, at which point you have paid for a system to route work to the same person who was doing it.

The document is a negotiation artifact. Contracts under active negotiation, disputed claims, and anything where the wording matters more than the values are not extraction problems. Someone has to read them. Extraction can index and locate; it should not summarise the position.

The process is about to change. Automating a document workflow freezes it. If the underlying process is being redesigned, or the form is being replaced with a structured intake, automation is a bet on a layout that will not exist in a year. Fixing the intake beats parsing the output — a supplier portal that captures structured data removes the document entirely, and that is a better outcome than reading it well.

The consequence is asymmetric and the volume is small. A dozen Tier 3 documents a month do not justify a governance apparatus. Handle them by process, write the rule down, and spend the engineering on the Tier 1 population instead.

Where This Is Still Uncertain

Several things in this document processing framework are our reasoning rather than established fact, and they are the parts most likely to be wrong.

The tier boundaries are judgements, not standards. No regulator publishes a four-tier document taxonomy. Annex III supplies the outer boundary for the EU and only for high-risk purposes; everything below that line is our framing, and a reasonable practitioner could argue that retention tagging belongs at Tier 1 with a sampled review rather than at Tier 2, or that remittance application is Tier 1 in a business with messy customer master data.

Thirty days is a convention. It matches common reconciliation cycles, but a company that closes weekly should test at seven days and one with an annual regulatory filing should test at the filing date. The mechanism is the question, not the interval.

The accuracy figures come from different worlds. CC-OCR V2 is a deliberately hard benchmark on multimodal models; the clinical meta-analysis measures human keying and older optical processing in trial data capture. Neither measures your invoice mix, and putting them side by side is a framing device, not an apples-to-apples comparison. The honest position is that nobody can tell you your production accuracy without processing your documents.

We have not run our own extraction benchmark, as noted at the top. Where this article makes an empirical claim it is sourced to someone who did; where it makes a design claim it is argued, and you should push back on it.

The regulatory anchor here is European. Annex III is the clearest published list of document-adjacent high-risk purposes, which is why we use it, but it is EU law. Organisations outside the EU inherit the same consequence logic without the same statutory boundary, and their Tier 3 line is usually drawn by sectoral rules — health, lending, employment, records retention — rather than by a single horizontal statute. Use the tiers as the mechanism and your own counsel for the line.

Regulatory scope is moving. EU AI Act obligations phase in over several years and guidance on classification is still being issued. A workflow that sits below the high-risk line today may not next year, particularly in HR and lending, where the line is drawn by purpose rather than by technology.

How LeapForce Fits

LeapForce does not sell an extraction engine, and this article is not an argument that you need one from us. Choose whichever parser handles your document mix best. The layer we build is the one that sits around it: who the processing agent is, what it is allowed to touch, what it did, and what that cost.

That maps to the tiers directly. Tier 1 and Tier 2 workflows need an agent with an identity rather than a shared key — an owner, a scope, and an expiry, so that when the person who built the invoice coder leaves, the agent does not become an orphaned credential with production access; this is the non-human identity model we have written about before, and it is what makes the audit trail's second row answerable. Workflows chain the extraction to the downstream commit with a human approval gate where the tier requires one, so the gate is part of the run rather than a convention people follow. Observability and audit supplies the tracing and action record behind the seven-row table above. On our published build status, gateway routing, tracing and SSO are live; inline masking and dollar budgets are in development; compliance evidence packs and shadow-AI discovery are on the roadmap — so if your requirement today is a one-click evidence pack for an auditor, we are not there yet and you should plan the trail yourself.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.