Re-identification risk and how to reduce it

Replacing every name in a dataset with a token is necessary, but it is not the whole job. People can often be recognized from what surrounds their name: their role, their location, the timing of an event, a detail they mentioned once. Reducing re-identification risk means dealing with that context, and being honest that the goal is to make re-identification impractical and prohibited rather than to claim it is impossible.

Imagine a 40-person design agency. Its chat history has been anonymized, and every employee is now a token. One message says the agency's only finance person is leaving to have a baby in March. Another mentions that the head of engineering just moved from Toronto to Lisbon. Neither message contains a name. Both describe someone a former colleague, or a curious outsider with a company directory, could probably identify.

This is what privacy researchers call quasi-identifiers: details that are harmless alone but identifying in combination. Small organizations make the problem sharper, because a role that is shared by a hundred people at a large company may belong to exactly one person at a small one.

When we assess an archive, these are the sources of re-identification risk we look for:

• Unique roles. "Our CFO", "the only designer", "the founder" point to one person in most small companies.
• Locations. Office addresses, home cities, travel plans and time zones narrow the field quickly.
• Distinctive events. A lawsuit, an acquisition, a publicized outage or a product launch can be matched against public news.
• Personal details in free text. Health updates, family news, side projects and previous employers come up naturally in chat.
• Public footprints. Press releases, social profiles and job postings can be cross-referenced with internal content if the company is recognizable.
• Images and documents. Faces, logos, signatures and letterheads can identify people or organizations at a glance.
• Private conversations. Direct messages tend to contain far more personal detail than team channels.

None of these is a reason to give up on anonymization. They are the reason anonymization has to be designed in layers.

The first layer is how the data itself is transformed. Every person, company, address, email, phone number and account becomes a consistent token across every tool. That consistency is what keeps the data useful: PERSON_014 is the same person in Slack, email and Jira, so the work still makes sense. It also means the anonymization covers organizations and places, not only people. A customer's name, a supplier's address and the company's own name are tokenized too, which removes many of the hooks for cross-referencing public information.

Credentials, API keys, card numbers and government IDs are removed outright. Faces, logos and signatures are blacked out in images and PDFs. Where a detail is unusual enough to single someone out, it can be generalized or removed. We explain why consistent tokens matter so much in why the same person must get the same token everywhere.

The second layer is deciding what never enters the dataset in the first place. HR, payroll, medical and legally privileged folders are excluded by default. These are where the most sensitive personal information lives, and they are rarely what AI labs need anyway.

Direct messages are excluded unless the company chooses to include them and has the right to. The seller can also exclude specific clients, channels, folders or projects. Those exclusions are annexed to the contract before any data moves, so they are binding rather than a verbal promise. A company with a well-known client or a sensitive internal matter can simply keep that material out. See exclusions: keeping clients, channels and folders out of scope for how sellers usually approach this.

The anonymized sample review is part of this layer too. The seller looks at real anonymized output before delivery and can flag anything that still reads as identifying.

Technical measures reduce what can be inferred. Contracts govern what anyone is allowed to try. Every licence restricts use to training and evaluation. Buyers may never market to, profile, contact or re-identify anyone in the data, and the data is never resold for marketing or people search.

This matters because the realistic threat is not a stranger stumbling on a message. It is someone with resources deliberately trying to link records to people. A clear contractual prohibition, backed by the licensing relationship, makes that a breach with consequences rather than an open question.

Handling of the raw data is part of the contract as well. No third party touches it, and the raw archive is deleted within 30 days of sign-off, with a deletion certificate issued. Once that happens, there is no un-anonymized copy left with us to leak or misuse.

Each layer covers gaps in the others. Tokenization handles names and identifiers but cannot anticipate every personal anecdote. Exclusions remove whole categories of risk but are coarse. Sample review catches what automated rules miss but depends on someone reading carefully. Contracts cannot undo a disclosure but strongly discourage misuse.

Used together, they give much stronger protection than any single technique could:

• Identifying values are replaced or removed
• The most sensitive material is never collected
• What remains is reviewed by the people who know the company best
• Anyone receiving the data is bound not to attempt re-identification

Our full approach, including our employee data standard, is on the trust page.

If you are weighing a data licence and want to understand how these layers would apply to your own archive, book a short call.