2026-08-16 · Regulation

RBI's FREE-AI framework, read as an engineering spec

The Reserve Bank's Framework for Responsible and Ethical Enablement of Artificial Intelligence came out of a committee process with more than a hundred stakeholders, and it reads differently from most AI guidance. It is enablement-first. It does not tell regulated entities to slow down, it tells them what has to be true while they move. That is a harder brief for an engineering team than a prohibition would have been, because a prohibition needs a policy document and enablement needs working software.

The scope is wide: scheduled commercial banks, NBFCs, all-India financial institutions, payment system operators and providers. And it reaches through you to your suppliers. If your AI capability arrives via a fintech partner, a cloud vendor or a model provider, the expectation is that the principles hold across the whole lifecycle, not just the part you wrote yourself.

Seven sutras, seven artefacts #

The framework distils its ethics into seven principles: safety, transparency, accountability, fairness, inclusivity, sustainability and explainability. Here is what each one costs you in build time, stated as the thing an internal auditor can ask for.

• Safety. Deterministic limits that the model cannot argue its way past. A hard block on a category of action is a control; an instruction in a system prompt asking the model to be careful is a hope. The two look identical in a demo and diverge under pressure.
• Transparency. The customer knows they are talking to a machine, at the start, in the language of the conversation, on every channel including voice.
• Accountability. A named owner per agent, and a record that ties each conversation to the exact configuration revision that was live at the time.
• Fairness. Outcome testing across the segments your product actually serves, run on a schedule and versioned, not once before launch.
• Inclusivity. Language coverage and a fallback that does not punish the customer for it. In practice this means a handover path, not a better prompt.
• Sustainability. The one most teams skip. It is answerable with per-session token and inference accounting, which you want anyway for cost control.
• Explainability. Given a session ID, reconstruct what the agent did, which tools it called, what came back, and which rule fired. Reconstruct, not approximate.

Six of the seven resolve to the same underlying capability: a durable, tamper-evident record of every step, keyed to a config version. Build that once and most of the framework becomes a query rather than a project. We have written separately on what that record has to contain.

Human oversight that survives contact with volume #

Every AI framework asks for human oversight and almost every implementation of it is theatre. A reviewer with a queue of four thousand items and a target handle time is not oversight, they are a rubber stamp with a salary.

What makes oversight real is that the agent stops. Not flags, not logs for later review, stops and waits. That means picking the conditions where a human must decide before the action happens: a settlement outside policy bounds, a hardship declaration, a dispute over a stated amount, any request to change contact details, anything the guardrail layer scored as ambiguous. The rest runs unattended, which is the only way the reviewed set stays small enough for review to mean anything.

The second half is resumption. An agent that stops and cannot cleanly pick the conversation back up creates a worse customer outcome than one that never stopped. The handover needs to carry the full context to the human, and the return path needs to restore state without replaying side effects. Our handover desk playbook covers the mechanics.

Incident reporting when the incident is a conversation #

Existing incident machinery in a regulated entity is built for systems that are up or down. An agent incident is rarely either. It is a policy that was misread for nine days, or a tool that returned stale balances to one segment of customers, or a rule that stopped firing after a config change nobody flagged as material.

Detecting that class of failure needs three things running continuously rather than at release time:

1. Synthetic traffic. Scripted conversations that assert on outcomes, running against production configuration on a schedule. This is the only mechanism that catches silent degradation before a customer does. See the synthetics and red-team playbook.
2. A blast radius query. When something is found, the first question is how many customers were affected and which ones. If the answer requires a data engineering project, you will report late. If sessions are indexed by config hash, it is a WHERE clause.
3. Config diffs in version control. "When did this change and who approved it" should be answerable from git history, because agent behaviour lives in YAML and Markdown rather than in a vendor's UI.

Vendors, and the phrase "throughout the AI lifecycle" #

The lifecycle language is where the framework gets expensive for teams that bought rather than built. You are expected to ensure the principles hold across partners, which means you need answers about a system you do not operate. Three questions decide whether that is tractable:

• Does customer data leave your perimeter, and to where? Prompts contain customer data. A hosted agent platform sends them to its own infrastructure and then to a model provider, which is at least two hops you have to describe and localise.
• Can you read the code that handles it? Assurance through independent audit is easier to arrange when the artefact under audit is a library in your repository rather than a multi-tenant service you have a certificate about.
• Where does the audit record live? Retention obligations outlast commercial relationships. A record that only exists in a vendor's database is a record you have rented.

None of this makes hosted platforms unusable. It makes them a documented risk position rather than an unexamined default, which is the same conclusion DORA reaches from the European side.

What to build first #

If you are starting a deployment now and want the compliance conversation to be short later, the order that pays off is:

1. Hash-chained audit with config hashes, before any customer traffic. Retrofitting a record is the single most painful thing on this list.
2. Guardrails as declared configuration, including per-customer contact caps across channels, so frequency limits hold when SMS and voice and WhatsApp are running independently. The contact caps playbook covers the shared-ledger pattern.
3. Redaction before the provider call, so the localisation question is about metadata rather than about customer identifiers. See the redaction playbook.
4. Evals wired into CI, so a config change that degrades behaviour fails a build instead of reaching customers.
5. Handover with a resume path, sized so the human queue is small.

That sequence is deliberately unglamorous. It is also the part of an agent deployment that determines whether the second line of defence signs off in a week or a quarter.

What this does not settle #

Two honest caveats. First, the framework is a set of recommendations and the supervisory detail will keep arriving; anything written today about exact reporting mechanics should be treated as provisional and checked against current RBI circulars before you rely on it.

Second, architecture makes obligations satisfiable, it does not satisfy them. A tamper-evident audit chain does not make your model fair, it makes unfairness detectable and provable. That is a genuinely different claim, and it is the only one software can make.

Related reading: why guardrails belong in config, and the collections use case where most Indian deployments start.

← All posts