Claims documents carry special category data. That decides your architecture before cost does.
TL;DR
On-premise claims document processing means extraction runs on hardware inside your own network, so the claims file never leaves it.
The reason to care is GDPR Article 9: claims files routinely carry medical evidence, which moves the decision from where data is stored to who can be compelled to produce it.
EU data residency on a US-owned provider answers the first question and not the second, because Schrems II and the US CLOUD Act turn on control rather than location.
The cost case is narrower than the control case. At Azure West Europe list prices, extracting 1.8 million pages a year costs about EUR 15,456 metered but about EUR 123,648 in the air-gapped container.
Local deployment removes an international transfer and a third-party processor. It does not remove your lawful basis, your Article 32 security or your DPIA.
Questions people ask
Where does the data actually sit when the model runs?
On hardware you specify, inside your own network. The model weights are downloaded once, the inference happens locally, and no claims document, extracted field or prompt leaves your perimeter during processing. That is the difference between a residency claim and a control claim: with an EU cloud region the data sits in Europe but a third party still holds it, whereas here the only organisation that can be served an order about those files is you. It also means the network segmentation, access control and logging are yours to design.
Can we process medical reports without a DPIA nightmare?
You still need the DPIA. Article 35(3)(b) of the GDPR names large-scale processing of Article 9 special category data explicitly, and a claims book qualifies whether the model runs locally or not. What local deployment changes is the content of the assessment: no international transfer to assess, no third-party inference processor in the data flow, and retention under your own control. That removes several of the harder sections rather than the exercise itself, and it tends to shorten the review with your DPO rather than eliminate it.
Is this a high-risk AI system under the EU AI Act?
Document extraction for claims handling is not automatically high risk, and it is worth being precise. Annex III point 5(c) covers AI systems intended for risk assessment and pricing in relation to natural persons in life and health insurance. Motor and property claims handling is not named there, and point 5(b) beside it concerns creditworthiness rather than insurance. Classification follows the intended purpose of the system the extraction feeds. If the output drives pricing or an automated outcome on a health or life policy, have your compliance function assess it rather than a vendor.
How do we handle right-to-erasure once a document is in the pipeline?
By designing for it before go-live. Extract against a minimised schema per document type so you know exactly which fields exist and where, and keep a pointer from each source document to its own extraction record. An Article 17 request then resolves to a known set of locations rather than a search across systems. The difficulty with erasure is almost never the model; it is the copies. If extracted fields are fanned out into three systems and an index, erasure means finding all four, and that is an architecture decision made early.
How many claims a day before this pays for a GPU?
Work it from list price. At EUR 8.5866 per 1,000 pages for Azure pre-built extraction in West Europe, 250,000 pages a year is a metered bill of roughly EUR 2,147, and no on-premise deployment costs less than that once hardware, integration and internal ownership are counted. At thirty pages per claim over 240 working days, 250,000 pages is about 35 claims a working day. Below that, only the control argument can carry the decision. Above roughly 150 to 200 claims a day with medical evidence common in files, both arguments agree.
What does the human-in-the-loop step look like under Article 14?
A claims handler works an exceptions queue in the system they already use, sees the extracted fields alongside the source page, and can override any value. The design test is whether disagreeing is genuinely possible and genuinely happens, because a review that never changes anything is a rubber stamp rather than oversight. The same design satisfies the GDPR Article 22 concern about decisions based solely on automated processing, which matters for a declined claim well before any AI Act classification question arises.
Want this worked out on your documents?
We will price a real sample against OpenAI or Anthropic and tell you whether Bulk document processing or a local model on your hardware is the cheaper first step.
On-premise claims document processing means the extraction models run inside your own network, on hardware you control, and the claims file never leaves it. For an EU insurer, MGA or TPA the strongest reason to do this is not cost. It is that a claims file routinely contains medical evidence, which is special category data under GDPR Article 9, and that moves the decision from where the data is stored to who can be compelled to produce it. Only one architecture answers the second question with your own name.
What follows is the control argument, then the arithmetic. There is a claims volume below which none of this is worth doing, and it is stated plainly below.
EU data residency is a location claim, not a control claim
Most document AI vendors selling into European insurance now offer EU hosting. Frankfurt, Dublin, Paris, a region selector in a console. That is real and useful. It is also a statement about where bytes sit, and your DPO asks a different question: if a foreign authority serves an order on the vendor or its parent, what happens to our claims files?
Schrems II turned on exactly that gap. In Case C-311/18 the Court of Justice invalidated the Privacy Shield decision because US surveillance law reached data held by US-controlled providers irrespective of storage location, and because data subjects lacked equivalent redress. The US CLOUD Act codifies the same reach: a US provider can be compelled to produce data in its possession, custody or control, wherever the servers are. GDPR Article 48 says a third-country order is not, on its own, a ground for disclosure in the EU. Those two positions do not reconcile themselves.
None of that makes a US-owned hyperscaler unlawful to use, and it would be dishonest to imply otherwise. The EU-US Data Privacy Framework, Commission Implementing Decision (EU) 2023/1795 adopted on 10 July 2023, is in force. The General Court dismissed a challenge to it on 3 September 2025, and an appeal was lodged before the Court of Justice on 31 October 2025, so the framework stands while that runs (IAPP). The large providers run serious privacy programmes and genuine EU regions. The argument is not that anyone is breaking the law. It is that their answer to who can be compelled is structurally not you, and that two previous adequacy decisions have already been struck down, so an architecture depending on the third one holding carries a risk it did not choose.
Note
On-premise does not answer the compulsion question better. It removes it. If the model weights, the inference and the claims file all sit on hardware inside your own network, the only party who can be served an order about that data is you, and you are already subject to EU process. That is the whole architectural claim, and it is narrower than most vendors make it sound.
What is actually in the file
Definition · Special category data
Article 9 GDPR data, including data concerning health. An IME report, a medical chronology, an injury description in a loss notice and a rehabilitation invoice are all Article 9 data. Article 9(1) prohibits processing by default, so you need an Article 9(2) condition on top of your Article 6 lawful basis before any of it goes near a model.
In practice the intake channel is a shared claims mailbox. EML and MSG files with attachments: a phone photograph of a European Accident Statement, a PDF policy schedule, a Word adjuster's report, a scanned garage invoice. Somebody opens each one, sets up the claim, indexes the file, and keys the same policy number into two systems. What each document carries differs by type, and your architecture should follow the worst row rather than the average one.
Common EU claims documents and what each one carries
Both drivers, addresses, plates, sketch, injury box
Sometimes
30+ standardised versions
On-premise or EU cloud
Policy schedule and policy wording
Policyholder identity, cover terms
No
Per market
Either
Loss adjuster report
Claimant, third parties, narrative, photographs
Frequently
Per market
On-premise
IME report and medical chronology
Diagnosis, treatment, prognosis
Always Art. 9
Per market
On-premise
Police report
Identities, alleged offences
Art. 10 territory
Per market
On-premise
Contractor invoice and damage estimate
Supplier, amounts, risk address
No
Per market
Either
Bordereaux from delegated authority
Claim lines, often pseudonymised
Usually no
Mostly English
Either
DSAR request
Requester identity, plus everything it pulls
Inherits the file
Per market
Follows the file
Common EU claims documents and what each one carries
The European Accident Statement is the honest proof point for multilingual extraction. It is a standardised pan-European form issued in many language versions with consistent field numbering, so a form completed in Greek carries the same numbered boxes as one completed in Swedish. We have not found an official source that fixes the number of language versions, so we do not state one. A model reading structure and position rather than translating prose handles the whole set without a per-language build. It is also a reminder that a European claims stack is not a US one: the vocabulary here is FNOL, loss adjuster, bordereaux and the constat amiable, not ACORD forms and Xactimate estimates.
Is claims document extraction a high-risk AI system?
Usually not on its own, and this is the easiest thing to get wrong on the subject. The AI Act lists at Annex III point 5(c) AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance. Read the scope carefully: risk assessment and pricing, in life and health insurance. Motor and property claims handling is not named. Point 5(b) above it covers creditworthiness rather than insurance, and the two get cited interchangeably often enough to be worth separating.
Extraction is a component, and classification follows the intended purpose of the system it feeds. If extracted fields land in front of a claims handler who reads the file and sets reserves, you are some distance from 5(c). If the same extraction drives an automated outcome on a health or life policy, or feeds pricing, the analysis changes and your compliance function should run it rather than a vendor. In scope, Articles 10, 13 and 14 on data governance, transparency and human oversight are what bite. More detail in our note on AI Act obligations for document processing.
For most claims teams GDPR Article 22 is the nearer constraint anyway, because it restricts decisions based solely on automated processing producing legal or similarly significant effects, and a declined claim qualifies. The practical answer matches the Article 14 answer and is a design question rather than a legal one: a handler who genuinely reviews and can disagree, not a rubber stamp on a queue of four hundred.
DORA and your ICT third parties
Since 17 January 2025, Regulation (EU) 2022/2554 (DORA) has applied to financial entities, insurers and reinsurers among them, and to their ICT third-party service providers. If extraction runs on somebody else's API, that API is an ICT service supporting a business function, and it belongs in your register of information, your contractual requirements, your exit strategy and your concentration analysis. BaFin, ACPR, IVASS, DNB, AFM and the Central Bank of Ireland each get to it in their own way, and EIOPA has been consistent that outsourcing the activity does not outsource the accountability. Solvency II governance, IDD conduct duties and NIS2 sit around the same decision.
Running the model on your own hardware does not remove DORA. It changes what you answer about: an internal ICT asset you already operate, rather than a cross-border dependency with its own concentration risk and exit problem. For a claims operation with a real IT function that is a simpler supervisory conversation. For one without, it is harder.
The arithmetic
Take a mid-market motor insurer handling 60,000 claims a year, thirty pages across the file: FNOL email and attachments, accident statement, policy schedule, adjuster report, garage invoice, photographs. That is 1.8 million pages a year. Prices below were pulled from the Azure Retail Prices API for West Europe on 12 September 2026.
Azure AI Document Intelligence, West Europe, Azure Retail Prices API, 12 September 2026
Option
List price
Cost at 1.8m pages a year
S0 pre-built extraction, metered
€8.5866 per 1,000 pages
€15,455.88
Disconnected (air-gapped) pre-built container
€61,823.80 per year per 1m-page unit
€123,647.60 (two units)
Open-weight model on your own GPU
No per-page fee
Hardware, deployment and run cost only
Azure AI Document Intelligence, West Europe, Azure Retail Prices API, 12 September 2026
The interesting number is not the first row. Fifteen thousand euro a year to extract 1.8 million pages is cheap, and anyone calling the cloud ruinously expensive at this volume is selling something. The interesting number is the gap between rows one and two. The same vendor's air-gapped container, the version that does not call home, costs roughly eight times the connected metered rate for the same pages. Control is the expensive part, not extraction. We broke that pricing apart in the Azure disconnected container cost breakdown.
Open-weight models change the third row. PaddleOCR-VL is 0.9B parameters, Apache-2.0 licensed, and scored 96.34% on OmniDocBench v1.6 (Roboflow). A model that size does not need a data centre behind it. Sizing the box is its own exercise, covered in our GPU sizing note.
The volume below which you should not do this
Run the same figures backwards. At €8.5866 per 1,000 pages, 250,000 pages a year is a metered bill of roughly €2,147. No on-premise deployment, counting hardware, integration and somebody internally owning it, comes in under €2,147 a year. At thirty pages per claim and 240 working days, 250,000 pages is about 8,300 claims a year, or 35 claims a working day.
So below roughly 35 claims a day the cost case does not carry, and the business case should say so rather than stretch. Only the control case can carry at that volume, and if your claims mix holds little Article 9 content, a DPIA plus a well-run EU cloud region is defensible. Above roughly 150 to 200 claims a day, with medical evidence in a meaningful share of files, both arguments point the same way and the decision stops being difficult.
What the pipeline looks like
The shared claims mailbox is the source. EML and MSG are parsed, attachments burst out, and each attachment classified by document type before anything is extracted.
Classification decides the route. A policy schedule and an IME report get neither the same schema nor the same retention clock.
Extraction runs against a minimised schema per document type. You pull the fields the claim needs, not everything on the page. That is data minimisation doing real work, and it makes erasure tractable.
Confidence thresholds split output into straight-through and an exceptions queue. The exception rate is the number to negotiate in a pilot, not a headline accuracy percentage.
A claims handler reviews exceptions in the system they already use and can override any field. This is the Article 14 and Article 22 human step, and it counts only if disagreeing is genuinely possible.
Extracted fields are written back to the claims system, and each source document keeps a pointer to its extraction, so a DSAR or erasure request finds both halves.
None of that requires a new claims system, which is deliberate. The outcomes worth measuring are touch rate on intake, TAT from notification to file set up, and how much backlog the team clears without overtime. Leakage and indemnity spend move later and for other reasons, so nobody should promise them early.
What local deployment does not fix
Ækora cannot make you GDPR compliant, and neither can anyone else. Running extraction locally removes an international transfer and a third-party inference processor, and puts retention under your control. Everything else stays where it was.
You still need an Article 6 lawful basis and an Article 9(2) condition for the medical content.
You still need Article 32 security. A GPU on a flat network with shared credentials is worse under Article 32 than a well-run EU cloud tenancy with proper identity management. On-premise is a location decision, not a security posture.
You still need a DPIA. Article 35(3)(b) names large-scale processing of Article 9 data explicitly, and a claims book qualifies.
You still need Article 30 records of processing, and now the processing is yours to record.
Article 17 erasure still needs a design. If extracted fields are copied into three systems and an index, erasure means finding all four. Minimised schemas and a document-to-extraction pointer make that survivable.
There is no claims workflow product here. No validation UI of our own, no approval routing, no Guidewire or Duck Creek connector, no two-way audit trail between our pipeline and your claims system. If the requirement is to replace the claims system, we are the wrong call.
Time to first result is slower than signing up to an API. This is a deployment engagement: hardware, network, schemas, a pilot on your own documents. If extraction has to be running on Thursday, this is not that.
There is no SLA, no status page and no vendor-side SOC 2. Procurement checklists that require SOC 2 from the processing vendor will disqualify us on the form, and that is a fair call by the buyer.
The counter-argument is real, and worth weighing yourself rather than accepting from us: when nothing leaves your network, the certifications governing the processing are your own. No vendor tenancy holds claims data, so there is no vendor audit boundary to certify. Whether that reads as a clean answer or a procurement problem depends on who signs off.
Getting a number for your own book
Four inputs decide this: claims a year, average pages per file, the share of files carrying medical evidence, and your current touch rate on intake. Three of them you already report monthly. If the arithmetic puts you above the threshold, our bulk document processing page sets out how the engagement runs, what a pilot on your own claims documents involves, and what we need to size the hardware honestly.