Responsible ML: Fairness, Privacy and Security

A model that decides about people can harm them in ways ordinary bugs do not:

• unfairly: worse outcomes for some groups, often without anyone intending it;
• invasively: revealing or misusing personal data;
• unsafely: being manipulated by attackers;
• without recourse: no explanation, no appeal, no human to ask.

These are design requirements, decided with the other requirements, not checked at the end.

Fixing them late is expensive and sometimes impossible.

• A model trained on data it should not have used may have to be discarded.
• Laws increasingly require assessments, documentation and human oversight before launch.
• Trust, once lost publicly, is very hard to win back.

Bias usually enters through the data and the setup, not the algorithm:

• historical bias: past decisions were unfair, and labels record them;
• representation: some groups have little data, so the model is worse for them;
• measurement: labels or features mean different things for different groups (fewer reports in areas with less checking);
• proxies: features that correlate with a sensitive attribute;
• feedback loops: decisions that generate more data about some groups (module 22).

Knowing the source tells you the fix.

• Representation problems need more data or group-aware evaluation.
• Historical bias in labels needs a rethink of what is being predicted.
• Proxy problems need feature review and testing, not just removing one column.

Compare outcomes across groups. Common measures:

• selection rate (demographic parity): are groups flagged or approved at similar rates?
• true positive rate (equal opportunity): of those who really are positive, is the same share caught in each group?
• false positive rate: of those who are really negative, is the same share wrongly flagged?
• precision and calibration by group: does a score mean the same thing in each group?

Mathematically, these usually cannot all be equal at once when groups' base rates differ. Choosing which matters most is a decision for the business, with legal and ethical input.

Measuring is the first step, and it is cheap.

• Report the measures per group alongside accuracy for every release.
• Large gaps are a signal to investigate, not automatically proof of unfairness, but they must be explained.

Interventions at three stages:

• Before training: collect more data for under-represented groups; fix biased labels; re-weight examples; review and remove proxy features.
• During training: add a fairness constraint or penalty to the objective.
• After training: adjust thresholds or calibration per group, where law allows; add human review for borderline cases.

Then measure again: an intervention can shift the problem elsewhere.

Data fixes are usually the most durable.

• A model that is simply worse for a group because it has seen too little of it improves with more and better data.
• Post-processing is quick but must be legally checked: in some domains, treating groups differently by rule is itself prohibited.

Models create privacy risks beyond the raw data:

• re-identification: 'anonymous' data with enough details (location history, purchase patterns) can identify people;
• memorisation: models, especially large ones, can memorise and reveal rare training examples;
• membership inference: attackers can sometimes tell whether a person's record was in the training data;
• inference of sensitive traits: a model can infer health, pregnancy or finances from purchases.

Privacy laws apply to these risks, not only to stored records.

• Removing names is not anonymisation; combinations of ordinary fields often identify people.
• Inferring a sensitive trait can be as harmful as collecting it.

Techniques that reduce privacy risk:

• minimisation and aggregation: use only what is needed; prefer aggregates over raw records;
• pseudonymisation with keys held separately, and strict access control;
• differential privacy: add carefully calibrated noise so no single person's data changes results much; used in statistics and training (DP-SGD);
• federated learning: train on users' devices and send only model updates, not data;
• on-device inference: keep data on the phone (module 18).

They allow useful models with less exposure.

• Each has costs: differential privacy reduces accuracy, especially for small groups; federated learning is complex to run.
• The right mix depends on how sensitive the data is and what the law requires.

When a user asks for their data to be deleted, it must leave:

• raw data, feature tables and training sets;
• feature-store values and caches;
• and, in principle, influence on trained models.

Practical approaches: delete from all stores promptly, and retrain on the cleaned data on a regular schedule, so models stop reflecting deleted users within a known time. Research on 'machine unlearning' aims to remove one person's influence without full retraining.

Laws such as GDPR and India's DPDP Act give people rights over their data.

• Lineage (module 8) is what makes finding every copy possible.
• Regular retraining already in place makes compliance much simpler.

ML systems face specific attacks:

• evasion: crafting inputs to fool the model (fraudsters tuning behaviour to stay under the score; tiny changes to images);
• data poisoning: injecting bad examples into training data (fake reviews, coordinated clicks, false reports);
• model extraction: querying a model many times to copy it or learn its decision boundary;
• supply-chain attacks: malicious model files or libraries (module 20);
• inference attacks: extracting private training data (above).

Any model that affects money, access or reputation will be attacked.

• Fraud, spam, moderation and ranking (search and reviews) are constant targets.
• Attacks exploit the same openness that makes ML useful: it learns from data that attackers can influence.

Defend in layers:

• hard-to-fake features: device, network, behaviour over time, rather than easily changed fields;
• rate limits and anomaly detection on queries and on training signals;
• data provenance and filtering: trust weights for sources; remove coordinated or bot activity before training;
• limited exposure: return decisions, not raw scores; avoid revealing exact reasons to suspected attackers;
• adversarial testing (red-teaming) before launch and regularly after;
• human review for high-stakes or uncertain cases.

No single defence is enough against a motivated attacker.

• Layers raise the cost of attack until it is not worth it.
• Monitoring for sudden changes (module 21) catches attacks the defences miss.

High-stakes decisions need people and processes around the model:

• human review of borderline or high-impact cases;
• explanations to affected people, and a way to appeal to a human;
• impact assessments before launch for risky uses;
• documentation: model cards, data sheets, decision logs.

Laws are converging on these: the EU AI Act sets duties by risk level (with some uses banned and 'high-risk' uses such as credit and hiring heavily regulated); India's DPDP Act governs personal data; sector rules apply to banks, insurers and health.

Regulation turns good practice into obligation.

• Designing review queues, explanations and logs in from the start is far cheaper than retrofitting them.
• Human review also improves the model: reviewers' decisions are high-quality labels.

The questions interviewers ask about responsible ML, from the first screening call to the senior round. Cover the answer, say yours aloud, then compare.

Reading an idea and explaining it are different skills.

• Each answer below is the two or three sentences an interviewer is listening for.
• The reasoning behind each one is in the cards above. If an answer surprises you, go back to that card.

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

An idea you have only read fades in a week.

• Building it once, even in fifty lines, is what makes it yours.
• Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.