How we protect people's data, in layers

Find-and-replace is a red flag

When a frontier lab looks at a new data vendor, one of the first questions is how the vendor replaces people's names. "We run a find-and-replace" is a red flag. A list of names and a search tool remove the names that appear exactly as listed. Real records write names in many other ways, and the rest of a record can point to a person when no name is left.

The law sets a high bar. Under European law, a person is identifiable if the holder of the data, or anyone else, can identify them by means reasonably likely to be used, and pseudonymised data are still personal data. ¹ The European Data Protection Board's draft guidelines, adopted for consultation on 7 July 2026, propose three criteria for anonymous data: no one can isolate a person's record, link it to other records about that person, or draw specific and meaningful inferences about them. ² The UK regulator asks whether a competent, motivated intruder could re-identify someone with the tools available today, and it counts generative AI tools among them. ³

We keep the original records, and the table that links each original value to its replacement. For us, the output therefore stays personal data, and we protect it as personal data. In EDPS v SRB (2025), the EU Court of Justice held that pseudonymised data may not be personal data for a recipient with no means reasonably likely to identify the people. For the party that pseudonymised them, they stay personal data, and its duties, such as telling people who will receive their data, are judged from its position when it collects them. ⁴ So the question that matters is what the people who receive the output could learn. Three kinds of reader count: staff at the recipient, anyone who obtains a copy after a leak, and the users of a model trained on the data. Each of them may hold other data, such as the web, data-broker files or their own users' records.

What find-and-replace misses

Take the phone export of an invented person: bank lines, messages, calendar events, e-mails, device records, contacts and notes, in the forms that real exports use. Ours holds 197 identifiers. 148 point at a person directly, such as names, numbers and addresses. 49 narrow a person down, such as an employer, a street or a date of birth. It also holds 104 ordinary words that look like names, such as the month May, the verb "mark" and the noun "bill". A good method keeps those.

A careful find-and-replace, with the full list of known people, organisations and places, with and without accents, and the standard patterns for e-mail addresses, phone numbers and bank and national ID numbers, leaves 76 identifiers. It misses every inflected form of a name (in Lithuanian, "Tomas" becomes "Tomo" and "Tomui"), every nickname, every name inside a file name, and every name that a look-alike letter or an invisible character has changed. It also replaces 11 ordinary words: "grace period" becomes a person.

Microsoft Presidio, a widely used open-source tool that finds names with a statistical language model, leaves 95, including nearly every identifier in the upper-case bank lines. It ran with its standard English model and without the list of known people that the other methods had. On court judgments, Presidio found only 46% of the direct identifiers. ⁵ Our layers leave 1: a pet's name in a password hint.

A record that we write ourselves is the easy case, so a separate model, which never saw our rules, wrote a second one: a Polish nurse who lives in Germany, with messages in Polish, German and English, 221 identifiers and 80 ordinary words that look like names. Find-and-replace leaves 137 identifiers on it, and Presidio 98. Our rules alone leave 97, because Polish grammar and German organisation names are hard for any list. The reviewer brings the count to 12: ages, a child's school class, the name of a child's nursery inside a password hint, two people whom no list knew, and a German social security number inside a file name. The scan catches that number and stops the build. Three other hits are the owner's real city, which the reviewer and the record's own answer key both missed.

Rules are only as good as the languages they know. The reviewer is what carries the method to a new record, and the scan is what makes the reviewer safe to use.

Two intruders, two records

We give each output to two frontier models from different labs, Claude Opus 5.5 and Gemini 4 Argon, and tell each to act as a motivated intruder: recover the owner's first and family name, date of birth, employer, street, city and six other facts, with only the output in front of it. From the find-and-replace outputs they recover 8 to 10 of the 12 facts, and from the Presidio outputs 11 or 12. From our rules alone they recover at most 1 on our record, but 7 on the blind record.

From all our layers they recover nothing on our record. On the blind record, Gemini recovers two facts: the owner's date of birth, from the social security number in a file name that our scan had already stopped, and the real name of a child's nursery inside a password hint. Language models infer a person's location, age and income from ordinary text at a fraction of a human's cost, so the attack must use them. ⁶ Our reviewer is also Claude Opus 5.5, so the Claude intruder can share its blind spots; Gemini is the independent attacker. Because the people are invented, this attack finds leftover text. It cannot test linkage with outside data.

The record itself is an identifier

Names are the easy part. An early study estimated that date of birth, sex and postcode single out 87% of Americans, and a later re-analysis put the figure at 61% to 63%. ^{7 8} Four points of place and time single out 95% of people in phone location data, and four purchases single out 90% of people in card records. ^{9 10} With 15 demographic attributes, 99.98% of Americans can be re-identified. ¹¹

Time series are no different. In a US national health survey, a machine-learning model matched 94% of adults to their records, from activity-monitor data with the health identifiers removed and basic demographics. ¹² Gait, heart signals and typing rhythm all work as biometrics. ^{13 14 15} A record with no name can therefore still be matched to the same person's other records by its rhythm alone, and moving the dates does not change that rhythm.

Formal models do not remove this risk either. k-anonymity requires each record to look like at least k others, and long, detailed records cannot meet that without the loss of most of their detail. ¹⁶ Differential privacy gives a mathematical bound, but for one person's record, the noise it needs removes the detail that a task depends on. ¹⁷ It fits best at training time, where the lab that trains the model sets it.

So a detailed trace is never anonymous by itself. Its protection comes from the detail that is kept, the length of the window, and who receives it, under what terms.

Our layers

No single method removes the risk, so we use eight layers. Each layer assumes that the one before it failed, and the release gate refuses a build that skips one.

• Rights before data. Every source has a record of its origin, its licence and the uses it allows.
• Read only what the work needs. Our readers open only the tables and fields that are named for each source. For a phone export, that leaves out the location history and the account, settings and billing files. Device names, which often carry the owner's first name, are never stored, exact coordinates are not carried, and the export's own record numbers are dropped.
• Map every value, and stop on the unknown. Structured values, such as the payee of a bank line, pass through a reviewed table that maps each original to its replacement. A value without an entry stops the build. Find-and-replace fails open: what it does not know, it lets through. A table fails closed.
• Replace consistently, in the same form. One person gets one replacement name everywhere, of the same gender and language. The rules know the inflected forms, diminutives, initials and glued forms of every known name, in each language of the record, and put the same form of the replacement in its place: "Tomui" becomes "Lukui", not "Lukas". No replacement shares a word with a real name, and the people around the owner, such as family, friends and colleagues, get the same protection as the owner.
• Move time, and the text with it. Every time in a record moves by an offset that we keep secret, and dates written inside the text move with it. A holiday named in the text becomes a general word, because a "May bank holiday" in October tells a reader how far the dates moved. No date of birth comes from the record.
• Read free text twice. Rules come first: they undo look-alike letters and invisible characters, find every form of every known name, and replace patterns such as phone and account numbers. Then a reviewer model reads what is left and marks the people that no list knew and the facts that identify only in combination, such as "the only Lithuanian-speaking hygienist in the city". The reviewer only marks. The rules write every number, from a reserved range or with a check digit that no real account can have where the format allows, and one fact keeps one value everywhere. In one study, language models anonymised text better than the commercial tools tested. ¹⁸
• Scan last, with a key held apart. A final scan reads every file of the build, including field names, comments and compressed pages, after it normalises the text. It cuts the text into runs of one to five words, also reads each word with its digits removed, and compares a keyed hash of each run with the hashes of the original values. The key is kept in a secrets vault, apart from the code, so the list of hashes cannot be reversed by anyone who hashes a list of names. The scan also checks every edit the reviewer proposes, before it applies. A single hit, or a file that the scan cannot read, stops the build.
• Intruders from two labs. Before every release, models from two different labs attack the output as motivated intruders. Their guesses are checked against the hashes of the original values, and a recovered value stops the release. A person reads what they found and signs the report.

Each layer catches the last one's mistakes

The order exists because every layer makes mistakes. Rules once read the Lithuanian name form "Tomo" inside the word "tomorrow" and changed the word. The reviewer model saw the damaged word and restored it, and the rule changed.

A reviewer that writes its own replacements makes worse mistakes. Told to replace a pseudonymous national insurance number, one wrote back the original, because the original was the standard example number from public documentation. The same reviewer moved one owner's date of birth by a different amount in different messages, and left five birthdays. A record that contradicts itself shows an intruder where the edits are. That is why our reviewer only marks, the rules write every number, and the scan checks every edit. A generative step must never write a value that no rule checks.

Intruders find what the rest misses. One worked out how far the dates had moved: the dates written inside the bank lines had not moved, and a "May bank holiday" now fell in October. With that offset it recovered the owner's real birthday. The same model saw an initial, "Ms I", in front of a replaced family name, and from it guessed the owner's real first name. Dates in the text now move with the record, holidays become general words, and an initial changes with its name.

What survives

Protection is worth little if the record no longer teaches anything. In the records above, these survive: amounts, merchants, the order of events and the time between them, the local time of day, weekdays, the mix of languages, typos, emoji and grammatical forms, family relations between names, and who writes to whom. These change: names, places, organisations, numbers, file names, the dates themselves, and rare facts, which become general ("one of the few staff who speak another language"). Our layers kept 103 of the 104 ordinary words that look like names in the first record, and 76 of the 80 in the blind record.

What protection cannot promise

No method makes re-identification impossible. US health guidance asks for a risk that is very small, not zero. ¹⁹ A model that trains on a record can repeat parts of it word for word, and larger models repeat more. ²⁰ Removing personal data before training reduces this leakage, but it does not remove it. ²¹ Synthetic data is not a way out: it either keeps the information that enables an attack or loses the information that makes it useful. ²² A hash does not hide a value with few possible forms. In 2014, New York City released taxi trips with hashed licence numbers, and one person computed every possible hash in less than two minutes. ²³

What a careful vendor can promise is a process: every layer written down, every build scanned, every release attacked by two labs' models and signed by a person, and the remaining risk named rather than denied.

Questions to ask any data vendor

Data partners trust us with records about real people, and labs train on what we build from them. Both should ask these questions of us and of every other vendor.

• Which fields do you read, and which do you never open?
• What happens to a value that your rules do not recognise?
• Do your replacements keep the grammatical form of a name, and does one fact keep one value?
• Can a generative step write a value that no rule checks?
• Who attacks your output before it ships, and with which models?
• Who receives the result, under what terms, and what other data about the same people do they hold?