Introduction to data masking

When building with LLMs, you must protect sensitive information. However, this doesn't mean locking it away; developers must still build features, and models must still learn from and reason over it. We need a way to keep data usable while ensuring it does not harm the people it describes. In this topic, we look at data masking and how it solves this problem.

What is data masking?

Data masking is the practice of replacing sensitive values with realistic but non-sensitive substitutes. The masked data remains usable for its purpose, but it no longer exposes the real information. A masked record looks and behaves like the original, but the specific values no longer belong to any real person. The goal is to preserve utility while removing sensitivity:

Masking is valuable because many legitimate tasks require realistic data without access to the actual values. Additionally, it is required for compliance with global data protection laws such as GDPR and PCI-DSS. These regulations require strict handling of personal data, and data masking helps companies protect consumer privacy and reduce legal risks.

Here are the common cases:

Model training and fine-tuning — a model can memorize what it is trained on and later reproduce it. Masking the training corpus before it reaches the model removes the sensitive values it might otherwise absorb. This allows you to use real-world datasets without exposing private information.

RAG corpora — a retrieval-augmented application indexes documents and pulls them into prompts on demand. Any sensitive data in that corpus can be retrieved and surfaced, so masking the corpus closes that path.

Live prompts and API calls — at runtime, a user's prompt and any data attached to it usually leave your trust boundary to a model provider you do not control. Masking at this boundary keeps personal data from leaving your hands.

Secure development and testing — engineers need data that tests their code the way production data would, but a test database should not hold real customer records. Masked data gives developers a faithful playground without the liability.

Types of data masking

The use cases we covered above differ in one important way. Some work on data at rest, ahead of time, while others must transform data in motion, as a request flows through. Masking comes in two types, and which one you need depends on whether the data is at rest or in motion.

Static data masking (SDM) transforms data once, in advance, producing a separate masked copy. The original stays secure, and the masked version is what gets shared or used. The transformation runs in a batch, before anyone touches it.

Because the masking happens before use, SDM suits use cases built around a fixed body of data:

• Creating a training or fine-tuning corpus.

• Provisioning a test database for secure development.

• Sharing data with an external collaborator.

• A RAG knowledge base before ingestion.

Dynamic data masking (DDM), on the other hand, transforms data on the fly. It happens along the request path, so different callers can see different masked views of the same record. DDM suits the cases where data is in motion:

• A live prompt as it heads to a model.

• Masking a retrieved chunk before it enters the context window.

• Sanitizing the payload of an outbound API call.

The defining feature is that the transformation is bound to the moment of access without altering the stored copy.

In some cases, the same dataset may need both. A customer table might be statically masked for a test environment and dynamically masked when a live application reads from it. Therefore, these two types are complementary: SDM protects data you prepare in advance, and DDM protects data you expose at runtime.

Data masking techniques

Various masking techniques determine the substitute value. Let’s start with substitution. Substitution replaces a value with a realistic alternative of the same kind, drawn from a reference list. The result is still valid data, so it suits cases where realism matters:

"Maria Sanchez"   ──▶   "Olivia Carter"

Randomization generates a fresh value within the original's valid range. It preserves statistical relevance without preserving any individual value:

dob: 1987-03-12   ──▶   1987-09-24     (still a valid date, similar age)
salary: 84,500    ──▶   79,120         (still within a plausible band)

Nulling (or blanking) removes the value entirely. It offers the strongest protection and the least utility, so you use it when a field is irrelevant to the task:

ssn: 123-45-6789   ──▶   "XXX-XX-XXXX"

Encryption transforms a value into a ciphertext that can be reversed only with a key. Use it when the original must be recoverable by an authorized party, at the cost of managing keys:

"[email protected]"   ──▶   "k8Fz1pQ2vR9tL4mWcX0a=="

Hashing maps a value to a fixed-length digest. The same input always yields the same hash, so you can match and group records without storing the real value. However, you cannot recover the original from a hash:

"[email protected]"   ──▶   "a3f5...e9c1"

Tokenization replaces a value with a surrogate token and stores the mapping in a separate, secure vault. Like encryption, it is reversible, but the reversal depends on the vault rather than a key. This makes it a natural fit for round-trips where a value must be masked out and later restored.

Challenges

Unfortunately, masking comes with a set of challenges. The first challenge is maintaining semantic integrity. Masked data must still be valid and follow a proper format. A masked credit card number must still maintain the credit card number format. You must also ensure that relationships are maintained. A masked postal code must still belong to a masked city.

Another one is over-masking. If done too aggressively, the data may be useless:

 age_band: 35-44   ──▶  age_band: NULL
 region: West Coast    ──▶  region: NULL
 spend: ~ $80k   ──▶  spend: NULL

On the other hand, masking too little may lead to data leaks. Therefore, you need the right balance.

For LLMs in particular, you need to preserve the model’s ability to reason over the data. You must ensure that the substitutes remain sufficiently coherent for the model to work with them. Imagine sending a prompt like this: “reply to [REDACTED] about [REDACTED]”. In this case, masking has destroyed the context, making the model unable to work with it.

Most recognizers find sensitive data by pattern and context. An unusually formatted identifier can still slip through. Therefore, you should use masking alongside other approaches for maximum safety. Later, we’ll see how data masking is performed with various libraries.

Conclusion

We’ve covered how data masking keeps data usable while stripping away sensitive information. This is needed for various uses such as RAG corpora, model training, and others. We can use two approaches: static and dynamic data masking. We also discussed various techniques for data masking—from substitution to tokenization. Finally, we saw why masking is harder than it looks: semantic meaning, over-masking, and a model's ability to reason all depend on getting the substitutes right.