Operating Model

A Governance Loop That Evolves With Your AI

Governance is not a one-time certification exercise. It is a continuous cycle from definition to assurance and improvement — and back again.

Models change, vendors change, usage changes and agents act on their own. Any governance approach that produces a snapshot is out of date before the ink dries.

The governance loopContinuous
01   Define — Policies · risk appetite Governance & risk
02   Assess — Use case · data · impact Governance & risk
03   Control — Access · safeguards Security & platform
04   Observe — Activity · behaviour Security operations
05   Improve — Evidence · remediation All of the above

↵ output of 05 becomes input to 01

Why a loop

Traditional governance assumes the thing being governed holds still.

You assess it, you approve it, you review it next year. AI breaks that assumption in three ways: the model behind a system can be swapped underneath it, usage spreads faster than any approval process, and agentic systems take actions that were never individually reviewed.

A loop handles this because nothing in it is final. Every stage produces something the next stage consumes, and the last stage rewrites the first.

Snapshot governance

Assess once, review yearly

  • Accurate on the day it is signed
  • Drifts silently between reviews
  • Evidence reconstructed afterwards
Loop governance

Assess on change, observe always

  • Current by construction
  • Drift surfaces as it happens
  • Evidence produced as you operate

Five stages

Define, assess, control, observe, improve.

Each stage feeds the next, and the fifth feeds the first. Ownership is shared, but every stage needs a named owner — an unowned stage is where the loop breaks.

01

Define

Policies · risk appetite

02

Assess

Use case · data · impact

03

Control

Access · safeguards

04

Observe

Activity · behaviour

05

Improve

Evidence · remediation

01

Define

Set what is permitted before anyone asks. Policies, standards, guidelines, an explicit risk appetite, and an approval path for exceptions. Crucially, define who decides — a policy with no named owner is a suggestion.

Owner: Governance & risk
02

Assess

Evaluate each AI system against those rules: what it does, what data it touches, how autonomous it is, and who it affects. Assessment produces a risk classification and the reasoning behind it — which is what regulators ask for later.

Owner: Governance & risk
03

Control

Apply controls proportionate to that classification — access and privilege boundaries, input and output safeguards, runtime enforcement. Controls should derive from the assessment, not be applied uniformly.

Owner: Security & platform
04

Observe

Record what the estate actually does: interactions, decisions, tool use, significant actions, behavioural drift. This is the stage most programmes skip, and the reason they cannot answer questions about their own systems.

Owner: Security operations
05

Improve

Feed observation back into policy. Where behaviour diverged from intent, either the control was wrong or the policy was — both are findings. Each pass sharpens the next.

Owner: All of the above

Closing the loop

Each pass sharpens the next.

Policies, controls, risk models and governance maturity improve from operational evidence rather than guesswork — and the evidence gathered during Observe is the same evidence an auditor asks for, so regulatory readiness becomes a by-product rather than a separate project.

Where a team is in that journey — and which stages to deepen first — is covered on the maturity path.

On changeAssessment trigger
ContinuousObservation
Per systemNamed ownership
By-productAudit evidence

Questions

Operating model FAQ

What is an AI governance operating model?

The repeating cycle a team runs to keep AI inside policy: define the rules, assess each system against them, apply controls, observe what actually happens, and improve based on that evidence. It describes how governance operates day to day, as distinct from what the controls are.

How often should the loop run?

Continuously rather than on a calendar. Assessment is triggered by change — a new system, a new model version, a new data source, a shift in usage — while observation runs constantly. Fixed annual reviews go stale between cycles.

Who owns each stage?

Ownership is usually shared: governance and risk own Define and Assess, security and platform teams own Control, security operations own Observe, and Improve is where all of them meet. What matters is that every stage has a named owner.

Is this the same as a compliance audit cycle?

No. An audit cycle produces a point-in-time attestation. This loop produces continuous evidence, which an audit can then draw on. Teams that run the loop properly find audits become a reporting exercise rather than a scramble.

Where do most teams break the loop?

At Observe. Define, Assess and Control all produce visible artefacts, so they get done. Observation produces nothing until something goes wrong — which is exactly when its absence is discovered.

How does this relate to the framework?

The framework describes what the controls are across five dimensions; the operating model describes the cycle that keeps them current. One is the anatomy, the other is the heartbeat.

Get Started

Run the loop, not the paperwork.

See how Govreign operates define, assess, control, observe and improve as one continuous cycle.