An LLM Pipeline for Claims, Tickets and KYC Files Inside Your Own Infrastructure: Extraction, Validation, Review and Audit

Claims files, support tickets and KYC documents have the same problem in common: people read them to fill in fields that another system needs. A claim becomes a policy number, a date of loss and line items; a ticket, a category and a customer; an identity document, a name, a date of birth and an expiry date. The requirement that comes with the work is usually stated before anything else: the documents may not go to OpenAI or any other external model provider.

Where the model runs is a separate decision, compared in an earlier article on this blog. This one assumes an open-weight model served inside your infrastructure and describes the pipeline around it, from intake to the record another system consumes. It explains mechanics; it is not a case study.

Seven stages, and every one of them stays inside

Keeping data away from external providers is a property of the whole pipeline, not of the model call: the OCR engine, the review tool, the evaluation set, the audit store and the logs all hold the document or something derived from it, as the earlier article on pilots lists in full.

Intake: classify the document before anything reads it

Every later stage depends on the document type: the schema, the rules, the reviewers and the retention period, so classification comes first and decides the route. A claims file arriving by email can hold a claim form, invoices, photos and a medical report; each attachment is classified on its own and linked to the same case.

• Record the channel, the sender and a content hash on arrival, so a document sent twice is recognised before it becomes two cases
• Classify from a closed list of types; vLLM's documentation on structured outputs lists a choice parameter, with which the output will be exactly one of the choices, so the classifier cannot invent a type
• Send a document that matches no type, or matches with low agreement, to a person instead of the nearest schema

Text and layout first, the language model second

A PDF generated by software carries a text layer that can be read directly. A scan or a phone photo carries only pixels, and something has to turn them into characters with positions.

The open-source engines for this step run locally. Tesseract's command-line documentation shows TSV output with a confidence column for every word and hOCR output with a word-confidence attribute, a per-word signal the routing stage can use. Docling, an open-source conversion library under the MIT licence, lists page layout, reading order and table structure among its PDF features, OCR support for scanned PDFs and images, and local execution for sensitive data and air-gapped environments.

• Read the text layer where one exists and use OCR only where it does not, so clean documents do not pick up recognition errors
• Keep the page number and bounding box of every word, so each extracted field can later be shown to a reviewer on the page it came from
• Preserve tables as tables: an invoice whose columns are flattened into one line of text loses which amount belongs to which item

A vision-language model can read the page image instead: vLLM's documentation on multimodal inputs states that image input is supported according to the OpenAI Vision API. Which works better is measured on your documents, keeping in mind that a separate OCR stage returns word positions and confidences and a model reading an image does not.

Schema-constrained output: the shape is enforced, the content is not

Each document type gets its own output schema, versioned like code. vLLM's documentation on structured outputs lists five kinds of constraint: choice, regex, a JSON schema, a context-free grammar and a structural tag, with backends including xgrammar, guidance, outlines and lm-format-enforcer, and a default, auto, that will try to choose an appropriate backend based on the details of the request.

• Make “not found” an explicit value for every field, so an absent date of loss is recorded as absent instead of guessed
• Use enumerations for anything another system will switch on: claim type, ticket category, document type, country code
• Add a source reference to each field, the page and the words it was taken from, so validation and review can check it against the document

Validate the output again in application code with an ordinary JSON Schema validator. Backends differ: the same page notes that xgrammar, guidance and outlines use Rust-style regular expressions while lm-format-enforcer uses Python's re module, and that for Qwen3 Coder models with reasoning enabled, structured outputs might become disabled if the reasoning content is not parsed into a separate field. A generation stopped by the token limit also ends mid-record. The second check is cheap.

Validation: the business rules that already exist, written as code

A record that fits the schema can still be wrong. The checks that catch it are the ones the back office applies by hand today, written as code per document type:

• Claims: the policy number exists in the policy system, the date of loss falls inside the period of cover, and the invoice line items add up to the invoice total
• Tickets: the customer identifier resolves to a real account, and the product named is one the customer actually has
• KYC: the check digits of the machine-readable zone are correct, the expiry date has not passed, and the name and date of birth in the machine-readable zone agree with the same fields read from the visual zone

Identity documents come with their own validator. ICAO Doc 9303, the specification for machine-readable travel documents, defines check digits in the machine-readable zone calculated on modulus 10 with a continuously repeating weighting of 7, 3, 1, with letters A to Z counted as 10 to 35 and the filler character as zero, and states that the check digits permit readers to verify that the data is correctly interpreted.

Routing: rules and signals decide which fields a person sees

Routing is decided per field, not per document: a claim whose invoice total fails while everything else passes sends one field to a person, not the whole file. The signals:

• Any validator failure, including a field the schema requires and the model marked as not found
• Low OCR confidence on the words the field was built from, with the threshold set per field on the evaluation set
• Two sources that disagree, such as the machine-readable and visual zones of one passport
• Fields that are never automated by decision, such as a claimed amount above a set limit
• A random sample of fields that passed everything, so the rate of errors nobody flagged is measured rather than assumed

The model's own statement of certainty is left out on purpose; an earlier article on this blog explains why it is a weak gate.

The review screen shows the page with the cited words highlighted next to the proposed value, so a reviewer checks instead of re-reading. Each correction is stored per field with the old value, the new value, the reviewer and a reason from a short list. Once a second person confirms it, it joins the evaluation set, but never the frozen part that release decisions are made on.

Evaluation per document type and per field, not one global score

One accuracy figure for the pipeline hides the result that matters, such as expiry dates failing on one country's identity cards while every other field passes. Measure along the lines the routing uses:

• Per field: exact match after normalisation, and separately how often the field was missed or invented when the document does or does not contain it
• Per document type and per input kind, such as digital PDF, scan and phone photo, because each has its own error pattern
• Per route: the share of fields automated, and the error rate in the sample drawn from them
• Weighted by cost: a wrong bank account number and a misspelt street name are not the same error

A release, whether a new model, prompt, schema, OCR version or validator, is scored on the frozen set before it goes live, and the gate is per field: no field on any document type drops below its pass mark, even if the average rises. Building the first labelled set is covered in the earlier article on pilots that never reached production.

Audit trail: which model and prompt produced which field

A disputed claim or an auditor's question about an accepted identity is about one field on one document. The record that answers it is written as the pipeline runs, one entry per field, in an append-only store:

• The document identifier and content hash, the page and the words the field cites
• The OCR or layout engine version and its confidence for those words
• The model name and weights checksum, the prompt template version and the schema version
• Each validator's result, the route taken and the reason for it
• The reviewer, the value before and after, and the time, if a person changed it

The EU AI Act sets a logging requirement for systems it treats as high-risk: Article 12(1) states that high-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. Annex III lists the high-risk uses, among them evaluating the creditworthiness of natural persons, except for detecting financial fraud, and risk assessment and pricing in life and health insurance; Article 6(3) sets out when a listed system is still not considered high-risk, for example when it performs a narrow procedural task. Whether a given pipeline is in scope is a question for the client's legal team; a per-field record written at run time is useful either way.

Personal data: each stage sees only what its task needs

A pipeline copies personal data into more places than the original folder. Article 5(1)(c) GDPR requires personal data to be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed. Article 25(2) asks for measures ensuring that, by default, only personal data necessary for each specific purpose are processed, and applies that to the amount collected, the extent of processing, the period of storage and accessibility. In pipeline terms:

• The model receives the pages its schema needs, not the whole case file
• Reviewers see the fields in their queue, and access to full documents is granted by role and logged
• Application logs record document identifiers, field names and results, not field values or prompts
• Prompt and output traces, where they are kept for debugging, live in the same restricted store as the documents, with a short retention period of their own
• The evaluation set is a copy of real documents and gets the same access controls

The OWASP Logging Cheat Sheet lists sensitive personal data and some forms of personally identifiable information, such as health data and government identifiers, among the data that should usually not be recorded directly in logs, and says such data should be removed, masked, sanitised, hashed or encrypted instead.

Retention differs by document type, and for KYC in the EU it is set by anti-money-laundering law. Article 77 of Regulation (EU) 2024/1624, which applies from 10 July 2027, requires obliged entities to retain a copy of the documents and information obtained in customer due diligence and to ensure that these records are not redacted. It sets a retention period of five years, counted from the end of the business relationship or the date of an occasional transaction, after which personal data are to be deleted, subject to exceptions in the same article. The original KYC record stays complete in the system of record; the pipeline's own copies, from traces to review snapshots, are minimised and deleted on a shorter schedule of their own.

Throughput: a queue for the spike, capacity for the steady state

Back-office volume is uneven: one event can affect many policyholders at once, and an outage fills the ticket queue. Queues, backpressure and a manual fallback are covered in the earlier article on pilots; what is specific to a self-hosted document pipeline:

• Separate queues by urgency: a KYC check a customer is waiting on during onboarding does not queue behind a batch of historical claims
• Scale OCR workers on CPU and model servers on accelerators independently, because they saturate at different volumes
• Watch the serving engine's own queue: vLLM exposes Prometheus metrics at its /metrics endpoint, including the number of requests waiting to be processed and the fraction of key-value cache blocks in use
• Scale workers on queue depth rather than CPU load; KEDA's documentation describes scaling any container in Kubernetes based on the number of events needing to be processed, with scalers for messaging systems among others, and scale-to-zero

Accelerator capacity inside your own infrastructure is fixed in the short term, so the order in which queues give way is decided in advance, not during the spike.

Claims, tickets and KYC: the same skeleton, different rules

• Claims: many documents per case, tables in invoices and often health information, which Article 9 GDPR lists among the special categories whose processing is prohibited unless an exception in the same article applies. Article 22 gives a person the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them, with exceptions in Article 22(2). Whether the pipeline only extracts and checks while a claims handler decides is therefore a design decision taken with the client's data protection officer, not an engineering default
• Tickets: short texts, high volume and someone waiting for a reply, so latency matters more; the output is mostly a category, a priority and a few identifiers. Ticket text is written by people outside the company and is untrusted input to the model, a risk discussed in the earlier article on pilots
• KYC: few document types with strict formats, such as passports and identity cards, which makes rule-based validation strong. A selfie matched against the document photo adds biometric data, which Article 9 GDPR also lists as a special category when processed to uniquely identify a person. Retention follows anti-money-laundering law, and the result feeds a compliance decision made by a person or a documented rule

Keeping documents away from an external model provider is decided by where the model runs. Whether the pipeline can be trusted with them is decided by everything around the model: the schema, the rules, the review queue and the record of who produced each field.

Which engineering companies build this inside your own infrastructure?

The question has three kinds of answer, and they sell different things. Document-processing vendors sell a platform, sometimes installable on premises, that you configure to your documents. Cloud providers sell managed services that run in their infrastructure. Engineering firms build the pipeline in your environment from open components and your rules.

Whichever kind you talk to, these questions show whether a team has built this before:

• Which stages call any service outside your network, including OCR, monitoring, error tracking and the annotation tool?
• What does the output schema for one of your document types look like, and how is “not found” represented?
• Which signals send a field to review, and how were the thresholds chosen?
• How do reviewer corrections reach the evaluation set without contaminating the part used for release decisions?
• Can they show, for one field on one document, the model, prompt, schema and reviewer that produced its value?
• Who owns the pipeline code, the schemas and the evaluation set when the work ends, and which parts stay the vendor's reusable components?

An answer that stays general on the first and the fifth question means the data path and the audit trail have not been designed yet.

What amBrain can say about its own work in this area

What amBrain can substantiate publicly beyond the production integration described in the summary above: amBrain has been building software since 2019. We work in three formats: full delivery, a dedicated team, or engineers embedded in your team. The client keeps full ownership of the product and the code, except our reusable components.

This article explains how such a pipeline works; it is not a case study, it names no clients, and it does not claim that amBrain built a claims, ticket or KYC system. The production work named above is the extraction of broker and venue notices for a trading system.

So the first step is not choosing a model. It is writing down, for one document type, the schema, the rules that check it and the fields a person must always see, before any document reaches the pipeline.