ML7: Responsible AI: fairness, explanations, privacy and security
Privacy in machine learning
🎯You'll be able to
Keep personal data out of features, logs and documents where it isn't needed, and explain the basic duties of data protection law in India.
🏠The everyday picture
A tailor needs your measurements, not your bank statement. Collecting only what the job needs, and keeping it safe, is the start of respecting people's privacy.
📘What it really is
- Personal data is anything about an identifiable person: names, phone numbers, addresses, and often combinations of ordinary facts.
-
Data minimisation: use and keep only what the purpose needs. DakDost's model doesn't need names or phone numbers, so they aren't features, aren't accepted by the API and aren't logged.
-
Where personal data hides in ML:
- training files and copies on laptops;
- prediction logs that record whole requests;
- documents indexed for RAG;
-
the model itself, which can memorise rare training examples, especially large models.
-
India's Digital Personal Data Protection Act, 2023, with its Rules notified on 13 November 2025, sets duties such as a clear purpose, consent or another lawful basis, reasonable security safeguards and breach reporting. The Rules start in phases: most of these duties apply from 13 May 2027, not from the day they were notified. Check the current text and your organisation's legal advice; this is a summary, not legal advice.
-
Techniques: pseudonymous keys instead of names, aggregation, deleting raw data after use, access control, and synthetic data for development and tests (as in the kit).
📝A worked example
Input: the starter kit's API, which accepts any JSON and writes the whole request to logs/predictions.jsonl.
Steps:
- Send a request that includes
"customer_phone": "+91 00000 00001". The starter logs it, phone number and all. - In the reference solution, the API's input schema forbids extra fields, so the same request gets
422(rejected), and the log lines contain only the booking features, the probability, the model version and a request id. - Project 2's test 8 checks that
customer_phoneandcustomer_namenever appear in the log.
Expected outcome: the model gets what it needs and nothing else, and a leaked log reveals no customer's contact details.
🌍Where it's used
- Any ML product: reviews of training data, logs and access before launch.
- Health and finance: stricter rules on sensitive data and on who can see it.
- RAG systems: document filters so that personal records aren't indexed (Lesson 4).
📝Case scenario
A team debugging a chatbot copied a week of real conversations, with customers' addresses and order details, into a shared spreadsheet. It was later shared with a contractor. The fix was a logging policy: mask personal details at the point of logging, keep logs for a set period, and give access only to named people.
🖱️Try it
List every place in the DakDost kit where a customer's phone number appears (files, columns, logs, documents). Success: you find
raw/shipments.csv, the internal page in docs/internal/ and, in the starter, the prediction log; and you write how each is protected in
the reference design.
⚠️Common mistakes
- Logging whole requests. Sign: phone numbers in logs. Fix: log only the fields you need, and mask the rest.
- Personal data as features "just in case". Sign: names in the feature list. Fix: minimise, and justify each feature.
- Real data in tests. Sign: customer records in a test folder. Fix: synthetic data.
🛠️For your project
Project 2's tests 4 and 8 check that the API rejects a phone number and never logs one; Project 3's test 6 checks that staff contact numbers never appear in answers.
✅Quick check
What is data minimisation?
Show the answer
Using and keeping only the personal data that the purpose needs.
Name two places personal data can hide in an ML system.
Show the answer
For example prediction logs and documents indexed for RAG.