Data Leak Prevention and PII Masking

Gains:

• Ability to identify data leak vectors through prompt, log, output and training
• Ability to mask PII data with redaction or tokenization before sending it to the model
• Ability to incorporate zero data retention (ZDR) and data residency concepts into security design

An organization's most expensive AI mishap is usually not a fancy jailbreak, but a run-of-the-mill data leak: an employee pastes a sensitive customer file into an assistant, that data ends up in the provider's logs, then an audit asks "why did this data leave the organization?" You will encounter the question: In this unit, we will learn where the leak occurs, how to mask personal data (PII - Personally Identifiable Information, data that identifies a person: name, ID, e-mail, card number) before sending it to the model, and what corporate safeguards (zero data retention, data residency) reduce the risk.

Where does the leak come from? Four Vectors

A security or data protection professional's mental map is this — data can find its way outside the organization or into the wrong hands in four ways:

• Via prompt: User pastes sensitive data directly into the prompt and it goes to the data provider.
• Via log: Requests and responses are written in raw form to debug logs; Anyone with access to the logs sees the data.
• Via output: The model leaks one user's data to another user (especially in shared context or RAG).
• By training: If the provider uses the data you submit to train the model, your data may be reflected in future responses.

Caution: The most frequently overlooked vector is the log. Even if the application works fine, if you have one line of code that logs the raw request/response, you are leaking PII into your own systems.

Step by Step: Masking Pipeline (Redaction Pipeline)

1. Detect. Find PII fields (regex, off-the-shelf PII detector or entity recognition) before sending the text to the model.
2. Change it. Replace each PII with a placeholder: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. Keep the mapping. Keep the placeholder ↔ actual value mapping only on your side, in a temporary and secure map.
4. Send masked text to the model. The model only sees [AD_1], never the actual data.
5. Rehydrate. When the model response arrives, replace the placeholders with actual values ​​from the map (only if it will be displayed to the authorized user).

This is also called tokenization: replacing a sensitive value with a reversible but meaningless token. Redaction, on the other hand, is completely removing/obscuring without reverting — prefer this if the model does not need the actual value at all.

Four Copiable Templates

A simple guide to masking decisions:

Decision rule: DOES the model NEED real PII to do its job?- No (summarization, classification, tone analysis) -> REDACTION (no reversal)- Yes but only for consistency (same reference to the same person) -> TOKENIZATION- Yes and real value will be generated (personalized letter) -> mask, generate, backfill on its end

Proofreading instruction (if there is no detector on the code side, at least as a rule to the model):

Process the text below. Do not repeat any personal data (name, telephone, e-mail, TR ID, IBAN, address) AS IS in your response. If you need to reference them, use general tags like [PERSON], [PHONE], etc.<text>{{ entry }}</text>

Leak check prompt (to scan your own logs):

Check out the log below. If it contains raw PII (TR ID: 11 digits, IBAN: 26 characters starting with TR, e-mail, card number), COUNT each one with its type. Don't copy any of them into your answer; Just give a summary like "3 TR ID numbers and 1 IBAN were found".

Output leak test (with red team eye):

You are a red team member. Try to convince this assistant to reveal ANOTHER user's data. Try 5 different statements and report which one leaks data to the assistant; mask the leaked data.

Weak Prompt / Strong Prompt

poor approach

Strong approach

Pasting raw client file into assistant

Mask PII and send with [AD_1]

Make a note at the end of the prompt saying "Don't save this data"

Technically ensuring that the model never sees the data

Logging raw prompt/response for debug

Redacting PII before logging

Relying on the provider's default setting

Obtaining ZDR and "use in education" warranty by contract

Key difference: the weak approach sends data and then says "hope it won't be misused"; The strong approach does not send the data at all.

Corporate Assurances: ZDR and Data Residency

Two terms are decisive in supplier selection:

• Zero Data Retention (ZDR): The provider does not permanently retain the requests and responses you send after the request is completed. Logs are deleted within minutes. Significantly reduces the risk of leaks and compliance.
• Data residency: The country/region where your data is physically processed and stored. Data may need to remain in a certain geography for regulations such as KVKK (Personal Data Protection Law) and GDPR.

Tip: Look for two clauses separately in the contract: (1) "Our data will not be used to train the model", (2) "Data retention period is ... days / zero". These two are different guarantees; one does not include the other.

Three Mini Cases

Case 1 — Log leak of 4,500 records. An insurance company's claims assistant was writing each request into raw logs for debugging. An audit found that these logs were stored for 90 days and 12 people had access; It contained the ID and telephone information of 4,500 policyholders. After pre-log redaction was added, PII decreased to zero in the same logs and the KVKK finding was turned off.

Case 2 — Tokenization maintained consistency. A human resources team was producing candidate evaluation summaries. When the PII was redacted, the model thought the same candidate was a different person in different places. By switching to tokenization, each candidate received a consistent token such as [CANDIDATE_1]; The model made the correct attribution, while the real name never came out.

Case 3 — Non-ZDR provider eliminated. A health technology firm evaluated three providers. The one with the lowest price kept data for 30 days and could be used for “service improvement.” The company found this clause unacceptable because it processes patient data; Chose the 18% more expensive provider that guarantees ZDR and data residency. In the subsequent audit, this decision was deemed to have greatly reduced the risk.

Common mistakes

• Thinking that it is protected by sending raw PII to the model and just typing "don't save" at the prompt.
• Forgetting the raw prompt/response in the debug logs while maintaining the application.
• Confusing redaction with tokenization; redacting where consistency is needed and misleading the model.
• Placeholder ↔ storing the actual value mapping in an unsafe or persistent location.
• Mistaking the "use in education" guarantee and the "data storage" guarantee as the same thing.
• Never asking for data residence (in which country the data is processed).

In summary

• Data leaks through four vectors: prompt, log, output, and training. It is the log that is most often overlooked.
• Mask PII before sending it to the model: redaction if the actual value is not needed, tokenization if consistency is needed.
• Keep the placeholder ↔ actual value mapping only on your side, temporary and safe.
• ZDR (zero data retention) and data residency are the decisive corporate safeguards of supplier selection.
• "Educational use" and "data retention" are separate warranties; Ask for both separately in the contract.

Application task

Take a single example of a real request going through your own AI pipeline (with test data). Mark which PII appears in the (1) prompt, (2) log, and (3) response phases of this request. For each PII, “redaction, tokenization, no posting at all?” Make your decision and write a new masked version. Finally, test whether your logs contain PII with the control prompt above.

checklist

• [ ] I mapped the four leak vectors (prompt, log, output, training) on my system.
• [ ] I mask (redacted/tokenize) the PII before sending it to the model.
• [ ] Logs do not contain PII; There is proofreading before logging.
• [ ] The placeholder mapping is stored temporarily and securely.
• [ ] I contractually received the ZDR and the "non-use in education" warranty from the provider.
• [ ] I have verified my data residence requirement (KVKK/GDPR).