The Digital Personal Data Protection Rules, 2025 (“DPDP Rules” or the “Rules”) under the Digital Personal Data Protection Act, 2023 (“DPDP Act” or the “Act”, and together with the Rules, the “DPDP Framework”), published in the Gazette of India on November 13, 2025, operationalize India’s new data protection regime.^[1] With respect to artificial intelligence (“AI”),^[2] the DPDP Act will influence how personal data is collected, ‘processed’, and used for training AI models and platforms.^[3] Like the European Union’s General Data Protection Regulation (the “GDPR”), the DPDP Act defines ‘processing’ broadly, including automated operations. The DPDP Rules translate these principles into enforceable operational requirements constraining how personal data may be sourced, stored, retained, and reused across the AI lifecycle.

Separately, the Ministry of Electronics and Information Technology (MeitY) issued the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Amendment Rules, 2026 (“Intermediary Amendment Rules”) to further amend the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 (“Intermediary Guidelines”) under the Information Technology Act, 2000 (“IT Act”). Effective from February 20, 2026, the Intermediary Amendment Rules address systemic risks posed by AI – especially deepfakes and misinformation.^[4]

This note is Part I of a two-part post analyzing the potential effect of India’s new digital data regime on the evolving AI industry in India,^[5] involving the DPDP Framework and the Intermediary Amendment Rules, respectively. Part I examines the implications of the DPDP Framework for AI developers and deployers, including the effects on data governance and the AI lifecycle.^[6] Part II will discuss the impact of the Intermediary Amendment Rules on AI development and use in India, along with implications for investors, emerging business opportunities, and key collective takeaways.

Implications of the DPDP Framework for AI developers and deployers

The most immediate and significant impact of the DPDP Framework will be on the training and fine-tuning of AI models, which rely on significant volumes of data. AI companies are likely to be treated as either ‘data fiduciaries’ or ‘data processors’ under the DPDP Act.^[7]

Consent and Purpose Limitation

Sections 5 (‘Notice’) and 6 (‘Consent’) of the DPDP Act, read with Rule 3 of the DPDP Rules, impose granular notice and consent requirements, such that a data principal’s prior approval is generally necessary for processing their personal data. Such consent must be “free, specific, informed, unconditional and unambiguous with a clear affirmative action”, limited to data necessary for the specified purpose.^[8] Accordingly, AI developers may need to obtain explicit consents before collecting and using personal data. Even where personal data has been voluntarily provided for a specified purpose (under Section 7(a) of the Act), separate consent for training LLMs or other AI models may still be required.

However, the DPDP Act does not apply to personal data made publicly available by a data principal (under Section 3(c)(ii) of the Act). AI companies may therefore be able to use public datasets and information scraped from the internet without individual consents, though copyright issues may persist. A recent judicial decision^[9] involving OpenAI appears to prioritize AI development over copyright protection.^[10] The Delhi High Court advanced the debate on LLM training under the Copyright Act, 1957 (“Copyright Act”), observing that “research” under Section 52 includes machine learning. However, if AI model training is also regarded as “research” under the DPDP Act (pursuant to Section 17(2)(b) – see below), current judicial reasoning under the Copyright Act may not automatically extend to the DPDP Framework.

According to Section 17 of the DPDP Act and Rule 16 of the DPDP Rules, the DPDP Framework will not apply to the processing of personal data necessary for research, archiving, or statistical purposes – provided such data is not used for individual-specific decisions and the processing complies with prescribed standards. The Second Schedule of the DPDP Rules sets out such standards, including: lawful processing; data minimization;^[11] purpose limitation; reasonable efforts to ensure completeness, accuracy, and consistency; data retention only as required; and reasonable security safeguards. The data fiduciary remains accountable for compliance.

These provisions potentially create a narrow carve-out for AI development. However, routine commercial AI training or deployment – such as LLM training, recommendation engines, or computer vision systems for product development or monetization – is likely to fall beyond the scope of this exemption.      Globally, copyright exceptions for AI training and research-related derogations under privacy legislation have been treated as independent frameworks requiring separate legal analyses. For example, EU copyright law provides distinct text-and-data-mining exceptions (Directive (EU) 2019/790, Articles 3-4), while the GDPR separately governs lawful processing and research safeguards (Articles 6 and 89) – compliance with one regime does not determine compliance with the other. Singapore’s Copyright Act 2021 expressly permits certain copying for computational data analysis, including AI training (Sections 243–244), while the Personal Data Protection Act, 2012 separately provides conditional exceptions for research-related use and disclosure of personal data (Second Schedule).

Since foundation models depend on large-scale heterogeneous datasets and continuous re-training, core privacy principles – such as purpose limitation and data minimization – may clash with the iterative nature of AI development. It remains unclear whether the DPDP Act’s public information exclusions extend to mass web scraping, especially when profiling or re-identification occurs, and whether courts will distinguish between public-interest research and commercially deployed AI systems.

Unlike certain international data protection frameworks,^[12] the DPDP Act does not contain a dedicated lawful basis for AI development, provides limited guidance on algorithmic fairness or explainability, and offers inadequate clarity on responsibility allocation across complex AI value chains. AI developers may therefore need to adopt a layered compliance strategy based on anonymized, synthetic, licensed, or non-personal datasets (where feasible), implement AI-specific impact assessments and governance controls, and maintain documentation evidencing the necessity and proportionality of processing activities.

Reliance on the research exemption (under Section 17(2)(b)) may be possible for early-stage exploratory work or public-interest AI research – including academic research, public sector AI initiatives, and pre-commercial pilots. The exemption is more likely to apply where personal data use is only incidental, appropriate anonymization or pseudonymization techniques have been deployed, and outputs are statistical or aggregated. It may also be relevant for model evaluation, bias testing, or safety research. Developers may front-load experimentation within qualifying research frameworks and ring-fence subsequent commercial training within regular DPDP compliance obligations.

Where a personal dataset is acquired from another data fiduciary or processor for training a model, the AI company may be able to rely on the consents obtained by the original entity. However, this depends on whether the original notices and consents related to the eventual purpose of AI model training. If they did not, fresh notice and consent requirements may arise. For instance, if an Indian health-tech company collected patient records with consent for healthcare services and AI-based diagnostic tools, and subsequently licenses a pseudonymized dataset to an AI company, the latter may rely on the original consents – provided those consents expressly contemplated downstream AI development. Other industry-specific cases arise similarly in financial services (e.g., banks sharing consented datasets for fraud detection), automotive (connected vehicle manufacturers licensing telemetry data for autonomous driving), and retail (e-commerce platforms sharing purchasing data for recommendation engines). In each case, the key consideration is whether the original notice and consent adequately encompassed the downstream AI processing activity.

Neither the DPDP Act nor the Rules expressly require every downstream data fiduciary to be identified by name in the notice. Nonetheless, Section 11 of the DPDP Act gives data principals the right to obtain the identities of other data fiduciaries and processors with whom their data has been shared. If the downstream AI developer is known at the time consent is sought, the more legally defensible approach is to identify that entity in the original notice. Where the downstream AI company is not yet identified, obtaining fresh consent or structuring the arrangement through a processor relationship may be more defensible.

The principles of data minimization and purpose limitation may restrict the ability of AI models to use large, multi-purpose datasets with narrow consent scopes, challenging the development of versatile AI systems capable of adapting to multiple use-cases. AI developers will need to provide comprehensive notices, and individuals may refuse or withhold consent. Developers must also notify data principals about previously processed data and explain how they may exercise their rights.^[13] Such obligations are likely to reduce the viability of large personal datasets and push AI developers towards curated databases, ‘synthetic’ data,^[14] anonymization techniques,^[15] and privacy-preserving model architectures.

Data Minimization

Section 6 of the DPDP Act embodies the principle of ‘data minimization’.^[16] At the model training stage, AI developers may need to adopt techniques such as perturbation (adding ‘noise’), synthetic data, and federated learning (training across multiple devices using local data without centralizing sensitive data). At the inference stage, potential techniques include conversion of personal data into feature vectors, on-device processing (making inferences locally), and privacy-preserving methods rendering personal information pseudonymous or anonymous. Certain companies have already adopted or announced on-device processing.

Lawful Purpose

Under the DPDP Framework, personal data can be processed only for lawful purposes. AI models cannot be legally built on unauthorized datasets or undocumented workflows. Each model must be designed with transparent and auditable processes, where every data point can be traced back to a lawful purpose and an individual’s consent (barring certain legitimate uses and limited exemptions). AI developers may need to incorporate a provenance layer enabling tracking of data lineage and lawful data collection at scale.

Comparable governance approaches are emerging internationally. The EU’s AI Act^[17] does not require every data point to be linked to individual consent,^[18] but requires providers of certain AI systems to maintain extensive documentation^[19] on training datasets, data governance, and record-keeping throughout the AI lifecycle. The AI Risk Management Framework (“RMF”) of the National Institute of Standards and Technology (“NIST”) similarly emphasizes data provenance, traceability, and governance.

In healthcare, hospitals and medical AI companies^[20] increasingly maintain consent management systems, provenance logs, and version-controlled datasets. Certain large enterprise AI providers^[21] have begun implementing de facto provenance layers. Although few jurisdictions presently require a dedicated ‘consent provenance’ layer, demonstrating the origin of training data and the legal basis for its use is rapidly becoming a governance best practice.

Right to Access Information

Under Section 11 of the Act, read with Rule 14 of the DPDP Rules, data principals have the right to obtain from data fiduciaries: (a) a summary of personal data being processed and the processing activities; (b) identities of all other data fiduciaries and processors with whom personal data has been shared; and (c) any other prescribed information related to such data and its processing.

From an AI governance perspective, Section 11 introduces an obligation to ensure human-centric traceability in systems typically designed to operate at abstract, aggregate, or probabilistic levels. Since Section 11 requires organizations to confirm processing and provide meaningful summaries, changes may be needed to data architecture and record-keeping practices. AI developers relying on historical, third-party, or scraped datasets may face challenges in accurately identifying personal data used in training activities.

Section 11 may also affect responsibility allocation between AI developers and deployers – deployers integrating models into customer-facing applications are likely to receive access requests directly from data principals, requiring increased contractual scrutiny including representations, warranties, and audit rights.

In general, access rights create practical tensions with the inherent opacity (‘black box’) of complex AI systems. Organizations may adopt differentiated models (injecting noise into data to prevent extraction of original data) or data pipelines using tightly controlled, consented datasets to mitigate compliance risks.

Right to Correction and Erasure

Section 12 of the DPDP Act gives data principals the right to seek correction, completion, updating, and erasure of their personal data. This presents distinct operational and governance challenges for AI. AI systems trained on large, heterogeneous datasets may not have the architecture to permit granular correction or deletion once data has been ingested into training pipelines. Erasure requests may raise complex technical questions about re-training, fine-tuning, or model editing. To address such concerns, developers are exploring novel tools such as ‘machine unlearning’.

In pre-deployment contexts, correction and erasure can typically be operationalized through conventional data governance controls. However, where personal data has been transformed into derived features, embeddings, or statistical weights, the relationship between original data and model output may be weakened. Section 12 may also influence data minimization and retention strategies, with developers increasingly relying on synthetic, anonymized, or tightly consented datasets to reduce exposure. Similar to access rights, the right to erasure may affect responsibility allocation between developers, platform providers, and deployers. Customer-facing entities are more likely to receive erasure requests, necessitating clear contractual mechanisms for cooperation, technical assistance, and, where appropriate, indemnification. Frequent or large-scale erasure requests may require re-training or model adjustments, creating tension between data principal rights and model stability. AI systems deployed in India may need to be designed with traceability, data lifecycle governance, and post-training remediation capabilities from the outset.

Significant Data Fiduciaries

Under Section 10 of the DPDP Act, the Government may notify any data fiduciary or class of data fiduciaries as a significant data fiduciary^[22] (“SDF”) based on factors such as volume and sensitivity of data processed, risk to data principals, and potential impact on India’s sovereignty. Pursuant to Section 10 and Rule 13 of the DPDP Rules, SDFs have additional compliance requirements including periodic audits and data protection impact assessments (“DPIAs”). Reports indicate that ‘Big Tech’ firms, social media intermediaries, and major banking, financial services, and insurance companies are expected to be notified as SDFs. Large-scale or high-impact AI developers processing substantial volumes of personal data may also be brought within the SDF regime, including in sensitive sectors such as finance, health, digital identity, telecommunications, and public services.

Rule 13 requires SDFs to observe due diligence in verifying that technical measures, including algorithmic software adopted for processing personal data, are not likely to pose a risk to data principals’ rights. DPIAs are likely to assume particular importance for AI systems. SDF-classified entities may need to systematically assess risks relating to profiling, automated decision-making, bias, and disproportionate impacts. This may necessitate audit-ready documentation of training data sources, model objectives, validation methodologies, and safeguards, along with privacy-by-design and risk assessment strategies embedded within AI governance frameworks.^[23] Independent data audits may also extend beyond conventional privacy controls to examine data ingestion practices, retention policies, cross-border transfers, and vendor ecosystems. For AI deployers, SDF designation might require ongoing oversight of downstream processing activities, with contractual audit rights, information-sharing protocols, and incident response coordination.

Children’s Data

Section 9 of the DPDP Act prohibits processing children’s^[24] personal data when it is likely to cause a detrimental effect on their well-being. AI deployers offering generative systems, immersive environments, or algorithmically curated content may be required to conduct structured risk assessments addressing potential psychological, developmental, or safety harms. Section 9 also prohibits tracking, behavioral monitoring, or targeted advertising directed at children unless specifically exempted, constraining AI-driven personalization for minor users.

Read with Section 9, Rule 10 of the DPDP Rules requires verifiable parental consent before processing a child’s personal data, including through appropriate technical and organizational measures and due diligence to verify that the consenting individual is an identifiable adult. This necessarily raises the antecedent question of age assurance. Internationally, regulators have generally adopted a risk-based approach under which the robustness of age verification is proportionate to the nature of the service and risks posed to children.^[25] Approaches range from self-declaration mechanisms to identity document verification and privacy-preserving cryptographic credentials. Several platforms have also begun deploying AI-based age estimation techniques^[26] that infer approximate age from facial analysis, behavioral signals, or contextual indicators, though these raise concerns regarding accuracy, bias, and biometric privacy.

AI developers operating in India may need to adopt risk-based age assurance frameworks proportionate to the nature of their AI systems, requiring structural changes to onboarding, data collection, and governance – while balancing compliance with data minimization principles. AI systems relying on large-scale behavioral data – such as recommendation engines, adaptive learning tools, and social media applications – may be particularly impacted. Overall, the children’s personal data regime under the DPDP Framework involves a precautionary and welfare-centric approach to algorithmic design.

Cross-Border Data Transfers

India’s cross-border data-transfer regime may influence where and how AI systems are developed, trained, and deployed. Section 16 of the DPDP Act allows transfers of personal data outside India, subject to restrictions that the Central Government may notify, while preserving stricter requirements under other applicable laws.

For AI developers, this creates an important distinction between legal transferability and operational portability. Training, fine-tuning, and inference frequently involve distributed datasets, cloud infrastructure, and global development teams; restrictions on overseas transfers may affect dataset composition, model-training architecture, vendor selection, and compute location. Financial services, payments, insurance, securities, and other regulated sectors may impose data localization or supervisory-access requirements more restrictive than the DPDP Framework, constraining offshore AI models even where transfers are permissible under the DPDP Act. For example, directions issued by the Reserve Bank of India (“RBI”) may have direct implications for third-party AI models: a bank using an overseas-hosted LLM may not treat the model as an ordinary software subscription if regulated data is transmitted to the provider. The draft Guidance on Regulatory Principles for Model Risk Management, 2026 recently released by the RBI proposes model-risk tiering, lifecycle management, validation, and continuous oversight, specifically addressing third-party and AI/ML models.^[27] Similarly, entities regulated by the Securities and Exchange Board of India (“SEBI”) may need to establish approved AI/cloud environments with controls governing data access, processing location, and provider retention of inputs.^[28] In the insurance sector, AI applications in underwriting, pricing, fraud detection, and claims assessment raise questions of data residency, confidentiality, outsourcing governance, and operational resilience.^[29]

The resulting regulatory landscape is likely to favor jurisdiction-aware AI architectures: data minimization, localized training or inference, segregated datasets, privacy-preserving techniques, and domestic compute. A key policy challenge lies in maintaining sufficient safeguards without unnecessarily fragmenting AI development. The eventual balance is likely to materially influence India’s competitiveness as an AI development and deployment market.

Conclusion

Part I of this two-part post has considered the DPDP Framework’s implications for AI developers and deployers, including consent, data minimization, lawful purpose, access, correction and erasure rights, SDF obligations, and the protection of children’s data. Part II will examine the impact of the Intermediary Amendment Rules on AI, along with implications for investors, emerging business opportunities, and a concluding assessment of the collective impact on AI.

*Dr. Deborshi Barat is the Head of Public Policy and Knowledge Management at S&R Associates.

[1] For an overview of the DPDP Act and its various aspects, see here. For a discussion on the DPDP Framework taking effect, see here. For an analysis of draft DPDP Rules, see the note here.

[2] For a broad overview of challenges and considerations related to regulating AI in India, see here.

[3] For a discussion on the meaning and scope of personal data and processing, see here, here, here, and here.

[4] For a discussion on deepfakes, see here and here.

[5] For a primer on data regulation and AI development in India, see here.

[6] For a general broad overview of the impact of India’s data-related laws and policies on AI development and deployment, see here.

[7] For an overview of such roles, see here.

[8] For a discussion on consent under the DPDP Act, see here. For a deeper analysis of notice and consent requirements under India’s new data protection regime (in relation to the Bill preceding the DPDP Act), see here. For a discussion on ‘deemed’ consent under such Bill, see here.

[9] See here.

[10] For a discussion on the judicial balancing of copyright protection with AI innovation in the context of such ruling, see the note here. For a discussion on addressing legal challenges on AI development and use, including in the context of the case, see here and here.

[11] For a discussion on navigating data minimization requirements under the DPDP Act, see the note here.

[12] For instance, the EU GDPR recognizes multiple lawful bases, including legitimate interests, and addresses fairness and certain automated decisions (Articles 5(1)(a), 6, and 22). Further, the EU’s AI Act adds AI-specific requirements on risk management, data governance, transparency, and responsibilities across the AI value chain (Articles 9, 10, 13, and 25).

[13] For a general discussion on preparedness with respect to substantive obligations under the DPDP Framework, see the note here.

[14] For a discussion, see here and here.

[15] For a discussion, see here and here.

[16] For an overview, see here.

[17] For a preliminary discussion on the global implications of the EU’s AI act, see the note here. For a brief analysis of the extraterritorial application of the EU’s AI Act, see here.

[18] For the purpose of training AI models on personal data in the EU, strict reliance on explicit user consent (under Article 6(1)(a) of the EU GDPR) may not be technically and/or operationally feasible. Developers and organizations rely on alternative lawful bases under Article 6 (‘Lawfulness of processing’) to justify AI data ingestion. Such alternatives include legitimate interests under Article 6(1)(f) (pursuant to a tripartite test involving purpose, necessity, and balancing – see here), contractual performance under Article 6(1)(b), and public interest under Article 6(1)(e). Also see here for guidance from the Information Commissioner’s Office in the context of the UK GDPR (see here and here).

[19] See, e.g., Article 18 of the EU AI Act.

[20] See, e.g., here and here.

[21] See, e.g., here.

[22] For discussions on SDFs, see here, here, and here.

[23] For a discussion on cross-border data transfers in the context of AI, see the note here.

[24] For discussions on children’s personal data, see here and here.

[25] See, e.g., here.

[26] See, e.g., here, here, and here.

[27] For an analysis of such RBI draft guidance, see the note here.

[28] See, e.g., the Framework for Adoption of Cloud Services by SEBI Regulated Entities and the Technical Clarifications to Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities.

[29] For a brief discussion on technology-led insurance infrastructure stack (see, e.g., here), ‘insurtech’ models and entities, and ‘embedded’ insurance ecosystems (see, e.g., here and here) in the context of insurance intermediaries, see the note here.