An AI Operating Model Your Board and Regulators Approve
An AI operating model, not a use-case list
Most regulated firms start their AI journey with a use-case list. A fraud detection pilot here, a claims triage agent there, a document intake workflow in a back office somewhere. The list grows, the pilots accumulate, and two years later the executive sponsor still cannot answer the only question that matters: can we run this safely in production, and who is accountable when something goes wrong?
A use-case list describes what you might build. An AI operating model describes how you will govern, run, and defend every model you actually ship. The distinction is not academic. Regulators do not ask for your backlog. They ask who owns model risk, how decisions are reviewed, and where the evidence trail lives. A board does not sign off on a spreadsheet of ideas. It signs off on a system of ownership, controls, gates, and inventory that a director can read in one page.
Banks, insurers, lenders, and capital markets firms do not get the luxury of moving fast and letting the safety team catch up. The EU AI Act classifies creditworthiness, insurance pricing, and similar use cases as high risk. DORA demands operational resilience for the systems that carry them. Supervisory guidance on model risk management, from SR 11-7 in the US to the PRA's SS1/23 in the UK, assumes a documented chain of accountability that most AI programs still lack.
That gap is exactly where an AI operating model earns its keep. It is the missing layer between having use cases and running AI safely in production.
The four components of an AI operating model
An operating model is not a policy document that sits on a shelf. It is four mechanisms that move together. If any one is missing, the model stops being a system and becomes a hope.
Ownership: one accountable executive per model
Every model, from a simple rules-based score to a multi-agent workflow, needs a named owner. Ownership means something specific: the owner can halt a model, can be held responsible for its behavior, and can explain its risk posture to a regulator without reading slides written by a vendor.
If a model has no named owner, it has no risk owner, and in a regulated firm that is the same as having no model at all. Name the executive, not the team. "The credit risk function" is not an owner. A named individual with a title, escalation rights, and a written mandate is an owner.
Ownership has three parts:
A named accountable executive with authority to stop the model
A written statement of the model's intended use and its limits
A single point of contact for model risk, audit, and the regulator
Controls: make risk explicit and testable
Controls turn "we think it is safe" into "here is the evidence." For each model, write down the specific harms it could cause and the control that mitigates each one, then attach evidence.
A fraud model needs controls for bias in the training data, drift in production, and the human override path. A customer-facing agent needs controls for prompt injection, hallucination, and escalation. Each control must be testable: if you cannot write the test, you do not have a control, you have an intention.
Regulators accept controls that can be evidenced, not controls that are asserted. In practice this means the control, its owner, its test, and its latest evidence all live in one place and are updated on a schedule.
Pre-production controls
These run before a model touches real data or real customers. They include fairness and bias checks, data quality validation, red teaming for prompt injection and jailbreaks, and a security review of the code path that serves the model. The hardening work here is the same discipline Kolega DevSec applies to AI and software before anything ships.
Runtime controls
These run while the model is live. They include drift monitoring, output and decision logging, rate and privilege limits on agents, and the human escalation path that takes over when confidence drops or a threshold is crossed. A runtime control without an alerting owner is decoration.
Review gates: stage-gate your way to production
Nothing goes live on ambition. Models move through staged gates, and each gate has an explicit decision maker:
Idea and eligibility: is this use case in scope, and what is its risk tier?
Design and build: are data, bias, and security concerns documented?
Pre-production: has it passed testing, red teaming, and a control review?
Go-live: has the owner signed off, and is monitoring switched on?
Retirement: who turns it off, and when?
A gate without a named approver is a suggestion. A gate with a named approver is a governance event.
Model inventory: a registry you can defend
The inventory is the spine of the whole model. If a regulator asks for every model in production, the answer should be a query, not a scramble.
A defensible model inventory is a machine-readable registry, not a spreadsheet of good intentions. Each entry records at minimum the model's purpose, owner, risk tier, data sources, deployment environment, controls, and last review date. That way the one-page governance view is a report generated from the inventory, not a document maintained by hand.
The board-ready one-page governance view
Boards do not read policies. They read one page that answers four questions, and they watch whether the answers change quarter over quarter.
A board signs off on a system it can see change, not a document it is told is under control.
Build the one-pager from the inventory so it is always current. Keep it to four blocks:
What is live: number of models in production by risk tier, and any tier that grew since last quarter
What changed: new models, retired models, and models that moved risk tier
What went wrong: incidents, near misses, and control failures, with the owner's name attached
What is next: models approaching a gate, overdue reviews, and open risk items
The discipline is not the layout. It is that every line traces to an owner and to evidence. A director should be able to point at any row and ask "show me," and get the control test, not a promise.
Model risk and accountability lines
Accountability fails when ownership is diffuse. Most regulated firms already run a three-lines-of-defense model for operational risk, and AI fits the same shape if you force it:
First line: the business owner who designs and runs the model
Second line: the independent risk and compliance function that reviews and challenges
Third line: internal audit, which tests whether the first two lines actually work
The line that breaks first in AI programs is the second line. Business teams build models fast, and risk functions are still learning what to challenge. The operating model has to fix that asymmetry on purpose: give the second line a seat at every review gate, and give it the tools to test a model without asking the builder for permission.
This is where the toolchain matters. You cannot hold a second line accountable for reviewing models it cannot see. A model inventory that records controls, drift metrics, and evidence in one place is what turns a second-line challenge from a meeting into a check. When models are prototyped in Kolega Studio and built and orchestrated in Kolega Code, the record of what changed and why should survive the handoff rather than live in someone's memory. The provable-migration mindset behind CAM applies here too: governance is built on evidence that survives an audit, not on assertions.
From model to operating cadence
An operating model only lives if it runs on a rhythm. Set the cadence in advance and make it boring on purpose:
Weekly: model owners review drift alerts and open incidents
Monthly: the second line reviews controls and outstanding risk items
Quarterly: the board sees the one-pager and the trend, not just the snapshot
Annually: every model gets a full validation, or a dated and approved deferral
Maturity is not how many models you have. It is how reliably the cadence fires. A firm with three models and a working cadence is further along than a firm with thirty models and a governance deck that gets updated the week before the board meeting.
Start with the operating model before you scale the portfolio. If you build the ownership, controls, gates, and inventory now, each new use case slots into a system that already knows where it belongs, who owns it, and how it gets to production. If you scale first, you will eventually be forced to retrofit governance onto a portfolio that was never designed to be governed, and that retrofit is where regulated firms burn a year and a budget.
The use-case list tells you what you could do. The AI operating model tells everyone who must sign off that you can be trusted to do it.