Document OCR in production: the parts that are not the model

Every document-extraction demo looks the same. Upload a passport, watch the fields appear, everyone nods. Then it goes live and the interesting problems start — and almost none of them are about extraction accuracy.

What follows is from building ID capture for a hotel check-in system, where a guest photographs an identity document at the desk and the record is filed against their stay. The model was the easy part.

It is slower than the demo, and sometimes much slower

A clean image on an idle provider comes back quickly. A phone photo taken at a badly lit reception desk, on a provider under load, can take tens of seconds. Occasionally far longer than anyone would sit and watch.

That single fact rules out the obvious design. If extraction happens inline in the request that uploads the file, you have built a form that sometimes hangs for a minute and then times out with the guest standing there.

The shape that works: accept the upload, acknowledge it immediately, extract asynchronously. The record exists from the moment the photo lands, with the fields arriving after. A receptionist can keep working, and a slow read degrades into a short wait rather than a failure.

Rate limits arrive before you expect them

Free and entry tiers are sized for evaluation, not for a Saturday afternoon. When several desks upload at once you will hit a limit, and the provider's response to being over the limit is an error, not a queue.

So the queue has to be yours. Work goes into it, a worker drains it at a rate you control, rejections are retried with backoff, and a burst becomes slower rather than lost. This is the same discipline as any outbound integration: treat the other side as unreliable and make the work replayable.

Plan the tier before rollout, not after the first incident. Extraction cost per document is knowable in advance, and comparing it against the manual alternative is a two-line calculation worth doing honestly.

Confidence is a product decision, not a model setting

The model will return something for almost any input. A blurred date of birth still produces a date. The question is not whether extraction succeeded — it is whether you should trust this particular field enough to save it without a human looking.

That threshold is a business decision and it differs per field. A misread surname is an inconvenience. A misread document number on a statutory report is a different category of problem.

Which means the manual correction path is not a fallback bolted on at the end. It is a primary flow, and it should be designed first: fields pre-filled where confidence is high, flagged where it is not, and always editable. The system's job is to save typing, not to be right unsupervised.

Identity documents are not just data

Two things that are easy to get wrong and expensive to fix later:

• Some numbers must be stored masked. Certain national identifiers carry a legal or contractual expectation that only part of the number is retained. That has to be decided before you start writing full values into a database and backing it up nightly.
• Field names lie. Different document types put conceptually different things in similarly named fields, and a single "document number" column quietly merges values with different formats, checksums and validation rules. Model the document type explicitly rather than flattening everything into one shape.

What to log, and what never to

Debugging a bad extraction is much easier with the request, the response and the confidence values in front of you. Debugging it is not worth keeping copies of identity documents in an application log.

Log the metadata — document type, per-field confidence, latency, whether a human corrected it and which fields they changed. That last one is the most valuable telemetry in the whole system: correction rate per field tells you exactly where the pipeline is weak, and whether it is improving.

The honest summary

Document extraction is a queueing and error-handling problem wearing an AI hat. The model is a component you can swap; the queue, the thresholds, the correction path and the retention rules are the parts you actually build, and they are what determines whether the feature survives contact with a busy Saturday.