Data Masking for AI Starts With Where the Copy Is Going, Then a Test Before It Moves

A customer table headed for your CI suite and the same table headed for an outside model carry very different risks, even with identical masking rules. So data masking for AI, replacing sensitive values in a copy before it reaches a test system, AI tool or training set, starts with where that copy is going.

Masked data is often still personal data, so don't assume a masked copy is safe to share. Generate synthetic data where you can, mask where you can't, and test the result with seeded records before anything moves.

Masking vendors tend to frame this as static versus dynamic masking. Those are useful terms, but they come second.

The practical work usually sits in your data pipelines, because that's where copies get made. This guide gives you a decision table, the legal position in the UK, EU and US, the places masking tends to fail and five checks to run before a copy moves. It is general information, not legal advice.

Data masking for AI: choose by destination, not by tool

Ask four questions about each copy before you pick a technique:

1. Who will be able to read it? Your team, a contractor, a vendor, or the public through a model.
2. Can you get it back? A row in staging can be deleted. A value absorbed into a trained model may not be removable in any simple way.
3. Does the use need real patterns? Unit tests rarely do. Fraud models usually do.
4. Can the recipient link it to anything else? That includes their own data and public sources.

The first option to consider is not sending that data at all.

Decision table: CI tests, staging, AI coding tools, third-party LLMs, model training

This table is our editorial judgement, built from the sources below. It is not a regulator's rule, so adjust it to your risk and your lawyer's advice.

Two notes on that table.

For CI, NIST's de-identification guidance suggests test data can be valid in form yet not accurate, and that conspicuously fake values such as "FIRSTNAME1 LASTNAME2" stop test data being mistaken for the real thing. It adds that realistic test data doesn't compromise confidential data, provided it wasn't developed from that data or from a model based on it.

For training, check whether retrieval would do the job first. Our comparison of RAG and fine-tuning covers that choice. A retrieval system still needs care, but you avoid baking the data into model weights.

Masking, pseudonymisation, anonymisation and synthetic data compared

These words get used as if they mean the same thing. They don't.

Don't use dynamic masking as the control for an AI agent with SQL access. Microsoft's SQL Server documentation says the data in the database isn't changed and that administrators can still see originals. It also shows a user with ad hoc query rights working out a masked salary by filtering on a range.

Microsoft says the feature suits accidental exposure, and shouldn't be used alone against those users.

Hashing causes similar confusion. The US Federal Trade Commission says firms should not treat hashed data as anonymised, because a hash is still a persistent identifier that can follow a person or device. NIST lists keyed hashing as a technique, but warns that it carries special risks and needs specific controls.

Data masking vs synthetic data isn't an either-or choice. Tonic.ai, a vendor that sells both, calls them complementary. That matches the table above, though its page also claims masking meets regulatory standards for anonymised data without showing evidence, so treat that as a sales claim. Independent research is more cautious about synthetic data too. Stadler, Oprisanu and Troncoso tested modern generative models and found no better privacy and utility trade-off than traditional anonymisation: the models either failed to stop inference attacks or lost their usefulness.

So "synthetic" isn't a pass. Data generated from rules alone is the safest kind. Data generated by a model trained on your production records needs testing like any other copy.

Is masked data still personal data? UK and EU positions, including where they differ

Often, yes. The answer depends on who holds the data and what else they can reach. Check any specific case with counsel, because this area is still moving.

Here is what we take from that, as a reading of the sources and not as legal advice.

The company holding the key gets no relief. The court's point is about recipients. For the key-holder, the masked copy is generally still personal data, and it also has to think about how it informs people. Clifford Chance's summary says the duty to tell people about recipients is judged at collection, from the controller's perspective.

A recipient's status rests on facts. It depends on the realistic means available to them, including cost and time, the factors named in GDPR Recital 26. A vendor with large data sets of its own could be in a very different position from a small contractor.

The UK and EU are close but not the same. On paper, the ICO summary and the court's ruling point in a similar direction. The EDPB's draft sits further away. If you serve both markets, design for the stricter reading, and treat "anonymous" as a claim you have to evidence.

Models bring one more question. In Opinion 28/2024, the EDPB says a model trained on personal data is not automatically anonymous. Regulators assess this case by case, and it should be very unlikely both that people can be identified and that their data can be drawn out by queries.

For US work, the FTC's hashing warning and NIST's SP 800-188 are useful reference points, but check the rules for your state and sector.

Where masking fails: free text, logs, embeddings and rare values

Rules protect the columns you listed. Leaks come from the places you didn't list.

Free text

Support tickets, notes, comments and chat logs hold names, phone numbers and health details in sentences. NIST warns that unstructured text can hold direct identifiers and clues, that finding them requires domain knowledge, and that such text can sit inside otherwise tabular data. It cites a case in which Dallas police published the names of six people who had complained of sexual assault, through unstructured fields.

Detection tools help, but they are one layer. The open-source toolkit Presidio states there is no guarantee it finds all sensitive information, and it advises extra safeguards. For most test environments, replacing free text with generated sentences is simpler than cleaning it. Keep the real text only where the text itself is what you're testing, as in RAG chatbot evaluation.

Logs, traces and prompts

You can mask a database perfectly and still leak the same values through application logs, stack traces, cached responses, LLM prompt history and evaluation sets. Treat each as a copy with its own destination. If staff paste data into chat tools directly, that's a different route, and our guide to data loss prevention for AI covers it.

Embeddings

A vector is not a mask. Li, Xu and Song showed in 2023 that sentence embeddings can be inverted to rebuild coherent text similar in context to the original. Give your vector store the same access rules as the source text, and mask before embedding.

Rare values

The chief executive's salary is identifying even with the name gone. So is the only customer in a village, or a rare diagnosis. Rocher, Hendrickx and de Montjoye's 2019 Nature Communications paper estimated that 15 demographic attributes would be enough to re-identify 99.98% of Americans correctly, whatever the dataset. That is a model estimate rather than an observed attack, but the message holds: combinations identify people. NIST's process accepts that outliers may have to be removed, at some cost to data quality.

Model memory

Carlini and colleagues extracted hundreds of exact sequences from GPT-2's training data, including names, phone numbers and email addresses, and found larger models were more vulnerable. This is an older model, so don't read it as a measure of current ones. It does show why you should test outputs as well as inputs.

How to build masking into the pipeline

Masking done by hand gets skipped when a deadline arrives. Make it the only route from production to anywhere else.

1. Inventory by destination. List every place production data goes, including exports, backups, analytics, prompts and vendor uploads. Our guide on whether you need a data warehouse is useful if those copies have multiplied.
2. Classify every column. Mark each as direct identifier, indirect identifier, free text or safe. Default new columns to "block", so a migration can't add an unmasked field silently.
3. Mask deterministically where joins matter. The same input should map to the same output across tables, so foreign keys still work. Keep any secret or lookup table away from the copy, because holding both brings you back to personal data. The EDPB's draft guidelines treat lookup tables as personal data.
4. Transform on the way out. Run masking inside the trusted zone, then deliver only the result. Don't copy raw data to staging and clean it there.
5. Use tools you can inspect. PostgreSQL Anonymizer, for example, offers static masking, dynamic masking, anonymous dumps and replica masking. Choose after you've finished the steps above.
6. Make the test a gate. The pipeline fails if the checks below fail, and the copy isn't delivered.
7. Expire copies. Set a retention period for each destination, then enforce it.

Test it: seeded records and a re-identification check

You can run this without buying anything. The numbers are our suggested starting points, not legal thresholds.

Test 1: seeded records. Add 50 fake customers to the source, each with a unique made-up marker in every field, including notes and attachments, such as ZZCANARY0417. Run the pipeline. Then search for those markers in the output, logs, traces, vector store metadata and prompt history. Any hit is a failure, and it tells you exactly which route leaked.

Test 2: free-text read. Have a person read a random sample of 200 free-text values after masking. Tools miss what people spot straight away, such as "ask for Sarah at the Leeds branch". Scale the sample up if the data is sensitive.

Test 3: small groups. Count how many records share each combination of indirect identifiers, using something like SELECT postcode, birth_year, job_title, COUNT(*) FROM customers_masked GROUP BY postcode, birth_year, job_title HAVING COUNT(*) < 5. Each row returned is a group of fewer than five people. Generalise those values, for example by shortening postcodes to districts, or remove the records.

Test 4: motivated intruder. This idea comes from ICO guidance, in which you ask whether a motivated person could identify someone. Give a colleague from outside the project a sample of the masked data, public sources and a day. Ask them to identify ten people. Write down what they tried, what worked and what you changed. For high-risk data, use an outside tester.

Test 5: output check, for models. Prompt a trained model or chatbot with partial records and see if it completes them. Run the same seeded markers through it.

Then record the result: date, data version, rules version, findings and who approved it. Run the tests again when the schema, the destination or the model changes. NIST's process works the same way: if data fails the risk threshold, adjust the procedure and test again.

Passing these tests doesn't prove the data is anonymous. It gives you evidence for that assessment. NIST is blunt on the wider point: without further controls, it says masking tools shouldn't be used to de-identify data meant for public release.

Frequently asked questions

Start with Test 1 on your busiest copy. If a marker turns up somewhere you didn't expect, book a free consultation and we'll look at where your copies go and which tests to run next.

Sources

• Legislation.gov.uk, UK GDPR Article 4
• EM Law, secondary summary of ICO anonymisation and pseudonymisation guidance (4 June 2025)
• ICO, anonymisation guidance (confirm directly; our tool could not read this page)
• GDPR Recital 26, unofficial reproduction
• EDPB, Guidelines 01/2025 on Pseudonymisation, consultation version (16 January 2025)
• EDPB, consultation page for Guidelines 01/2025
• EDPB, Opinion 28/2024 on AI models, news release (18 December 2024)
• Clifford Chance, secondary summary of EDPS v SRB, C-413/23 P
• IAPP, EDPB and EDPS joint opinion on the Digital Omnibus (February 2026)
• IAPP, EU member states finalise Digital Omnibus stance (22 October 2026)
• FTC, No, hashing still doesn't make your data anonymous (24 July 2024)
• NIST SP 800-188, De-Identifying Government Datasets (September 2023)
• Rocher, Hendrickx and de Montjoye, Nature Communications 10:3069 (2019)
• Li, Xu and Song, Sentence Embedding Leaks More Information than You Expect, Findings of ACL 2023
• Carlini et al., Extracting Training Data from Large Language Models
• Stadler, Oprisanu and Troncoso, Synthetic Data: Anonymisation Groundhog Day
• Microsoft, Dynamic data masking, vendor documentation
• Presidio, project documentation
• PostgreSQL Anonymizer, project documentation
• Tonic.ai, Data synthesis vs data masking, vendor (22 July 2025)