Identify the responsible person, applicable law and required controls.
The categories below are an applicability checklist, not a statement that every regime governs every deployment. Confirm the current instrument, entity, activity, jurisdiction and commencement.
Section 2(i) identifies the person determining purposes and means as the Data Fiduciary, not the software. Section 3 concerns processing in India and qualifying overseas processing connected with offering goods or services to Data Principals in India, subject to exclusions.
Identify whether the business is an intermediary and which category-specific rules apply. Do not read a duty addressed to a defined class of intermediaries as a universal requirement on every AI user.
Identify the regulated entity, activity and current regulator instrument before assessing AI use in trading, lending or advice. A vendor relationship does not itself establish the same duties as a regulated customer.
Assess the software’s intended purpose and classification before treating it as a regulated medical device. Not every healthcare AI tool has the same regulatory status.
Using an algorithm does not displace competition-law analysis. Assess agreements, coordination, market position and conduct; the use of AI alone does not establish collusion or abuse.
A proposed law, policy announcement or voluntary governance standard is not an enacted obligation merely because it concerns AI. Record the legal status and applicable version before relying on it.
Commencement matters: the substantive processing duties, breach-reporting requirements and penalty adjudication provisions discussed here belong to the eighteen-month phase after Gazette publication under G.S.R. 843(E) and Rule 1. They are not yet operative. Existing CERT-In and other applicable legal obligations continue independently.
Training can involve processing of personal data. Identify provenance, purposes, permissions and the person deciding how the data is used.
Once the substantive DPDPA provisions operate, assess consent under Section 6 or an applicable certain legitimate use under Section 7, with scope and exemptions. Consent for one purpose does not automatically cover a new training purpose.
An automated output does not remove the responsibility of the person making or deploying the decision. Assess the affected individual, contractual terms and sector-specific rules.
The DPDPA does not create a general GDPR Article 22-style right to reject every automated decision or a universal explainability duty. Map the actual access, correction, grievance and other applicable obligations.
An inference relating to an identifiable individual can itself be personal data. Identify the source, inference, recipient and intended use.
Assess lawful purpose and the applicable processing ground rather than claiming every disclosure necessarily needs fresh consent. Check notices, purpose, Section 7 where relevant and statutory exclusions.
Map offshore training, inference, support access and sub-processors rather than relying only on the customer location.
Apply Section 16, relevant Rules and any sector-specific restriction when operative. Do not import a universal GDPR transfer-impact-assessment or standard-contractual-clause requirement into the DPDPA.
Record what the agent can read, disclose and do, who sets its objectives, and who authorises external actions.
Approval limits, access controls, action logs and escalation are recommended controls. Map each to an actual legal or contractual duty; an internal framework is not legislation.
Section 9 concerns children, defined as individuals under eighteen, subject to the Act and relevant exemptions.
Once operative, assess verifiable parental consent, processing detrimental to well-being, tracking or behavioural monitoring, and targeted advertising directed at children. Apply notified exemptions and conditions rather than a blanket rule for every system.
The assessment maps information entering the system, inferences, disclosures, offshore access and authorised actions. Each finding should identify its evidence, relevant law or contract, uncertainty and proposed action. It is an advisory method, not a statutory certification or an assumed numerical risk score.
The practice of AI governance sits at the convergence of data protection law, sector specific regulation, technical safety standards, and constitutional principle. The framework is a governance operating system designed to scale as both the technology and the regulation evolve.
Comprehensive mapping of every applicable AI regulation across India, EU, UK, US, and sector specific frameworks. The foundation layer that determines what law applies to which AI system.
Board oversight structures, AI Owner designation, AI Safety Officer mandate, Model Risk Committee constitution, and DPO coordination protocols.
Use internal risk tiers to prioritise review. Do not present another jurisdiction’s statutory categories as universal Indian legal classifications; applicable overseas duties require a separate scope analysis.
Training data provenance, consent architecture for AI processing, data minimisation enforcement, and synthetic data strategies. DPDPA compliance embedded at the data layer.
Secure AI development lifecycle covering model versioning, bias testing, red teaming protocols, adversarial robustness, and prompt injection defence.
Model cards, system documentation and impact assessments can support review. Identify any particular disclosure or watermarking duty from the applicable law or contract rather than treating all documentation as universally mandatory.
Incident response for AI failures, continuous monitoring for model drift, human in the loop safeguards, and operational resilience standards.
Internal audit frameworks, third party certification readiness (ISO 42001), evidence bundles for regulatory inquiry, and continuous compliance monitoring.
LLMs, automated decision engines, and neural networks move faster than regulation. We let boards deploy AI within clear legal guardrails, balancing the commercial upside against copyright, data leak, model bias, and cross border compliance risk.
We review your actual technical pipelines, data scrapers, retrieval configurations, and model fine tuning setups to locate potential liabilities.
We build frameworks that help your development teams innovate freely while clearly defining and containing liability risk.
We build clear compliance trails grounded in constitutional privacy rights, copyright law, and evolving technology regulation.
These are recommended workstreams. For each, distinguish a statutory duty from contractual commitments and internal risk controls.
Map training, inference, support and agent actions. Identify personal data, commercial information, outputs and affected people; citizenship is not the DPDPA scope test.
Identify the person determining purposes and means, operational owners and escalation routes. Board reporting is a recommended governance arrangement unless a specific applicable obligation requires it.
A supplier may be a processor for one activity and a fiduciary for its own purposes. Review actual decisions, instructions, secondary use, security, audit and incident terms rather than automatically labelling every vendor a processor.
Document intended uses, prohibited uses, human review, bias and security testing, complaints and remediation. Distinguish organisational policy from legal requirements.
Section 10 provides additional duties for notified Significant Data Fiduciaries once operative. A risk-based impact assessment may also be prudent for other AI uses; it is not a universal DPDPA duty merely because software profiles individuals.
Track each applicable provision, commencement, regulator instrument and contract commitment. Record changes and have the affected proposition and dependent documents reviewed before release.
Complete AASAI assessment of your AI stack against DPDPA and existing Indian law. Delivered as a board ready legal risk report with prioritised remediation.
End to end AI governance policy suite covering ethics policy, DPIA template, vendor assessment criteria, AI risk register, and board reporting framework.
DPDPA compliant Data Processing Agreement drafting for every AI vendor and model infrastructure partner. Includes liability allocation and audit rights.
AMLEGALS represents enterprises before the Data Protection Board, SEBI, RBI, and CCI on AI related regulatory matters.
AMLEGALS analyses AI vendor contracts and generates negotiation intelligence, identifying risk clauses and compliance gaps across your vendor portfolio.
Comprehensive advisory under the AMLEGALS AI Governance Framework, from board level governance architecture to technical compliance integration across eight governance pillars.
Short, direct, on the record.
No. Section 2(i) identifies a person who alone or with others determines the purpose and means of processing. Analyse the provider, deployer and customer separately; software is not assigned that role merely because it processes data.
No. Section 3 concerns digital personal data processed in India, including data collected digitally or digitised later, and overseas processing connected with offering goods or services to Data Principals in India, subject to statutory exclusions.
Assess the data, purpose, existing consent and any applicable Section 7 certain legitimate use or exclusion. An earlier consent does not automatically authorise a different training purpose, but consent is not the only ground in Section 4.
The substantive processing duties and penalty adjudication provisions are in the eighteen-month phase after Gazette publication under G.S.R. 843(E). Distinguish enacted duties from operative duties; other applicable laws continue independently.
No. Identify the applicable legal provision or contract for each control. Internal risk tiers, model cards, committees and general AI impact assessments may be useful governance measures without being universal Indian statutory requirements.
An agreed engagement can produce a role-and-scope note, source-linked obligation map, data and vendor review, contract amendments, incident protocol and a governance action register. It does not certify every technical outcome or guarantee regulator acceptance.
DPDP Act: Sections 2(i), 2(k), 3, 4, 6–10 and 16 · Commencement notification · DPDP Rules
Sector-specific advice requires the relevant current regulator instrument and the actual activity.
The complete enterprise DPDPA compliance guide, every obligation, penalty, and phase of the compliance roadmap.
The complete penalty matrix under DPDPA Section 33. What you face if your AI system causes a data breach.
Identify who determines purposes and means, who acts on instructions, and which duties apply to each activity.
Provide the intended use, data categories, vendor arrangements and any regulatory notice for an initial scope discussion.