Naavi.org

We seem to be entering an inflexion point on AI regulation in India with multiple agencies holding out their own perspectives on What is the AI liability, AI Governance and AI Audit with DSCI, FDPPI and CERT In expressing their own views throguh different documents.

While at first glance they may appear to be overlapping, on deeper examination, it appears that each has a distict role to play.

FDPPI’s rights-centric approach, CERT-In’s organisation-centric security approach and DSCI’s value-chain approach need to be understood together and this article tries to address this.

Naavi

---

Artificial Intelligence governance in India is developing rapidly. Several institutions have begun addressing the risks arising from AI, but they do not necessarily approach the subject from the same starting point.

A comparison of the approaches adopted by the Foundation of Data Protection Professionals in India (FDPPI), through DGPSI, DGPSI-AI and AIGSI; CERT-In, through its AI Security Auditing Guidelines of November 2026; and the Data Security Council of India (DSCI), through its October 2026 AI Liability: Industry Guidance for Agentic AI, reveals three distinct perspectives.

These differences are not merely differences in terminology or the selection of controls. They reflect different answers to a fundamental question:

Whose interests should AI governance primarily protect, and against whom should accountability be established?

FDPPI’s approach begins with the individual whose rights are affected; CERT-In’s approach begins with the organisation whose AI systems must be secured and audited; and DSCI’s recent guidance begins with the actors in the AI value chain and the allocation of responsibility among them.

All three perspectives have value. But they should not be mistaken for substitutes for one another.

1. FDPPI: The Data Principal is the starting point

The DGPSI framework developed by Naavi and adopted by FDPPI as a framework for DPDPA compliance is founded on the obligations of the Data Fiduciary towards the Data Principal.

The Digital Personal Data Protection Act, 2023, places obligations on the Data Fiduciary in relation to the processing of personal data. The Data Fiduciary cannot avoid its statutory obligations merely because it engages a Data Processor to perform the processing.

The central question in DGPSI is therefore not simply whether the organisation has protected its information assets. It is whether the organisation has established a governance system that enables it to discharge its obligations towards the individual whose personal data it processes.

This is a significant philosophical distinction.

A security breach may be an organisational incident. But a personal data breach is also an event that can affect the rights and interests of individuals. The governance system must recognise both dimensions.

DGPSI translates this rights-based obligation into implementable governance requirements, management responsibilities, measurable implementation specifications and audit evidence.

Extension into AI: DGPSI-AI

When a Data Fiduciary deploys AI for processing personal data, the accountability does not disappear merely because the processing is performed by an algorithm.

DGPSI-AI extends the same philosophy to AI deployment.

It asks questions such as:

• Why is AI being used for a particular process?
• Has the Data Fiduciary evaluated the risks arising from the use of AI?
• Does the Data Fiduciary understand the AI system it has adopted?
• Has the developer disclosed the manner in which the AI system operates?
• Who is the designated human handler accountable for the AI process?
• Can the Data Fiduciary explain the consequences of the AI system’s use to the affected Data Principal?
• Are appropriate safeguards available against unexpected or harmful AI behaviour?

The underlying proposition is that the deployment of AI does not dilute the accountability of the Data Fiduciary.

The AI developer may have designed the algorithm, and the Data Processor may operate the system, but the Data Fiduciary remains responsible for the obligations imposed on it by the DPDPA.

AIGSI: Extending protection beyond personal data

The AI Governance Standard of India (AIGSI) extends the philosophy further.

AI can cause harm even where the affected person is not necessarily a Data Principal of the organisation deploying the system. AI-generated misinformation, manipulation, unfair decisions, physical harm and societal consequences may not always fit within the conventional boundaries of personal data protection.

AIGSI therefore recognises a wider human and societal interest.

Its principles include:

• Unknown Risk is a Significant Risk.
• Behind every AI algorithm there shall be one human accountable for it.
• Explainability by Design.
• Justified Use, Not Default Use.
• Guardrails against Dark Patterns, Neurological Manipulation and Harm.
• Fiduciary Responsibility to Society.

The important evolution is from the protection of the Data Principal to the protection of human beings and society affected by AI.

DGPSI begins with the rights of the Data Principal. DGPSI-AI extends those rights into AI deployment. AIGSI expands the accountability horizon to include wider human and societal interests.

2. CERT-In: The organisation and its security assurance perspective

The CERT-In AI Security Auditing Guidelines, Version 1.0, dated 4 November 2026, approach AI governance from a different direction.

The framework is primarily concerned with establishing whether AI systems are secure, reliable, auditable and appropriately controlled.

Its orientation can be understood through the traditional information security model of the CIA triad:

• Confidentiality: Preventing unauthorised access to information and AI assets.
• Integrity: Ensuring that data, models, processes and outputs are not improperly altered or manipulated.
• Availability: Ensuring that AI systems and supporting infrastructure remain available and resilient.

The organisation deploying or providing the AI system is the immediate subject of the audit. Its governance arrangements, risk assessments, technical safeguards, testing processes, monitoring mechanisms and remediation capabilities are examined.

This resembles the organisational orientation of an Information Security Management System (ISMS). The organisation identifies its information security risks and establishes policies, controls, responsibilities and assurance mechanisms to manage those risks.

CERT-In’s AI guidelines take this approach into the AI environment through risk classification, audit planning, technical testing, evidence collection and remediation.

The guidelines also go beyond the narrow CIA model. They address fairness, transparency, human oversight, safety and other responsible AI considerations. It would therefore be inaccurate to describe CERT-In as concerned only with protecting the organisation.

Nevertheless, its primary operational perspective is that of the organisation responsible for the AI system and the assurance of its security and responsible operation.

The distinction is important.

An organisation may successfully protect its AI model against unauthorised access, manipulation and service disruption and still deploy that model in a manner that unfairly affects an individual.

Similarly, a system may pass technical security testing but use personal data in a manner that does not meet the requirements of the DPDPA.

Security assurance is necessary, but it does not automatically establish that the rights of affected individuals have been protected.

CERT-In asks whether the organisation has adequately secured and controlled its AI system. DGPSI asks whether the organisation has adequately protected the Data Principal while using that system.

These are complementary questions.

3. DSCI: A third perspective — accountability across the AI value chain

The DSCI publication of October 2026, AI Liability: Industry Guidance for Agentic AI, introduces another important dimension.

The document addresses the question of who should bear responsibility when an autonomous AI agent acts and causes harm.

Rather than proposing an entirely new liability regime, it examines how established legal doctrines may apply to autonomous and multi-vendor AI systems.

The guidance considers the different participants who contribute to bringing AI into use, including:

1. User organisations.
2. Service providers and integrators.
3. Product companies and start-ups.
4. Tool and framework providers.
5. Cloud and infrastructure providers.
6. Model providers.

The DSCI approach recognises that responsibility cannot always be assigned through a simple distinction between the enterprise deploying AI and the developer creating it.

The allocation of responsibility may depend on several factors, including:

• Who designed and developed the AI system?
• Who controls the model and its hosting environment?
• Who configures the agent and defines its permissions?
• Who determines the decision space within which the agent operates?
• Who supplies the data and tools?
• Who exercises operational control?
• Who had the ability to prevent or mitigate the harm?

An important insight in the DSCI guidance is that hosting architecture and control over the AI system can materially influence the allocation of responsibility.

For example, an enterprise that exercises extensive architectural control over an AI agent, configures its permissions, integrates it into business processes and allows it to act autonomously may not be able to avoid responsibility merely by arguing that the underlying model was supplied by a third party.

This is a useful contribution to the AI liability debate.

Is DSCI Data Fiduciary-centric or Data Principal-centric?

In our assessment, the recent DSCI guidance is neither fundamentally Data Fiduciary-centric nor Data Principal-centric.

Its principal concern is the allocation of responsibility across the AI value chain.

The individual affected by the AI system is relevant because there may be harm requiring legal accountability. The enterprise deploying AI is relevant because it controls the deployment environment. The developer is relevant because it controls aspects of system design and functionality.

However, the document’s organising principle is not the rights of the affected individual or the statutory obligations of the Data Fiduciary.

It is the relationship between the actor, the decision made by that actor, the degree of control exercised and the resulting responsibility.

This makes the DSCI approach value-chain-centric and control-centric.

It has a strong developer and provider dimension because developers, model providers, hosting providers and integrators exercise important forms of control over AI architecture and behaviour. But it also recognises that the user organisation may become the principal bearer of responsibility when it controls the deployment and the agent’s operational decision space.

There is, however, an interesting historical continuity in DSCI’s work. Its earlier 2021 Handbook on Data Protection and Privacy for Developers of Artificial Intelligence in India explicitly adopted a practitioner-centric approach, with AI developers and solution architects as its principal audience. The 2026 liability guidance broadens that focus to the entire AI value chain.

The two documents should not be confused, but they help explain DSCI’s sustained interest in the responsibilities of those who build and supply AI technology.

4. Comparing the three approaches

The following comparison captures the fundamental difference.

Dimension	FDPPI: DGPSI / DGPSI-AI / AIGSI	CERT-In	DSCI
Starting point	Rights of the Data Principal and wider human interests	Security and assurance of the organisation’s AI systems	Actors in the AI value chain
Primary concern	Protection of individuals and society	Security, integrity, availability, resilience and responsible operation	Allocation of responsibility and liability
Principal accountability question	Has the Data Fiduciary and other responsible actors discharged their obligations?	Has the organisation implemented adequate controls and demonstrated assurance?	Which actor controlled the relevant decision or action, and who should bear responsibility?
Main orientation	Rights-centric and human-centric	Organisation-centric and security-assurance-centric	Value-chain-centric and control-centric
Developer’s role	Accountable for developer-side obligations and commitments	Subject to relevant security and audit requirements	Important participant whose design, hosting and control decisions influence liability
Deployer’s role	Data Fiduciary accountability and protection of affected persons	AI system owner or auditee responsible for controls	User organisation whose deployment decisions and control may attract responsibility
Individual’s position	Central beneficiary of the governance system	One of the stakeholders whose interests are protected through responsible and secure operation	Affected party whose harm is relevant to liability allocation

The comparison is about the dominant perspective, not an assertion that any one framework ignores the other concerns.

5. An example: An AI agent that rejects a bank customer’s loan application

Consider a bank deploying an AI agent to evaluate loan applications, access customer records, obtain external information and recommend or execute decisions within specified limits.

The three approaches would examine the same system differently.

DGPSI-AI / AIGSI examination

The questions would include:

• Was the customer’s personal data collected and processed lawfully?
• Was the use of AI justified?
• Was the customer informed appropriately?
• Could the AI system produce unfair or harmful outcomes?
• Was a human handler designated?
• Can the customer seek an explanation or exercise applicable rights?
• Has the bank considered the wider societal consequences of the use of AI?

The focus is on the Data Principal and the human consequences of the AI deployment.

CERT-In examination

The questions would include:

• Can the agent be manipulated through malicious prompts?
• Can it access unauthorised customer records?
• Can an attacker alter the model, data or decision process?
• Are its tools and APIs appropriately secured?
• Is its behaviour monitored for anomalies?
• Can the bank detect and respond to a security incident?
• Is the system resilient and auditable?

The focus is on the bank’s ability to secure and control the AI system.

DSCI examination

The questions would include:

• Who developed the agent?
• Who supplied the underlying model?
• Who integrated it with the bank’s systems?
• Who configured the agent’s permissions?
• Who controls its hosting and operational architecture?
• Who authorised the agent to make or execute decisions?
• Which actor could reasonably have prevented the harmful action?

The focus is on allocating responsibility across the actors involved.

The three examinations may identify different failures in the same incident. A single harmful loan decision could involve a failure of data protection, a failure of technical security and a failure of deployment governance. The fact that one actor is responsible for one failure does not automatically absolve the others of their respective obligations.

6. What does this mean for Indian AI governance?

It may not be necessary for India to  reduce AI governance to a single audit framework or a single liability model.

The three approaches serve different purposes.

First, a rights-centric foundation is necessary.

An AI system is not trustworthy merely because it is secure or technically reliable. It must also respect the rights and interests of the people affected by its use.

The DPDPA provides a statutory foundation for the obligations of the Data Fiduciary in personal data processing. DGPSI operationalises those obligations, while DGPSI-AI and AIGSI extend the governance framework into AI deployment and wider human consequences.

Second, organisational security assurance is indispensable.

The rights of individuals cannot be protected if the AI systems processing their data are vulnerable to manipulation, unauthorised access, disruption or compromise.

CERT-In’s guidelines offer a valuable technical audit and assurance reference. They can strengthen the security and resilience dimension of AI governance.

Third, the AI value chain must be made accountable.

An enterprise may deploy an AI system developed by another entity, hosted by a cloud provider, integrated by a service provider and connected to third-party tools.

Responsibility cannot be determined merely by identifying the organisation that purchased the software. The actual roles, decisions, control and applicable legal obligations must be examined.

DSCI’s guidance makes a useful contribution here.

However, value-chain allocation should not be used to dilute statutory accountability towards an affected individual. Under the DPDPA, a Data Fiduciary cannot contract away its statutory obligations simply because another participant developed or operated the AI system.

There is a distinction between the Data Fiduciary’s statutory accountability and the allocation of contractual, technical or other legal responsibility among the participants. Both must be examined independently.

7. A proposed integrated architecture

The three approaches can be brought together in a practical governance architecture.

Governance layer	Framework	Purpose
Human and rights protection	AIGSI	Ensure responsible AI use and protection of individuals and society
Personal data protection	DGPSI / DGPSI-AI	Ensure Data Principal rights and Data Fiduciary accountability
Technical security assurance	CERT-In AI Security Auditing Guidelines	Test security, resilience, vulnerabilities and technical controls
Value-chain accountability	DSCI AI Liability Guidance	Identify responsibility based on roles, decisions, architecture and control

This should not be understood as a rigid hierarchy in which one framework supersedes another. It is a functional architecture in which each framework addresses a different governance question.

An organisation adopting AI should ideally maintain a common AI inventory, an impact and risk assessment, a responsibility matrix, developer and supplier assurance records, a security audit trail, a human accountability structure and a mechanism for addressing harm to affected individuals.

The governance system should connect these elements rather than operate them as isolated compliance exercises.

8. The fundamental question: Is AI governance about protecting the organisation or protecting humanity?

The emergence of AI creates a temptation to treat governance primarily as a method of protecting organisations against liability, cyberattacks, regulatory action and operational disruption.

These are legitimate concerns. But they cannot be the ultimate objective of AI governance.

An organisation may successfully defend itself against a cyberattack and still use AI in a manner that harms people. It may comply with security audit requirements and still fail to respect the rights of a Data Principal. It may distribute contractual liability among its vendors and still remain accountable for its own decisions.

The starting point matters.

FDPPI’s DGPSI philosophy begins with the rights of the Data Principal. Its extension through DGPSI-AI and AIGSI recognises that the consequences of AI extend beyond the conventional boundaries of data protection.

CERT-In contributes the essential discipline of organisational security assurance.

DSCI contributes an important method for examining the distribution of responsibility across the AI value chain.

These approaches should converge, but their different starting points should not be erased.

The ultimate purpose of AI governance should not be merely to ensure that an organisation is protected from the risks of AI. It should be to ensure that human beings are protected from the risks arising from the organisation’s use of AI.

That is the distinction between an organisation protecting itself and an organisation accepting responsibility for the consequences of its technology.

And that, in my view, is the foundation on which a genuinely human-centric Indian AI governance architecture should be built.

Naavi

References:

1. DGPSI – Data Governance and Protection Standard of India
2. AI Governance Standard of India (AIGSI)
3. CERT-In, Artificial Intelligence (AI) Security Auditing Guidelines, Version 1.0, 4 November 2026.
4. DSCI – AI Liability: Industry Guidance for Agentic AI, 28 October 2026
5. DSCI – Handbook on Data Protection and Privacy for Developers of AI in India, 2021

 

The objective of AI Audit under DPDPA may be derived from

a) Reasonable Security obligations under Rule number 6

b) Additional responsibilities of a Significant Data Fiduciary under Rule number 13

The concern of DPDPA related to AI is to ensure that if it is used for processing personal data, then the risk of harm caused to the data principal by the use of AI should be recognized and mitigated.

In the case of Significant Data Fiduciaries (SDF),  the SDF shall observe due diligence to verify that technical measures including algorithmic software adopted by it for hosting, display, uploading, modification, publishing, transmission, storage, updating or sharing of personal data processed by it are not likely to pose a risk to the rights of Data Principals [Rule number 13 (3)].

Under DGPSI as a compliance framework, AI Risk is considered an “Unknown Risk” and therefore is a “Significant Risk”. Hence the mere use of AI either by a data fiduciary or any of its data processors itself shall render it a SDF.

In view of the Rule 13(3), it is necessaryy for an SDF using AI to verify on its own the AI algorithm and ensure protection of Data Principal rights by exercising “Due Diligence”.  Such due diligence includes

“Assessing that the AI Algorithm processes personal data for a lawful purpose and with either a specific consent or under legitimate use.”

“Ensuring that no cross border transfer of data is permitted without permission”

“Ensuring that any personal data breach which includes impermissible use of personal data is recognized and notified”

“Ensuring that the processing of data of minors is recognized and flagged for consent by the verified guardian and reversed after the minoir attains majority”.

“Ensuring that the processing of data of a mentally disabled person is recognized and flagged for consent by a legal guardian”

“Ensuring that the death of a data principal is recognized and action taken to give effect to the nmomination if any”

“Ensuring that withdrawal of consent or expirty of the purpose is recognized so that data retention is within the legally permitted time limits”

“Ensuring that whenever personal data is required to be archived or disclosed under  any legal obligation, the need is recognized and given effect to.”

” Ensuring that if the use of personal data for AI learning is not permitted,  it is not used for machine learning”

” Ensuring that the the processing of personal data by AI is without any discrimination and bias”

“Ensuring that the output of the processing results in accurate and reliable data output”

” Ensuring that evidence of processing as may be required under law is preserved”.

” Ensuring that there is adequate transparency and explainability in the processing of Personal data by the AI which gets reflected in the summary of processing provided when a data principal exercises his right to access”

The FDPPI approach in DGPSI-AI is to ensure the above assurances.  Even the AIGSI which extends to the developer of the AI algorithm and the intermediaries involved in bringing the AI algorithm from the  foundation model developer to the end user data fiduciary, the underlying objective is legal compliance under DPDPA 2023.

In comparison, CERT In AI audit guidelines focus on information security in general and recognizes Privacy and Data Security as one of the 9 different governance domains.  AIGSI also focusses on guardrails, prevention of hallucination etc which need to be the basis of audits which is also recognized by the CERT In.

However the assessment of risk under AIGSI and CERT In may still differ like the objectives of an ISMS audit and DPDPA audit. The CERT In risk assessment is from the perspective of the organization while the DPDPA perspective is always from the perspective of the data principal.

Naavi

….Continued

CERT In which is a quasi judicial authority and the regulator under ITA 2000 is the nodal agency for Cyber Security in India. Under ITA 2000 it regulates organizations processing both personal data and non personal data under the provisions of ITA 2000. It is the authority to which information security data breaches under ITA 2000 are to be reported. After DPDPA 2023 was enacted, the Data Protection Board (DPB) under DPDPA 2023 became the regulator designated for Personal Data Breach. Currently therefore there is an overlapping of the functions of CERT-IN and DPB in respect of Personal data breach which needs to be reported both to the CERT In and DPB besides the data principals.

CERT In has issued several infoprmation security guidelines earlier and more recently on 25th May 2026, CERT In had released the “Blue Print for defending against AI assisted Vulnerabilities” using AI. This has been discussed earlier in Naavi.org. It provide a structured framework covering Governance and accountability mechanisms for AI assisted Vulnerability management and related issues. It was meant to improve organizational understanding of AI assisted cyber threats and recommended core defensive principles. It also suggested Cybersecurity Governance and Operational reaadiness requirments, Technical defensive Controls etc. This was basically a guidline on Cyber Security and how AI needs to be used to meet the emerging security threats.

On 4th November 2026, CERT In issued a fresh guideline called “Artificial Intelligence security auditing guidelines”. These guidelines  establish a comprehensive, risk-based framework for auditing the security, governance and responsible operation of Artificial Intelligence systems throughout their life cycle.

This framework is taking is aligned with standards and frameworks such as the CER-In guideline of May 25th on AI assisted vulnerability management, Meity”s AI related guidline as well as ISO 42001, ISO 27001 etc.

This framework is not designed for DPDPA but can be used partially as a guideline for AI algorithmic audit which is a necessity under DPDPA 2023. The DPDPA related AI audit is required to look at the impact of the AI algorithm in the personal data processing scenario. Within this requirement, the security related audit may be performed using this framework.

The framework is built on a four tier risk classification system (Low, Moderate, High and Critical). Nine different audit domains have been identified. Dedicated audit provisions for large language models, Generative AI, RAG, Agentic AI, Multimodal AI, Multi-Agent AI
and Autonomous/Cyber-Physical AI, addressing prompt injection, hallucination etc are also identified as “requirements”. IT also covers the audit planning, scoping etc.

It adopts the Meity”s AI Governance guiding principles including

i. Security-by-Design
ii. Accountability and Human Oversight
iii. Transparency and Explainability
iv. Fairness and Bias Management
v. Data Security and Privacy
vi. Auditability and Traceability
vii. Resilience and Continuous Assurance

Following Risk assessment factors have been mentioned in the framework

F1: Impact Severeity

F2: Autonomy and Actionability

F3: Data Sensitivity

F4: Scale and Exposure

F5:Reversibility and Recoverability

F6: Operational/Sectoral Criticality

F7: Adversarial Exposure

F8: Complexity and Auditability

On each of the above factors the risks are suggested to beassessed as Low, Moderate, High and Critical so that the overall system can be fit into one of the four risk tiers.

Guiding principles for Responsible AI Governance include Security by Design, Accountability and Human oversight, Transparency and Explainability, Fairness and Bias Management, Data Security and Privacy, Auditability and Traceability, Resilience and Continuas Assurance. These are like 7 specifications similar to the DGPSI-AI implementation specifications.

The document provides useful Auditor checklists and also outlines the recommended audit methodology.

Findings are classified and the note lists the remediation requirements with examples.

Overall this is a very useful document that requires a more detailed study. A combination of AIGSI, DGPSI-AI and CERT In AI Audit guidance could be a useful document that can provide a comprehensive guidance on AI Governance and Audit for both DPDPA purpose and otherwise.

Naavi

An audio review

In Continuation of the earlier article on the emerging AI Guidelines 

Out of the nine AI-related guidelines identified in our earlier discussion, seven have already been examined on Naavi.org. We may revisit these documents at a later stage. For now, let us focus on the two new guidelines that deserve particular attention.

Let us examine the DSCI document and compare its approach with the philosophy adopted by DGPSI-AI.

1. Understanding the DSCI Discussion Paper on AI Liability

The DSCI document is titled “Discussion Paper on AI Liability: Industry Guidance for Agentic AI.” Its declared objective is to examine how existing legal principles and doctrines can be applied to emerging Agentic AI systems.

The document explains its purpose in the following words:

“This guidance is an attempt of providing an actionable framework to map established legal doctrines. It tries to bring together the realities of agentic systems, identifying where responsibility could shift and diffuse.”

The guidance identifies five groups of stakeholders whose involvement may contribute to an AI-related outcome resulting in liability:

1. 1. User organisations operating AI agents.
   2. Service providers and integrators operating AI-enabled workflows.
   3. Product companies and start-ups incorporating Agentic AI capabilities.
   4. Tool and framework providers whose resources are harnessed by AI agents.
   5. Cloud and infrastructure providers supporting AI agentic systems.

The Model Provider may also be considered a sixth element in the value chain.

The underlying philosophy of the guidance is that “framing AI liability as a choice between the end-user organisation and an upstream technology provider would be legally flawed, technically inaccurate, commercially paralysing and detrimental to maintaining a level playing field”.

Instead, the guidance advocates mapping responsibilities across the entire AI value chain.

It also argues:

“The AI models neither have operational context nor capacity to act, unless someone brings them to the enterprise environment. They provide the probabilistic intelligence. Primary focus of this guidance is therefore dedicated to the five groups.”

This is an important observation. An AI model, by itself, does not operate in an organisational environment. Its capabilities are brought into an operational context by other participants in the value chain.

However, an important question arises:

Does mapping responsibility across the AI value chain necessarily mean that the legal accountability of the AI deployer should be diluted?

We believe this is where the DSCI approach requires closer examination.

2. DGPSI-AI: Liability Must Begin with the AI Deployer

DGPSI-AI starts with a fundamental proposition: an organisation deploying an AI system must remain accountable for the consequences of its deployment, particularly when it is a Data Fiduciary under the Digital Personal Data Protection Act, 2023.

The DPDPA places statutory obligations on the Data Fiduciary even when personal data processing is undertaken through a Data Processor.

The Data Fiduciary cannot transfer its statutory obligations to a technology provider merely through a contractual arrangement.

The accountability of the Data Fiduciary towards the Data Principal is a statutory obligation and cannot be diluted by the complexity of the AI value chain.

There is, however, an important distinction between the regulatory accountability of the Data Fiduciary under the DPDPA and the personal remedies available to an affected individual.

The DPDPA establishes a regulatory enforcement framework, including adjudication of contraventions and imposition of penalties. It does not provide a general individual compensation mechanism for every loss suffered by a Data Principal.

For personal remedies, other applicable laws, including the Information Technology Act, 2000, may become relevant.

This distinction is fundamental to understanding the DGPSI-AI approach.

3. Section 11 of ITA 2000: Attribution of AI-Generated Electronic Records

Section 11 of the Information Technology Act, 2000 deals with the attribution of electronic records.

It recognises that an electronic record may be attributed to its originator when it is sent by an information system programmed by or on behalf of that originator to operate automatically.

This provision assumes considerable significance in the context of Agentic AI.

An AI agent may independently generate a recommendation, approval, rejection, instruction, communication or other decision output without direct human intervention at the time of generation.

Where such output constitutes an electronic record, the principles of attribution under Section 11 become relevant.

The fact that an output is generated autonomously by an algorithm should not, by itself, make the electronic record legally unattributable.

If an organisation deploys an AI agent, authorises its functions and permits it to generate electronic communications or instructions on its behalf, there is a strong basis for examining the attribution of those records to the organisation.

There is a distinction between attribution and liability. Section 11 identifies the legally relevant originator in the circumstances covered by the provision. The substantive liability arising from the electronic record or its consequences must still be established under the applicable law.

Nevertheless, the principle is important.

An AI agent cannot become a legal shield behind which the deployer avoids responsibility merely because the output was generated autonomously.

Section 11 provides an important statutory foundation for this interpretation, although its precise application to different types of AI-generated decisions may require judicial clarification.

4. Section 43 and Section 46: Personal Remedies for AI-Related Data Breaches

The relationship between Sections 43 and 46 of the ITA 2000 is particularly important in the context of AI-related data breaches.

Section 43 identifies specified unauthorised acts involving computer resources and provides for compensation to persons affected by such acts.

Section 46 provides the adjudication mechanism for determining contraventions and compensation claims falling within its jurisdiction.

Thus, Section 43 identifies the actionable conduct and Section 46 provides the mechanism through which the claim can be adjudicated.

A data breach that also results in regulatory consequences under the DPDPA may independently attract examination under Section 43 of the ITA 2000.

However, every DPDPA violation does not automatically constitute a Section 43 violation. The ingredients of the relevant clause of Section 43 must independently be satisfied.

This distinction is important.

The DPDPA determines the statutory accountability of the Data Fiduciary for personal data processing. The ITA 2000 may provide a separate route for personal compensation where the facts satisfy its requirements.

The significance of Section 43(g)

Section 43(g) deals with providing assistance to facilitate unauthorised access to a computer resource.

An important judicial interpretation of this provision is found in S. Umashankar v. ICICI Bank, decided by the Telecom Disputes Settlement and Appellate Tribunal (TDSAT).

In this case, the question arose whether negligence in maintaining security arrangements could amount to assistance in facilitating unauthorised access.

The Tribunal adopted an interpretation that recognised that assistance need not necessarily involve an affirmative act. An omission arising from negligence could also amount to assistance in appropriate circumstances.

The Tribunal illustrated this through the example of a watchman who facilitates theft by negligently remaining absent from duty or switching off the security light.

This interpretation is significant for AI governance.

Consider an organisation that deploys an AI system with access to personal data and other computer resources.

If the organisation fails to implement appropriate access controls, grants excessive privileges to an AI agent, neglects known vulnerabilities or fails to monitor the agent’s activities, and such failures facilitate unauthorised access, Section 43(g) may become relevant.

The question would not merely be whether the AI algorithm was defective.

It would also be whether the deployer, through its own acts or omissions, facilitated unauthorised access.

The Umashankar judgment therefore provides an important legal basis for examining negligence in the context of Section 43(g).

The significance of Section 43(i)

Section 43(i) addresses destroying, deleting or altering information residing in a computer resource, or diminishing its value or utility or affecting it injuriously by any means.

This provision is also relevant to Agentic AI.

An autonomous AI agent may be authorised to modify, delete, reorganise or process information.

If it undertakes an unauthorised alteration or deletion of information, the consequences may need to be examined under Section 43(i).

For example, an AI agent operating in a banking environment may delete transaction records, alter customer information or modify information residing in a computer resource beyond its authorised scope.

If the statutory ingredients are satisfied, the fact that the action was performed autonomously by an AI algorithm does not necessarily remove the possibility of liability.

The attribution of the action, the authority under which the system operated and the conduct of the deployer would all become relevant.

Thus, Sections 43(g) and 43(i) offer two different but potentially important routes for examining AI-related security failures and unauthorised data operations.

Negligence and reasonable security practices after the repeal of Section 43A

Section 43A of the ITA 2000 specifically addressed compensation arising from negligence in implementing and maintaining reasonable security practices and procedures while handling sensitive personal data or information.

However, Section 44(2) of the DPDPA provides for the omission of Section 43A, which becomes effective on 13 May 2027 under the notified commencement schedule.

Does this mean that negligence and reasonable security practices will cease to have relevance under the ITA 2000 after that date?

We believe that such a conclusion would be incorrect.

Section 43A is a specific provision dealing with negligence in the context of sensitive personal data and information. Section 43 contains separate provisions addressing unauthorised acts involving computer resources.

The interpretation adopted by TDSAT in the Umashankar case demonstrates that negligence may be relevant to establishing assistance under Section 43(g), where the necessary connection with unauthorised access is established.

Therefore, the repeal of Section 43A does not automatically eliminate the relevance of negligence, due diligence and reasonable security practices when examining conduct independently falling within Section 43.

It is important, however, not to equate every failure to maintain reasonable security practices with a violation of Section 43. The specific ingredients of the relevant clause must still be established.

The important point is that the legal relevance of due diligence and reasonable security practices is not confined exclusively to Section 43A.

This has significant implications for DGPSI-AI.

The deployer’s due diligence in selecting, authorising, supervising and monitoring AI service providers and Data Processors is not merely a contractual governance requirement.

Depending on the facts, failures in these areas may also become relevant in determining whether the deployer has facilitated an unauthorised act under Section 43(g), or whether an unauthorised alteration or deletion has occurred under Section 43(i).

5. Section 72A: Contractual Accountability Between the Data Fiduciary and Data Processor

Section 72A of the ITA 2000 introduces another important legal dimension.

It addresses the disclosure of personal information in breach of a lawful contract, subject to the conditions specified in the provision.

In an AI value chain, the relationship between a Data Fiduciary and a Data Processor is ordinarily governed by a contract.

If a Data Processor obtains personal information while providing services under such a contract and subsequently discloses it in circumstances satisfying Section 72A, the provision may become relevant.

This creates an additional statutory consequence associated with contractual confidentiality obligations.

Section 72A does not create general liability for every contractual breach or defective AI output. Its application is confined to the conduct specified in the provision.

Nevertheless, it reinforces the importance of contractual accountability.

DGPSI-AI recognises that the relationship between successive participants in the AI value chain must be supported by appropriate contractual arrangements.

The AI deployer may have a contract with a system integrator. The integrator may have a separate contract with a product developer. The developer may have contractual relationships with model providers, tool providers and infrastructure providers.

Each relationship should establish appropriate responsibilities, warranties, indemnities, audit obligations, security requirements and remedies.

This creates a chain of enforceable obligations without requiring the affected Data Principal to investigate and pursue every upstream participant.

The affected person can seek remedies against the entity legally accountable to them, while that entity may pursue appropriate remedies against its immediate contracting party.

This is the contractual architecture advocated by DGPSI-AI.

6. The DSCI Approach versus the DGPSI-AI Approach

The DSCI guidance appears to distribute responsibility for Agentic AI outcomes across multiple participants in the value chain.

While this may be useful for identifying where a technical failure originated, it raises a fundamental question concerning the rights of the end user.

Consider a bank that deploys an Agentic AI system for processing customer transactions.

The bank may have obtained the AI solution through an integrator, who relies on a product developer, a model provider, a tool provider and a cloud infrastructure provider.

If an adverse outcome occurs, should the affected customer be required to identify the precise technical failure and pursue the entity responsible for it, even if that entity is four or five contractual layers removed from the customer?

In our view, this is impractical.

The customer has a direct relationship with the bank. The bank has chosen to deploy the AI system and has authorised the scope of its autonomous operations.

The bank’s applicable legal obligations towards the customer cannot be avoided merely because the error originated in an upstream technology component.

The bank may subsequently seek indemnification or other remedies from the relevant technology provider.

This distinction is essential.

There are three different questions:

1. 1. Who is legally accountable to the affected person?
   2. Which participant contributed to the technical or operational failure?
   3. Who should ultimately bear the financial consequences?

These questions need not have the same answer.

The DSCI guidance may be useful in addressing the second and third questions. However, it should not become a basis for diluting the deployer’s accountability towards the affected person.

7. The DGPSI-AI Human Handler: More Than a Human-in-the-Loop

Another important contribution of DGPSI-AI is its concept of the Human Handler.

Many AI governance frameworks emphasise Human-in-the-Loop arrangements. These arrangements are intended to ensure that human beings can review, approve, reject or intervene in AI-generated decisions.

Such mechanisms are important safeguards, but they do not necessarily resolve the question of legal accountability.

DGPSI-AI introduces the Human Handler as a distinct concept.

The Human Handler is not merely a person who monitors the algorithm or intervenes when something goes wrong. The Human Handler is the designated human authority who bears legal responsibility for the algorithm within the defined scope of its authorised operation.

The distinction can be summarised as follows:

Human-in-the-Loop	Human Handler
Primarily an operational safeguard	Primarily a legal accountability mechanism
Reviews or intervenes in AI decisions	Bears defined responsibility for the AI algorithm
May be involved only at selected decision points	Has continuing responsibility for the authorised deployment
Intended to reduce errors and risks	Intended to prevent an accountability vacuum
Does not automatically establish legal liability	Is designated as the person bearing legal responsibility under the DGPSI-AI governance model

The distinction is fundamental.

The Human-in-the-Loop is a guardrail. The Human Handler is the designated bearer of accountability.

DGPSI-AI therefore advocates a stronger accountability model than merely requiring a human being to participate in selected AI decisions.

The Human Handler concept must, of course, operate consistently with the statutory responsibilities of the organisation. An internal designation cannot automatically transfer the Data Fiduciary’s statutory liability to an employee.

However, it ensures that an organisation cannot treat an AI algorithm as an independent decision-making authority without an identifiable human accountability structure.

The Human Handler is not merely expected to watch the algorithm. The Human Handler is expected to take responsibility for the algorithm.

8. Agentic AI: Autonomy Cannot Become an Excuse for Avoiding Liability

Agentic AI introduces a new dimension to accountability.

Unlike conventional AI applications, an Agentic AI system may independently select tools, plan actions, interact with other systems and execute decisions within an authorised operational environment.

However, this autonomy is not self-created. It is granted by the deployer.

The organisation decides whether to use Agentic AI, what functions to delegate, what operational boundaries to establish and what safeguards to implement. Consequently, the responsibility for granting autonomy must remain with the deployer. The organisation cannot reasonably argue that the AI agent acted independently and therefore the organisation should be relieved of its legal obligations.

The doctrine of caveat emptor, or Buyer Beware, should not be used to transfer the consequences of an AI deployment to an affected person who had no role in selecting or configuring the system.

The principle advocated by DGPSI-AI is straightforward:

The entity that authorises an AI agent to act must remain accountable for that authorisation and its legally attributable consequences.

This does not prevent the deployer from establishing the responsibility of upstream technology providers or pursuing contractual remedies against them. It merely ensures that autonomy does not become a convenient means of escaping accountability.

9. The Kill Switch: DGPSI-AI Advocates an Independent Emergency Stop

The DSCI guidance also appears to adopt a different approach to intervention mechanisms.

It recommends that intervention should not be limited to a single blanket action but should operate through a hierarchy of controls.

There is merit in this proposition. Depending on the nature of the risk, an organisation may wish to restrict a particular tool, suspend a transaction, disable a workflow or stop an entire AI system. Such graduated interventions can be useful in managing complex AI deployments.

However, DGPSI-AI goes one step further.

It recommends that an AI system should have an independent Kill Switch capable of immediately halting the relevant autonomous operation when necessary.

The independence of the Kill Switch is crucial.

If the mechanism for stopping the AI system depends entirely on the same algorithm whose operation has become unsafe, the effectiveness of the safeguard may be compromised.

The emergency stop mechanism should therefore be designed to operate independently of the main AI decision-making algorithm.

A hierarchy of interventions may be useful for normal risk management, but it should not replace the availability of an independent emergency stop.

Both mechanisms can coexist.

The DSCI approach can provide graduated operational controls, while DGPSI-AI ensures the availability of a final independent intervention mechanism.

10. A Three-Layer Approach to AI Liability

The discussion brings us to a fundamental distinction that should guide the development of AI liability principles in India.

There are three separate dimensions of liability.

First: Accountability towards the affected person

This is determined by applicable statutory and other legal obligations.

Where the AI deployer is a Data Fiduciary, its obligations under the DPDPA remain with it, even when processing is undertaken by a Data Processor.

Where a compensable wrong has occurred under another applicable law, the affected person should have access to the corresponding legal remedy.

Second: Attribution and responsibility for the AI action

This involves identifying the person or organisation to whom the AI-generated action or electronic record can legally be attributed.

Section 11 of the ITA 2000 provides an important basis for examining the attribution of electronic records generated by automated information systems.

Sections 43(g) and 43(i) provide additional legal provisions for examining qualifying unauthorised access, assistance and unauthorised alteration or deletion of information.

The DGPSI-AI Human Handler concept adds a proposed layer of identifiable human accountability.

Third: Allocation of liability across the AI value chain

This concerns the respective responsibilities of the deployer, integrator, developer, model provider, tool provider and infrastructure provider.

These responsibilities may be determined through contractual obligations, indemnities, statutory duties and other applicable legal principles.

The DSCI guidance may be particularly useful in addressing this third dimension. However, the third dimension should not be permitted to undermine the first two.

11. Conclusion: AI Liability Must Not Become a Game of Passing the Buck

The DSCI Discussion Paper is a welcome contribution to the emerging debate on Agentic AI liability. Its attempt to map responsibilities across the AI value chain can assist organisations in identifying sources of risk and designing appropriate contractual and operational safeguards.

However, the legal framework must not become so complicated that the affected person is left searching for an accountable entity somewhere within a multilayered technology ecosystem. India already has important legal provisions relevant to this discussion.

Section 11 of the ITA 2000 provides a foundation for attribution of electronic records generated through automated information systems.

Sections 43(g) and 43(i) provide legal grounds for examining specified unauthorised access-related assistance and unauthorised alteration or deletion of information.

Section 46 provides the adjudication mechanism for compensation claims falling within its jurisdiction.

The Umashankar judgment demonstrates that negligence may be relevant to determining assistance under Section 43(g), where the statutory requirements are satisfied.

The repeal of Section 43A on 13 May 2027 does not automatically eliminate the relevance of due diligence and reasonable security practices under other applicable provisions of the ITA 2000.

Section 72A provides an additional statutory dimension for specified contractual disclosures of personal information.

The DPDPA establishes the statutory accountability of the Data Fiduciary for personal data processing undertaken on its behalf.

DGPSI-AI builds upon these legal foundations and proposes an accountability architecture based on:

• • The deployer’s continuing statutory accountability.
  • Attribution of AI-generated electronic records.
  • Due diligence and reasonable security practices.
  • Contractual allocation of upstream responsibilities.
  • A designated Human Handler.
  • An independent Kill Switch.

The objective is not to exempt developers, model providers or infrastructure providers from liability. Nor is it to impose every conceivable liability on the deployer irrespective of the applicable law.

The objective is to ensure that the affected person is not denied an effective remedy merely because the AI system operates through a complex value chain.

The principle that should guide Indian AI governance is therefore:

“AI autonomy cannot dilute human accountability, and the complexity of the AI value chain cannot become an excuse for denying legal remedies to the affected person.”

The DSCI guidance would become more useful if its mapping of value-chain responsibilities were explicitly aligned with this principle.

DGPSI-AI offers a possible foundation for such an approach.

We welcome alternate views and invite legal professionals, AI developers, Data Protection Professionals and Independent Data Auditors to contribute to this important discussion.

Naavi