GDPR Articles 25 and 32 for AI Prompts: Pseudonymization Before Egress
When staff or agents send personal data to an AI provider, GDPR obligations on minimization, data protection by design, and security of processing apply to the controller. Replacing identifiers with surrogates in client memory before transmission is a technical measure that supports those obligations. It does not turn personal data into anonymous data.
Summary
Article 5(1)(c) requires data minimisation. Article 25 requires data protection by design and by default and names pseudonymisation as an example of an appropriate measure. Article 32 requires appropriate technical and organisational measures and names pseudonymisation as an example.
ZTDS tokenizes identifiers in client memory so the provider receives surrogates. Because the controller can reverse the mapping, the result is pseudonymised data, which Recital 26 says remains personal data when additional information exists. The benefit is a smaller disclosure to the provider and a stronger Article 32 posture, not an exemption.
Article-Level Mapping
| Provision | Obligation | ZTDS contribution |
|---|---|---|
| Article 5(1)(c) | Personal data must be adequate, relevant, and limited to what is necessary. | Only surrogates needed for the task leave the client. |
| Article 25 | Data protection by design and by default. | Sanitization is built into the workflow rather than left to user discipline. |
| Article 28 | Processor obligations when a processor handles personal data. | Reduces the personal data a provider receives. Whether an agreement is still required is the controller's own analysis. |
| Article 32 | Security of processing, including pseudonymisation. | Pseudonymisation is applied before egress with local evidence receipts. |
| Recital 26 | Pseudonymised data stays personal data when re-identification is possible. | Acknowledged: the mapping is retained by the controller and never leaves volatile memory. |
How ZTDS Applies
A defensible rollout combines the technical control with documentation:
- Record the sanitization step in the record of processing activities and the data protection impact assessment.
- Keep the token map in volatile memory only and zeroize it at session end (Invariant 3).
- Retain the local receipts as evidence of the measure operating.
- Review the provider agreement with counsel instead of assuming the sanitization removes the need for one.
What This Control Does Not Cover
- It does not make data anonymous. Under Recital 26, pseudonymised data remains personal data where additional information can re-identify.
- It does not remove the need to assess lawful basis, purpose limitation, or international transfer rules.
- Free-text can include indirect identifiers that pattern-based methods cannot guarantee to catch.
- This page is not legal advice and is not a regulator position.
Frequently Asked Questions
Is tokenized prompt data still personal data under GDPR?
It can be. Recital 26 states that pseudonymised data which could be attributed to a person with additional information is still personal data. Client-side tokenization reduces what the provider receives but does not by itself make data anonymous.
Does pre-egress sanitization remove the need for a data processing agreement?
Not automatically. It reduces the personal data a provider receives, which can change the analysis, but the controller must make that determination with counsel for its own facts.
Which GDPR articles does client-side sanitization support?
It supports the minimisation principle in Article 5(1)(c), data protection by design in Article 25, and the security of processing in Article 32, which names pseudonymisation as an example of an appropriate measure.
Related Specifications and Tools
- Global Regulatory Compliance Matrix — Cross-framework statutory mapping.
- CISO Procurement Pack — Vendor-questionnaire and safe harbor material.
- ZTDS RFC v1.0 Specification — The four invariants referenced on this page.
- Framework Mappings Hub — All framework mappings in one index.
- OWASP LLM02 Sensitive Information Disclosure — Maps pre-egress tokenization to OWASP LLM02:2025 and states what it does not cover.
- NIST AI RMF Generative AI Profile — Places ZTDS across GOVERN, MAP, MEASURE, and MANAGE for generative AI data privacy risk.
- EU AI Act Article 10 Data Governance — Describes how pre-ingestion sanitization supports Article 10 data governance practices.
- HIPAA Safe Harbor for LLM Prompts — Shows how 18-identifier removal applies to clinical text sent to language models.
- MCP stdio PII Sanitization — Describes a local gateway that sanitizes JSON-RPC traffic over the MCP stdio transport.
- RAG Pipeline PII Sanitization — Places sanitization at ingestion, retrieval, and prompt assembly stages of a RAG pipeline.
- Client-Side Sanitization vs Proxy DLP — Compares client-side in-memory sanitization with network proxy and cloud DLP approaches.