Anonymised vs pseudonymised data for AI

The UK distinction: anonymous or still personal data?

For Northern Ireland and Great Britain, the ICO's introduction to anonymisation distinguishes anonymous information from pseudonymised personal data. Anonymous information does not relate to an identified or identifiable person. Pseudonymisation keeps additional identifying information separately; it is not the same as making the information anonymous.

The ICO also explains that anonymising personal data is itself processing. Do not treat the intended anonymous result as permission to use the source records however you choose. Ask an adviser to assess the proposed processing and sharing arrangement.

Checked on 16 October 2026, this ICO guidance carries an update notice following the Data (Use and Access) Act. That caveat matters: use the current guidance and advice for the particular situation, not an old checklist labelled "GDPR compliant".

Use Irish guidance for a Republic of Ireland business

The Irish Data Protection Commission's anonymisation and pseudonymisation guidance is the relevant regulator's starting point for the Republic of Ireland. Its currently linked guidance note is dated June 2019; the hosting path is not a new publication date.

The note says effectively anonymised information is not personal data, while pseudonymised information remains personal data. It asks organisations to consider identification using other information, including retained source material. The test is not simply whether the recipient has been given a name column.

Do not carry a conclusion reached under a UK process into an Irish transaction without review. This article does not determine the status of a particular dataset or approve a cross-border transfer. Our Ireland and Northern Ireland page keeps the service availability and jurisdictions separate.

Why deleting names can leave identifying clues

The ICO's effectiveness guidance discusses singling out and linking information. A record can identify someone through context or a combination of details, even without their name.

Consider this invented example: a support note describes a unique role, an unusual incident and an exact event date. Removing the sender's name would leave those clues. Whether they identify a person depends on the situation and other available information; the example is a reason to investigate, not a conclusion about a real archive.

Ask the reviewer to consider free text, attachments, repeated identifiers and combinations of fields. Do not assume a search-and-replace step covers everything. For support archives, our support ticket guide covers the wider permission questions.

Tokens and hashes need an assessment too

The ICO's pseudonymisation guidance discusses techniques including tokenisation and hashing. A technique's name does not establish that the result is anonymous. The design, additional information and ability to identify people still matter.

For a licensing discussion, ask your technical and privacy advisers to document what was replaced, what remains linkable and who holds any mapping information. Do not send that mapping with a demonstration. Avoid an improvised transformation undertaken solely to answer a buyer quickly.

A useful description is specific about uncertainty: "Direct identifiers have been removed from an internal working copy, but identification risk has not been assessed." That is an illustrative wording pattern, not a certification and not a statement about your records. Use only the parts that are true.

Prepare questions for a proper review

Before asking whether a collection could be licensed, organise the questions your business needs answered. Keep this working note internal and use descriptions rather than copying personal information into it.

• What does one record concern: a person, an organisation, an event or something else?
• Which fields and free-text areas might reveal personal details?
• What transformations have actually been performed, and who checked them?
• Which source records or other information still exist?
• Who would receive access, and for which proposed purpose?
• Which conclusions are documented and which are only assumptions?

Ask for the reasoning behind an assessment, not just a pass label. Record the version assessed and any limits on the conclusion. A later change to fields, recipients or purpose should be brought back to the adviser rather than treated as covered automatically.

Do not ask Fairlode to inspect an export to decide whether it is anonymous. The initial process is descriptions-only.

Keep privacy, permissions and buyer interest separate

A useful internal decision note has separate headings: privacy status, ownership and contractual restrictions, proposed use, and commercial interest. Leave unanswered headings open. Do not let progress on one heading silently close the others.

For example, a team might understand its field definitions but still be unsure whether customer terms permit the proposed use. Another team might have a buyer enquiry but no assessment of identifying text. Those are different unresolved questions, not reasons to rush a sample.

At the first enquiry, say that personal information may be present if that is what you know. Do not paste the material to illustrate the issue. Use the readiness checklist to prepare a non-confidential outline and describe the outstanding review work honestly. A decision not to share yet is a legitimate result.