Turning AI governance principles into executable controls

“AI should be fair, transparent, secure and accountable” is a reasonable direction. It is not yet an operating system. An engineer cannot implement “fairness” without knowing the affected decision and relevant groups. A reviewer cannot test “transparency” without knowing who needs which information to do what. A leader cannot accept “accountability” without an owner and an enforceable response.

The work of governance is translation: principle to context, context to requirement, requirement to control, control to evidence, and evidence to decision. Skip a link and an organisation can accumulate polished policies while systems continue to change outside them.

Anchor the principle in one workflow

Principles gain meaning through use. Start with a named system, intended purpose, users, affected people, data, action authority and credible consequences. Then ask what the principle requires in that setting.

Take transparency. It may mean different things to different actors:

• a customer needs to know they are interacting with an AI system and how to seek help;
• an operator needs source provenance and uncertainty to review a recommendation;
• an incident responder needs action traces and configuration history;
• a governance body needs a concise account of purpose, evidence, findings and ownership.

One generic model explanation will not satisfy all four jobs. The OECD AI Principles combine high-level values with recommendations on transparency, robustness, accountability and human-centred values. Operationalisation begins by identifying whose outcome is at stake and what observable state would support it.

Write requirements that can be challenged

Turn the contextual interpretation into requirements with a subject, condition and expected outcome. Compare:

• Weak: “The agent must be safe.”
• Testable: “The agent must not send an external message unless the initiating user has send authority and confirms the final recipients and content.”
• Weak: “The system must protect privacy.”
• Testable: “Retrieved context must exclude records the active user is not authorised to view, and denial must occur before content enters the model context.”

Good requirements state boundaries and make failure visible. They can include qualitative judgement where the subject demands it, but the judgement method, reviewers and evidence should still be explicit.

Maintain traceability from requirement back to the principle, risk or obligation that motivated it. This prevents controls from surviving after their purpose is forgotten and helps reviewers identify gaps when the context changes.

Build a layered control set

One requirement often needs several control types:

Control layer	Purpose	Example for external agent actions
Preventive	Stop an unacceptable event	Tool gateway checks identity, scope and transaction limit
Directive	Tell people and systems what is expected	Approved action classes and escalation procedure
Detective	Reveal failure or drift	Alert on denied or unusual action patterns
Corrective	Restore a safe state	Revoke credential, cancel queued work, roll back change
Evidentiary	Make operation reviewable	Tamper-resistant action record linked to request and policy

Prefer enforcement outside the generative model for hard boundaries. A prompt can guide behaviour; it should not be the only barrier protecting a record or transaction. Use identity systems, policy engines, schemas, tool wrappers, transaction controls and human gates where they can deterministically constrain action.

The NIST AI RMF Core distinguishes governance, mapping, measurement and management while treating governance as cross-cutting. That structure discourages a common failure: defining policy separately from the teams and systems that implement, measure and respond to it.

Specify the control as an operational contract

For every material control, record:

1. Objective: which requirement and failure it addresses.
2. Scope: systems, action classes, users and environments covered.
3. Mechanism: where and how the control acts.
4. Owner: who maintains it and who accepts residual risk.
5. Trigger: what invokes preventive, detective or corrective behaviour.
6. Evidence: what shows implementation and effectiveness.
7. Failure response: what happens when the control is unavailable or breached.
8. Change triggers: which modifications require reassessment.

This turns a control catalogue into something an operator can run. A “human review” control, for example, should state which actions pause, what evidence the reviewer sees, response-time requirements, fallback on timeout and how override effectiveness is tested.

Control ownership must match authority. A policy team may define the objective, but a platform team may own the enforcement point and a workflow owner may own the decision. Record those separate responsibilities rather than assigning everything to an AI committee.

Define evidence before implementation is declared complete

Evidence should answer two different questions:

• Was the control implemented? Configuration, code, policy rules, access maps and operating procedures can show design and deployment.
• Did the control work under relevant conditions? Test results, runtime traces, recovery exercises, sampled decisions and incident outcomes can show effectiveness.

A screenshot of a settings page is weak effectiveness evidence. A test that demonstrates an unauthorised request was denied before retrieval, records the active policy version and confirms no restricted content entered the model context is stronger.

The UK government’s Introduction to AI assurance frames assurance as measuring, evaluating and communicating whether a system meets relevant criteria and notes that multiple techniques are needed across the lifecycle. That matters because governance controls span technical, procedural and human behaviour. Code review alone cannot show that an escalation works under workload; a workshop alone cannot show that a permission is enforced.

Make exceptions first-class decisions

Controls that cannot accommodate legitimate exceptions will be bypassed. Define an exception path with scope, rationale, compensating controls, approver, expiry and evidence. Never let “temporary” mean indefinite.

For example, a team may need to use a new model before the full evaluation suite is ready. The exception might restrict the system to internal drafting, disable external tools, limit users, increase sampling and expire after two weeks. The decision owner can then see what changed and what is not being claimed.

Monitor exceptions as a portfolio. Repeated exceptions against the same control may indicate that the control is badly designed, the operating model lacks capacity or the organisation’s stated risk tolerance does not match its actual choices.

Connect controls to change and release

Controls should participate in delivery, not wait for a quarterly committee. Material changes can automatically create governance work:

• adding a tool prompts an authority and recovery review;
• changing retrieval sources prompts access, privacy and provenance tests;
• changing a model or prompt reruns defined evaluations;
• expanding users or geography revisits context and obligations;
• raising transaction limits requires an owner decision;
• a control failure blocks release or narrows operation.

The NIST AI RMF Playbook provides suggested actions for operationalising framework outcomes. Use it as a source of practices, not a universal checklist. Select controls based on the system’s context and consequence, and record why they are sufficient for the decision at hand.

ISO/IEC 42001 specifies a management-system approach that includes establishing, implementing, maintaining and continually improving processes for AI. A local control map can support that work, but it does not by itself demonstrate conformity or certification.

Measure the gaps between words and operation

An effective governance review asks for traceability in both directions. Pick a principle and follow it to requirements, controls, evidence and open gaps. Then pick a runtime control and trace it back to the risk and owner it serves.

Useful portfolio measures include:

• consequential requirements without an implemented control;
• controls without an owner or recent effectiveness evidence;
• releases using expired evidence or open severe findings;
• exceptions past expiry;
• material changes that did not trigger review;
• incidents where the expected control did not activate;
• controls that generate noise but no actionable response.

Do not mistake the absence of incidents for control effectiveness. Test the conditions the control is supposed to handle. Preserve failed tests and workarounds because they reveal where the design and the policy diverge.

Close with an explicit residual-risk decision

No control set eliminates uncertainty. The workflow owner needs a concise view of the requirement, evidence, remaining gaps, affected people, operating constraints and proposed decision. Approval should say what is allowed, under which conditions, until which trigger or review—not merely “governance complete.”

The organisation can then improve without pretending that a principle has been permanently solved. Principles provide direction. Requirements make them specific. Controls change behaviour. Evidence makes the change reviewable. Decisions keep accountability attached.

Choose one consequential workflow and follow that chain end to end. It will reveal more about governance maturity than another page of aspirational language.