Two conversations happen about AI governance in Indian enterprises, and they use different vocabularies.
Your risk and audit function names frameworks: ISO 42001, NIST AI RMF, the EU AI Act. Your regulator names obligations: the DPDP Act, outsourcing directions, data localisation, audit rights. The frameworks are useful structure. The obligations are what will actually stop a deployment.
The frameworks, and what each is for
ISO/IEC 42001
A management-system standard for AI — the same shape as ISO 27001, applied to AI systems. It gives you the governance structure: roles, risk assessment, documented controls, review cycles.
It is worth designing against long before it is worth certifying to. The structure is governance you need regardless; the certificate is a signal you buy when a contract or tender asks for it.
NIST AI Risk Management Framework
Voluntary, American, and the most practically useful of the three because it is organised around doing rather than around auditing. Its govern-map-measure-manage cycle translates cleanly into engineering work: what could go wrong, how would we know, what do we do when it does.
The EU AI Act
Binding only if you place a system on the EU market — but if you serve European customers, its risk tiering decides your obligations. Systems touching creditworthiness, employment or essential services fall into the high-risk tier, which brings documentation, human oversight and logging requirements that are expensive to retrofit.
What actually binds an Indian enterprise
None of the above is Indian law. These are:
The DPDP Act 2023
The constraint most likely to reshape an architecture. Consent is purpose-bound: data collected to service a loan is not automatically available to train a model on. Consent is withdrawable, which means training corpora need to be traceable to their consent basis — a withdrawal you cannot honour is a problem you built.
It also brings breach notification and a data principal's right to correction, both of which are harder when part of your system is a model rather than a database row.
Your regulator's outsourcing directions
For banks and NBFCs, RBI's outsourcing framework governs what a third party may do with your data, where it may be processed, and what audit rights you must retain. It applies to an AI vendor exactly as it applies to any other service provider — which surprises teams who treated a model API as infrastructure rather than as outsourcing.
SEBI's cybersecurity and resilience framework and IRDAI's requirements for insurers work similarly: different text, same practical effect on architecture.
Data localisation
Payment data must be stored in India under RBI's directive. That decides, before any technical discussion, whether a hosted model API is usable for a given workflow — and often means the sensitive majority of processing runs on self-hosted models inside your own environment, with the remainder routed out under a zero-retention agreement.
What governance looks like in engineering terms
Frameworks describe outcomes. These are the artefacts that produce them:
- A data boundary, written down. What leaves the environment, what never can, what is redacted or tokenised in between. This is the first design decision, not a review item.
- An action allowlist. The agent or system may call these operations, with these parameters, as this identity. A general-purpose credential plus a prompt asking for care is not a control.
- A scored evaluation set that runs on every model, prompt or retrieval change, gating releases the way tests gate a deploy. Without it, quality drift is invisible until a user complains.
- A reconstructable event log: input, retrieved context, model and prompt version, tool calls, output, confidence, human review. The test is whether a decision from eleven months ago can be reproduced, not whether it was recorded.
- A human lane with a threshold that is a business parameter rather than a constant buried in code.
- A named owner. Every framework asks who is accountable. In most organisations the honest answer at the start is nobody, and naming someone is the cheapest governance improvement available.
The sequencing that survives a security review
Governance retrofitted onto a working pilot is the most expensive way to arrive at the same place. The order that works:
- Establish the data boundary before choosing a model.
- Build the evaluation set from real questions during discovery, before the system exists.
- Design the log for reconstruction, not for debugging — they are different schemas.
- Get the security review early, on the architecture, while changing it is cheap.
- Then optimise accuracy, which is the part everyone wants to start with.
Why this decides whether a pilot ships
Industry surveys of enterprise agent programmes consistently rank security, compliance and integration above model quality as barriers to deployment, and analyst commentary through 2026 has repeatedly warned that a large share of agentic projects will be cancelled for cost and risk-control reasons rather than technical failure.
That matches what we see. The pilots that stall rarely stall because the model was not good enough. They stall because nobody could answer what happens to the data, who is accountable, and how a decision would be explained to a regulator — and those three questions have engineering answers that are cheap at the start and expensive at the end.