A Sluis guide for privacy, security and platform teams. Last checked 23 September 2026.
Every prompt that reaches an AI provider is a disclosure. This guide covers which personal data typically ends up in prompts, how well each detection method removes it, what replacing it with placeholders achieves under EU law since the Court of Justice's September 2025 judgment, and what you still have to do even when redaction works.
In short
- Pattern matching catches structured identifiers: e-mail addresses, phone numbers, IBANs, card numbers, national ID numbers, API keys. It removed 57% of annotated personal details in our test. Names and descriptions are what it misses.
- A trained entity-recognition model closes most of that gap. In the same test it raised removal to 98.7%, at a cost of about half a second per text segment.
- Replacing identifiers with placeholders can mean the text is no longer personal data for the AI provider. The Court of Justice confirmed this in EDPS v SRB, but only where the provider has no realistic way to re-identify the person, including by combining details.
- For you, the data remains personal data, and you must still tell people that it goes to the AI provider. The Court assessed that duty from the controller's side, at the moment the data is collected.
- Check your provider's retention default in the contract, not on its marketing page. Several major providers changed their defaults in the past twelve months.
What ends up in prompts
What employees paste into AI tools follows the work they do. The same categories come up in almost every organisation:
| Data | Example | What detects it |
|---|---|---|
| Structured identifiers | jan.devries@example.nl, NL91 ABNA 0417 1643 00, +31 6 1234 5678 | Patterns and checksums, very reliably |
| Credentials | API keys, access tokens, connection strings in pasted logs | Patterns and entropy checks |
| Names of people | "Please reply to Marieke about her refund" | Dictionaries for common names; a trained model for the rest |
| Organisations and places | Company names, street addresses, towns | Dictionaries plus a trained model |
| Special category data | "She has been off sick with burn-out since May" | Context. No detector is reliable here: this needs a usage rule |
| Identifying combinations | "Our only female partner in the Eindhoven office" | Nothing reliable. The combination identifies, not any single word |
The last two rows matter most. A detector finds values; it does not understand that a job title, a location and a date together point to one person. Those cases are best handled by policy: some tasks should not go to an external model at all.
How well detection works: our measurement
We measured three detection set-ups in our own gateway on 105 held-out synthetic test cases (not 105 independent documents), 372 annotated details per set. Whether each detail was removed in context was judged by the benchmark's model grader, a separate language model, not by human review.
| Set-up | What runs | Details removed | Rate |
|---|---|---|---|
| Patterns only | Regular expressions, checksums, context rules, name directory and dictionaries | 211 of 372 | 56.7% |
| Patterns and a light model | The above plus a small multilingual entity model | 299 of 372 | 80.4% |
| Patterns and a PII model | The above with a model trained specifically for personal data | 367 of 372 | 98.7% |
| PII model and LLM review | The above plus an optional review by a hosted language model | 371 of 372 | 99.7% |
Measured 15 September 2026. Two things to keep in mind when you use these numbers:
- They measure how many annotated details were removed in context. They do not measure whether a whole document became anonymous. One missed detail can be enough to identify someone.
- They are measurements of our own pipeline on our own synthetic test set. We have not run other vendors' products on the same test cases. Run a similar test on 50 of your own documents before relying on any vendor's figure, including ours.
What it costs
| Tier | Median time per call | Slowest of 30 calls |
|---|---|---|
| Light model | 3.5 ms | 4.0 ms |
| PII model | 521.5 ms | 549.6 ms |
Measured 14 September 2026 on a 919-character multilingual text, in-process, excluding network time. For a chat assistant, half a second before the model starts answering is usually acceptable. For a high-volume API with tight latency targets it is a design decision.
Recall also costs precision. Aggressive rules remove things that are not personal data. A rule that treats every unfamiliar capitalised word as a possible name will also remove product names, project codes and model names, which can make answers worse. That is why we ship that rule switched off. Measure false positives on your own documents alongside recall.
Fail closed
Decide what happens when detection fails: a model times out, a document cannot be parsed, a file type is unknown. A pipeline that fails open sends the unredacted text. A pipeline that fails closed blocks the request. For personal data, fail closed. This single setting matters more than the choice of model.
Placeholders instead of deletion
Deleting personal data makes many prompts useless: "Write a reply to [removed] about the refund of EUR 40 to [removed]" gives the model nothing to work with. Replacing it keeps the structure:
Write a reply to «PERSON_NAME_1» about the refund of EUR 40 to «IBAN_1».
The gateway keeps the mapping between «PERSON_NAME_1» and the real name, sends only the placeholder to the provider, and restores the real values in the answer before it reaches the user. Two details make this work in practice:
- Consistency. The same person gets the same placeholder throughout a conversation, so the model can follow who is who.
- Type information. «PERSON_NAME_1» and «IBAN_1» tell the model what kind of value was there, which keeps answers grammatical and useful.
What the law says
The Court of Justice: EDPS v SRB, 4 September 2025
The case (C-413/23 P) concerned the Single Resolution Board, which replaced the names of people who had submitted comments with randomly generated 33-digit codes, kept the table linking codes to names, and passed 1,104 comments to Deloitte. The Court held:
- Opinions are personal data about their author (paragraphs 58 to 60). Text your staff write into a prompt is, as a rule, personal data about them.
- Pseudonymised data is not automatically personal data for everyone. The existence of a linking table means pseudonymised data can never be treated as anonymous in all cases (paragraph 73). But pseudonymisation "may, depending on the circumstances of the case, effectively prevent persons other than the controller from identifying the data subject in such a way that, for them, the data subject is not or is no longer identifiable" (paragraph 86).
- For the recipient, that depends on two conditions (paragraph 77): the recipient cannot undo the pseudonymisation, and it cannot identify the person "by recourse to other means of identification such as cross-checking with other factors".
- Your duty to inform does not change. Whether you had to tell people that their data would go to a recipient is judged from the controller's position, at the time of collection (paragraphs 111 and 112). What the recipient can or cannot identify afterwards is irrelevant to that duty.
Applied to prompts:
| Prompt sent to the provider | Identifiable for the provider? | Why |
|---|---|---|
| "Refund for «PERSON_NAME_1», IBAN «IBAN_1», order 48213" | Probably not | The order number means nothing to the provider, and the mapping stays with you |
| "«PERSON_NAME_1», our only female partner in Eindhoven, is on sick leave" | Yes | The description identifies her without a name, and it reveals health data |
| A stack trace containing a customer's e-mail address | Yes | The identifier was not detected, so it was sent in clear |
The EDPB's guidelines are still a draft
The EDPB's Guidelines 01/2025 on Pseudonymisation were published for consultation in January 2025; the consultation closed on 14 March 2025. We could not find a final version. The draft takes the position that pseudonymised data remains personal data when it can be attributed using additional information. It predates the judgment, and it is not yet clear how the final text will reflect it.
In practice: treat prompts as personal data in your own records and DPIA; use the judgment's two conditions to assess the provider's position; and write your reasoning down.
What you still have to do
- Name the AI provider as a recipient in your privacy notice, or the category of recipient, as paragraph 111 of the judgment makes clear.
- Carry out a DPIA where the use is likely to result in a high risk, for example HR, health or large-scale customer data.
- Keep a record of processing that includes the AI provider as a processor or recipient.
- Check the transfer position if the provider or its parent is outside the EU. Our guide on CLOUD Act exposure covers this.
What the providers keep
Retention defaults changed repeatedly in the last year. The positions below are as reported by the providers in announcements and help pages; confirm them against the terms you actually sign.
| Provider | Default for API customers, as reported | What to ask for |
|---|---|---|
| OpenAI | Content not used for training by default for business customers. Zero data retention available to eligible API customers, reaffirmed in August 2026 | Zero data retention in your agreement, and whether your endpoints qualify |
| Anthropic | API logs kept for 7 days since September 2025. Zero data retention agreements for qualifying enterprise customers. A 30-day retention scheme for its most capable models, with an option to keep the data in your own cloud, announced for autumn 2026 | Which retention applies to the models you use, and the zero-retention agreement |
The New York Times court order that required OpenAI to keep ChatGPT output logs indefinitely was lifted in October 2025, with exceptions for logs already preserved and accounts flagged in the case. It is still cited as a live risk; it is no longer an open-ended obligation.
Checklist
- Use cases mapped to the data they put into prompts
- Tasks that should never go to an external model defined in the AI use policy
- Detection layers chosen per use case, with a trained model wherever names appear
- Pipeline fails closed when detection errors or times out
- Recall and false positives measured on at least 50 of your own documents
- Placeholders used instead of deletion, consistent within a conversation
- Privacy notice names the AI provider or the category of recipient
- DPIA completed for high-risk uses
- Provider retention and training settings confirmed in the signed terms
Sources
- Court of Justice of the European Union, EDPS v SRB, Case C-413/23 P, judgment of 4 September 2025, paragraphs 23 to 28, 58 to 60, 72 to 77, 85, 86, 111 and 112
- European Data Protection Board, Guidelines 01/2025 on Pseudonymisation, consultation version, feedback period 17 January to 14 March 2025
- OpenAI, Offering Zero Data Retention for frontier models, 19 August 2026
- Anthropic, API and data retention documentation
- The lifting of the New York Times preservation order (order of 9 October 2025) and Anthropic's autumn 2026 retention scheme are taken from press reporting, including Engadget and CNBC.
- Detection and latency figures: Sluis measurements of 15 and 14 September 2026. The method is described in the Sluis data protection documentation.