The AI Governance Operating Model

The governance conversation in most enterprises still gets stuck in the same place. Legal and risk want a policy document. Technology wants a green light. The business wants both, quickly, without either side becoming a bottleneck. The result is usually a 40-page policy that no product team reads and a review board that meets monthly, which for AI product cycles is roughly geological time.

Governance done well is not a document and it is not a board. It is an operating model — a set of decisions about who is accountable for what, made once and enforced consistently, so that most AI work never has to go through a review at all.

The frame we use with clients is that governance has four jobs: to decide what the enterprise will and will not build; to make sure what gets built meets a defined standard before it goes live; to catch problems in production before they become incidents; and to respond credibly when something does go wrong. Each of those jobs needs a different mechanism. Collapsing them into one review committee is the single most common design error.

Start with a risk tier. Not a taxonomy of 30 categories — a small, memorable tier with clear thresholds. A version we have seen work well has four levels. Tier 1: internal productivity tools with no customer data and no external decisioning. Tier 2: internal tools that touch customer data but do not directly affect customer outcomes. Tier 3: customer-facing or decisioning systems in non-regulated contexts. Tier 4: systems that make or materially influence a decision a regulator cares about — credit, hiring, healthcare triage, fraud, insurance underwriting.

Each tier has a different set of controls, and each tier is owned by a different accountable person. Tier 1 is self-service; the team ships and logs it in the model registry. Tier 2 requires a lightweight review — a checklist, a data protection sign-off, and a named owner. Tier 3 requires an evaluation report, a model card, and sign-off from the business owner and the risk function. Tier 4 requires all of the above plus a formal risk assessment, a red-team exercise, an approved rollback plan, and periodic re-review.

Publishing this tier and its thresholds does more for velocity than any process change. Teams stop guessing what they need to do and stop being surprised by review outcomes. Risk teams stop drowning in low-tier reviews and can concentrate their expertise where it matters.

Model cards are the artifact this whole system runs on. Not a marketing document — a structured record of what a model is, what it was trained on, how it was evaluated, where it is used, what its known failure modes are, who owns it, and what the escalation path is if something goes wrong. Every deployed model has one. It lives in a searchable registry. It is updated on every material change. It is the first thing an auditor asks for and the first thing an incident responder reads.

For enterprises using third-party foundation models — which is almost everyone — the model card also captures what you know about the provider: the version pinned, the terms in effect, the data-handling commitments, and the fallback provider you can switch to if the primary changes its terms or goes down. This is where the model gateway pays for itself; it makes the model card machine-generated rather than a task the team has to remember.

Human-in-the-loop policy is the other artifact that repays the effort. For every deployed system, the policy names three things: which decisions require a human before the system acts (approval gates); which decisions the system takes autonomously but a human reviews after (surveillance sampling); and which decisions require no human review at all (automated with logging). The policy is versioned, and every change is a governance event, because expanding autonomy is exactly the kind of change that quietly increases risk.

The evaluation harness is what makes all of this credible. For each Tier 3 and Tier 4 system, there is a held-out set of cases — real inputs, expected outputs or acceptable output ranges, refreshed at a documented cadence, owned by someone other than the team that built the system. Every model change, every prompt change, every tool change is scored against this harness before promotion. The scores are published. Regressions block deploys. This is what turns "we tested it" into an audit trail.

In-production controls matter as much as pre-production ones. Every system emits structured logs that let you answer three questions at any time: what did the system do, why did it do it, and was that consistent with policy? Log volume for a well-instrumented AI system is substantial. That is not a reason to log less; it is a reason to design the retention and query story before you ship, not after your first incident.

Incident response is where governance meets reality. Every AI system in Tier 3 or Tier 4 has a documented playbook: who gets paged, what the first three actions are, how to disable the system, how to communicate with affected customers, how to preserve evidence for post-incident review. Rehearse it. Once a quarter, run a tabletop with a plausible incident and time how long it takes to disable a production agent. If the answer is more than five minutes, you have a design problem, not a training problem.

The regulatory environment matters too. For most Indian and multinational enterprises we work with, the governance model has to satisfy at least three regimes simultaneously: the EU AI Act (which applies to systems used in or affecting EU markets), India's DPDP framework (for personal data), and sector-specific regulation (RBI, IRDAI, SEBI, HIPAA, or their local equivalents). The good news is that these regimes largely converge on the same requirements: risk classification, data protection, transparency, human oversight, accountability. Build the operating model to the most demanding of them and the rest are mostly satisfied by construction.

The trap to avoid is treating each regulation as a separate compliance program. That produces duplicate documentation, contradictory processes, and audit fatigue. Map the requirements once, land on a single set of controls, and generate the different regulator-facing views from the same underlying artifacts.

One question we get in almost every engagement is where governance should sit organizationally. There is no perfect answer, but the pattern that works best is a small central function — sometimes called the AI office, sometimes AI risk, sometimes responsible AI — that owns the policy, the tiering, the artifacts, and the incident response process. It sits close to the CTO or CDO, and it has a formal reporting line into the CRO and the audit committee. Its authority is derived, not delegated: it can block Tier 3 and Tier 4 launches, and it reports launches, incidents, and coverage gaps to the board.

Sizing this function is straightforward. For a large enterprise with a serious AI programme, expect roughly one full-time person per 15 to 20 Tier 3 or Tier 4 systems in production, plus a small platform contingent. Under-investing here is the fastest way to end up with either a shadow AI estate or a governance function that becomes a delivery bottleneck — both of which are worse than the alternative you were trying to avoid.

The final thing worth saying is that governance is a competitive capability, not a compliance cost. Enterprises that can move a new AI use case from idea to production in weeks, with the audit trail and the incident playbook already in place, will out-ship enterprises that cannot. The regulatory environment is going to keep tightening. The organisations that treated governance as an operating model, not a policy document, will find the transitions easy. The rest will find them expensive.