Where your documents go, and who can compel them
Most EU-only claims describe where bytes sit and stop there. The harder question is whose courts can reach them. Both answers are on this page, with every company in the chain named — including the parts that do not flatter us.
Last reviewed 2026-08-28 · reviewed quarterly and on any change of provider
Two questions, not one
1 · Where is it processed?
Residency. Which racks, in which country. This is the question every vendor answers, because it is the easy one.
2 · Who controls the processor?
Jurisdiction. A US-incorporated company can be ordered under the CLOUD Act to produce data in its possession, custody or control — including data held by a foreign subsidiary.
A vendor can pass the first and fail the second. That is the failure mode worth watching, and it catches both providers below — which is why they are listed with their owners rather than just their addresses. It is also why we do not use AWS Textract, Google Document AI or Azure Document Intelligence: all three offer EU regions, DPAs and Standard Contractual Clauses, and all three answer only the first question.
The chain, in full
Two providers touch documents. Both are EU-incorporated and both operate under an Article 28 DPA. Neither is EU-controlled, and that distinction is the point of this table.
| Provider | Role | Incorporated | Processing | Controlled by |
|---|---|---|---|---|
| Contabo GmbH | Hosting and compute | Munich, DE | Germany | KKR & Co. Inc. — New York, majority since June 2022 |
| Mistral AI | Model inference for hard pages | Paris, FR | EU endpoint | Independent, France |
| Polar Software Inc. | Payments — merchant of record | United States | US | Independent, United States |
Polar is in the billing path, not the document path. It takes the card, charges and remits the tax, and issues the invoice, which is why no card number or billing address reaches our server at all. It sees an email address, a name, a billing country and which plan was bought. It never receives a document, and no page of this site loads anything from it — checkout is a redirect to Polar's own domain. It is listed here because it is a US company processing customer data on our behalf, and leaving it off a page titled "the chain, in full" would make this page the thing it exists to argue against.
Mistral's own sub-processors, in scope for the API
Published because a chain is only as short as its longest link. Taken from Mistral's trust centre; they list 25 in total, of which these eight are scoped to the API path our documents take. Most vendors publish their providers. This is their providers' providers.
| Sub-processor | Role | Location | Note |
|---|---|---|---|
| Mistral Compute | Cloud infrastructure | France | — |
| CoreWeave Inc. | Inference provider | EEA | US-incorporated |
| Cloudflare Inc. | Traffic routing | Worldwide | US-incorporated, in the request path |
| CrowdStrike Inc. | Security | EEA, US | US-incorporated |
| Ory Corp. | Authentication | BE, DE | — |
| Sentry | Error handling | EEA | US-incorporated |
| Stripe Inc. | Billing | US | Billing metadata only |
| Twilio Inc. | Phone verification | US | Account data only |
Two entries deserve singling out. CoreWeave is the inference provider — US-incorporated, sitting at the most sensitive point in the pipeline. Cloudflare routes Mistral's traffic worldwide, so documents transit a US company the moment they leave our box for theirs. We refuse Cloudflare's proxy in front of our own server, which removes one hop we control; it does not remove that one.
Verify it yourself: trust.mistral.ai/subprocessors · legal.mistral.ai/terms/data-processing-addendum · docs.mistral.ai/studio-api/regional-inference. Printed rather than linked on purpose — this page makes no third-party requests.
The EU endpoint, and as few pages as possible
The paid tier calls api.eu.mistral.ai, not the global endpoint. We confirmed OCR is actually served there rather than taking the documentation's word for it — the regional-inference documentation describes only chat completions, and it is incomplete.
The escalation ladder is a privacy control as much as a cost one. A page only reaches the model after the embedded text layer and our own OCR have both been tried and judged inadequate, and the response records which pages left the box and why. For most documents that number is zero.
What is kept, and for how long
A PDF sent to the API is deleted from our disk the moment it has been parsed — success or failure, in the same code path, so a failed parse cannot leave a document behind. One uploaded through the dashboard is kept, because the result screen shows it beside the text it produced, and it is deleted on exactly the same schedule as that text: one setting, one purge run, no way for the file to outlive its own extraction. You can also delete the file on its own, at any time, from the document screen — the extraction stays.
The text is kept for seven days by default so you can actually read your results; set that to zero on the privacy screen and both the text and the file are discarded the moment parsing ends, which is the right choice if you only ever call the synchronous API and take the answer from the response.
The caveat is the model provider, and it is a real one. Retention there is theirs, not ours. The honest figure is on the right and we are not going to round it down.
Found a hole in this?
Tell us. A compliance objection we have not thought of is worth more than a signup, and it gets answered by the person who wrote this page.