Module 5 · Protect the data
Masking data properly
In short
Swapping names for codes is pseudonymisation, not anonymisation: the data can still be traced back to the person, so it is still personal data. Drop what you do not need, mask the rest, and keep the code table elsewhere.
After this lesson you can
- Tell pseudonymisation apart from anonymisation
- Mask data as far as the task needs without destroying its meaning
- Keep the masking key separate from the data you send
Terms in this lesson
Understand
Many people call every kind of masking "anonymous". The difference matters, because it decides whether the data is still protected by the PDP Law.
Pseudonymisation means replacing direct identifiers, such as a name or employee number, with a code like "Employee K-07". Whoever holds the code table can turn K-07 back into the real name. Even without the table, someone who knows your office can often guess: if there is only one pharmacist at that branch, no code hides them. Because it can still be traced back to the person, pseudonymised data is still personal data and still falls under the PDP Law.
Anonymisation means processing data until there is no reasonable way, for anyone including you, to identify the person. An example is a report that only holds aggregate figures: "12 of 80 staff at the eastern branch took more than 10 days of sick leave this year". For small office datasets, true anonymisation is rarely reached, because every row still describes one real person.
So masking is a way to reduce risk, not a way to free your data from the rules. You still need to think about whether this task may use the data, which service receives it, and who holds the code table.
One more thing: do not ask an AI to mask your raw data. The moment you paste real data to have it "masked", the real data has already been sent. Masking happens before the data leaves your computer, by hand, with a spreadsheet formula, or with an approved internal tool.
The order we use has three steps, and the first is the one people forget most:
- Drop first. Delete columns and sentences the task does not need. To summarise complaint patterns, home addresses and phone numbers are no use at all. Data that is never sent cannot leak.
- Replace direct identifiers. Names, ID numbers, order numbers and e-mail addresses become consistent codes: the same person always gets the same code, so the model can still see that three complaints came from one customer.
- Blur indirect identifiers. These are what most often reveal identity again: a job title held by one person, a full date of birth, the name of a small village, an event only one person went through. Turn them into ranges or categories: age 34 becomes "30-39", a full date becomes a month, a branch name becomes a region.
The yardstick is the task. Blur until the person is not easy to guess, but stop before the meaning breaks. If the task compares branches, the region must stay. If the task looks at leave length, the number of days must stay intact.
The code table, the list that matches "K-07" to a real name, is the most valuable item in the whole process. If it gets sent too, or sits in the same spreadsheet as the data you paste, your masking means nothing.
Keep the code table where only the people who need it can open it, separate from the file you send to the AI. When the AI's result comes back, for example "K-07 and K-12 complain about the same delivery", you are the one who maps it back to real people, on your own computer. Once the work is done and the table is no longer needed, delete it. Every copy of a code table is one more way to undo the masking.
Before
The prompt
Please summarise our team's sick-leave pattern this month so I can report to my manager. [here I paste a table with full names, employee numbers, dates of birth, job titles, branch names, days of leave and the diagnosis from the doctor's note for 14 people]
What came back
This month 14 employees took sick leave. The longest was [name], the pharmacist at the small branch, 12 days because of [diagnosis]. Three people in the warehouse had the same back complaint...
After
The prompt
I need a summary of the sick-leave pattern for the monthly report to my manager. The reader is the operations manager; they need to know which section is most affected, not who the people are. I have masked the data: everyone has a code from K-01 to K-14, age is a range, branch is a region, and I removed the diagnosis. Code | Age | Section | Region | Days of leave K-01 | 30-39 | Health staff | East | 12 K-02 | 20-29 | Warehouse | West | 4 K-03 | 20-29 | Warehouse | West | 5 (and so on to K-14) Shape: three to five points, then one sentence of advice. Do not guess medical reasons and do not mention anyone's code in the summary.
What came back
- The warehouse section in the western region accounts for almost half of the leave days this month. - Most leave lasted 3-5 days; one leave in the eastern region was much longer. - The 20-29 age group took leave most often, but for short periods. Advice: review workload and equipment at the western-region warehouse.
What changed
- The diagnosis was dropped because the task does not need it. That is step one: drop first.
- "The pharmacist at the small branch" points to one person. It became "health staff" and "eastern region".
- This data is still pseudonymous, not anonymous: with the code table, K-01 can be traced back to a name. Still treat it as personal data.
- The code table was not pasted. It stays on my computer.
Common mistake
- Mistake
- Calling data "anonymous" because names were swapped for codes, then treating it as if no rules apply.
- Why it hurts
- Codes can be traced back by anyone holding the table, or guessed from job titles, dates and locations. Such data is still personal data under the PDP Law. A wrong "anonymous" label makes others store it carelessly or send it to services that were not approved.
- Do this instead
- Name it honestly: "pseudonymised" or "masked". Still use an approved tool, keep the code table separate, and use aggregate figures when the task only needs aggregates.
Try
Sorting card
Which data is pseudonymous, which is anonymous, and which is not masked yet?
An applicant list with names replaced by P-01 to P-40, code table in the HR folder
The row "Employee A, the only warehouse head in that town, was warned twice"
Meeting notes naming the employee under review
"The service team's average response time this month was 3 hours"
An attendance table with real employee numbers, no names
"Four of 30 trainees failed the final exam"
6 cards left
Names are already codes. What can still reveal identity in each row? Guess, then reveal.
A full date of birth plus a small section almost certainly points to one person. Use an age range only.
An event only one person went through is an identifier. If the task does not need it, drop it.
A small village branch may have only one or two cashiers. Replace the branch name with a region.
Free-text quotes often carry personal details. Summarise or drop quotes that point to a person.
Take home
Request template with masked data
Works with any AI assistant.
Your prompt
I need ‹tugas› for ‹pembaca›. The data below is masked: direct identifiers are replaced with codes, ‹yang-dikaburkan›, and columns that are not needed have been removed. ‹data-samaran› Rules: do not guess who is behind a code, do not guess data I removed, and do not mention anyone's code in the final result unless I ask. Shape of the result: ‹bentuk›.
Before sending masked data
- I removed the columns the task does not need
- Names, ID numbers and contacts are replaced by consistent codes
- Unique job titles, full dates and small locations are blurred
- The code table is not sent and is stored separately
- I still treat it as personal data and use an approved tool
What went wrong for us
Every table must be classified
- Context
- Our platform serves many organisations in one database. Tables owned by an organisation are protected by row-level security rules.
- What tends to go wrong
- A new table added without that rule is guarded only by app code. One query that forgets to filter by organisation can expose another organisation's data.
- What it costs if ignored
- Data leaking between organisations is one of the most serious mistakes on a shared platform.
- Root cause
- Security rules are written by hand for every table, and are easy to forget while focusing on the feature.
- How we do it
- Every new table is declared as owned by an organisation with its rule, or exempted with a written reason.
- The rule we keep
- A schema test fails when any table is not classified.
The lessonTurn a rule that is easy to forget into a test that cannot be skipped.
What it means for your workRules that live only in your head are easy to forget. Turn important ones, such as masking data before sending it, into a fixed step on your checklist.