Employee privacy and company data: our standard

Every company archive is full of people. They wrote the messages, filed the tickets, reviewed the code and answered the customers. None of them signed up to have their work used to train AI, and our standard starts from that fact: a licence should let a lab learn how work gets done without ever learning who did it.

When a company licenses its operational data, the company is the party that signs and gets paid. The employees, contractors, customers and vendors who appear in the data are not at the table. That makes us responsible for protecting people who will never read the contract.

We think about it this way. A lab needs to see that a support lead escalated a bug to an engineer, who opened a ticket and shipped a fix two days later. It does not need to know the support lead's name, where they lived, what they were paid or whether they took sick leave that month. Everything in our standard follows from separating the shape of the work from the identity of the people doing it.

Our standard has a few layers. Some things are replaced, some are removed outright, and some are never collected in the first place.

• Replaced with consistent tokens. Every person, company, address, email, phone number and account becomes a token. PERSON_014 is the same person in Slack, email and Jira, but is never named. This keeps the work coherent without revealing anyone.
• Removed outright. Credentials, API keys, card numbers and government IDs are deleted, not tokenized. There is no reason for them to exist in a training set.
• Blacked out in images and documents. Faces, logos and signatures in images and PDFs are covered so they cannot be read or matched.
• Excluded by default. HR, payroll, medical and legally privileged folders are left out unless there is a specific, considered reason otherwise. In practice, they stay out.
• Excluded unless chosen. Direct messages are excluded unless the company decides to include them and has the right to do so.

The consistent token is worth explaining. Simple redaction, replacing every name with a black bar, destroys the thing that makes the data useful: the ability to follow one person or one project across tools. Tokenization keeps that thread intact while removing the identity at the end of it. We go deeper on this in why the same person must get the same token everywhere.

The riskiest moment in any data project is when raw, unanonymized data is sitting somewhere. Our standard keeps that window short and closed.

No third party touches raw data. Anonymization is done in-house, and the evaluation that comes before it is read-only. The full sequence is described on our trust page. Before any data moves, the seller sets the scope and any additional exclusions, such as a sensitive channel, a particular client or a folder, and those are annexed to the contract.

The seller then reviews an anonymized sample before anything is delivered. This is a real check, not a formality. People who worked at the company are well placed to spot details an automated pipeline might miss, such as a nickname or an inside reference that could point to a specific person.

After sign-off, the raw archive is deleted within 30 days. That is a contract obligation, not a policy we can quietly change, and the seller receives a deletion certificate when it is done. What remains is only the anonymized version that was reviewed and approved.

Anonymization is one half of the standard. The other half is what the licence allows, and more importantly what it forbids.

Licensed data is for training and evaluation only. Buyers may never market to, profile, contact or re-identify anyone in the data. The data is never resold for marketing or people search. These terms exist because anonymization reduces risk but no technique is perfect, so the contract has to close the remaining gap by making re-identification a breach rather than just a difficulty.

We are careful about the limits here. No responsible provider can promise that re-identification is impossible in every case. What we can do is make it very hard technically, forbid it contractually and limit who receives the data to labs bound by those terms.

For a founder or officer considering a licence, the standard is designed to answer the question they will hear from their team: is my information going to end up somewhere it should not? The honest answer is that names, contact details, IDs, credentials, faces and signatures are removed or replaced, sensitive folders stay out, and the licence forbids anyone from trying to work backward.

Imagine a 90-person marketing agency that ran on Teams, email, Asana and a shared drive for seven years. Under this standard, a lab would see how campaigns were planned, approved, revised and delivered. It would not see who worked late, who was on a performance plan or which client a particular account manager handled. If the agency wanted a specific client excluded entirely, that client would be written into the contract annex before any data moved.

Some companies choose to tell their team about a licence, and we think that is often a good idea.

This post describes the standard, and our trust page lays out the anonymization pipeline behind it. Both are easier to judge with your own archive in mind, so we are glad to walk through any part of it with you.

If you are weighing a licence and want to understand exactly how your team's privacy would be protected, book a 15-minute call.