Find and remove personal data before it reaches a model

What you will be able to do

Find the personal data in a bank’s documents and mask it before the text goes to a language model. You compare simple rules, Microsoft Presidio on your own computer, and a recorded language model. You measure what each one misses and what it masks too much, by type of value and by language. Then you decide what still needs a person, and what the masking costs the model.

Case studyPortfolio piece

Dataset

synthetic_pii_finance_multilingual (Gretel), English, French and German test files

Licence

Apache-2.0

Time

About 2.5 hours

Runs in

Colab, Kaggle or VS Code

Skills used

• Personal data and a masking policy
• Checking the labels
• Rules and named-entity recognition
• Misses and over-masking
• Slices by type and language
• Confidence intervals
• Review decisions
• Processors and trust boundaries

Open in ColabOpen in KaggleView on GitHub

Colab and Kaggle open your own copy. To use VS Code, download the notebook from GitHub. Stuck? See the solution notebook.

This case study is a measurement, so it comes as a notebook, not as a project folder. The notebook downloads a fixed version of the documents, runs the detectors on your computer and replays the model’s recorded answers. You need no account and no key. A live run with your own key is optional, at the end.

Before you startWhat to know and to have readyAbout 150 minutes

What you need to know

This case study uses these lessons most:

• Personal data, PII and processors, from Data inventory.
• Masking with markers, and why patterns find only the shapes they know, from Minimize and retain deliberately.
• Slices by language, and what a small slice can tell you, from Bias and accessibility.
• Architecture evidence and the questions that need qualified review, from Residency and contractual questions.
• The 95% interval for a count, from the evaluation course’s Uncertainty and slices.

What you need on your computer

Nothing: the notebook runs in Colab or Kaggle. To run it in VS Code, use a new virtual environment with Python 3.12. The notebook’s first cell installs Presidio 2.2.364, spaCy 3.8.16 and three small spaCy models (about 40 MB). We tested it in Jupyter on macOS, from a fresh start. We did not run it in Colab or Kaggle.

Models and detection tools change fast. The numbers on this page are a snapshot of one model, one prompt and one sample. The method is what lasts.

The situation

Nordhafen Bank is a small bank with customers in several countries. Its back office receives about two thousand documents a week: letters, claim forms, emails, payment messages. Lena Brandt runs the back office. She wants a language model to sort the documents into the right queue and draft a first reply.

Claire Morel is the bank’s data protection officer. She agrees, with one condition: “The personal data stays with us. A name, an account number or an address must not reach the model provider.” Yusuf Okafor, a privacy engineer, must make that true, and show how true it is.

Yusuf has three questions. How much personal data does masking find? Where does it fail: which values, which languages? What does the model lose? Lena adds a fourth: “If masking is not good enough, what must a person check?”

We invented the bank and the people. The documents come from a public dataset in which every person, account and address is made up. The model’s answers are real recordings.

What you will build

You will build a small masking pipeline and a measurement of it. The pipeline finds personal data in a document and replaces each value with a marker, such as <PERSON> or <IBAN>. You build it from two detectors that run on your computer: rules, and Presidio. A third detector, a language model, is the comparison.

You measure every design on the same 900 test documents in English, French and German. There are two measures: the share of personal values hidden, and the share of other text masked too much. You split both by type of value and by language. Then you write a review rule, measure what masking costs the model, and recommend a design to Claire and Lena.

A black marker on a letter

Think of a clerk who must send a copy of a letter to an outside office, with the personal details blacked out. Two things can go wrong. The clerk can miss a name, and the outside office reads it. Or the clerk can black out too much, and the outside office cannot do its work: it no longer sees which company paid, or when.

Software makes the same two errors. A detector that misses a value leaks it. A detector that masks too much destroys meaning. A value can also be partly hidden: the city is masked, but the street and the house number remain. The picture shows all four outcomes on one made-up letter, with the real output of Presidio in its default settings.

The four outcomes that this case study counts, on one made-up letter (real output of Presidio with its default settings).

Text description of the diagram

A made-up letter and four outcomes from Presidio with its default settings. Hidden: the phone number is masked completely. Partly hidden: only the city of the address is masked, and the street remains. Missed: the name Ana Lima is not masked. Over-masked: the company name and the date are masked, although they are not personal data.

The phone number is hidden: this case study counts a value as hidden when at least 80% of its letters and digits are masked. The address is partly hidden. The name is missed. The company and the date are over-masked. No pipeline makes the last three zero, so you must measure them.

The data

The documents come from synthetic_pii_finance_multilingual, a dataset that Gretel.ai made to test detectors of personal data. Each row is a whole financial document with a list of labelled spans: where each value starts and ends in the text, and its type, such as name, iban or company. Language models wrote the documents, and every value in them is made up.

Source and licence

“synthetic_pii_finance_multilingual” by Gretel.ai (A. Watson, Y. Meyer, M. Van Segbroeck, M. Grossman, S. Torbey, P. Mlocek, J. Greco, 2024), huggingface.co/datasets/gretelai/synthetic_pii_finance_multilingual, under the Apache-2.0 licence. We use the test files in English, French and German at commit 7b844d1, take a fixed sample, and change nothing in the documents or the labels.

We compared four datasets before we chose this one. NVIDIA’s Nemotron-PII (CC BY 4.0) has more types of value, but only English. Gretel’s English PII set (Apache-2.0) is English only too. The ai4privacy sets are multilingual, but their licence allows only non-commercial use and no redistribution, so the course cannot use them. Gretel’s multilingual set has full documents with span labels in three of the course’s languages, under a permissive licence.

The sample and the policy

The notebook takes 440 documents per language at random, with a fixed seed: 140 for development and 300 for the test. On the development part you may look, write rules and choose settings. You score each design on the test part once, at the end.

The dataset has 29 labels. A masking policy says which ones the model must never see. Write it first, because every number below depends on it:

Group in the report	Labels in the dataset	Policy
name	name, first_name, last_name	mask
address	street_address, local_latlng	mask
phone, email	phone_number, email	mask
customer or staff ID	customer_id, employee_id	mask
bank account, card	iban, bban, bank_routing_number, credit_card_number, credit_card_security_code	mask
government ID	ssn, passport_number, driver_license_number	mask
secret, online ID	password, api_key, account_pin, ipv4, ipv6, user_name	mask
date of birth	date_of_birth	mask
kept for the model	company, date, time, date_time, swift_bic_code	keep

A company name, an ordinary date and a bank’s SWIFT code identify no person, and the model needs them to sort a payment. Masking them protects nobody and costs meaning. A template slot such as [Date] or MM/DD/YYYY holds no personal data, so it counts neither way: we call it a placeholder.

The test part holds 2,411 personal values and 1,338 values to keep. Names (1,156) and addresses (661) are three quarters of the personal values. Cards (34), secrets (41) and dates of birth (39) are rare. In one language, several groups have fewer than 20 values. A percentage of 10 values says little, so the page shows those as counts.

First checks: test the labels

A labelled dataset is someone’s work, and work has mistakes. The dataset’s card says that its labels came from a named-entity model and a language-model judge, and that “some errors may still be present”. So we checked the labels before we trusted any score. The notebook repeats the first and third checks.

1. Placeholders. 136 labelled values in the sample are template slots, such as [Nom de la Société] or [Phone Number]. The policy sets them aside.
2. Role words labelled as names. We read 30 random name labels per language. A few are not a person: guests and employees, L'Employé, a crypto address. That was 1 of 30 in English, 2 in French and 1 in German.
3. Personal data with no label. Of 278 email-shaped strings in the sample, 154 have no label. We read 30 of them: 15 name a person (jean.dupont@example.com), and the rest are team addresses (support@…). Names in greetings (“You’re welcome, John!”) often have no label either.
4. Fake values that fail their own checks. Only 32 of 54 IBANs pass the IBAN checksum, and only 10 of 26 card numbers pass the card checksum. A real IBAN always passes. Presidio checks these sums, so it misses many fake values that it would catch in real documents.

What this tells us. Check 3 matters most. When a detector masks an unlabelled email, it is right, but the score calls it over-masking. When it misses an unlabelled name, the score does not count the miss at all. So the measured misses are a lower bound: the real leak is somewhat higher. Check 4 works the other way: on real IBANs and card numbers, Presidio would do better than here.

Frame the problem

The unit is one labelled personal value. For each value, a design gets one of three outcomes: hidden, partly hidden or missed. The headline measure is the share of personal values hidden. Partly hidden counts against a design: a street and a house number without the city still lead to a door.

The second measure is over-masking: the share of all other letters and digits that a design masks. It includes the values to keep, ordinary words, and some unlabelled personal data (check 3). A third measure answers Lena’s question directly: the share of documents with every personal value hidden. A document with one missed name still leaks that name.

Where the masking runs matters as much as how well it works. Claire’s condition is a trust boundary, as in Trust boundaries: the personal data must not cross from the bank to the provider. So the masking must run inside the bank, before the model call.

Where masking runs. Only masked text crosses the boundary; a model used as the detector would receive the unmasked text.

Text description of the diagram

Documents enter the bank’s systems. Rules and Presidio find the personal values and replace them with markers. A review rule sends the masked text to the model provider, or holds the document for a person. A model used to find the personal data would receive the unmasked text, so its provider would need the same contract as any other processor.

This is why the language model is a comparison in this case study, not a candidate. To find the personal data, the model must read the text before it is masked. The data would cross the boundary that the masking must protect. That can be acceptable, but only as a decision about a processor and its contract, not as a technical detail.

Explore what the decision needs

One view decides most of this case study: which kinds of personal data are common, in which language. In the notebook’s table, names and addresses dominate in all three languages.

The data holds a second surprise. The language of a document is not the language of the names in it. A “French” document can hold Giosuè Gelsomina Borsellino or a Swedish street, and an “English” one María Teresa Feijoo. The generator mixed names and addresses from many countries. A detector trained on one language’s names meets other languages’ names too.

The baseline: rules

Rules are what the course’s mask() function does in Minimize and retain deliberately: patterns for shapes. This case study’s rules know emails, IBANs, card numbers, IP addresses, phone numbers, long numbers, ID-shaped codes and long keys. Keyword rules mask the value after words such as password:, date of birth, Geburtsdatum or adresse :. Street rules know rue, straße, Street and some others.

A tiny example shows what rules can and cannot do:

Notebook, section 4

TINY = "Dear Ms Ana Lima, your card 4111 1111 1111 1111 was blocked on 12/03/2024. Call Joe on +44 20 7946 0958."
print(mask(TINY, detect_rules(TINY)))

Dear Ms Ana Lima, your card <CARD> was blocked on 12/03/2024. Call Joe on <PHONE>.

The card number and the phone number have a shape, so the rules hide them. The two names have no shape, so the rules miss both. The date stays, as the policy wants. Names are the most common personal value, so this limit is serious.

We wrote the rules on the development part only, in three rounds, and logged each round:

Rules, development part	English hidden	French hidden	German hidden
1. Shapes only: email, IBAN, card, IP, phone, ID, key	13.5%	17.0%	12.8%
2. Phone formats fixed; long numbers; keywords for secrets and dates of birth	23.1%	24.3%	20.2%
3. Keywords and street words for addresses	35.2%	35.4%	30.6%

Round 1 missed (800) 123-4567 at the end of a sentence, because the pattern did not allow a full stop after the number. Round 2 still found no address at all. After round 3, the rules hide about a third of the personal values and mask less than 2% of the other text. That is the baseline: cheap, fast and easy to explain, but blind to names.

Named-entity recognition: Presidio

To find names, you need a model that reads words in context. Named-entity recognition (NER) is the task of finding names of people, places and organisations in text. A small NER model learns that in “Ottmar Keudel signed”, the first two words are probably a person, even if it never saw the name. Microsoft Presidio (MIT licence) combines a spaCy NER model with its own pattern recognizers, and runs on the CPU.

The spaCy models need a licence check too. The small English and German models are MIT. The small French model is under LGPL-LR, which is not on the course’s list. So this case study uses spaCy’s multilingual model (MIT) for French. A licence can limit your choice of tool for each language.

Presidio, as it comes, finds every type it knows, including dates (DATE_TIME) and organisations (ORGANIZATION). The case study tunes it: it drops dates, organisations and URLs, and findings with a score under 0.4. On the development part:

Development part	Hidden	Over-masked
Presidio, defaults	55.9%	11.9%
Presidio, tuned	49.6%	4.7%
Rules + Presidio, tuned	69.9%	5.8%

The defaults hide more than the tuned setting, because masking every date also masks dates of birth. They pay for it with much more over-masking. Rules plus the tuned Presidio hide the most of the local designs, with modest over-masking. We chose this design on the development part, before we scored anything on the test part.

The comparison: a language model

The third detector is chat-small (gpt-6-luna on Azure). We asked it to list every personal value in the document as JSON, with the same policy in its instructions. We recorded its answers for the 900 test documents: 502,561 input tokens, US$0.0759 in all, and a median of 1.02 seconds per document. It listed 2,880 values. 4 of them were not exact copies of the text, so they masked nothing.

Remember the boundary: in production, this detector receives the unmasked document.

A fair comparison, on the test part

Every design now runs once on the same 900 test documents, with the same labels and the same two measures.

Test part: 2,411 personal values in 900 documents (300 per language). Intervals: Wilson, 95%. The model is chat-small (gpt-6-luna on Azure), one recorded run.

Text description of the chart

Share of personal values hidden on the test part, with 95% intervals: Rules 30.1% (28.3 to 32); Presidio, defaults 53.8% (51.8 to 55.8); Presidio, tuned 46.7% (44.7 to 48.7); Rules + Presidio 65.8% (63.9 to 67.7); Model (chat-small) 90.6% (89.4 to 91.7); Rules + Presidio + model 94% (93 to 94.9). Share of the other letters and digits masked: Rules 1.7%; Presidio, defaults 12.5%; Presidio, tuned 4.9%; Rules + Presidio 5.9%; Model (chat-small) 1.9%; Rules + Presidio + model 6.6%.

Read the top panel first. The rules alone hide 30.1% of the personal values. Presidio’s defaults hide 53.8%, but over-mask 12.5% of the other text. Rules and the tuned Presidio together hide 65.8%, with 5.9% over-masking: the best design that runs inside the bank. The model hides 90.6% and over-masks only 1.9%. All three together hide 94%.

The intervals are narrow, and the 25-point gap between the local design and the model is far larger than them.

Now count documents, as Lena would. Of the 640 test documents that hold personal data, rules and Presidio hide every personal value in only 245. The other 395 would leak at least one value. With the model, 538 documents are clean; with all three detectors, 576. A share of values hides how often a single document leaks.

Slices: by language and by type

Test part, about 800 personal values per language. Intervals: Wilson, 95%.

Text description of the chart

Rules and Presidio: English 58.2% (54.8 to 61.5); French 72.6% (69.6 to 75.5); German 66.6% (63 to 70). The model: English 90.4% (88.2 to 92.2); French 91.9% (89.9 to 93.6); German 89.3% (86.8 to 91.4).

The local design is worst in English: 58.2%, against 72.6% in French and 66.6% in German. You might expect the opposite, because English tools are the best known. The reason is in the names. The English documents hold many Spanish, Italian and Dutch names, and the small English model misses many of them. It hides only 56% of the names in English documents. The multilingual model that reads the French documents hides 73%. The model detector is about the same in all three languages, near 90%.

The view by type shows where the misses are:

Test part, all three languages; the number of values in brackets. Orange: under 90%. Intervals: Wilson, 95%.

Text description of the chart

Rules plus Presidio, share hidden by type of value: address (661): 57.2% (53.4 to 60.9); secret (41): 61% (45.7 to 74.3); name (1156): 63.1% (60.2 to 65.8); bank account (103): 67% (57.4 to 75.3); card (34): 67.7% (50.8 to 80.9); online ID (53): 71.7% (58.4 to 82); customer or staff ID (75): 78.7% (68.1 to 86.4); date of birth (39): 79.5% (64.5 to 89.2); government ID (62): 85.5% (74.7 to 92.2); phone (114): 96.5% (91.3 to 98.6); email (73): 98.6% (92.6 to 99.8).

Emails and phone numbers are nearly solved: they have a shape. Names and addresses are the two largest groups and two of the weakest. Bank accounts are weak too, partly because many fake IBANs fail their checksum (check 4). Cards and secrets have wide intervals, because there are few of them.

One example of each failure

Each failure has a cause that you can see:

• Missed names: Hugh M. McLean and María Teresa Feijoo in English documents; a lone first name such as Jean, Sophie or Pierre in French ones. A single first name has little context.
• Partly hidden addresses: 378 Stewart Coves, Chanburgh keeps its street; 4 Skolstigen, Skövde keeps its house number. Presidio finds the city, not the street line.
• Missed codes: U733-U3195-Ti (a customer ID) and a fake cloud API key that starts with AKIA match none of the rules.
• Over-masking: in French documents, the multilingual model tags ordinary capitalised words as people or places: Boissons, Développer, Destinataire, Partie.
• The model’s own misses: it listed 567, East Sunshine Avenue, Los Angeles with an extra comma, so that exact text was not in the document and nothing was masked. A detector that rewrites values fails silently.

Common mistake

The score looks fine, but most documents still leak

Symptom: the team reports “66% of personal data masked” and plans to send every masked document to the model.

Cause: the share counts values, not documents. A document with 12 values and one missed name scores 92%, and it still sends a name to the provider. On the test part, only 245 of 640 documents with personal data are fully masked by the local design.

Fix: report the share of clean documents next to the share of values, by language. Decide for each document whether to send it, as the next section does.

What still needs a person

Lena needs a rule that she can run every day. A group of values in one language goes to a person when the test part has at least 20 values of that group and the design hides under 90% of them. A group with fewer than 20 values cannot be judged from this sample, so it needs more data before anyone trusts it.

Rules + Presidio, test part	English	French	German
name	56% of 411 review	73% of 396 review	60% of 349 review
address	46% of 244 review	63% of 241 review	64% of 176 review
phone	93% of 41	100% of 44	97% of 29
email	97% of 32	100% of 22	19/19
customer or staff ID	83% of 23 review	77% of 22 review	77% of 30 review
bank account	56% of 32 review	75% of 36 review	69% of 35 review
government ID	11/14	92% of 25	83% of 23 review
card	6/10	13/18	4/6
secret	10/17	8/13	7/11
online ID	9/11	66% of 32 review	8/10
date of birth	7/9	13/17	11/13

The answer is uncomfortable. With the local design, names and addresses need a person in every language. Almost every document with personal data has a name or an address. So in practice, every document with personal data needs a person. Local masking alone does not meet Claire’s condition.

With the model as the detector, the same rule flags only names (87–89%) and bank accounts in English and German. That is a smaller review load, but the model buys it by reading the unmasked text.

What masking costs the model

Masking protects people, but the model reads less. We recorded two tests on test documents. Each test has three versions of the text: the original, the text masked by rules and Presidio, and the text masked by Presidio’s defaults.

Routing. The model chose the document’s type from five choices, for 100 documents per language. It was right for 295 of 300 original documents, 295 of 300 masked by rules and Presidio, and 296 of 300 masked by the defaults. The type of a document does not depend on who it is about, so masking costs routing nothing here.

Facts. The model listed the dates and company names in 300 documents. The score is the share of the labelled dates and companies that it gave back:

chat-small (gpt-6-luna on Azure), 300 test documents with a labelled date or company (100 per language): 156 dates and 574 company names. Intervals: Wilson, 95%.

Text description of the chart

Dates given back: Original text 98.1%; Masked: rules + Presidio 95.5%; Masked: Presidio defaults 10.9%. Company names given back: Original text 81.5%; Masked: rules + Presidio 73.5%; Masked: Presidio defaults 28.9%.

Masking that follows the policy costs little. With rules and Presidio, the model still gave back 95.5% of the dates (against 98.1% from the original) and 73.5% of the company names (against 81.5%). The companies it lost were the ones that Presidio took for a person or a place, such as a firm named after its founders. Presidio’s defaults cost much more: only 10.9% of the dates and 28.9% of the company names survive. Over-masking is not a safe extra; it is lost work.

Some tasks need the masked values on purpose: a reply that greets the customer by name. Then the bank can keep the list of markers and values inside its systems. After the call, it puts the name back into the model’s draft. That list is personal data too, so it needs the same protection and an end date, as in Module 4.

The recommendation

Yusuf’s report to Claire and Lena has four parts.

1. Mask inside the bank, always. Rules plus the tuned Presidio run on the bank’s own computers. They took about 34 seconds for 1,320 documents on a laptop, hide 65.8% of the personal values, and keep dates, amounts and most companies. They are the first layer for every document and every log.
2. Do not send automatically on local masking alone. Only 245 of 640 documents were fully masked. Names and addresses fail the review rule in all three languages.
3. Choose the second layer as a decision about a processor. A language model hides about 91% of the values, but it must read them first. Claire can accept that only if the provider is a contracted processor for these documents. Then masking still protects the later steps: stored prompts, logs and any second model. If she does not accept it, the options are a person, or a stronger detector that runs inside the bank. This needs qualified review, as in Residency and contractual questions. The measurement is the architecture evidence for it.
4. Keep a person for the weak cells, and measure again on real documents, with labels that the bank checks.

End to end: one new letter

A new letter arrives, in French. The notebook runs the chosen design on it. This is what the model would receive:

The masked letter (notebook, section 10)

Objet : remboursement
<PERSON>, <PERSON>,
Je m'appelle <PERSON>, cliente n° <ID>. Le 3 mars 2026, votre agence de <LOCATION> a débité deux fois 129,90 € sur mon compte <IBAN>. Merci de me rembourser. Vous pouvez me joindre au <PHONE> ou à <EMAIL>.
Adresse : <ADDRESS>, <PERSON>

Every personal value is masked: the name (twice), the customer number, the IBAN, the phone, the email and the street address. The date and the amount stay, so the model can still handle the refund. Now look for over-masking. The greeting Madame, Monsieur became two people. The branch’s city became a location. The address rule took the next line too, Cordialement. None of these identifies a person, and the model loses a little. Under the review rule, this letter would still go to a person, because it holds a name and an address.

Insights and limits

• Shapes are easy, names are hard, and names and addresses are the most common values.
• Language is not one slice. The weakest language for the local design was English, because of the foreign names in it.
• Count documents, not only values, and check the labels: both change what a share means.
• The best detector crosses the boundary. The model hides about 25 points more, because it reads the personal data.

The limits are real. The documents are synthetic, written by language models, in one industry. The sample has 300 test documents per language, so rare groups are uncertain. We used the small spaCy models; larger ones, or a detector such as GLiNER, may find more names. The model is one model with one prompt, recorded once.

Responsible use

Learn on synthetic data. Never test a detector by sending real customers’ documents to a model or a website. Use the method on real data only where that data may be, with its owner’s permission.

Do not call a masking pipeline “anonymisation”. Masked text still holds dates, amounts, company names and context, and a determined reader can often link it back to a person. Data inventory says it: data that can be linked to a person is still personal data. Whether masked text may go to a provider is a legal and contractual question, not a score.

When you publish results, show the clean documents, the slices and the label checks next to the headline share.

Make it a portfolio piece

Put the notebook, a short report and your review table in a public repository. The dataset is Apache-2.0, so you may name and link it with its attribution. A README in this shape works:

# Masking personal data before an LLM call: misses, over-masking, review

## Problem
A bank wants a model to route documents, but personal data must not reach the provider.
How much does local masking find, where does it fail, and what does it cost the model?

## Data and licence
Gretel synthetic_pii_finance_multilingual (Apache-2.0), test files EN/FR/DE, 440 per language
(140 development, 300 test). Label checks: placeholders, unlabelled emails, invalid fake IBANs.

## Approach
Masking policy first (24 labels mask, 5 keep). Detectors: rules; Presidio 2.2.364 with small
spaCy models; a recorded LLM as comparison. Measures: share of values hidden (>= 80% of
characters), over-masking, share of clean documents; by type and language; 95% intervals.

## Results (test part)
Rules 30% hidden; Presidio defaults 54% (12.5% over-masked); rules + Presidio 66% (5.9%);
LLM 91% (1.9%). Clean documents: 245/640 locally, 538/640 with the LLM.
Routing unchanged by masking; Presidio defaults lose 89% of the dates.

## Decision
Mask locally always; local masking alone is not enough to send automatically; names and
addresses go to a person; the LLM detector is a processor decision.

## Limits
Synthetic documents, incomplete labels, small rare groups, one model and one prompt.

How to describe it in an interview, in two sentences: “I measured how much personal data local tools and a language model find, miss and over-mask in bank documents in three languages. Local masking hid two thirds of the values but fully cleaned only 38% of the documents, so I designed a review rule for a person.”

Go further:

• Replace the small spaCy models with en_core_web_lg and a GLiNER PII model (Apache-2.0), and measure names again. Predict first by how much.
• Add Spanish and Italian from the same dataset, and check whether the review table changes.
• Make the policy stricter: mask company names too. Measure what the facts test loses.
• Label 50 development documents yourself, including the unlabelled emails and names, and measure how much the scores change.

Knowledge check

Check your understanding

Rules plus Presidio hide 66% of the personal values on the test part. Lena asks: 'So two documents in three are safe to send?' What do you answer, and which number do you show her?

Show the answer

No. The 66% counts values, not documents. A document leaks if one value is missed, and most documents hold several values. Show her the share of clean documents: only 245 of the 640 test documents with personal data had every value hidden, about 38%. Show it by language too, and add that the labels miss some personal data, so even that number is optimistic.

Check your understanding

The language model hides about 91% of the personal values, against 66% for rules plus Presidio. Tomás says: 'Then use the model as the detector, problem solved.' What is the problem?

Show the answer

To find the personal data, the model must read the document before it is masked. The unmasked text then crosses the boundary that the masking must protect, to the model provider. That is acceptable only if the provider is a contracted processor for this data. The data protection officer decides that, with qualified review; it is not a technical choice. The model also misses about 7% of the values. And when it rewrites a value, nothing is masked and nothing warns you.

Check your understanding

Presidio's defaults hide more personal values than the tuned setting on the development part. Why does the case study still choose the tuned setting, combined with rules?

Show the answer

The defaults mask every date and organisation. That catches some dates of birth, but it also destroys values that the model needs. In the facts test, only about 11% of the dates survived. Rules plus the tuned Presidio hide more personal values than the defaults and over-mask far less. So they are better on both measures. We chose them on the development part, before the test.

Recap

• Write the masking policy first: what must not reach the model, and what the model needs.
• Check the labels before you trust a score: placeholders, unlabelled personal data and fake values change what the numbers mean.
• Measure two errors: personal values missed or partly hidden, and other text over-masked. Count clean documents too.
• Slice by type and language: shapes are easy, names and addresses are hard, and a document’s language is not the language of its names.
• A detector that must read the data first is a processor decision, not only a better score.
• Decide what goes to a person from the measured slices, and measure what masking costs the model.

Next, the second case study: threat-model and test an open-source AI application that runs on your computer.

Next: Threat-model and test an open-source AI application