Data licences and the people in the data

A data licence has two signatures on it, but the data inside it involves hundreds or thousands of people. Employees wrote the messages, customers sent the emails, vendors appear on invoices and candidates show up in hiring threads. None of them sign the licence, so the licence and the process behind it have to be designed with them in mind.

This post looks at who those people are, what the licence promises about them and where the remaining responsibility sits with the seller. It is general information, not legal advice, and companies should involve counsel on privacy and employment questions specific to their situation.

It helps to name the groups, because each shows up differently across the tools:

• Employees and contractors, who wrote most of the Slack messages, tickets, pull requests and internal documents
• Customers and their staff, who appear in support tickets, email threads, CRM records and shared channels
• Vendors and partners, who appear in procurement threads, invoices and integration discussions
• Candidates, who appear in recruiting threads and interview notes
• Investors, advisors and board members, who appear in fundraising and governance discussions

Each of these groups has different expectations. An engineer expects their pull request comments to be read by colleagues. A candidate does not expect their interview feedback to travel anywhere. A good scope reflects those differences rather than treating the archive as a single block.

The first protection is that the people stop being identifiable as themselves. Every person, company, address, email, phone number and account is replaced with a consistent token across every tool. PERSON_014 is the same person in Slack, email and Jira, but the name behind PERSON_014 is not in the delivered dataset. Our post on why the same person must get the same token everywhere explains why consistency is what keeps the data useful.

Some personal information is removed rather than tokenized. Credentials, API keys, card numbers and government IDs are stripped outright. Faces, logos and signatures are blacked out in images and PDFs, so a scanned contract or a team photo does not carry anyone's likeness or signature.

No third party touches raw data at any stage. Anonymization is done in-house, and the buyer receives only the anonymized output.

Some parts of a company's records are more personal than others, and the defaults reflect that. HR, payroll, medical and legally privileged folders are excluded by default. Direct messages are excluded unless the company chooses to include them and has the right to do so.

These defaults matter most for employees. Performance reviews, salary discussions, leave requests and private conversations are the material people would least expect to leave the company in any form. Leaving them out entirely, rather than relying on tokenization, is the more conservative choice.

The seller can go further. A recruiting folder, a channel used for personnel matters or a hiring pipeline in the CRM can be excluded like any client or folder. Those exclusions are annexed to the contract before any data moves. Our employee privacy standard and the trust page describe these defaults in more detail.

The licence then limits what happens to the anonymized data. Use is restricted to training and evaluation. The buyer may never market to, profile, contact or re-identify anyone in the data, and the data is never resold for marketing or people search.

Those clauses are written for the people in the data more than for the seller. A former employee does not need to worry that an AI lab will use the dataset to build a contact list, attempt to work out who PERSON_014 is or sell the material to a people-search service. Each of those would be a breach of the licence.

Re-identification deserves a particular note. Tokenization removes direct identifiers, but context can sometimes hint at who someone was. That is why the prohibition on re-identification sits in the contract alongside the technical work, and why we have written separately about re-identification risk and how to reduce it.

The pipeline and the licence carry most of the load, but some decisions belong to the company. The seller decides what is in scope, whether to include direct messages and whether it has the right to do so. The seller reviews an anonymized sample before delivery and can raise anything that looks wrong.

Imagine a 120-person healthcare scheduling company that is winding down. Its directors might keep engineering, product and support tools in scope, exclude the recruiting folder and a leadership channel, leave direct messages out and rely on the default exclusion of HR and medical material. That is a reasonable set of choices, but they are the company's choices, made with its counsel, not something the pipeline decides for it.

The seller also decides how to communicate with the people involved. Some companies tell current or former employees before a licence is signed, and some may be required to. That is a question for the company and its advisors, and it is worth asking early.

Once the seller signs off on the anonymized sample, the raw archive is deleted within 30 days. That is a contract obligation, with a deletion certificate at the end. The only version that persists is the anonymized one, under a licence that limits it to training and evaluation.

For the people in the data, that means there is no lingering unredacted copy outside the company, and the copy that does exist is covered by explicit restrictions on contact, profiling and re-identification.

If you are weighing a licence and want to think through how it would affect your employees, customers or candidates, that is a good place to start. Book a 15-minute call and we will go through scope, defaults and exclusions with the people in your data in mind.