Anonymising professional documents for AI training under UK GDPR: a checklist
Most of the value in a professional firm's archive sits in documents that were never written with privacy in mind. Inspection reports name site contacts, calculation packs carry the initials of the engineer who checked them, and patent or regulatory files are full of correspondence with individuals at clients and counterparties. If you are thinking about licensing that material as AI training data, the question is not only whether the reasoning is good enough, but whether the people who appear in it can still be identified once it leaves your hands.
This checklist is written for UK engineering, legal, patent and regulatory firms that want to prepare documents responsibly. It draws on the Information Commissioner's Office (ICO) guidance on anonymisation and pseudonymisation, published in March 2025. The ICO notes that this guidance is under review following the Data (Use and Access) Act, so it is worth checking the live version before you rely on any detail.
First, understand what "anonymised" means in law
Under UK GDPR, anonymous information is information that does not relate to an identified or identifiable living person, and data protection law does not apply to it. That sounds simple, but the ICO's guidance, starting with its introduction to anonymisation, makes three points that catch firms out.
The first is that anonymising personal data is itself processing. You need a lawful basis and a defined purpose for the anonymisation work, even though the finished output may fall outside the law.
The second is that pseudonymised data is still personal data. Replacing a client contact's name with "Contact A" while keeping a lookup table in your system reduces risk, but it does not take the document out of scope. If you, or anyone the data reaches, can reasonably re-identify people, the law still applies.
The third is that if you anonymise for further use within your own organisation, you must not keep additional information that would allow identification. If you need to keep the original files, and most firms do, the honest position is often that the dataset is anonymous in a recipient's hands but remains personal data in yours. The ICO calls this the "whose hands?" question, and it is worth getting clear on early.
The checklist
1. Decide what you are trying to share, and why
Start with the purpose rather than the files. Which document types carry the reasoning an AI developer wants, and which personal details are actually needed to preserve it? In most technical documents the answer to the second question is very few. A model learning how an engineer weighed two drainage options does not need the name of the client's project manager. Removing identifiers that serve no purpose is a data minimisation requirement in its own right, whether or not you reach full anonymisation.
2. Check whether a DPIA is needed
If the source documents contain personal data and the processing is likely to be high risk, a data protection impact assessment is a legal requirement. The ICO's DPIA guidance explains when one applies. Even where it is not strictly required, a short DPIA-style record of what you are doing, why, and what safeguards apply is a sensible way to demonstrate accountability.
3. Remove direct identifiers
Names, email addresses, phone numbers, signatures, home addresses, employee and staff numbers are the obvious ones. In professional files you should also look at:
- document metadata, such as author, last modified by and tracked-change history;
- headers, footers, title blocks and drawing revision tables;
- handwritten initials and checker stamps on scanned pages;
- email chains embedded in reports or appendices;
- photographs that show people, vehicle registrations or house numbers.
The ICO is clear that masking like this is necessary but not sufficient, and on its own it is not considered an anonymisation technique.
4. Deal with indirect identifiers
This is where most of the real work sits. A person can be identifiable without a name if the surrounding detail narrows things down enough. The ICO describes two key tests: singling out, where one person's records can be isolated, and linkability, where your data can be combined with other sources to identify someone. Its guidance on how to make anonymisation effective gives the Netflix Prize dataset as an example, where supposedly anonymous film ratings were matched against public IMDb reviews.
For professional documents, typical indirect identifiers include a precise site address, an unusual job title at a named client, a specific date of an incident or hearing, and a distinctive project that was covered in the trade press. The ICO suggests changing details such as precise place names and dates. In practice that might mean describing "a site in the North West" rather than giving the address, or a month rather than an exact date, as long as the change does not destroy the technical meaning.
5. Treat free text as its own problem
Spreadsheet techniques such as k-anonymity and noise addition do not translate well to reports, minutes and correspondence. The ICO says plainly that anonymising qualitative material is time-consuming, does not lend itself to bulk processing, and can need careful human judgement. Automated redaction tools are useful for a first pass, but a reviewer who understands the subject matter should check a sample, because they will recognise the details an outsider would miss. The UK Data Service makes a similar point from the research world, recommending that anonymisation is planned early rather than treated as a single step at the end.
6. Run a motivated intruder test
The ICO expects you to consider whether a reasonably competent person, with internet access, public records and some investigative effort, could identify people from the material. For professional data, think about who might actually try: a former employee, a competitor, a journalist covering a failed project, or a counterparty in a dispute. The ICO also lists generative AI chatbot tools among the resources an intruder might use, which is a useful reminder that what looks obscure to you may be easy to cross-reference.
You do not have to eliminate every theoretical risk, because the legal standard is what is "reasonably likely" rather than what is conceivable. You should, however, be able to explain why the remaining risk is remote.
7. Consider who receives the data and on what terms
The ICO distinguishes between public release and release to a defined group under controls. A dataset licensed to a specific AI developer under contract, with restrictions on onward sharing and re-identification, sits in a different position from material posted online. Contractual terms do not replace good anonymisation, but they are part of the overall assessment. It is also worth knowing that under section 171 of the Data Protection Act 2018, knowingly or recklessly re-identifying de-identified personal data without the controller's consent is a criminal offence, subject to specific defences.
8. Remember that data protection is not the only issue
Removing personal data does not settle confidentiality, copyright or client contract terms. Many engineering appointments and legal engagement letters restrict how project information can be used, and those duties apply to commercial information about organisations as well as people. Check them separately, and take advice where the position is unclear. Our guide to how UK engineering firms can monetise their knowledge as AI training data covers the IP and client-appointment checks in more detail.
9. Document your decision and review it
The ICO expects you to record how you assessed identifiability, what techniques you used and why you concluded the risk was sufficiently remote. It also expects you to review that assessment when circumstances change, for example when new public information appears, when a dataset is combined with others, or before it goes to a new recipient.
A short version for busy partners
If you only remember a few points, make them these:
- Pseudonymised data is not anonymised data, and the law still applies to it.
- Strip metadata as well as visible names.
- Generalise locations and dates that would let someone who knows the project work out who was involved.
- Have a subject expert check a sample by hand.
- Write down what you did and why, and review it before the data goes to anyone new.
How ID43 Labs approaches this
ID43 Labs works with UK firms to capture professional reasoning from approved documents and expert sessions, structure and anonymise it, and license the resulting datasets to AI labs on a revenue-share basis. You stay in control of what is shared. If you would like to discuss what preparing your archive would involve, see our pages for engineering firms, legal and patent firms and closed company archives.
This article is general information, not legal advice. Take independent legal advice on data protection, confidentiality and intellectual property for your own documents and appointments.