Three Perspectives on AI Governance: The Data Principal, the Data Fiduciary and the AI Value Chain

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:

User organisations.
Service providers and integrators.
Product companies and start-ups.
Tool and framework providers.
Cloud and infrastructure providers.
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