DPDP Act 2023 for AI Teams: What 'Purpose Limitation' Means for Your Data Pipeline
AI Snapshot
Key Takeaways
- 1
India's Digital Personal Data Protection Act mandates that data collected for one purpose cannot be used for another — including AI model training — without fresh consent
- 2
The 'Purpose Limitation' principle creates a data pipeline challenge: most AI teams train on customer data collected under one consent scope and use it for model training under a different (undisclosed) scope
- 3
Hybrid-BYOC (Bring Your Own Cloud) architecture resolves this by keeping all personal data within the bank's own infrastructure, where existing consents and data governance policies already apply
What Does DPDP Act 2023's 'Purpose Limitation' Principle Actually Require?
Direct Answer: Section 6 of India's DPDP Act 2023 establishes purpose limitation: personal data can only be processed for the specific purpose for which consent was collected. If a customer provided their income data for a loan application, using that data to train a new credit model requires a separate, explicit consent — even if the data never leaves the bank's systems.
The DPDP Act distinguishes between three types of data processing:
Specified purpose processing: The data subject has been informed of the specific purpose (e.g., "we will use your income data to process your loan application"). Processing for this purpose is lawful under the original consent.
Compatible purpose processing: Some jurisdictions allow processing for "compatible" purposes without fresh consent. The DPDP Act does not include this exception — India's framework is stricter than GDPR on this point.
New purpose processing: Any processing beyond the specified purpose requires fresh consent from the data principal (the customer). This includes using historical loan application data to train new AI models.
Practical implications for AI teams: Most banks hold millions of historical customer records collected under loan application, account opening, and KYC consents. Almost none of these consent forms mention AI model training as a purpose. Using this data for model training is technically non-compliant with the DPDP Act without re-consent campaigns.
The enforcement risk is real: Section 66 of the DPDP Act allows the Data Protection Board to impose penalties up to ₹250 crore per violation.
How Does Hybrid-BYOC Architecture Satisfy DPDP Act Requirements?
Direct Answer: Hybrid-BYOC (Bring Your Own Cloud) architecture keeps all personal data within the Data Fiduciary's (bank's) own infrastructure. Claris's analytical engine runs inside the bank's private VPC, processing data under the bank's existing data governance framework. No personal data is transmitted to Claris's systems — only aggregated model metrics and anonymised insights are exchanged. This means the bank's existing consent architecture governs all personal data processing.
Traditional SaaS architecture (DPDP non-compliant): Customer data → API transmission → Third-party processing environment → Results returned
Under this model, transmitting customer data to Claris's SaaS environment constitutes a new processing purpose that requires specific consent disclosures. Most banks cannot retrospectively obtain this consent at scale.
Hybrid-BYOC architecture (DPDP compliant): Customer data → stays inside bank's VPC → Claris engine deployed inside VPC → Only metrics transmitted → No personal data leaves bank's environment
Under BYOC, the bank's existing consents govern all personal data processing. Claris's engine becomes functionally equivalent to a new analytics module within the bank's own infrastructure — no new consent basis is required.
Technical implementation: The BYOC deployment uses containerised Claris workloads (Docker/Kubernetes) deployed into the bank's private AWS/Azure/GCP environment. The containers have no egress permissions for personal data. Model metrics, drift scores, and explainability outputs flow out through a dedicated API gateway, with a cryptographic audit trail confirming no personal data was included.
Data Localisation bonus: BYOC also satisfies Section 16 of the DPDP Act, which requires that certain categories of personal data (financial, health) be stored within India. With AWS ap-south-1 (Mumbai) deployment, all personal data processing occurs on Indian soil.
What Consent Framework Should Banks Build for AI Model Training?
Direct Answer: Banks that want to use customer data for AI model training under a traditional SaaS model must build a layered consent framework: (1) Update privacy notices to explicitly include AI model training as a processing purpose; (2) Obtain fresh consent from existing customers via opt-in campaigns; (3) Include AI training consent in new customer onboarding flows; (4) Implement consent revocation mechanisms that propagate to training data pipelines.
For banks that cannot or choose not to deploy BYOC, the consent framework requires five elements:
1. Updated Privacy Notice The notice must specifically mention: "We may use your financial data, including transaction history, income records, and creditworthiness assessments, to develop, train, and improve AI models that inform lending and risk decisions." Vague language about "improving our services" is unlikely to satisfy the DPDP Act's specificity requirement.
2. Granular Consent Collection AI model training consent should be collected separately from operational processing consent. Bundling them into a single "I agree to the terms" checkbox creates enforcement risk.
3. Fresh Consent for Historical Data For customers who consented before the DPDP Act came into force, a re-consent campaign is required before historical data can be used for model training. This is operationally significant — it means banks must contact their entire customer base.
4. Consent Propagation to Training Pipelines When a customer revokes AI training consent, their data must be removed from all future model training datasets within the timeframe specified by the Data Protection Board (likely 30 days). This requires tagging all training data records with consent status and building automated exclusion logic.
5. Third-Party Model Risk Banks using third-party credit bureau data (CIBIL, Experian) in their AI models must verify that the bureau's own consent architecture permits this use case. Bureau data collected under credit reporting consents may not extend to model training uses.
About Nodex8 AI Research Team
The research team of Nodex8 AI focuses on the global AI governance agenda, policy-to-code maturity, theoretical and empirical explainable AI research, and technology advancement in the domain.
More from the Claris Blog →Get AI Governance Insights
Research digests on XAI, drift detection, and regulatory updates.
See Claris on your own models
Explainable, auditable and defensible AI, deployed inside your own perimeter.