India AI Governance Guidelines Need Control Owners, Tests, and Evidence

India's AI governance work starts with coordination. The government's advisory-group process examined gaps across the existing legal and institutional structure, then proposed a whole-of-government approach rather than treating AI as one ministry's technical project. For an enterprise, that mechanism leads to a practical requirement: every deployed use case needs a named decision owner. It also needs controls in the systems that can enforce them and evidence showing what happened when the controls were tested.

TL;DR

• India AI governance guidelines point toward coordinated, risk-based oversight across existing authorities.
• Enterprises should maintain one system record linking the use case, affected people, data flows, and model route. It should also identify owners, controls, tests, and exceptions.
• Each control belongs in the component with authority to change the outcome.
• Request-level policy and audit records cover only the authenticated HTTP traffic routed through that enforcement point.

India AI governance guidelines create an operating problem

The official report on AI governance guidelines development describes work by a Ministry of Electronics and Information Technology advisory-group subcommittee. It examined the current governance structure and identified gaps. It also proposed a coordinated government approach and completed a public-consultation process on 27 February 2025.

That structure matters more than a slogan about responsible AI. A company can already face duties through privacy and consumer protection, along with sector rules and contracts. Cybersecurity requirements can also apply. The governance task is to show which duty attaches to a specific AI system and who owns the resulting decision. A generic policy PDF cannot answer that question during an incident.

I would reject any governance program that ends with a 47-slide principles deck and no executed control test. The useful artifact is a live system record. It names the use case and its business and technical owners. It also records data classes, the model provider, affected users, and material risks. The remaining fields cover control locations and evidence, plus the event that forces another review.

One system record connects policy to deployment

Start with the deployed system rather than the model brand. Record the business decision or task and the people affected. Identify the identities allowed to use it, the input data, retrieval sources, and model destination. Then document connected tools, output recipients, and the retention path. Add the legal and sector owners who can decide which obligations apply.

This creates a boundary that reviewers can inspect. A recruitment-screening system and an internal coding assistant may call the same model, but their data and affected people differ. Their decision authority and evidence needs differ too. One vendor questionnaire cannot stand in for both assessments.

The AI governance policy operating model provides the wider ownership structure. The system record supplies the implementation detail beneath it. Every policy statement should point to an observable control or an accountable approval. If the record says sensitive customer data may reach only an approved endpoint, the architecture must identify the component that checks the destination and the evidence retained after each decision.

Control ownership follows technical authority

Assign each control to the component that can change the result. Identity providers own authentication and account lifecycle. Data stores own retrieval permissions. Application services own business workflow. Tool endpoints own the final authorization for actions that change money or records, or that alter access. Model providers own controls inside their service.

An AI request gateway can own a narrower slice. When authenticated HTTP model traffic crosses that boundary, the gateway can receive caller context and classify prompt content. It can also restrict destinations, evaluate an identity-aware policy, and record the outcome before forwarding permitted traffic. It is blind to local execution and training-data integrity. It also cannot see direct calls that bypass it or authorization inside a downstream tool.

The post-authentication gap appears when a valid account or service credential hides the person and purpose behind a model call. Closing that gap requires the application to carry identity context to the request boundary. The policy point can then evaluate this caller and data class against the model route and policy version as one decision.

Tests turn governance claims into evidence

A control description earns little trust until someone executes a permitted case and a denied case on the production-like path. Define the input and expected outcome, then record the observed outcome and configuration version. Include the reviewer and timestamp. Preserve the request correlation identifier so evidence from the identity provider and application can be joined with records from the gateway, model route, and downstream service.

Consider a customer-support assistant handling an account record. One test sends a permitted summary request from an assigned support role. Another sends the same record under an unassigned identity. The evidence should show which component denied the second path and confirm that the model never received the restricted payload.

Repeat the test when the model route or data source changes. Changes to a user role, tool permission, or policy should also trigger the test. A yearly review misses too much. A change trigger catches the moment when the previous evidence stops describing the deployed system. This is where governance is an engineering process rather than a calendar meeting.

National coordination changes enterprise accountability

India's current institutional direction continues to emphasize coordination. The official announcement establishing the AI Governance and Economic Group places national policy work across government and industry, with academia and civil society also represented, rather than inside one product regulator.

Enterprises should expect questions to arrive through more than one route. Privacy teams may focus on personal data and purpose. Security teams will ask about access and abuse, along with incident evidence. Procurement will ask what providers retain and which subprocessors receive data. Business owners are accountable for the use case and the decision it produces.

One system record lets those reviewers work from the same deployment facts while retaining separate authority. It also prevents a dangerous shortcut: treating a provider's certificate or model card as proof that the enterprise's own workflow is controlled. Vendor evidence belongs in the file. It covers only the provider's part of the system.

A review packet should survive personnel changes

The final packet needs enough detail for a reviewer who missed every design meeting. Include the architecture and data-flow diagram, then state the system purpose and affected groups. Record risk decisions and control owners. Add executed tests and exceptions, along with residual-risk approvals. Finish with source dates and review triggers. Store policy and configuration versions beside the results.

A clean packet also lists explicit exclusions. If training-data provenance sits with the provider, say so and record the contractual evidence reviewed. If a local agent executes outside the HTTP model route, assign its controls elsewhere. Blank rows invite assumptions. Named boundaries force an accountable decision.

The opinion I would defend is simple: a short, executed control file beats an ornate responsible-AI charter. The first can stop a release or explain an incident. The second usually survives because nobody gave it authority.

DeepInspect

DeepInspect can serve as the policy and evidence point for authenticated HTTP traffic between enterprise users or agents and LLM endpoints. It evaluates the identity context supplied by the application and the prompt classification. It also checks the destination and route against the policy version before forwarding permitted requests.

Each decision creates an independent audit record containing the caller and policy, plus the data classification and outcome. It also records the route and event time. That record gives the governance packet evidence for one defined slice of the architecture while leaving training and retrieval, along with tools and local execution, with their proper owners. Book a technical deep dive at deepinspect.ai.