India's AI Governance Guidelines: what a GCC actually has to do

India has no standalone AI statute. MeitY's India AI Governance Guidelines, released 5 November 2025, govern AI through existing law (the IT Act 2000, the DPDP Act 2023, and consumer protection legislation) coordinated by a new AI Governance Group. For a GCC the practical obligations are consent provenance for training data, audit trails, and documented risk ownership.

Key takeaways

• India governs AI through existing law, not a dedicated AI Act (MeitY Guidelines, 5 Nov 2025).
• The DPDP Act 2023 constrains what customer data may train or ground a model.
• IBM IBV: 83% of Indian executives call effective governance essential; only 4% have embedded risk frameworks.
• A GCC's core obligations are consent provenance, audit trails and named risk ownership.

Freshness note: this is a regulatory page under a 90-day review cadence. Verify current MeitY and DPDP guidance before acting on it.

Does India have an AI law?

No, and that is the most important fact to get right, because a lot of vendor material implies otherwise. India has deliberately chosen not to pass a standalone AI Act. Instead, MeitY's India AI Governance Guidelines, released on 5 November 2025, govern AI through the laws that already exist: principally the Information Technology Act 2000, the Digital Personal Data Protection Act 2023, and consumer protection legislation (IAPP, November 2025).

The practical consequence for a GCC is that there is no single checklist to certify against. Your AI obligations arrive from several statutes at once, coordinated rather than consolidated, and compliance is a mapping exercise across them. That is more work than a single AI Act would be, not less, and pretending a dedicated law exists is the fastest way to miss an obligation that actually lives in data-protection or consumer law.

What the MeitY guidelines actually require

The Guidelines set direction and coordinate oversight; they do not replace the underlying statutes. For an operating GCC, the substance reduces to a small number of demonstrable capabilities: you can show where your training and grounding data came from and on what consent basis; you keep an audit trail of what your AI systems did and who decided around them; and you can name the person accountable when a system fails. Everything else is elaboration on those three.

The reason this matters is that most organisations cannot currently demonstrate any of them. IBM's Institute for Business Value found that 83% of Indian executives say effective governance is essential to successful AI, while only 4% of Indian organisations have embedded frameworks to manage AI-related risks (IBM IBV, 27 November 2025). That gap (near-universal recognition, near-absent implementation) is the exact space the Guidelines now push organisations to close. We treat that governance gap as its own subject in why so few organisations have real AI governance.

How the DPDP Act constrains AI training data

The Digital Personal Data Protection Act 2023 is where the sharpest constraints sit for a GCC, because GCCs process personal data at scale on behalf of others. The Act's principles of consent and purpose limitation mean personal data gathered for one purpose cannot simply be repurposed to train or ground a model. You need a lawful basis for the AI use specifically, and you need to be able to evidence it.

For a GCC serving overseas customers this compounds. You are typically a processor acting on a controller's instructions, so the client's contractual data terms flow down to you and often bind you more tightly than Indian law alone. The working rule is to satisfy both the DPDP Act and the client's home-jurisdiction requirements, applying whichever is stricter on any given point. "The model performs better with more data" is not a lawful basis, and a retrieval pipeline that grounds answers in personal data it had no consent to use is a DPDP exposure regardless of how good the answers are.

What a GCC's audit trail needs to contain

An audit trail that satisfies a regulator and a client answers four questions for any AI-assisted decision: what data went in, what the system produced, which human decided around it, and when. If your system cannot reconstruct those four for a given output, it is not auditable, and an unauditable AI system is a liability the moment anyone asks about a specific decision.

| Element | What to capture | Why |
|---|---|---|
| Input provenance | Source and consent basis of data used | DPDP purpose limitation |
| Output record | What the system produced, versioned | Reconstruct any past decision |
| Human decision | Who reviewed or overrode, and when | Accountability cannot be delegated to a model |
| Model/version | Which model and prompt produced it | Behaviour changes with versions |

This is the same audit surface a production evaluation harness already generates, which is why governance and engineering are not separate projects. Build the harness and much of the audit trail comes with it.

Who signs off: mapping the AIGG structure to your org

Because oversight is coordinated across existing regulators through the AI Governance Group rather than centralised in one AI regulator, accountability inside your organisation has to be equally explicit. Name, in writing, who owns AI risk for each deployed system; who approves the data a system may use; and who has authority to switch a system off. Diffuse ownership is the failure mode the Guidelines are designed against, and it is the practical meaning of the 4% figure: most organisations recognise the need and have nobody actually holding the risk.

A governance framework you can stand up in 90 days

You do not need a year. A workable AI governance framework has five components, and they can be assembled in a quarter: a written policy set defining who may deploy what, on which data; a model register listing every AI system in use with its owner and data boundary; an evaluation harness scoring the systems that matter; a documented escalation path with a named owner per system; and a review cadence, 90 days for anything touching regulated data. Standing this up and maintaining it is precisely what a governance and CoE retainer exists to do.

What this means for a GCC transformation owner

Governance is usually treated as the brake on AI adoption. Under India's approach it is closer to the enabling condition, because the obligations attach whether or not you have a framework: the only question is whether you can demonstrate compliance when asked. The GCCs that will move fastest on AI are the ones that can say yes to a client's data-governance due-diligence in one meeting rather than three months.

Start the framework alongside the first workflow, not after it. Retrofitting audit trails and consent provenance onto a system already in production is far more expensive than building them in, and it is the version of this work that stalls at the production gate.

Sources

1. IAPP, India releases DPDPA rules and AI Governance Guidelines, November 2025. https://iapp.org/news/a/notes-from-the-asia-pacific-region-india-releases-dpdpa-rules-ai-governance-guidelines
2. IBM Institute for Business Value, AI Infrastructure That Endures (India), 27 November 2025. https://in.newsroom.ibm.com/2025-11-27-83-of-Indian-executives-say-effective-governance-is-key-to-successful-AI-infrastructure

Related reading: what an AI governance framework contains · what a global capability centre is · the AI governance and CoE retainer