RBI IT Outsourcing Direction: what it means for AI vendors

Most NBFCs using cloud LLMs today — including paid enterprise tiers of GPT-4 and Claude — are not in compliance with the RBI Master Direction on Outsourcing of IT Services. Most do not know it. Their IT vendors certainly are not volunteering it.

The Master Direction on Outsourcing of IT Services (RBI/2023-24/102, DoS.CO.CSITEG/SEC.1/31.01.015/2023-24), dated 10 April 2023 and effective 1 October 2023, is not a guidance note. It is a binding direction. It applies to every NBFC in the Middle, Upper, and Top Layer under the RBI Scale-Based Regulation framework — Bajaj Finance, Cholamandalam, Shriram Finance, Muthoot Finance, Manappuram. Smaller Base Layer NBFCs are excluded, but the moment an institution crosses into the Middle Layer the direction binds in full.

This post walks through the seven clauses that bite hardest when the IT service in question is an LLM — whether cloud-delivered or on-prem — and sets out what a compliant vendor contract must contain.

The seven clauses that bite

§11(g) source-code escrow — the deal-breaker

Para 11(g) is the clause most AI vendors do not want to discuss. For a material IT outsourcing arrangement, the Master Direction requires either (a) a source-code escrow arrangement with a third-party agent, or (b) an equivalent business-continuity arrangement that ensures the NBFC can sustain operations without the vendor.

For a cloud LLM, the plain-reading implication is stark. OpenAI does not escrow GPT-4 weights with NBFC customers. Anthropic does not escrow Claude's weights. Neither vendor has, to date, issued a written acknowledgement that their standard enterprise agreements satisfy §11(g). A SOC 2 Type II report is a security attestation. It is not a source-code escrow arrangement, and RBI's plain language does not equate the two.

The RBI Master Direction on IT Governance (7 November 2023) reinforces this from a different angle. Its Para 12(f) requires NBFCs to obtain source code for critical applications or implement a source-code escrow arrangement. Applied to LLM deployments by analogy, this means model-weight escrow: the NBFC must have a mechanism to obtain the model weights if the vendor disappears or is acquired.

On-prem deployment resolves §11(g) by design. The fine-tuned adapter weights are delivered to the NBFC's own hardware at deployment. The runtime Docker Compose definitions, fine-tuning pipeline configuration, evaluation scripts, and runbook are deposited with a third-party escrow agent — NCC Group and Iron Mountain are the standard choices — within 30 days of SOW signature and refreshed quarterly. Release triggers include vendor insolvency, AMC failure exceeding 30 consecutive days, and, critically, any RBI supervisory direction to the NBFC to obtain source-code access from a critical IT service provider.

§16 audit rights — RBI shows up on demand

Paras 16(m), 16(n), and 16(o) collectively give the NBFC, its appointed auditors, and the Reserve Bank of India itself the right to audit the vendor with unrestricted and effective access to facilities, records, books, accounts, and personnel. The audit right extends to the vendor's sub-contractors. There is no provision for the vendor to refuse access on IP or commercial-secrecy grounds.

Cloud vendors do not satisfy this clause on a plain reading. The standard enterprise audit accommodation from OpenAI, Anthropic, Microsoft Azure OpenAI, and AWS Bedrock is a SOC 2 Type II report. A SOC 2 engagement is scoped by the vendor, conducted by the vendor's chosen auditor, on the vendor's timeline. RBI's §16 audit right is none of those things: it is on-demand, it can be conducted by RBI examiners directly, and it includes on-site access to the vendor's facility in India.

On-prem deployment inverts the problem. The vendor's operational footprint during the service period is the NBFC's own hardware, on the NBFC's own premises, in India. RBI walks into the NBFC's data room for its routine inspection and the AI system is already there. The audit trail — every prompt, every completion, every model version — is exportable from the Langfuse logging layer and sits in a format the NBFC's own compliance team can read.

§17(8) — the 6-hour clock

Para 17(8) is, operationally, the hardest clause to satisfy with a cloud LLM. The Master Direction requires the service provider to notify the NBFC of any incident "without undue delay" so the NBFC can discharge its own obligation to report to RBI within 6 hours of detection. In practice, this means the vendor must notify the NBFC within 1-2 hours of detecting an incident.

Enterprise cloud LLM SLAs do not meet this standard. The standard operational commitment is a status page update within 24-48 hours. The gap between "vendor detects incident" and "NBFC is notified" is typically measured in hours to days for cloud-AI incidents, not the sub-2-hour window §17(8) operationally demands.

The CERT-In 6-hour reporting obligation creates a concurrent clock. An NBFC facing simultaneous RBI and CERT-In reporting obligations with a cloud LLM vendor that cannot commit to sub-2-hour notification is structurally non-compliant regardless of the quality of its own internal response processes.

§14 confidentiality + the terms-of-service carve-out problem

Para 14 requires the service provider to maintain strict confidentiality and use data only for the contracted service. Cloud LLM terms-of-service routinely carve out "service improvement" and "safety research" uses of input data, even in enterprise tiers. This carve-out is a direct conflict with §14 unless explicitly overridden in writing by the vendor — which OpenAI/Anthropic do not provide as standard.

On-prem deployment resolves §14 structurally. No data leaves. The vendor cannot use data it never receives. The confidentiality obligation in the SOW is belt-and-suspenders — contractually meaningful but operationally redundant, which is exactly where a regulated institution wants to be.

Bottom line.

The RBI Master Direction is not an obstacle invented by cautious compliance teams. It is a binding framework designed for exactly the risk profile that cloud LLM deployments at NBFCs represent: a critical, data-intensive IT function delivered by a vendor that the NBFC cannot audit on demand, that may use the NBFC's data for purposes beyond the contracted service, that cannot give the NBFC its source code, and that cannot notify the NBFC inside a 6-hour incident window.

A cloud LLM deployment at a Middle/Upper/Top Layer NBFC requires, at minimum, a documented gap analysis against §11(g), §14, §16, §17(8), and §19. For each gap, the NBFC needs either a written carve-out from the vendor or a documented compensating control that an RBI examiner would accept. Neither is easy to obtain. Neither is free. And neither eliminates the fundamental problem that §11(g) presents.

On-prem deployment from a vendor whose SOW bakes in escrow, a 6-hour incident SLA, on-site audit rights, zero data use beyond contracted delivery, and a structured exit plan satisfies the Master Direction on a plain reading. See the compliance matrix for clause-by-clause mapping, or the NBFC page for the deployment overview. Book a discovery call to walk through your specific RBI exposure.