10.11 Responsible AI and Indian data law

What this is and why it exists

If your system touches personal data and is deployed in India, the Digital Personal Data Protection Act, 2023 is the floor rather than an opinion. Its obligations are not paperwork to attach at the end: consent, purpose limitation and erasure decide what your architecture may store, for how long, and how it must be able to delete — and retrofitting those into a shipped system is far more expensive than building with them. This topic is that floor, and the documentation a review actually asks for.

The vocabulary

• Data Principal — the individual the personal data is about.
• Data Fiduciary — the entity deciding why and how it is processed.
• Notice — telling the person what will be processed and for what.
• Purpose limitation — using data only for the purpose consented to.
• Data minimisation — collecting no more than the purpose requires.
• Erasure — deleting personal data when consent is withdrawn or the purpose ends.
• Fairness metric — a measure of whether a model behaves differently across groups.
• Model card — documentation of what a model is for and where it fails.

The mental model

The two roles decide who carries the obligations. The Act defines a Data Principal as "the individual to whom the personal data relates", and a Data Fiduciary as "any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data". If you decide why and how personal data is processed, you are the fiduciary, and outsourcing the processing to a cloud provider does not move that — which is why the terms you accept from a provider are part of your compliance rather than separate from it.

Consent has a specific standard and it rules out several common patterns. Section 6 requires that "the consent given by the Data Principal shall be free, specific, informed, unconditional and unambiguous with a clear affirmative action". Read those adjectives as design constraints. Specific means one consent per purpose, so a single agreement covering everything you might later do is not consent for the later things. Clear affirmative action rules out pre-ticked boxes, and rules out treating continued use of a service as agreement. Unconditional means access cannot be made contingent on consenting to processing the service does not need.

Withdrawal must be as effortless as giving. The Act states "the Data Principal shall have the right to withdraw her consent at any time, with the ease of doing so being comparable to the ease with which such consent was given" — so a single tick to agree and a written request to withdraw is not compliant. And on withdrawal, "the Data Fiduciary shall, within a reasonable time, cease and cause its Data Processors to cease processing the personal data of such Data Principal" unless another provision requires otherwise. Note the words "and cause its Data Processors to cease": your obligation follows the data to everyone you passed it to, which is an architectural requirement about knowing where it went.

And the burden of proof sits with you: the fiduciary "shall be obliged to prove that a notice was given" and that consent was given in accordance with the Act. Consent that was obtained and not recorded is, for this purpose, consent you cannot demonstrate — so record what was consented to, when, in what wording, and to which version of the notice.

Erasure is the obligation that most constrains architecture. Section 8 requires a fiduciary to "erase personal data, upon the Data Principal withdrawing her consent or as soon as it is reasonable to assume that the specified purpose is no longer being served". Section 8 also requires "reasonable security safeguards to prevent personal data breach" and, on a breach, "intimation of such breach" to the Board and to each affected person.

Now think about where personal data actually is in a machine learning system, because that list is the reason this belongs in an engineering topic rather than a legal one. The production database. The training dataset. Every copy of that dataset in object storage. The feature store. The prediction logs. The experiment-tracking artefacts. The evaluation set assembled from real traffic. Backups. And, if you fine-tuned, the model weights.

That last one is the hard case. Personal data trained into weights cannot be deleted from them — which is a concrete argument for the rule the fine-tuning topic gave for entirely separate reasons: keep facts about people in retrieval, where they can be updated, cited and removed, rather than baking them into a model. Where personal data must inform a model, use aggregates, hold identifiers out of the features, and be able to say what a retrain would cost, because a deletion request may require one.

So the three principles, as design questions to answer before building. Consent: what exactly are you asking for, per purpose, and how is it recorded? Purpose limitation: is this new use within what people agreed to, or does it need fresh consent? Training a model on data collected to provide a service is a different purpose from providing the service, and treating it as covered is the commonest quiet violation in this field. Minimisation: which fields does the purpose actually require? A field you do not collect needs no consent, no security, no retention rule and no deletion path — not collecting is the cheapest compliance there is.

The comparison with the European regime is useful for orientation and not a substitute for reading the Indian Act. Both rest on consent, purpose limitation and minimisation, and both give individuals access, correction and erasure. The differences that matter operationally: the European regime offers several lawful bases besides consent, including legitimate interests, while the Indian Act is built much more around consent and specified legitimate uses; the European regime has an explicit provision about decisions made solely by automated processing; and the enforcement structures and penalties differ. If you built for one, you have not automatically built for the other, and the one that applies where you deploy is the one to read.

Bias auditing is the other half of responsible practice, and it starts from measurement. Report your metrics broken down by group, not only overall, for the groups where unfair treatment would matter and where you can measure lawfully. An aggregate that looks excellent routinely hides a segment on which the model is substantially worse, and nobody discovers that from a single number.

Then the part worth understanding properly: the fairness definitions conflict, mathematically. Equal accuracy across groups, equal false-positive rates, equal false-negative rates, and predicted probabilities meaning the same thing across groups cannot generally all hold at once when the underlying rates differ between groups. This is a proven impossibility rather than an engineering shortfall. So choosing which definition applies is a decision, not a calculation — it depends on what the error costs and to whom, it has to be made deliberately with the people affected in view, and it must be written down with its reasoning. A system claiming to be fair without naming which definition it satisfies has not answered the question.

Documentation is what a review asks for and what protects you afterwards. A model card: what the model is for, what data trained it, how it was evaluated and on what, how it performs per group, its known limitations, and where it should not be used. A datasheet for each dataset, as the versioning topic described. And a record of the decisions — which fairness definition, which retention period, what the consent covers, and why.

Write it while you build. Reconstructing it six months later is a project, and the moment it is needed — a review, a complaint, an incident — is the moment it cannot be written honestly, because by then you are writing it to a conclusion.

What you should now be able to explain or do

Say who the fiduciary is and why outsourcing processing does not move the obligation. Read the consent standard as design constraints and name three patterns it rules out. Meet the withdrawal, cessation and proof requirements, including for processors you passed data to. List everywhere personal data lives in a machine learning system, and say why weights are the hard case. Answer the three design questions before building. Name the operational differences from the European regime. Report metrics per group and choose a fairness definition deliberately, knowing they conflict. Write a model card, a datasheet and a record of decisions, while building.

Check yourself