Companion to "The same prompt, two definitions of personal data". Engineering reference, not legal advice. Verify against counsel before it drives a production policy.
What each regime catches that the others do not
| GDPR (EU) | CCPA/CPRA (California) | LGPD (Brazil) | PIPL (China) | |
|---|---|---|---|---|
| Core unit | identified or identifiable natural person | consumer or household | identified or identifiable natural person | identified or identifiable natural person |
| Catches free-text opinion | Yes. Opinions are personal data by their nature (EDPS v SRB, 2025) | Through the broad linkability test | GDPR-shaped, so in practice yes | Broad definition, in practice yes |
| Unusual inclusion | pseudonymised data, as a rule with a contextual exception | AI systems capable of outputting personal information (AB 1008, in force 1 Jan 2025); neural data as sensitive | mirrors GDPR categories, with a broader sensitive-data list in practice | separate, stricter track for sensitive personal information |
| Unusual exclusion | properly anonymised data only | publicly available information, but not biometrics collected without knowledge | limited | limited |
| Sending a prompt abroad | a transfer needing a mechanism where the provider is outside the EEA | not framed as a transfer regime | needs adequacy, ANPD standard clauses, or consent | needs approval, the Chinese standard contract, or a security assessment |
| Practical trigger | data subjects in the Union, plus establishment and targeting tests | California residents, plus business thresholds | data subjects in Brazil, plus targeting | personal information handled in China, plus extraterritorial reach |
The table is a starting point for scoping, not a substitute for advice. The rows that most often surprise engineering teams are the household unit in California, the opinion point under the GDPR, and the fact that a prompt leaving the country is itself the export event under the PIPL.
Choosing a standard for a project
Work through these in order. Stop when you have a template, not when you have an argument.
Not who the product is aimed at. Who actually shows up in the traffic. A B2B product sold in Germany carries EU personal data whether or not the contract mentions consumers.
Assume more than one. A German resident who is also a California consumer is not a corner case in a global product. The applicable set is a union, not a choice.
These regimes are not ordered. Compose the requirements: broadest entity coverage, strictest handling for sensitive categories, tightest transfer route.
If detection cannot run, does the request stop or proceed. Write the answer down per project. It is a policy decision, and the reviewer will ask about it before they ask about recall.
The template identifier and its version travel with the request. Looking it up later against a config that has since changed is not an answer.
Detection layers, and what each one is for
| Layer | Catches | Fails at |
|---|---|---|
| Deterministic patterns | card numbers, IBANs, national IDs, emails, anything with a checksum or a fixed shape | anything without a shape; false positives on lookalike strings |
| Named entity recognition | people, organisations, locations in free text | uneven recall across languages; novel or domain-specific entities |
| Custom rules | your case numbers, contract references, employee formats | only what you thought to describe |
| Reversible tokenization | keeping the response usable while the provider sees nothing reversible | nothing, if the mapping outlives its purpose or leaks |
Measure recall per language, not once. Jurisdiction and language correlate, so a pipeline tuned on English tickets is quietly weakest exactly where a European regulator is strictest.
The token mapping is a security asset
If you rely on the recipient-side argument, that a provider holding only tokens has no reasonable means of reidentification, then the mapping is what that argument rests on.
A leaked mapping does not just cause an incident. It retroactively weakens the position for every request the mapping covered.
What to record, per request
- The standard and template version that applied.
- What was removed, as categories and counts, never as values.
- Whether detection ran at all, distinguishable from finding nothing.
- The decision: allowed, redacted, blocked, held.
- The jurisdiction the request was treated as belonging to.
That set answers the reviewer's question without becoming a second copy of the personal data. It is also the minimum needed to reconstruct a single request eleven months later, which is the test that matters when the question arrives from outside.