Waiting for an AI law is a poor compliance strategy

India’s lack of a dedicated AI law does not create a compliance holiday. Courts can apply ordinary law, while sectoral regulators can issue binding or supervisory directions. Businesses must therefore treat current legal decisions, regulatory circulars, and data-protection obligations as active requirements. The central expectation is simple: show your working.

For an AI-assisted decision, a company should preserve the model version, the input or source data, any retrieval step, the human reviewer, and the resulting record. This matters when an account is frozen, a loan is assessed, or another consequential action is challenged. A policy alone is not enough if the business cannot reconstruct what happened.

The RBI has already asked regulated entities to assess frontier-AI cyber risk and proposed enterprise-wide model governance. The DPDPA will fully apply from May 13, 2027, including when vendors process personal data. A future AI law will add to this framework, not replace it.

On July 2, 2026, the Supreme Court of India quashed orders made by the National Company Law Tribunal and the National Company Law Appellate Tribunal. Those orders had relied on citations generated by an AI tool and attributed to the Supreme Court itself. The case was Pooja Ramesh Singh v. Jammu and Kashmir Bank Ltd.

The failure was not merely technical. AI-generated legal material entered formal proceedings because people did not catch the error before filing. The Supreme Court’s action showed that ordinary judicial processes can address harm caused by unreliable AI output, without waiting for a dedicated AI statute.

The Court also directed the Bar Council of India to constitute a committee. That committee must prescribe disciplinary norms for advocates who file AI-generated citations. The parties bore the cost of the machine error through multiple proceedings, making the incident a business and process-control problem as well as a legal one.

Companies remain responsible because AI is used inside existing legal and business processes. A court can assess whether a filing, account freeze, or other action was properly supported under ordinary law. A sectoral regulator can also require controls, assessments, and records under its existing authority. The technology does not erase the organisation’s duty to operate lawfully.

The tribunal case demonstrates the mechanism. Orders rested on fabricated AI-generated citations, but the Supreme Court quashed them and directed disciplinary norms for advocates. No AI-specific statute was needed. In banking, the RBI’s proposed model-risk framework similarly places governance responsibility on the regulated entity using a model.

This makes waiting for legislation a poor sequence. The RBI has already sought board-signed frontier-AI cyber-risk assessments, and the DPDPA will apply wherever an AI system handles personal data. A future AI law will sit on top of case law and sectoral directions, rather than displace them.

The challenge is not simply that 400 cases require processing. It is that this volume can overwhelm a nominal human-control system. When staff must clear roughly 400 suspicious-transaction cases each day, repeated approvals may become routine. A workflow can technically include human sign-off while practically depending on the AI’s recommendation.

The key risk appears when the system freezes an account incorrectly. If the bank cannot show which information the reviewer examined, what the model produced, or whether the reviewer exercised independent judgment, the sign-off provides little protection. The record of approval may exist, but the substance of review may not.

This example shows why AI compliance is also an architecture problem. Businesses need records that identify the model, data, retrieval step, and reviewer for each consequential decision. Without those records, a high-volume process can make responsibility difficult to establish and errors difficult to reconstruct.

Model risk management means controlling the risks that arise when models influence important decisions. The RBI’s proposed guidance would create a comprehensive, enterprise-wide governance framework for financial-sector models. It treats models broadly, including artificial intelligence, machine learning, and models supplied by outside vendors.

The reason for including third-party systems is practical. A bank may license a model that influences lending, monitoring, or another decision. Even though the bank did not build the model, its business process uses the output. The bank therefore needs to understand the model’s version, operation, data, controls, and results well enough to govern the decision.

Released publicly as a draft on June 24, the guidance covers commercial banks, small finance banks, payments banks, NBFCs, and other financial institutions. It signals that outsourcing development does not outsource accountability. The regulated entity must manage the model risk created by its use.

The article places primary responsibility on the organisation using the AI system. If a vendor’s model influences a lending decision, the regulated business remains responsible for managing the resulting model risk. The same principle applies to other consequential workflows, including account monitoring and freezing. Buying a model does not transfer accountability for the decision.

The mechanism is governance and evidence. The buyer should ask which model version handled each request, whether records can be exported and retained, where inference occurs, what happens to inputs, and where a human must act. These answers determine whether the business can explain and defend its process later.

The RBI’s draft guidance expressly extends to third-party models used by financial institutions. Vendors still matter because weak vendor controls increase the buyer’s exposure. But under the article’s stated approach, a vendor’s involvement does not remove the responsibility of the entity putting the AI system to use.

AI provenance is the history of an AI output: which model produced it, what data it used, and whether a retrieval step supplied additional information. An audit record adds the human and time trail, including who reviewed the result and whether the record still exists later. Together, they show the decision’s working rather than merely its final outcome.

This matters most when an AI system makes a consequential decision. A bank may freeze an account or assess a lending application based partly on a model. If challenged, it must identify the model version, source data, retrieved material, and human sign-off. A generic approval log cannot show what was actually reviewed.

The article describes this as an architecture question before a policy question. Recording prompts, model versions, retrieved data, and sign-offs is cheap only when designed into the system. Reconstructing them afterward can become close to impossible, especially in high-volume workflows.