GDPR compliance dossier: TokenVeil

Document for the customer’s DPO / CISO. Version 1.0, to be adapted to each deployment’s context.

TokenVeil is a self-hosted anonymization proxy placed between an organization’s staff and the generative AI models (Claude, Gemini, ChatGPT, Mistral, and so on). It pseudonymizes personal and sensitive data before a message reaches the AI provider, and restores the real values only for local display. This dossier describes how TokenVeil fits into the GDPR obligations of the organization that deploys it.

Party	Role	Rationale
Customer organization	Controller	It decides the purposes and means (which employees, which AI uses).
TokenVeil vendor (Joopin’s Lab)	Software vendor, not a data processor	The software is delivered and runs on the customer’s infrastructure. The vendor has no access to the processed data, neither in operation nor through telemetry (see section 7).
AI provider (Anthropic, Google, OpenAI, Mistral, and so on)	The customer’s sub-processor	It only receives pseudonymized data (see section 3). The customer keeps its existing contract/DPA with that provider.

Key point: TokenVeil introduces no new sub-processor into the personal-data processing chain. The vendor never sees the data. The only outbound flow from the instance is the license check (section 7), which carries no personal data.

2. The nature of the processing TokenVeil performs

TokenVeil performs pseudonymization within the meaning of GDPR Article 4(5): each identifying item detected is replaced by a neutral token (<PERSON_1>, <IBAN_CODE_2>, and so on). The token-to-real-value mapping:

is encrypted at rest (symmetric Fernet encryption / AES-128-CBC + HMAC);
never leaves the customer’s network perimeter;
is never transmitted to the AI provider.

Careful terminology: from the customer organization’s point of view, this is pseudonymization (the data stays reversible on the customer side, so it remains personal data). From the AI provider’s point of view, the data it receives is not re-identifiable (it has no access to the mapping): the risk of that third party processing personal data is thereby strongly reduced, and even removed for the categories that are correctly detected.

3. Categories of data detected and pseudonymized

TokenVeil detects and replaces, using an NER engine (Presidio + spaCy) and deterministic patterns:

Identity: first/last names, civility titles, composite identifiers (user_jean_dupont).
Contact details: emails, phone numbers (FR and international).
National IDs: NIR (French social security number), IBANs, credit cards, license plates.
Identifying technical data: IP addresses (public and internal), MAC addresses, hostnames, session identifiers.
Secrets: API keys (AWS, GitHub, Stripe, Anthropic, OpenAI, and so on), JWT tokens, cleartext passwords, connection strings, PEM private-key blocks.
Financial data: contextualized transaction amounts.
Custom business terms: internal product names, codenames, defined by the deployment administrator.

Measured coverage: 0% leakage on the annotated test set and on 5,500+ randomly generated values (see tools/benchmark_anon.py and the public benchmark page). The active categories are configurable per deployment (admin interface).

Limit to document in the records: no detection system is perfect. A proper name unknown to the NER, in an ambiguous context, can escape pseudonymization. TokenVeil reduces the risk, it does not contractually eliminate it, and the impact assessment (DPIA) must take this into account.

Principle	Article	TokenVeil’s contribution
Data minimization	5(1)(c)	Only pseudonymized data reaches the AI provider.
Protection by design	25	Pseudonymization is applied by default, before any external send.
Security of processing	32	Encryption of the mapping at rest, pseudonymization in transit to the third party, access control (see section 5).
Transfer limitation	44-49	The real data never leaves the customer network; any transfer outside the EU to the AI provider carries only non-re-identifiable tokens.

TokenVeil is a tool that serves the controller’s compliance, not a guarantee of compliance in itself: overall compliance also depends on the purposes, the information given to individuals, and the retention periods the customer decides.

5. Technical and organizational measures (Art. 32)

See the detail in security-measures.md. In summary:

Encryption at rest: the pseudonymization mapping, the credentials of linked AI accounts, the LDAP service account password, all encrypted (Fernet).
Authentication: local accounts (PBKDF2-HMAC-SHA256, 600,000 iterations) or LDAP/Active Directory; sessions stored as a SHA-256 hash (the cleartext token is never persisted).
Brute-force protection: lockout per account and per IP address (anti-password-spraying).
Rate limiting: an application guardrail per user / API key / IP.
HTTP security headers: strict CSP with no third-party origin, anti-clickjacking, HSTS behind TLS.
Zero external CDN dependency: all frontend assets (scripts, fonts) are served locally, so it works air-gapped and removes the supply-chain risk.
Audit log: records that a pseudonymization happened (category + number of occurrences), never the real value, so the log itself creates no leak risk.
Least-privilege execution: non-root Docker container.

6. Data retention and location

Location: entirely on the infrastructure the customer chooses (on-premises server or a sovereign FR/EU cloud of its choice). No data is hosted by the vendor.
Database: SQLite with application-level encryption of the sensitive items, on the customer’s disk.
Retention period: fully controlled by the customer. Conversations and their mappings can be deleted at any time from the interface; deletion is final (the encrypted mapping is destroyed, so pseudonymization becomes irreversible).
Right to erasure (Art. 17): deleting a conversation erases the mapping; any residual tokens then become non-reversible.

7. Outbound flows and absence of telemetry

The only network flow a TokenVeil instance initiates to the outside is the license check (phone-home), which transmits exclusively:

the license identifier,
an anonymous instance identifier (a locally generated UUID),
the software version number.

No personal data, no message content, no usage metric is transmitted. This flow can be audited (a single outbound stream to the configured license server URL). For a fully isolated deployment, the license can be provided as a signed file (Ed25519) with no phone-home.

8. Elements for the customer’s records of processing

To carry into the customer organization’s records (Art. 30):

Purpose: enable staff to use generative AI tools without exposing personal or sensitive data to third parties.
Categories of individuals: staff users plus anyone mentioned in the submitted content (clients, prospects, patients depending on the sector).
Categories of data: see section 3.
Recipients: the selected AI provider(s), in pseudonymized data only.
Transfers outside the EU: depending on the AI provider; they carry only non-re-identifiable tokens.
Retention period: set by the customer (see section 6).
Security measures: see section 5 and security-measures.md.

security-measures.md: Detailed technical and organizational measures (Art. 32).
DPA-template.md: A data processing agreement template, to adapt if the vendor provides support services.

This dossier is technical material provided in good faith. It is not legal advice. GDPR compliance is a matter for the controller and, where applicable, its DPO to assess.