Blog/Redaction

The same prompt, two definitions of personal data

30 June 20266 min readObstruo team
RedactionPIIGDPR

A support message from Munich and the same message from California are not the same compliance object.

A customer support message arrives with a name, an email, a phone number and an order reference. If the sender is in Munich, that is personal data under the GDPR and the request needs minimisation before it reaches a provider. If the sender is in California, the CCPA draws the line in a different place. Brazil and China draw it in two more.

Most teams solve this once, in the first service that talks to a model, with a regex file. Then the second service ships with a different regex file.

The line moves, and not where you would expect

The differences between these regimes are not a matter of one being stricter than another across the board. They cut in different directions, and each one catches something the others do not.

The GDPR reaches the free text, not just the identifiers. In EDPS v SRB the Court of Justice confirmed that personal opinions and views are personal data by their nature, because they are inseparable from the person who expressed them, with no need to run the usual content, purpose and effect analysis. A complaint about a delayed order is personal data because of what it is, not because of the phone number sitting next to it. Strip every identifier from a support ticket and you have reduced risk, not left the regulation.

California counts households, and now counts models. The CCPA covers information that can reasonably be linked, directly or indirectly, to a consumer or a household, a unit that has no equivalent in the GDPR. Since 1 January 2025, AB 1008 has made clear that personal information can live in abstract digital formats, expressly including "artificial intelligence systems that are capable of outputting personal information". A companion bill added neural data to the sensitive category. The exclusion for publicly available information is also narrower than teams assume: biometrics collected without the consumer's knowledge do not qualify.

China turns the prompt into an export event. Under the PIPL, moving personal information out of the country needs a legal route: a recognised approval, the Chinese standard contract, or a government security assessment for larger volumes and sensitive categories. If a prompt containing personal information leaves for a provider hosted elsewhere, that is the transfer, not a preliminary to it.

Brazil is GDPR-shaped and moving. The LGPD tracks the GDPR closely, the ANPD has adopted its own rigid standard contractual clauses, and the European Commission published a draft adequacy decision for Brazil in September 2025. The direction is convergence, but the mechanism is still Brazil's own.

Overlap is the normal case

The mistake underneath the regex file is not choosing the wrong standard. It is assuming that a request has one.

These regimes are extraterritorial by design. They attach to the person and the context rather than to where your servers sit, which means a single request can sit inside two or three of them at once: a German resident who is also a California consumer, or a Brazilian user of a US product handled by a support team in Ireland. The question a request has to answer is not which standard applies. It is which standards apply, and what the union of them requires.

That is a composition problem, and composition is exactly what a per-service regex file cannot do.

Jurisdiction is a property of the request

Redaction that is hardcoded per service is really redaction per team. What you want is a standard chosen per project and per jurisdiction, applied to the request in flight, so a prompt from Germany leaves with GDPR-grade redactions and the same prompt from California gets CCPA-grade.

Every template ships with the product. You pick which one applies to a project, and different projects can run different standards side by side without either team writing detection logic.

The corollary is that jurisdiction has to be carried on the request, not inferred at the far end. If the only way to know where a request came from is to look up the API key in a table that has since been edited, you do not have a jurisdiction; you have a guess with a timestamp.

Detection is layered, because one method is never enough

  • Deterministic patterns for structured identifiers: card numbers, national IDs, IBANs, emails.
  • Named entity recognition for the things patterns miss: people, organisations, locations in free text.
  • Reversible tokenization, so the response can be re-identified inside your boundary and the mapping then discarded.
  • Your own rules for the identifiers only your business has.

Two things worth being honest about with a layered pipeline.

First, recall is not uniform across languages. An NER model that performs well on English support tickets will not perform identically on German or Portuguese ones, which matters precisely because jurisdiction and language correlate. The pattern layer carries more of the load in some languages than others, and that is an argument for measuring per language rather than quoting one number.

Second, and following from the CJEU point above, no layer removes free-text opinion. Detection reduces what leaves; it does not convert a support ticket into non-personal data.

What the CJEU changed for gateways

In September 2025 the Court held something that had been assumed to be settled the other way. Sufficiently pseudonymised data may be personal data for the controller who holds the key, and not personal data for a recipient who has no reasonable means of reidentification. The assessment is contextual and risk-based, judged from the recipient's position.

That maps directly onto the architecture described above. Tokenise at the boundary, keep the mapping inside it, and the provider receives something it cannot reverse. What was previously a good practice argument now has a judgment behind it.

Three caveats, because this is the part where a vendor would normally stop talking.

It is not a licence. The data stays personal data for you, with every obligation that follows. Redaction is minimisation and risk reduction, not an exit.

It is contextual. The reasoning turns on whether the recipient has reasonable means of reidentification, and a provider that also receives your identity metadata, your logs, or a low-entropy token space may well have them.

And it is contested. The EDPB's draft Guidelines 01/2025 on pseudonymisation take the stricter position that pseudonymised data remains personal even when the additional information sits elsewhere, and updated guidance has been announced. Build for the strict reading and the permissive one is upside.

One practical consequence: the token mapping is now a security asset in its own right. If it leaks, the recipient-side argument collapses retroactively for every request it covers. Short-lived mappings, discarded after re-identification, are worth more than a long-lived vault.

The failure mode matters more than the coverage

If the detector cannot run, does the request proceed unredacted or stop?

That is a policy decision, and it should be yours rather than a default someone inherited. It is also the question a reviewer reaches fastest, because it is the one where a wrong answer produces an incident rather than a finding. Worth deciding explicitly, per project, alongside the standard:

  • What happens when the NER model times out.
  • What happens when a custom rule set fails to load.
  • What happens when the token store is unreachable and re-identification is impossible.
  • Whether "no entities found" and "detection did not run" are distinguishable in the record. If they are not, every clean request is indistinguishable from every failed one.

What this changes in review

The question a reviewer asks is not whether you redact. It is whether you can show which standard applied to a given request and what was removed.

Category counts on the record answer that without storing the personal data itself, which is the only version of that answer a data protection officer will accept. A record reading policy v4.2, GDPR template, three identifiers and one payment instrument removed, decision: redacted and forwarded is evidence. A record holding the identifiers is a second copy of the problem.

That is also why the standard has to be pinned to the request rather than looked up afterwards. Eleven months later, the only defensible answer to "which rule was in force" is the one the request carried with it.

This is an engineering perspective on where redaction belongs in a request path, not legal advice. Whether a given regime applies to a given request turns on facts about establishment, targeting and residency, and the pseudonymisation question in particular is unsettled.

Sources

Companion checklistFour regimes, one prompt: a working cheat sheetOpen the checklist