AI document processing, and where it still needs a person

Somebody in the business is retyping. Invoices into the accounting system, delivery notes into stock, forms into a spreadsheet, contracts into a summary nobody trusts. It is the most visible manual work in most companies, which is why it is the first thing anyone points an AI tool at, and why the pilots so often stall at eighty percent.

The technology is not the problem. The exception handling is. This note is about which documents are safe to automate, what the design has to do about the rest, and how to run a pilot that tells you something true.

What the technology is genuinely good at now

Reliability tracks how much a document looks like the last one. A supplier invoice from a supplier you have had for three years is close to solved. A handwritten delivery note photographed at an angle in a warehouse is not, and no amount of model choice changes that ordering.

The confidence score is the whole design

A system that returns an answer for every document is worse than one that refuses. What makes automated extraction usable is that it knows when it is unsure and routes those documents to a person, and the engineering question is where the threshold sits rather than which model you picked.

Set the threshold from what an error costs. A misread quantity on a stock receipt is a stock count problem someone will notice. A misread bank detail on a payment run is money leaving the business. Those two do not deserve the same threshold, and a single global setting across all document types is the most common design mistake here.

Vendors publish accuracy figures and they are usually measured on clean public datasets rather than on your paperwork. Treat them as a reason to run a trial and not as a result. Your own number, on your own documents, is the only one worth planning against.

Where a human pass is not optional

• Anything that authorises a payment. Extraction can prepare it. A person approves it.
• Anything with a legal consequence, including contract terms and dates that trigger obligations.
• Anything where the document is the record. If the original is discarded after processing, an error becomes permanent and undetectable.
• The first few weeks of any new document type, regardless of how well the pilot went on the old ones.

The failure to design for is quiet wrongness. A system that fails loudly gets fixed. A system that is confidently wrong two percent of the time seeds errors into records that other decisions are then built on, and it is discovered months later by an accident. That is the same argument for keeping a person in the loop that applies across operations generally, set out in how to use AI in operations without breaking the business.

What the rules actually require

Worth being precise here, because the AI regulation conversation is often applied to the wrong thing. The EU AI Act's transparency obligations under Article 50 became applicable on 2 August 2026. They require that people are told when they are interacting directly with an AI system unless that is obvious, and that providers of systems generating synthetic content mark those outputs in a machine readable format.

Back office extraction from your own paperwork is not usually the case Article 50 is aimed at, since nobody is interacting with it and it is not generating synthetic content. Where it does start to bite is when the same pipeline drafts a reply, produces a summary that goes to a customer, or fronts a conversational interface. Knowing which side of that line your deployment sits on is a five minute question that saves an argument later.

The rules that reliably do apply are data protection ones, because business documents are full of personal data. Where the paperwork touches health, financial or biometric information, most regimes in this region treat it as a higher category with stricter handling, and sending it to a third party processor is a decision with consequences rather than a procurement detail. Ask where the documents are processed and whether they are retained for training before the pilot, not after.

How to pilot it without committing

Pick one document type, the highest volume one with the most consistent layout. Collect two hundred real examples including the awkward ones people usually set aside. Run them through, and compare against what a person produces from the same set.

Then measure three things: how many were extracted correctly without help, how many were correctly flagged as uncertain, and how many were wrong while appearing confident. The third number is the one that decides whether to proceed, and it is the one most pilots do not measure because it requires checking the answers the system was sure about.

Where the output lands matters as much as the extraction. If it is going into a spreadsheet that three people edit, you have automated the input to a system that was already the problem, and the sequence in migrating from spreadsheets to a database without losing the history is the prior step. The reporting layer is a separate question again, covered in automating manual reporting without buying a BI platform.

Honest limits

If the volume is under a few hundred documents a month, the arithmetic rarely works. Integration, exception handling and the review process are most of the cost and they do not shrink with volume. At that size, redesigning the form so the data arrives structured in the first place beats extracting it afterwards, and it is a smaller project.

The other limit is that this does not remove the role, it changes it. The person who was retyping becomes the person who handles exceptions, and exceptions are the harder half of the job. Teams that plan for a headcount saving on day one tend to get neither the saving nor a working system. The same honest sizing applies to the other obvious AI deployment, and the case for it is in an AI chatbot for customer support, and what to trust it with.

For a smaller business weighing whether any of this is worth starting, Khaled Badr worked through the same arithmetic for a different tool in a chatbot for a small business: the maths changed. The conclusion transfers: the question is never whether the technology works, it is whether the volume justifies the exception handling.