Data Ethics and Privacy: Responsible AI in the Age of Aadhaar

In January 2018, a journalist at an Indian newspaper paid an anonymous seller ₹500 over WhatsApp for login access to a portal. Once inside, typing any 12-digit Aadhaar number into a search box returned the person's name, address, photograph, phone number, and email — for any of the (at the time) roughly 1.1 billion Aadhaar holders in India, not just the reporter's own record. Paying ₹300 more got a printed, ready-to-laminate copy of that person's Aadhaar card. UIDAI, the authority that runs Aadhaar, disputed that its own central database had been breached and said the access came through a compromised state-government portal — but the incident forced a question every AI system built on Indian data eventually has to answer: when you feed a machine learning model on people's personal information, who actually controls what happens to it, and what stops that control from silently leaking away? That question — not "is privacy a nice-to-have" but "what specific technical and legal mechanisms make privacy real" — is what this chapter works through.

What Data Does Aadhaar Actually Hold — and Where Does It Go?

Aadhaar is a 12-digit unique identity number issued by the Unique Identification Authority of India (UIDAI) to residents of India. It is worth being precise about what it stores, because vague fear ("they have all my data") and vague reassurance ("it's just a number") are both wrong in different ways. The Central Identities Data Repository (CIDR) — UIDAI's core database — holds two categories of information per person: demographic data (name, date of birth, gender, address, and optionally a mobile number and email) and biometric data (ten fingerprints, two iris scans, and a facial photograph). That is the entire list. UIDAI does not store your bank balance, your caste, your religion, your medical history, or your purchase history — despite those often being lumped into "Aadhaar data" in casual conversation.

The more important design question is what happens when an agency — a bank, a telecom operator, a government scheme — wants to verify someone's identity. This is called Aadhaar authentication, and its architecture is a genuine case of privacy engineering, not just policy. The requesting agency (technically an "Authentication User Agency," AUA) captures a live fingerprint or iris scan and sends it, encrypted, along with the claimed Aadhaar number to UIDAI's servers. UIDAI's system compares the live scan against the biometric template stored in the CIDR for that number and sends back one of exactly two things: a plain Yes/No match result, or — only if the resident has separately consented to an e-KYC ("electronic Know Your Customer") request — a small demographic packet (name, address, DOB, photo). Crucially, the raw biometric template inside the CIDR is never transmitted back out to the requesting agency in either case. The matching happens on UIDAI's side of the wall; the agency only ever learns the outcome.

This "Yes/No, not the raw data" design is called data minimization by architecture: instead of trusting every bank, telecom store, and ration shop counter across India to responsibly handle a copy of your fingerprint template, the system is built so that copy never leaves UIDAI's servers in the first place. It is one of the few places where you can point to a concrete engineering decision and say "this is what privacy-by-design looks like," rather than just a policy promise. It does not, however, protect the demographic data (name, address, photo) that legitimately gets released for e-KYC — which is exactly the category of data exposed in the 2018 portal incident described above.

Personal Data and the Two Roles the Law Cares About

Before going further, we need precise vocabulary, because "privacy" is too vague a word to build rules around. India's Digital Personal Data Protection Act, 2023 (DPDP Act) — the country's first comprehensive data protection law — defines personal data as any data about an individual who is identifiable by or in relation to that data. It then names two roles: the Data Principal is the individual the data is about (you), and the Data Fiduciary is whoever decides why and how that data is processed (the bank, the app, the school). An AI system trained on personal data does not remove the Data Fiduciary's obligations — the company that builds the model is still the fiduciary for the data it trained on.

Sensitive personal data — health records, biometric data, financial details, sexual orientation, caste or religious affiliation — deserves extra caution because misuse causes disproportionate harm: a leaked address is inconvenient, but a leaked HIV status or leaked caste marker can get someone socially ostracized or physically harmed. Any AI system (a hospital triage model, a loan-approval model, a college-admission recommender) that ingests sensitive personal data inherits a higher duty of care than one that only sees, say, anonymous website clickstream data.

Privacy as a Fundamental Right: The Puttaswamy Judgments

For decades, Indian law did not settle whether privacy was a constitutionally guaranteed right at all. That changed in 2017, when a nine-judge bench of the Supreme Court, in Justice K.S. Puttaswamy (Retd.) v. Union of India, ruled unanimously that the right to privacy is intrinsic to the right to life and personal liberty guaranteed under Article 21 of the Constitution. This is the single most important legal fact underlying every Indian data-protection rule you will encounter: privacy is not a courtesy a company extends to you, it is a constitutional entitlement the state itself must justify overriding.

The same case, in its 2018 phase, produced the specific ruling on Aadhaar. The Court upheld Aadhaar's constitutional validity for its core welfare purpose — subsidies, benefits, and tax-related use (PAN linking) could still require it — but struck down several extensions that had crept in: private companies could no longer make Aadhaar mandatory for their own services, telecom SIM cards could no longer require mandatory Aadhaar-linking, and schools could no longer demand it for admission. The reasoning matters more than the specific list: the Court applied a proportionality test — a measure that restricts a fundamental right is only constitutional if it is necessary for a legitimate state purpose, and no less-restrictive alternative would achieve the same goal. A bank wanting Aadhaar purely for its own convenience, with no comparable state interest, failed that test; a subsidy scheme trying to stop ineligible or duplicate claimants passed it.

The DPDP Act, 2023: Rules Written for the AI-Data Era

The DPDP Act, passed in 2023, is India's operational answer to "so what specifically must a company (or an AI team) do?" Its core obligations map directly onto how a machine learning pipeline is built:

• Consent must be free, specific, informed, and unconditional — a pre-ticked checkbox or a 40-page terms document buried under "I agree" does not count as informed consent. For an AI product, this means the training-data collection step needs a genuine, understandable opt-in, not a legal fig leaf.
• Purpose limitation — data collected for one stated purpose (say, verifying identity for a loan) cannot silently be repurposed to train an unrelated model (say, an ad-targeting engine) without fresh consent.
• Data minimization — collect only what the stated purpose actually requires. A homework-help chatbot does not need your home address.
• Storage limitation and the right to erasure — data must not be retained indefinitely "just in case it's useful for training later"; the Data Principal can demand deletion once the purpose is served.
• Breach notification — a Data Fiduciary that suffers a data breach must inform both the Data Protection Board of India and the affected individuals, not quietly patch the hole and stay silent.
• Financial accountability — the Act's penalty schedule allows fines running as high as ₹250 crore for a single serious violation, which is designed to make privacy failures a board-level financial risk, not a line item in a terms-of-service document nobody reads.

Every one of these is a direct constraint on how you would responsibly build an AI system today: before you scrape or license a dataset of Indian users' data to train a model, you have to be able to answer "what consent covers this, what purpose does it serve, and when does it get deleted?" — and if you cannot answer all three, the DPDP Act says you should not have the data.

Why "We Deleted the Names" Doesn't Make Data Anonymous

A very common and very wrong belief — worth naming explicitly as a misconception — is that stripping obvious identifiers (name, Aadhaar number, phone number) from a dataset makes it "anonymous" and therefore safe to release or use freely. This is false, and the failure mode has a name: a linkage attack, sometimes called the mosaic effect, where an attacker combines the "anonymized" data with a second, independently available dataset to re-identify individuals.

The classic demonstration is from computer scientist Latanya Sweeney. In 1997, Massachusetts released "anonymized" hospital records — name and address removed, but ZIP code, birth date, and sex retained — for research purposes. Sweeney bought the publicly available voter registration roll for the city of Cambridge for $20, matched it against the hospital data using exactly those three fields, and re-identified the medical records of the sitting Governor of Massachusetts, William Weld, whose insurance claims were sitting right there in the "anonymous" dataset. She later showed, more generally, that ZIP code, birth date, and sex — three fields that feel harmless on their own — uniquely identify roughly 87% of the U.S. population when combined. The lesson generalizes directly to Indian datasets: PIN code, date of birth, and gender are exactly the kind of "harmless" quasi-identifiers that show up in school records, hospital records, and government scheme databases, and combining any such dataset with a second public list (a voter roll, a school directory, a social media profile) can undo the anonymization.

The formal defense against this is k-anonymity: a dataset satisfies k-anonymity if every combination of quasi-identifying fields (age, PIN, gender, and similar) is shared by at least k records, so no single row can be isolated. Consider a school's AI-based wellness chatbot that logs which students it flagged for anxiety, alongside age, gender, and a truncated PIN code — with names already removed:

Every row here has a unique combination of (age, gender, PIN). Any classmate who knows "the 15-year-old girl in my class with PIN 110001" instantly learns her anxiety flag — the name was removed, but the record was never anonymous. To achieve k = 2, we generalize the fields: collapse age into the band 15–16, and truncate the PIN to its first three digits (110):

Now rows 1 and 3 share the identical quasi-identifier (15–16, F, 110), as do rows 2 and 4 — those two groups satisfy k = 2. But rows 5 and 6, the two 17-year-olds, are each still alone: generalizing age into two-year bands was not coarse enough for that part of the table. A real k-anonymization pipeline would either widen the age band further (merging 17–18 into 15–18) or suppress those two outlier rows entirely — dropping records that cannot be safely grouped is a normal, expected part of the technique, not a failure of it. This is the actual engineering tradeoff behind every "anonymized dataset" you will hear an AI company mention: more generalization means more safety and less analytical precision, and there is no setting that gives you both for free.

Differential Privacy: Turning a Promise into a Provable Bound

k-anonymity has a weakness: it protects against a specific attack (linking known quasi-identifiers), but it does not give a mathematical guarantee against attacks nobody has thought of yet. Differential privacy, introduced by Cynthia Dwork and collaborators in 2006, takes a different approach: instead of hiding specific fields, it adds carefully calibrated random noise to any query's answer, and proves — with an actual inequality, not a promise — a bound on how much any single person's presence in the dataset could have changed the answer.

Here is the formal idea. Let D and D′ be two datasets that differ in exactly one person's record ("neighboring" datasets). A randomized mechanism M is ε-differentially private if, for every possible output r,

Pr[M(D) = r]
------------  <= e^ε
Pr[M(D') = r]

In words: whether or not any one specific person's data was included changes the probability of seeing any particular reported answer by at most a factor of e^ε. Smaller ε means a tighter bound, meaning more privacy (and, unavoidably, more noise); larger ε means a looser bound, less privacy, less noise.

The standard way to achieve this for a numeric query (like a count) is the Laplace mechanism: compute the true answer f(D), then add noise drawn from a Laplace distribution centered at 0 with scale b = Δf / ε, where Δf (the "sensitivity") is the largest amount the true answer could change if one person's record were added or removed — for a simple count, Δf = 1, since one person can change a count by at most 1.

Why does this specific choice of b give exactly the e^ε bound? The Laplace probability density is f(x) = (1/2b)·e^(−|x|/b). For two neighboring datasets D and D′ whose true answers differ by at most Δf, and a reported value r, the ratio of densities is:

Pr[M(D)=r]     e^(-|r - f(D)| / b)
----------  =  --------------------
Pr[M(D')=r]    e^(-|r - f(D')| / b)

           =  e^( (|r-f(D')| - |r-f(D)|) / b )

           <= e^( |f(D) - f(D')| / b )      (triangle inequality)

           <= e^( Δf / b )

Setting b = Δf / ε makes the exponent exactly ε, which gives Pr[M(D)=r] / Pr[M(D')=r] ≤ e^ε — precisely the definition. This is why the scale isn't arbitrary: it is reverse-engineered so the privacy bound comes out exact.

Let's trace this with real numbers. Suppose a school survey asks 100 students, anonymously, "Have you ever used an AI chatbot to write a graded assignment without declaring it?" and the true count of "yes" answers is 42. We want to publish this count without letting anyone infer, with confidence, whether any one specific student answered yes — so we release a noisy version instead.

import math

true_count = 42       # true number of "yes" answers, out of 100 students
epsilon = 0.5          # privacy budget: smaller = more private, noisier
sensitivity = 1        # one student's answer changes the count by at most 1
b = sensitivity / epsilon        # Laplace scale

noise = 1.73            # one fixed draw from Laplace(0, b), used here for a traceable example
released_count = true_count + noise

def laplace_pdf(x, b):
    return (1 / (2 * b)) * math.exp(-abs(x) / b)

p_from_42 = laplace_pdf(released_count - 42, b)   # density if the true count were 42
p_from_41 = laplace_pdf(released_count - 41, b)   # density if the true count were 41 (one fewer "yes")
ratio = p_from_42 / p_from_41
bound = math.exp(epsilon)

print(f"b = {b}")
print(f"released_count = {released_count}")
print(f"ratio = {ratio:.4f}")
print(f"e^epsilon bound = {bound:.4f}")

Tracing it by hand: b = 1 / 0.5 = 2.0, so released_count = 42 + 1.73 = 43.73. Then p_from_42 = (1/4)·e^(−1.73/2) = 0.25 × e^(−0.865) ≈ 0.25 × 0.4211 ≈ 0.10526, and p_from_41 = (1/4)·e^(−2.73/2) = 0.25 × e^(−1.365) ≈ 0.25 × 0.2554 ≈ 0.06385. Dividing, ratio ≈ 0.10526 / 0.06385 ≈ 1.6487, which equals the bound e^0.5 ≈ 1.6487 exactly — this is because the specific noise draw used here (1.73, on the side away from 41) sits exactly at the mechanism's worst-case direction, so the inequality holds with equality. The published number, 43.73 (rounded to 44 in practice), is close enough to 42 to be useful to a school counsellor deciding whether to run an awareness session, but the mathematics guarantees that no single student's yes/no answer shifted the published number's probability by more than a factor of about 1.65 — a concrete, provable limit on what an attacker could infer, instead of a hopeful claim that "the data has been anonymized."

DEPA and Account Aggregators: Consent as Live Infrastructure, Not a Checkbox

India has also built a genuinely novel piece of regulatory-technical infrastructure for consent itself: the Data Empowerment and Protection Architecture (DEPA), implemented through RBI-licensed Account Aggregators (AAs). Before this system, "consenting" to share your bank statement with a lender for a loan application usually meant physically printing statements or emailing PDFs — an unauditable, all-or-nothing act. Under the AA framework, a consent request is a structured, machine-readable object: it specifies exactly which data (say, six months of a specific bank account's transactions), for exactly which purpose (credit assessment), for exactly how long, and it is revocable at any time. The Account Aggregator itself is a data-blind intermediary — a licensed entity that routes the encrypted data from the bank to the lender based on your consent, without the AA itself ever being able to read the contents.

This matters directly for AI ethics because credit-scoring and loan-approval models are exactly the kind of AI system built on this pipeline: a fintech company's model ingests bank-transaction data flowing through the AA with a specific, logged, revocable consent artifact attached to it, rather than a scraped or purchased dataset with no clear consent trail. It operationalizes the DPDP Act's purpose-limitation principle as running infrastructure rather than a paragraph in a privacy policy — the system enforces the boundary rather than merely stating it.

When the System Itself Is the Harm: Exclusion and Algorithmic Accountability

Data ethics is not only about leaks and re-identification; it includes what happens when an AI-driven verification system fails a real person even while working "as designed." Aadhaar's biometric authentication has a documented failure mode: fingerprint-matching accuracy degrades for people whose fingerprints are worn smooth by decades of manual labour, and for elderly residents whose skin and prints change with age. Field research, including work by economist Reetika Khera, documented cases where genuinely eligible beneficiaries were denied their monthly food-grain rations at Public Distribution System (PDS) shops because a biometric scan failed to match — not because they were impostors, but because the sensor and matching algorithm were not built or tested with their fingerprints in mind.

This is a fairness and accountability failure layered on top of a privacy-preserving design: the same architecture that correctly avoids leaking your fingerprint template can still, through an ordinary false-negative match, cut someone off from a welfare entitlement they are legally owed. The ethical fix is not "collect less biometric data" (that would defeat de-duplication, the scheme's actual anti-fraud purpose) but "the system must have a working fallback" — and government guidelines do specify that authentication failure should not, by itself, be grounds for denying a welfare entitlement; a supervisor override or an alternative ID check is meant to be available. Whether that fallback is reliably offered in practice, at every ration shop counter in the country, is the real accountability question — and it is a reminder that an AI/biometric system's ethics are judged by its worst-served users, not its median accuracy statistic.

Common Misconceptions, Corrected

• "Removing the name anonymizes the data." False. As Sweeney's re-identification of a sitting governor showed, quasi-identifiers like ZIP/PIN code, birth date, and gender can uniquely re-identify most people even with names stripped out. Real anonymization requires generalization or suppression sufficient to guarantee k-anonymity (or a differential-privacy guarantee), not just deleting the obviously identifying columns.
• "Every time I do Aadhaar authentication, the agency receives my fingerprint data." False. The requesting agency sends your live scan to UIDAI and receives back only a Yes/No match result (plus limited demographic data only under separate e-KYC consent) — the stored biometric template never leaves UIDAI's CIDR.
• "A privacy law is just a policy statement companies can word around." Under the DPDP Act, obligations like purpose limitation and breach notification carry financial penalties up to ₹250 crore, and the Puttaswamy judgment established privacy as a constitutional right subject to a judicially enforced proportionality test — this is binding law with real remedies, not a best-practices suggestion.

Exam Mapping

This chapter's legal material (Puttaswamy, the DPDP Act's principles, Aadhaar's scope) is directly examinable under CBSE's AI/CS elective units on AI Ethics, and makes strong material for case-study and general-awareness sections in KVPY-style and Olympiad aptitude tests, where "explain the ethical tradeoff in this scenario" questions are common. The mathematics — the Laplace-mechanism derivation, the exponential inequality, and the k-anonymity generalization logic — is genuine applied algebra and exponential-function reasoning of the kind that strengthens JEE/BITSAT-level comfort with inequalities and exponent manipulation, even though data ethics itself is not a JEE Physics/Chemistry/Maths syllabus topic; treat the derivation as math practice with a real-world payoff, not as exam content to memorize verbatim.

Summary

• Aadhaar's CIDR stores only demographic data (name, DOB, gender, address) and biometric data (fingerprints, iris, photo) — nothing else — and its authentication flow is designed so raw biometric templates never leave UIDAI's servers, returning only a Yes/No result or, with separate consent, limited e-KYC demographic data.
• Puttaswamy (2017) made privacy a fundamental right under Article 21, subject to a proportionality test; the 2018 Aadhaar judgment applied that test to strike down private-sector and telecom mandates while upholding welfare-scheme use.
• The DPDP Act, 2023 operationalizes privacy for the AI era through consent, purpose limitation, data minimization, storage limitation, breach notification, and financial penalties up to ₹250 crore.
• Deleting names does not anonymize data — quasi-identifiers enable linkage/re-identification attacks, as Sweeney demonstrated; k-anonymity fixes this via generalization and, when needed, suppression of outlier records.
• Differential privacy gives a provable bound, Pr[M(D)=r]/Pr[M(D')=r] ≤ e^ε, achieved for counting queries by Laplace noise with scale b = Δf/ε — a mathematical guarantee rather than a promise.
• DEPA/Account Aggregators operationalize purpose-limited, revocable consent as live infrastructure for AI systems like credit-scoring models.
• Privacy-preserving design and fairness are separate concerns — a system can correctly protect your fingerprint template and still unfairly deny you a welfare entitlement through a biometric false negative; both failure modes require distinct fixes.

Practice: Active Recall

1. A dataset query has sensitivity Δf = 1. You want ε = 1 (looser than the 0.5 example above). Compute the Laplace scale b, and compute e^ε. Is the resulting privacy bound tighter or looser than the ε = 0.5 example worked above? Explain in terms of how much noise would typically be added.
2. A hospital dataset has quasi-identifiers {Age, 3-digit PIN, Gender} for 500 patients. After generalizing Age into 10-year bands, is 2-anonymity guaranteed for every record? Justify your answer using the outlier-suppression idea from the worked school example.
3. In two or three sentences, explain why the 2018 Supreme Court verdict allowed a government subsidy scheme to require Aadhaar but disallowed a private bank from requiring it for opening a savings account, using the proportionality test.
4. Explain, in your own words, the difference between k-anonymity and differential privacy: what specific guarantee does differential privacy give that k-anonymity does not?
5. A ration shop's biometric scanner fails to match a 70-year-old genuine beneficiary three months running. Identify (a) which part of the system is a privacy-preserving success and (b) which part is an ethics/fairness failure, and explain why fixing (b) does not require weakening (a).

Think About It

Think about this: How would you explain data ethics and privacy: responsible ai in the age of aadhaar to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.