Last updated: 2026-09-07 · Audience: developers and product engineers routing customer data through an AI API
Zero data retention vs EU residency
A badge that says EU-hosted tells you where bytes are processed. A badge that says zero retention tells you how long they persist. These are independent guarantees, and buying one because it sounds like the other is how customer content ends up somewhere your DPA never covered. This page shows how to read both, what usually persists anyway, and how the ISMS Copilot API expresses each guarantee explicitly.
The short version
- Residency: where request content is processed, by which providers, in which regions, and whether you can pin it per request.
- Retention: how long prompts, outputs, and logs persist after the response.
- They are orthogonal. Any combination exists on the market. Ask for both answers in writing.
- On this API: the
-eualiases select the EU-oriented path,x-isms-processing-regionreports eu or global on every response, and Zero Data Retention applies to request content on both paths. - Binding version: the API DPA on the Trust Center, not a badge.
Why a dedicated guide
Vendor trust pages compress four different promises into one badge: where processing happens, how long content persists, whether content trains models, and who else touches it in transit. Procurement then inherits whatever the badge happened to mean. The result is predictable: a team buys EU hosting and assumes deletion, or buys zero retention and assumes the bytes never left the region. Neither assumption is safe to make.
If you are still deciding whether to call a compliance AI API at all, read the build vs buy decision guide first. If the question is why this API instead of any model, read the vs-any-model argument. If you want to make a first call, use the OpenAI-compatible quickstart. This page is only about the data guarantees themselves.
Two guarantees, two different questions
Residency answers: where does processing happen?
Which providers run the inference, in which regions, and whether you can pin the path per request, per key, or only per account. Location matters because when personal data is processed outside the EEA, GDPR Chapter V (Articles 44 to 49) governs the transfer and requires a valid transfer basis, such as an adequacy decision, appropriate safeguards, or an applicable derogation. That basis and the Article 28 processor contract are written commitments: make sure both exist before routing customer data. The badge on the marketing site is neither of them.
What residency does not promise: that content is deleted quickly, that it is not used for training, or that every sub-processor in the pipeline is covered. Those are the other questions on the checklist, and each one needs its own answer.
Retention answers: how long does content persist?
Prompts, completions, embeddings, uploaded files, agent-plane content, logs. Where request content includes personal data, the storage-limitation principle (GDPR Article 5(1)(e)) is the benchmark an auditor will apply: personal data is kept no longer than necessary. A retention promise is only readable when it says what is covered, what persists anyway, and who keeps it in which controller role.
One regulator reference point: the EDPB's Opinion 28/2024 (December 2024) addresses how GDPR applies to personal data processed in the context of AI models. The safe read for a builder: the questions below are the ones a DPA review will ask, so get the answers before routing customer data, not after.
The four combinations
Because the two guarantees are independent, every vendor sits in one of four quadrants. Each combination has a different data story, and only one of them is the pair most compliance buyers think they are buying.
| Processing posture | With zero retention | With retention |
|---|---|---|
| EU residency | Content processed in the EU path and not kept as customer records after the response. The strong pair for customer data under GDPR, if the DPA says what the badge says. | Processing location is EU, but prompts, outputs, or logs persist for some window. Residency answers where, not how long. Read the retention schedule before assuming deletion. |
| Global processing | Content does not persist, but processing runs outside the EU path (or on a mixed path). Transfer analysis under GDPR Chapter V still applies to the pipeline that touches the content in flight. | Content persists and processing location is not pinned. The combination that demands the closest contract reading before any customer data is routed. |
Both axes are spectrums, not switches. Residency ranges from pinning per request to no choice at all. Retention ranges from zero retention to 30-day abuse windows to training use. Read the actual position on each axis; do not average them into one badge.
What persists anyway (the honest part)
Almost every API vendor retains something after the response: usage metadata for metering, billing records for accounting, sometimes abuse-detection windows. A zero-retention claim that cannot tell you what persists anyway is not a claim you can put in front of a customer. Here is the full picture on the ISMS Copilot API, as documented on docs/api/zero-data-retention (checked 2026-09-07):
- Not kept as customer records: your prompts and model outputs. Inference is transient in process memory; request content is not stored in the data layer. Request content is not used to train models.
- Kept as usage metadata: model alias, token counts, cost, status, timestamps, key label. ISMS Copilot keeps this ledger as an independent controller for metering, fraud prevention, and French accounting and tax retention rules. It contains no prompt or reply text.
- Knowledge-injection aggregates: per request, the selection mode (auto, none, pinned), the injected knowledge size, and the estimator version. Which frameworks were injected is never stored anywhere; the module ids exist only in the live response header and body.
- Upstream paths: global aliases run on zero-retention upstream endpoints (OpenRouter with account-level mandatory ZDR plus in-request ZDR flags); EU aliases run on Mistral under a commercial ZDR agreement on the EU processing path. Exact upstream providers can change; the aliases are the stable contract for your integration.
What ZDR is not (per the docs)
- Not a claim that content never exists in process memory while a request is being served. Inference needs the text in flight.
- Not a claim that infrastructure sub-processors never see content in transit (gateway, hosting, TLS hops). The sub-processor list is published on the Trust Center.
- Not the chat product. Chat conversations are a different product with different retention controls. The docs page is scoped to the Model API only.
How this API expresses both guarantees per request
The useful pattern to copy from any vendor is not the badge; it is whether the two guarantees are visible at the request level, where you can verify them.
| Guarantee | How it is expressed |
|---|---|
| Residency (processing path) | The -eu alias suffix (isms-fast-eu, isms-thinking-eu) selects the EU-oriented inference path. Bare isms-fast and isms-thinking use global processing when global mode is on (it is on in production). isms-mini is a bulk alias on the global path only, with no EU twin. Every successful response reports the region via x-isms-processing-region (eu or global), so the path is verifiable per call rather than promised per contract alone. |
| Retention (what persists) | Zero Data Retention for request content on both processing modes: prompts and outputs are not kept as customer records, training does not use request content, and the console usage history is metadata only. The binding detail is on the API DPA and the sub-processor list. |
Seven questions before you route customer data through any AI API
Portable checklist. Apply it to any vendor, including us. If a vendor cannot answer questions 2, 3, and 7 in writing, treat the zero-retention badge as marketing until the contract proves otherwise.
1. Where is request content processed, and can I pin it per request or per key?
If you cannot pin it, find out what the default depends on: account settings, model choice, or provider routing you do not control.
2. What exactly does the retention promise cover?
Prompts, completions, embeddings, file uploads, agent and tool-plane content. A promise scoped to one plane does not cover the others.
3. What persists anyway, and for how long?
Usage metadata, billing records, abuse-detection windows. Ask which controller role keeps them and under which retention rules.
4. Is request content used for training?
Under which settings, and does the answer change for free versus paid tiers?
5. Which sub-processors see content in transit or at rest, and are they in the DPA?
Gateways, hosting providers, TLS hops. A sub-processor list that stops at the first company is not a list.
6. What do the vendor's upstream providers promise, and does that flow through contractually?
Your contract is with the vendor. The upstream zero-retention promise only helps you if the vendor's DPA passes it through.
7. Where is the binding version written?
DPA clause and terms, not a badge, a sales deck, or a blog post. If a claim is not in the contract, it is not a guarantee.
Frequently asked questions
Is EU hosting the same as zero data retention?
No. Residency is about where processing happens; retention is about how long content persists afterward. A vendor can be EU-hosted and still retain content for an abuse window, or run a global path and retain nothing. You need both answers in writing. On the ISMS Copilot API, the -eu aliases select the EU-oriented inference path and the Zero Data Retention posture applies to both processing modes.
Does zero data retention mean my text never exists anywhere?
No. Inference requires the text in process memory while the request runs, and infrastructure sub-processors (gateway, hosting, TLS) see content in transit. Zero retention here means prompts and outputs are not kept as customer records after the response is returned. The ISMS Copilot docs list exactly what the claim does and does not cover.
What is retained even under zero data retention?
On the ISMS Copilot API: usage and billing metadata only (model alias, token counts, cost, status, timestamps, key label), kept by ISMS Copilot as an independent controller for metering, fraud prevention, and accounting and tax retention rules, plus knowledge-injection aggregates (selection mode, injected knowledge size, estimator version). No prompt or completion text is kept, and which frameworks were injected is never stored. Details: docs.ismscopilot.com/docs/api/zero-data-retention.
Does the Model API's ZDR promise cover the chat product or MCP?
No. The docs page is scoped to the Model API. Chat conversations are a different product with different retention controls, and other surfaces have their own posture. Check each surface's docs and legal terms before quoting a retention promise for it.
How do I verify the processing region on a live call?
On the ISMS Copilot API, every successful response reports the region via the x-isms-processing-region header (eu or global). Pick the path per request with the -eu alias suffix. Region selection is otherwise an account-level or routing question on most vendors, which is why the checklist asks whether you can pin it.
Where is the binding version of any of this?
The legal terms, the data processing agreement, and the sub-processor list. For the ISMS Copilot API those live on the Trust Center (API Terms, API DPA, API sub-processors). Documentation pages explain the posture; the DPA is what binds.
Primary sources
- ISMS Copilot API docs: Zero Data Retention (what ZDR covers, what persists, what ZDR is not). docs.ismscopilot.com (checked 2026-09-07).
- ISMS Copilot API docs: Models and regions (alias table, EU vs global paths, x-isms-processing-region). docs.ismscopilot.com (checked 2026-09-07).
- ISMS Copilot Trust Center: API DPA (binding legal detail and sub-processor references). trust.ismscopilot.com (checked 2026-09-07).
- GDPR (Regulation (EU) 2016/679): Article 5(1)(e) storage limitation, Article 28 processor contracts, Chapter V (Articles 44-49) international transfers. eur-lex.europa.eu (checked 2026-09-07).
- EDPB Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models (18 December 2024). www.edpb.europa.eu (checked 2026-09-07).
- ISMS Copilot Trust Center: API sub-processors. trust.ismscopilot.com (checked 2026-09-07).
Written and maintained by the ISMS Copilot team for API integrators. Last reviewed 2026-09-07.
This guide is not legal advice. Product capabilities, retention posture, and commercial terms are defined by live docs, the Trust Center, and the platform console. Where this page summarizes those surfaces, the live surface wins on drift. For GDPR obligations specific to your processing, ask your DPO or counsel.