Chapter 21 — AI, Analytics, Profiling and Derived Data

1. The model is a processing artifact

A model, feature store and identifiable prediction are different governance objects. Training on personal data is processing; serving on a person’s inputs is another processing activity. The definitions include operations such as indexing, use, alignment and combination, but do not automatically classify every resulting model weight as personal data (ACT:113–129).[1] An output attached to an identifiable borrower is personal data. Whether a particular trained model itself contains information about an identifiable individual requires separate technical and legal assessment. “Derived from personal data” is neither proof of anonymisation nor a universal proof that every artefact remains identifiable.

The practical thesis is to govern each activity and artefact according to its actual facts: purpose and ground, applicable data-quality duty, identifiable-copy retention/erasure reach and child restrictions. A registry is the proposed engineering instrument, not a statutory AI certificate. It should expose uncertainty about model weights rather than answer it by analogy to an ordinary database row.

2. The tension: derived‑data utility versus ground honesty

The tension of this chapter is the Chapter 8 tension at its most seductive, because the derived layer is where reuse hides best.

The utility pull. Derived data is where the value lives. The churn model predicts who leaves; the credit score prices the loan; the propensity score targets the offer. The derivation feels like creation — the team built something new from something old — and the enterprise’s instinct is that the new thing inherits none of the old thing’s obligations. “It’s just a model” is the phrase this tension produces, and it is sincerely meant every time.

The ground‑honesty pull. But the statute does not see creation; it sees processing. The model was trained on data collected for a purpose; if the model’s use is a different purpose, Section 4’s gate re‑arms, and the ground must be found — consent or a matched Section 7 clause — for the training and for the use, separately. And derived from identifiable data, the model’s outputs are themselves personal data: the churn score attached to a customer is data about her, processed, needing its own grounding.

The failure modes, in their AI‑specific costumes:

• “Anonymised, so it is free.” A reversible pseudonym or linkable ticket ID can preserve identifiability. The Section 2(t) definition concerns an individual identifiable by or in relation to the data; it does not prescribe a k-anonymity score or a universal re-identification threshold (ACT:113–114).[1] A technical assessment should state the auxiliary information, access conditions and attacks considered, and avoid calling a limited test proof against every possible identification route.
• “It’s just analytics.” The model trained on fulfilment data and pointed at a personalisation use — Chapter 8’s silent reuse, wearing a Jupyter costume. The warehouse’s gravity, Chapter 8 called it; the feature store is where it pulls hardest.
• The invisible decision. The score that quietly gates a service — eligibility, pricing, fraud flags — with nobody ever having asked whether Section 8(3)‘s accuracy duty attaches. The duty attaches to decisions affecting the principal, and most models exist to make exactly those.

The insight. Ground each processing activity and document each identifiability judgment. An anonymisation assessment should record its technique, auxiliary-information assumptions, tests, limitations and review trigger; no finite attack suite proves universal non-identifiability. For in-scope activities, this book recommends a model/feature registry carrying purpose, ground, provenance and disposition reach. The registry extends Chapter 8’s matrix into the derived estate, but it is one implementation choice rather than the only possible instrument.

2.1 Deepening training‑data provenance analysis

The Source Data Provenance Matrix (SDPM) is an author-recommended, versioned design. It records a scoped source token, intended training purpose, consent or exact applicable Section 7 clause, conditions, authority version, provenance and restricted retention class. A contract clause is not a freestanding third ground under Section 4 (ACT:160–166,269–329).[1] The matrix should preserve a change history without preserving identifiable training content forever. Hashes support identity and change detection; they neither validate the original facts nor prove erasure. Linking a subject to a training run identifies candidates for review, not a legal or technical guarantee that retraining alone removes personal information.

Before admitting a batch, reconcile purpose-specific authority and current restrictions, distinguish data retained only for law from data available for training, and evaluate identifiable fields and auxiliary links. k-anonymity and l-diversity may be diagnostic tools in a stated threat model; passing them is not a DPDP anonymity safe harbour. These are engineering recommendations to support applicable obligations, not steps mandated by definitional Section 2(t).

2.2 Training versus serving authority

The trusted policy service in SYS-010 issues decisions for a requested operation, subject, purpose and data scope. A client-supplied purpose string is untrusted. SYS-005 must check the serving purpose, PUR-004, for inference; the training purpose is PUR-003 and has no grant in the base dossier. Training approval does not authorise serving and serving approval does not authorise training. This follows the separate lawful-purpose/ground requirement, while the policy-service architecture is a recommendation (ACT:160–166,206–218).[1]

The Section 7(a) row follows ACT:271–284; withdrawal follows ACT:232–249.[1] The table’s immediate deny is a stricter recommended admission policy. Section 6(6) requires cessation and processor cessation within reasonable time unless processing without consent is required or authorised under the Act, Rules or other Indian law. It does not demand refusal of the withdrawal request, and a lawful retention obligation does not authorise renewed marketing.

The runnable local teaching model is out/templates/tests/control_model.py; test_controls.py varies training and serving grants independently and exercises the non-consent Section 7(a) receipt. It has no real identity provider, cryptographic token verification, inference server or distributed consistency. Trusted facts are supplied fixture inputs; the implementation is not offered as production middleware.

Failure and recovery design. Refuse new affected work on an unavailable policy service, expired decision, changed purpose or mismatched policy sequence. A retried request must not reuse a cached allow after withdrawal. Queue accepted withdrawal with an idempotent event identity and monotonic subject/purpose sequence; stale grant replay must not undo it. Treat a missing processor acknowledgement as pending/failed propagation, not success. When service returns, reconcile current policy and pending events before releasing work; replaying an old snapshot without subsequent restrictions is not recovery.

An in-flight decision needs a documented commit boundary. Checking once at request start cannot prove that later external effects were authorised at commitment. The production design would revalidate at the side-effect boundary, preserve already committed lawful outcomes and record uncertain external effects for reconciliation. The supplied sequential model tests purpose/sequence rules, not atomicity across independent systems. A log is supporting audit evidence; it does not discharge the independent-auditor appointment and evaluation duty in Section 10(2)(b) (ACT:427–429).[1]

3. The statutory anchors, assembled

Section 2(x) and Section 2(t) define processing and personal data (ACT:113–129).[1] Apply them to each dataset, output and model rather than assume every derivative has identical classification.

Section 4 / Section 7 — the gate and the doors, re‑armed per use: training is a use; serving is a use; each needs the ground. The chatbot training walkthrough of Chapter 8 showed the discipline at the pipeline’s entry; this chapter extends it to everything downstream.

Section 8(3) requires completeness, accuracy and consistency of personal data likely to be used for a decision affecting the principal or disclosed to another fiduciary (ACT:338–342).[1] It is not a statutory minimum AUC, model fairness percentage or KS test threshold. Source completeness checks can support the duty; they cannot certify that an underwriting model is suitable.

Section 9 separates verifiable parent/guardian consent, detrimental effects, and tracking/behavioural monitoring or targeted advertising restrictions. Rule 12 and the Fourth Schedule supply conditioned exceptions to Section 9(1)/(3), not to Section 9(2) (ACT:386–403; RULES:1269–1275,1682–1707).[1][5] An educational institution’s restricted educational/safety monitoring may qualify under the applicable entry; commercial edtech, an ad feed or a “family” label is not blanket relief. Check class, purpose and conditions before deciding. No exception is established for the Company’s proposed child targeting.

Section 10/Rule 13 add SDF assessment/audit and due diligence concerning listed technical measures, including algorithmic software. Rule 13(3) is not limited to models assumed to have significant effects (ACT:430–438; RULES:1276–1290).[1][5] Chapter 19 maps the actual requirements; Chapter 20 supplies the voluntary/non-SDF distinction and lawful stop gate.

4. The model/feature registry

The registry operationalises the insight: one row per model, per feature set, per embedding store, recording what Chapter 8’s matrix records for raw data plus the AI‑specific fields the controls need.

The registry is deliberately not a new instrument — it is the inventory (Ch.7) and matrix (Ch.8) extended into the derived estate, which is why it joins the Chapter 24 dashboard and the Chapter 22 grid like any other control plane.

5. The four disciplines at the model, worked

Ground. The training run asks the two‑purpose question: the data’s collected purpose versus the training purpose — consent or a matched clause for each, or the pipeline does not run. The serving deployment asks it again: trained lawfully, served on a different purpose, is still unsupported reuse. The Chapter 8 flag, extended to the feature store’s every edge.

Accuracy. Before a decision, check data completeness, allowed freshness and consistency against the stated source contract. The age threshold is a chosen system parameter, not the legal definition of accuracy. A counterexample is a complete, fresh input assigned to the wrong person: recency alone cannot make it accurate. Reject missing required input or route to an authorised alternative; do not silently manufacture a value and label the statutory duty met (ACT:338–342).[1]

Erasure and restricted retention. Trace identifiable features, embeddings, outputs, caches and exports. Assess model-weight identifiability separately. Sections 8(7) and 12(3) have retention qualifications; Rule 6(1)(e) and Rule 8(3) impose distinct retention duties in the retained Rules (ACT:351–359,473–476; RULES:1101–1104,1153–1166).[1][5] The design must stop unauthorised active use while retaining only the scope permitted/required under the reviewed retention decision. A retraining request is not a disposal receipt; a destroyed index is not proof that every copy or model has ceased to contain personal data. Preserve unresolved reach as a constraint on use and supplier handoff, not as a green erasure status.

Child guard. In the ordinary no-exemption path, exclude child tracking/behavioural monitoring and targeted advertising. Do not collect behavioural inputs in a “safe-mode” route and assume an aggregate output cures the collection. For CASE-103’s conditional exception, enforce its educational/safety scope and re-open the assessment if purpose, recipient or harm changes. A sandbox label does not itself meet an exception.

6. Operational safeguards for the model lifecycle

Calibrated monitoring, proposed. A distribution shift statistic is a diagnostic, not a significance conclusion without sample sizes, selection assumptions and a calibration procedure. This chapter withdraws the unsupported “>5% KS distance” legal gate. Define the reference window, current window, population/segment, feature semantics, sample counts, missingness and expected false alarms. Choose thresholds using held-out or historical data appropriate to the estate; no such telemetry is supplied here. Couple feature drift to observed input errors and delayed outcome quality when available. A large shift may be benign seasonality; a small shift can conceal a serious subgroup or source failure.

Choose responses by the failure mechanism. Invalid authority or known incomplete required data stops the affected decision regardless of drift. An unexplained distribution alarm opens investigation and possibly a bounded restriction; it does not automatically prescribe retraining. Retraining on the same faulty feed can reproduce the defect. Before restoring a route, establish lawful batch authority, data-quality repair, validation against the intended population and explicit release approval. Record the publication time of the repaired model and policy; do not let future correction rewrite what the system actually used earlier.

Data-minimising evidence. Store decision ID, subject-scoped token when needed, model/policy versions, purpose/ground decision, outcome class and necessary event times. Avoid raw feature vectors and scores in general logs unless a documented evidence purpose requires them. Tokenisation and hashes may remain personal data when linkable. Define separate access and retention classes for security evidence, processing logs and assessment summaries, following the Chapter 14 reviewed overlap rather than “immutable forever” (RULES:1087–1108,1153–1166).[5] Audit access is itself controlled processing. A reviewer must be able to see scope and limitations without receiving an unnecessary training corpus.

Retraining governance. A new batch rechecks authority for its own training purpose; it cannot treat data retained for security or statutory archive purposes as freely available training data. Provenance and retention conflicts route to a human decision. A valid serving authority is not a substitute. Where a model’s identifiable content or deletion reach remains unresolved, record the affected uses that remain stopped and the technical/legal evidence needed to reconsider them.

These design recommendations tie the registry to enforceable boundaries. They do not establish actual deployed controls, universal model compliance or a completed independent audit.

7. Two worked walkthroughs

Walkthrough one — the Company’s separate-purpose refusal. This is a synthetic branch using SYS-005 and DS-006, not a report of a lender deployment. PUR-003 training has no grant; the model rejects it. A separate fixture supplies a reviewed PUR-004 serving grant and shows that absence of training consent need not itself deny serving. The converse fixture grants only training and denies serving. These local outcomes are retained in out/remediation/Q05/test-results.json; they establish conditional program behaviour on supplied facts, not that the facts or model quality are valid in an enterprise.

For the DPIA, proposed negative cases include a truncated source and a misassigned identity. A production test would need the real feature contract and expected rejection/exception path. The local package deliberately makes no bureau-quality or lending-outcome claim. The lesson is narrower and operational: authorisation and data suitability need independent evidence, and a single green metric cannot replace either.

Walkthrough two — an anonymisation claim that cannot be assumed. Suppose a proposed support-training corpus contains pseudonymised ticket IDs still joinable to accounts. That is an authored counterexample, not a benchmark. Removing direct names would not establish non-identifiability. The team must either substantiate a genuinely out-of-scope dataset or establish the intended processing’s actual ground and controls; no qualifying Section 7 route is established merely because training would be useful. Even anonymising source material is processing while it remains personal data and needs a lawful route. This decision is recorded as stopped pending evidence, not as a test allegedly run “for free”.

8. What remains for the reader and the reviewer

The open items, each <residual>:

1. The boundary of anonymisation under Section 2(t) for the entity’s specific techniques — a technical‑legal question settled with evidence per method, not a blanket assertion.
2. Whether profiling/automated decisions attract any added notice or rights duty beyond the general ones — the Act’s rights (Sections 11 to 12) serve the outputs; whether any further DPDP‑specific transparency duty emerges from Rules or Board practice is monitored (Ch.36’s list).
3. The Section 8(3) evidence standard — what “ensure completeness, accuracy and consistency” will be held to mean as practice emerges; the Chapter 22 fixture design prices against it.

The question that hands the book its next chapter

Every discipline this chapter applied to models — ground, accuracy, erasure, child‑guard — shares one completion condition: it counts only when demonstrated. And demonstration is not a per‑chapter afterthought; it is a system — the grid, the fixtures, the evidence owners — that every one of the last twenty chapters has assumed. Chapter 22 takes up Control Testing, Audit Evidence and Effectiveness: the obligation→control→test→evidence system that converts this entire book from described controls into demonstrated ones.

References (sources retained)

• Retained Act, commencement, Rules and corrigendum: source-key paths and machine-generated references below.
• out/remediation/Q05/ai-registry.json: populated synthetic training/serving decisions and proposed operational controls.
• out/templates/tests/: limited executable teaching model and negative tests; actual run logs in the Q05 packet.
• Chapters 7–8, 13–14 and 19–20 supply the inventory, purposes, child, retention and assessment context.

Source keys and evidence limits

Line locators use newline-based retained text, not PDF page numbers. Primary sources were reread locally; no complete live legal-update search or entity-specific opinion is asserted. Vendor passages are documented claims, not observed capabilities.

• COMM: research/legal/evidence/02_gsr_843e_commencement.txt.
• RULES: research/legal/evidence/05_gsr_846e_dpdp_rules_2025.txt.
• CORR: research/legal/evidence/06_gsr_892e_corrigendum.txt.
• ACT: research/legal/evidence/01_dpdp_act_2023_gazette.txt.

Sources

[1] https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf — Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) [2] https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf — G.S.R. 843(E), DPDP Act commencement notification [5] https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf — Digital Personal Data Protection Rules, 2025, G.S.R. 846(E) [6] https://www.meity.gov.in/static/uploads/2025/12/3c7ebbae0e5456f493f486e6845df86b.pdf — Corrigenda to G.S.R. 846(E), G.S.R. 892(E)

Contents · Reader guide and citation conventions · Artifact index