GDPR-compliant document AI: the five obligations, and the two a local model removes
TL;DR
GDPR does not say “on-premise” and does not ban cloud APIs. It asks for five things on paper: a lawful basis, a minimized field list, an Art. 28 contract with every processor, a transfer mechanism, and a DPIA where the risk is high.
The schema you hand the model is your data-minimization statement under Art. 5. Extract what the purpose needs and nothing else, and do not keep the full-page text dump “in case it is useful later.”
An EU region is not the absence of a transfer: the US CLOUD Act reaches a US-owned provider wherever the server stands, and Art. 48 is written for exactly that case.
Several API providers retain requests for up to 30 days for abuse monitoring — a copy of every invoice, contract page and claim sitting with a processor a month after the job finished.
A local open-weight model removes the transfer and the third-party inference processor. It does not remove the lawful basis, the minimized schema, Art. 32 security or the DPIA.
Questions people ask
Is it legal under GDPR to send documents to a cloud AI API?
Yes, if the controller has done the work. You need a lawful basis, an Art. 28 contract with the vendor and each sub-processor, and — for a US provider — a transfer mechanism: Data Privacy Framework certification for that entity, or Standard Contractual Clauses plus a transfer impact assessment. An EU region alone does not settle the transfer question, because the CLOUD Act reaches US-owned providers wherever the server stands.
What lawful basis applies to AI invoice processing under GDPR?
Usually Art. 6(1)(b), performance of a contract — you must process the invoice to pay the supplier — or Art. 6(1)(c), legal obligation, because bookkeeping and VAT law require the record. Legitimate interests under Art. 6(1)(f) covers efficiency gains if you write down the balancing test. Consent is almost never right for back-office documents: a supplier cannot meaningfully refuse to have their invoice booked. Record the basis per purpose in your Art. 30 register.
Do I need a DPIA for AI document processing?
Assume yes at scale. Art. 35 makes a DPIA mandatory where processing is likely to result in a high risk, and Art. 35(3)(b) names large-scale processing of special categories explicitly. A pipeline reading 50,000 claims a month with a machine-learning model ticks “new technology,” “large scale” and, if claims carry diagnoses, “special category.” Write it before the pilot and consult your DPO under Art. 35(2).
Does a local AI model make document processing GDPR compliant?
Not by itself. A local open-weight model removes the international transfer and the third-party inference processor, and puts prompt and image retention under your own control. You still need a lawful basis, a schema limited to the purpose, real Art. 32 security on your own infrastructure, and a DPIA where scale or the data category triggers one. A GPU with no access control is worse under Art. 32 than a well-run EU cloud.
Is an EU cloud region enough for GDPR when using a US AI provider?
It helps physically, not legally. If the provider is US-owned, the CLOUD Act lets US authorities compel it to produce data in its control regardless of where the server stands — the situation Art. 48 and the EDPB’s post-Schrems II guidance address. A US inference API can still be lawful under the Data Privacy Framework or SCCs plus a transfer impact assessment, but someone must have chosen and documented that mechanism in the DPIA.
What should I ask a document AI vendor about GDPR?
Five things the “GDPR-ready” badge usually skips: the full sub-processor list with a country for each and a change-notification mechanism; whether API inputs are ever used for training, including on free or beta tiers; how long prompt logs are retained — often up to 30 days for abuse monitoring — and whether zero retention is available; where human reviewers sit and what they see; and the Art. 28 contract itself, with audit rights.
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.
GDPR does not say “on-premise” and it does not ban cloud APIs. What it asks of a document-AI pipeline is more specific than that, and most vendor pages skip it. If you extract fields from invoices, contracts or claims with a model, you need five things you can show a regulator or a customer on paper: a lawful basis for each purpose (Art. 6), a field list limited to that purpose (Art. 5), an Art. 28 contract with every processor that sees a page, an answer to where the page goes and under which transfer mechanism (Chapter V, Art. 44–49), and a DPIA (Art. 35) where the volume or the data category makes the processing high-risk. A local model does not make those obligations disappear. It removes the two that are hardest to satisfy with a US cloud API: the transfer and the third-party inference processor.
Definition · GDPR-compliant document AI
A document-AI pipeline is GDPR-compliant when the controller can name a lawful basis for each extraction purpose, limits the extracted fields to what that purpose needs, holds an Article 28 contract with every processor that handles a page, can list every sub-processor and country the page passes through with a valid transfer mechanism for each, and has a DPIA on file where the scale or the data category makes the processing high-risk.
What GDPR actually requires when a model reads a document
An invoice carries a supplier contact name, an IBAN, sometimes a sole trader’s home address. A contract carries signatories and negotiated terms. A claim carries a claimant, a policy number and often a diagnosis. All of that is personal data the moment it relates to an identifiable person, so the pipeline is “processing” under Art. 4(2) from the first scan onward. Six articles do most of the work.
Lawful basis — Art. 6
You need one of the six bases in Art. 6(1) before the first page is read. For accounts-payable extraction, the usual candidates are Art. 6(1)(b), performance of a contract (you have to process the invoice to pay the supplier), Art. 6(1)(c), legal obligation (bookkeeping and VAT law require you to record it), and Art. 6(1)(f), legitimate interests (the residual basis for efficiency gains, provided you have balanced them against the data subject’s interests and written that balancing test down). Consent is almost never the right basis for back-office document processing: it must be freely given and revocable, and a supplier cannot meaningfully refuse to have their invoice booked. Pick the basis per purpose, not per vendor, and record it in your Art. 30 register.
Purpose limitation and data minimization — Art. 5
Art. 5(1)(b) says data is collected for specified, explicit purposes and not further processed in a way incompatible with them. Art. 5(1)(c) says it is limited to what is necessary. In practice: the schema you hand the model is your minimization statement. If the purpose is “pay the invoice and book the VAT,” extract supplier, invoice number, dates, net, VAT and total. Do not extract the contact person’s mobile number because the model can. Do not keep the full-page text dump “in case it is useful later” — that is a second purpose without a basis. The same principle governs retention under Art. 5(1)(e): the extracted fields follow your bookkeeping retention period; the model’s working copy of the image should not outlive the job.
Special categories — Art. 9
Health data, and anything revealing ethnicity, political opinion, religion, union membership, genetic or biometric data, or sex life, is prohibited to process unless one of the Art. 9(2) exceptions applies. Insurance claims with a diagnosis, prescriptions, occupational-health forms and some HR documents are in this category. An Art. 6 basis is not enough; you need an Art. 9(2) ground on top (for health care, typically 9(2)(h) with the professional-secrecy condition in 9(3); for insurance, often member-state law under 9(2)(g) or explicit consent under 9(2)(a)). If your invoice pipeline occasionally sees a medical invoice from a company doctor, that occasional page is still special-category data. Route it, or decide deliberately not to process it.
Processors and sub-processors — Art. 28
Any vendor that runs the model on your pages is a processor. Art. 28(3) lists what the contract must contain: the subject matter and duration, the nature and purpose, the data types, an instruction-only clause, confidentiality, Art. 32 security measures, the deletion-or-return obligation at the end, and audit rights. Art. 28(2) and (4) are where cloud API chains get complicated: the processor may only engage a sub-processor with your prior authorization (specific or general, with a right to object), and must flow the same obligations down. A document SaaS that calls a model API that runs on a hyperscaler is three processors deep. You need to know all three, and the country each one operates in.
Security — Art. 32
Art. 32 asks for measures “appropriate to the risk,” and names pseudonymization and encryption, confidentiality and integrity, resilience, restore capability, and regular testing. For a document pipeline this translates to: encryption in transit and at rest, access control on the extracted output, a log of who saw which page, and a stated retention for the images and the model logs. Art. 32 binds the processor as well as you — it is one of the things you are entitled to see evidence of under Art. 28(3)(h).
Data protection impact assessment — Art. 35
A DPIA is mandatory when processing is “likely to result in a high risk.” Art. 35(3)(b) makes it explicit for large-scale processing of special categories, and Art. 35(3)(a) for systematic and extensive automated evaluation that produces effects on people. The supervisory authorities’ lists under Art. 35(4) add triggers such as new technology, combining datasets and processing at scale. A pipeline that reads 50,000 claims a month with a machine-learning model ticks “new technology,” “large scale” and, if claims carry diagnoses, “special category.” Assume a DPIA is required and write it before the pilot, not after the audit letter.
International transfers: Chapter V, Schrems II and the Data Privacy Framework
Chapter V (Art. 44–49) applies the moment a page, or the tokens derived from it, is sent to a country outside the EEA. Art. 45 allows transfers to countries with an adequacy decision. Art. 46 allows them with “appropriate safeguards,” in practice the 2021 Standard Contractual Clauses. Art. 49 holds narrow derogations that do not scale to bulk processing. Art. 48 says a foreign court order or administrative demand is not by itself a lawful ground to hand data over, unless an international agreement such as a mutual legal assistance treaty backs it.
Two events set the terms for US providers. In Schrems II (CJEU, C-311/18, July 2020), the Court struck down the Privacy Shield and ruled that SCCs only work if the exporter checks, case by case, whether the destination’s law undermines them, and adds supplementary measures where it does. In July 2023 the Commission adopted the EU–US Data Privacy Framework adequacy decision, which restores an adequacy route for US organizations that self-certify under it. The DPF has already been challenged in the EU courts once — the General Court dismissed the first action in 2025 — and further challenges are expected. So a US inference API can be lawful under the DPF, if the specific entity is on the certified list, or under SCCs plus a transfer impact assessment. It is never lawful by omission — someone in your organization has to have chosen and documented the mechanism, and to have a plan for the day it is invalidated.
What cloud document-AI vendors gloss over
None of the following is a secret, and none of it is wrongdoing. It is simply what tends to be missing from a “GDPR-ready” badge on a pricing page.
An EU region is not the absence of a transfer. If the provider is US-owned, the US CLOUD Act (2018) lets US authorities compel it to produce data in its possession, custody or control regardless of where the server stands. That is exactly the situation Art. 48 and the EDPB’s post-Schrems II guidance are about. In June 2025 a Microsoft France executive told a French Senate committee that the company could not guarantee that data held in the EU would never be handed to US authorities. An EU region reduces latency and satisfies “data stays in the EU” in the physical sense. It does not by itself close the Chapter V question. Your DPIA should say which position you are taking and why.
Training-on-your-data clauses. Most large API providers state that they do not train on API inputs by default. The word to check is “default”: consumer tiers, free tiers, beta features and some “improve the service” toggles can differ, and the position can change with a terms update. For Art. 5(1)(b) purposes, a page used to train a model is a new purpose you never had a basis for.
Retention of prompt logs. Several providers retain API requests for a period — often described as up to 30 days — for abuse monitoring, unless you qualify for a zero-retention arrangement. That is a copy of every invoice, contract page and claim sitting with a processor for a month after the job finished. It is a legitimate security measure and a retention decision you must have made consciously, with a line in the DPIA and in the Art. 28 contract.
Opaque sub-processor lists. A document SaaS that “uses leading AI models” has sub-processors it may not name on the website. Art. 28(2) requires that you authorize them. Ask for the list, the country for each, and the notification mechanism for changes. If the answer is a link that redirects to a generic trust page, treat the chain as unknown.
Offshore human review. Many extraction services back a confidence threshold with human validators. If those validators sit outside the EEA, every page they see is a transfer and, for special-category data, one that Art. 9 and Art. 32 both scrutinize. Ask where the review team sits, whether they see the whole page or a redacted crop, and under which contract.
How local models change the analysis
Running an open-weight document model — PaddleOCR-VL, DeepSeek-OCR, Qwen3-VL, Gemma 4 or a similar family — on hardware you control, or on an EU-owned host under your Art. 28 contract, removes three items from the list above and simplifies a fourth.
No transfer. The page never leaves the EEA, so Chapter V, the Schrems II analysis, SCCs, the transfer impact assessment and the DPF question fall away. The weights were downloaded once; no personal data goes back.
No third-party inference processor. With the model on your own box there is no Art. 28 contract for inference, no sub-processor chain behind it, and no abuse-monitoring log you do not control. If Ækora runs the pipeline for you, there is exactly one processor, in the EU, and the contract names it.
Logs stay on your side. Prompt, image and output retention become a configuration decision in your Art. 32 measures, not a clause you negotiate. You can set it to zero after delivery, and prove it.
Training is off by construction. An open-weight model does not learn from what it reads at inference. If you later fine-tune on your own pages, that is a purpose you define, under your basis.
What local does not change: you still need the lawful basis, the minimized schema, Art. 32 security on your own infrastructure, and a DPIA if the scale or the data category triggers one. A GPU in the basement with no access control is worse under Art. 32 than a well-run EU cloud. The gain is that the remaining obligations are all inside your building, where you can actually meet them. For the technical side of running such a stack, see what on-premise document AI is and the European buyer’s guide to local document models.
Obligation-by-obligation comparison of a cloud API path and a local-model path for bulk document extraction. “Cloud API” assumes a US-owned provider with an EU region; “local” assumes open-weight models on your own hardware or an EU host under your Art. 28 contract. Both paths assume you are the controller.
Obligation
Cloud API path
Local-model path
Lawful basis (Art. 6)
Required; same analysis
Required; same analysis
Purpose limitation, minimization (Art. 5)
Your schema, plus vendor retention and training terms
Your schema and your retention setting
Special categories (Art. 9)
Art. 9(2) ground plus transfer scrutiny
Art. 9(2) ground; no transfer
Processor contract (Art. 28)
DPA with vendor plus each sub-processor, flow-down, change notices
None for inference; one DPA if a managed EU provider runs it
Security (Art. 32)
Vendor evidence plus your own
Entirely your own measures; must be real
DPIA (Art. 35)
Required at scale or with Art. 9 data; must cover the transfer
Required at scale or with Art. 9 data; no transfer section
Transfers (Art. 44–49)
DPF certification or SCCs plus TIA; a written CLOUD Act position
Not applicable
Prompt or image logs
Vendor retention window, negotiable
Zero after delivery if you choose
Human review location
Ask; may be offshore
Your team, in the EEA
Obligation-by-obligation comparison of a cloud API path and a local-model path for bulk document extraction. “Cloud API” assumes a US-owned provider with an EU region; “local” assumes open-weight models on your own hardware or an EU host under your Art. 28 contract. Both paths assume you are the controller.
A DPIA-lite checklist before the first 1,000 pages
A full DPIA follows the Art. 35(7) structure: description, necessity and proportionality, risks, measures. The following eleven steps produce most of its content in a working afternoon, and tell you whether the cloud path or the local path is defensible for your document families.
List the document families (invoices, contracts, claims, forms) and, for each, the categories of people whose data appears (suppliers, employees, customers, patients).
Flag Art. 9 data per family. Any diagnosis, sick-note, disability or union field makes the family special-category, even if it appears on one page in a hundred.
Write the purpose in one sentence per family and pick the Art. 6 basis (and Art. 9(2) ground where needed). Record it in the Art. 30 register.
Freeze the schema. Every field must trace back to the purpose sentence. Delete the rest.
Draw the data path: scanner, storage, model, validator, output store, ERP. Mark every hop that crosses an organizational boundary and every hop that crosses the EEA border.
Name each processor on the path, the sub-processors behind it, and the country. Collect the Art. 28 contract for each. An unnamed hop is a finding, not a gap to fill later.
For each non-EEA hop, name the transfer mechanism (DPF certification, SCCs plus TIA) and state your CLOUD Act position in writing.
Set retention for images, model logs and extracted fields — three separate numbers, each with a reason.
Locate the human reviewers and record what they can see and under what confidentiality obligation.
Estimate scale: pages per month and data subjects per month. Above tens of thousands of pages, or with any Art. 9 data, treat a full DPIA as mandatory and consult the DPO under Art. 35(2).
Decide the path. If steps 6 and 7 produced more unknowns than answers, the local path (or an EU-only managed pipeline) is usually the faster route to a clean file.
The practical output is not a compliance certificate. It is a one-page data path with every hop, every contract and every country filled in, plus a schema you can defend as minimal. Get that page done first. If it shows a US inference hop you cannot justify, or a sub-processor you cannot name, that is the moment to price bulk document processing on an EU-only pipeline, or to put local document models on your own hardware and take the transfer off the table entirely.