AI DLP pseudonymisation: protect the mapping

Assess AI DLP pseudonymisation by checking three things together: what identifying detail leaves the organisation, who can access the information needed to restore it, and whether the transformed material still supports the authorised task. Replacing a person's name with an alias addresses one part of that assessment.

A useful procurement exercise follows both the transformed text and the separate mapping. It also checks the reply, where incorrect restoration or newly inferred personal information can create another disclosure risk.

Define what the transformation promises

Pseudonymisation replaces or transforms identifying information while keeping additional identifying information separately protected. The UK ICO's guidance explains that the information remains personal data in the hands of a party that holds the additional information. The ICO currently marks this guidance as under review following legislative changes.

Australia's OAIC evaluates de-identification in its release context, including whether re-identification risk is very low. Its guidance also carries an update notice. The jurisdictions use different terminology, so involve Privacy and Legal when translating a technical feature into a legal claim.

For this guide, an alias is the replacement shown in transformed text. A mapping is the additional information linking that alias to the original. The proposed checks below concern those technical records, without deciding the legal status of a particular disclosure.

Give the mapping its own access boundary

Ask where the mapping is created, stored, read and deleted. Identify every component that can request restoration, including the employee interface, support tools, exported records and background jobs.

The ICO recommends separate storage, restricted access, encryption, access logging and protected backup and recovery for the additional information. Those controls should be explained for the mapping itself, including any temporary copies.

In a fictional test, an authorised reviewer may restore an alias within one case. A second reviewer assigned to another case should receive the documented denial or unresolved result. The difference in authority is the important variable; the test data can remain entirely invented.

Check whether access logging creates another copy of the identity. An event identifier, requester, purpose and outcome may support an audit without reproducing the original value. The monitoring privacy checklist covers those collection and retention questions.

Review the information left around the alias

A transformed paragraph may still reveal a rare job role, precise location or unusual combination of events. The OAIC's commercial AI guidance cautions about re-identification and about personal information inferred by AI.

Use fictional examples with deliberately different levels of contextual detail. One might describe an ordinary team request; another might describe a uniquely specified role and event. Ask the assessor to explain whether the remaining detail meets the organisation's sharing rule.

This is a review of authorised synthetic examples, with no attempt to identify real people. A successful name replacement alone leaves contextual disclosure to be evaluated separately.

Preserve useful relationships deliberately

Within an authorised task, the same fictional person may appear in several paragraphs. Consistent aliases can help the model track those relationships. Across unrelated cases or users, reuse of the same alias can enable unwanted linking. Agree the intended scope before judging either behaviour.

Prepare paired examples that repeat one invented name, use two distinct invented names and contain an ordinary word resembling an alias. Verify that the output preserves the intended relationships and avoids restoring text that was never part of the mapping.

Check the restoration step against the actual structured result or user-visible text. A model may change punctuation, omit an alias or create a similar-looking token. Define how the product handles those cases without guessing at identity.

Our exact data matching guide addresses detecting known records before a policy decision. This exercise follows the transformation and restoration after a record has been selected.

Test expiry and the reply together

Give the mapping a documented retention purpose. Use a synthetic case to check restoration before expiry, after expiry and after the relevant access is revoked. Record the expected user experience when restoration is unavailable, including a supported way to finish the legitimate task.

Ask how backup recovery interacts with expiry and how derived copies are handled. Deleting one visible mapping entry supports a narrower conclusion than proving every retained copy has expired. Document which claims were directly tested and which depend on contractual or architectural evidence.

Finally inspect the proposed outgoing material and the returned answer. Check whether the model introduced an identifying inference, whether the mapping remained inside its intended boundary and whether the correct authorised reader received the result.

Retain a compact record of the fixture, transformation scope, mapping access, contextual review, restoration outcome and useful-task result. These are evaluation criteria, without a claim that Promptective or another product passed them. No real personal information or production prompt is needed for the exercise.

Review your AI data-handling requirements with Promptective.