CloseIT  /  AI governance · Policy to practice
AI governance · Controls

Your AI policy is written. Now what?

The document is approved and circulated, and now every sentence in it is a claim somebody will eventually have to demonstrate. This is the translation step: what each of the usual policy sentences has to become in practice before it is true.

Short answer

A policy sentence becomes a control when it has four parts: a trigger that starts it, a named person who acts, a defined output, and a record it leaves behind. Anything missing one of the four is an intention. The work after approval is not more policy text — it is going through the document sentence by sentence and giving each claim its four parts.

Why approved policies stall

An AI policy is normally written in the language of principles, because that is the language it has to be approved in. Principles survive a board meeting; they do not survive contact with a Tuesday. The stall that follows is rarely about willingness — it is that nobody owns the translation. Risk wrote the document, engineering did not sign up to anything in particular, and the operational steps live in no system at all.

The cost of leaving it there is delayed but predictable. The policy is the first thing an assessor reads, and every claim in it becomes a question: show me where this happens. A policy with no mechanisms behind it does not protect the organisation — it gives whoever asks a ready-made list of things to test.

Sentence by sentence: claim → mechanism

These are the sentences that appear in almost every AI policy, and what each one has to become to be both true and provable.

The policy saysWhat has to existWhat it leaves behind
“AI systems are recorded in an inventory” A register with one entry per use, and a creation trigger — a point in procurement, onboarding or deployment where the entry is made. Without the trigger the register records only what people volunteer. Entries with owners, dates and a visible last-changed
“AI systems are assessed before use” An assessment step attached to the entry, with a defined point at which it must be complete, a person who performs it, and a written conclusion. “Before use” means nothing until something blocks use. A dated assessment with an author and a verdict
“Models are monitored” Named metrics per system, a threshold for each, an alert route, and a named recipient who is expected to respond. Monitoring that reaches a shared mailbox is not monitored. Alert history and what was done about it
“Changes are controlled” A release gate: a defined set of changes (model version, prompt, data source, scope of use) that cannot ship until a stated check passes, with the check recorded rather than asserted. A gate decision per release, with who approved it
“Human oversight is effective” A named overseer per system, the authority and the means to override, and — the part that is usually missing — a way for overrides and interventions to be counted. An oversight right that is never exercised and never measured cannot be shown to work. A trail of reviews, overrides and interventions
“Third-party AI is reviewed” An intake step in the path a vendor actually takes into the company — procurement, IT onboarding, the card payment — with a short set of questions and a record of the answers. A vendor record linked to the system entry
“Staff using AI are trained” Defined content, a defined audience derived from the register, and an attendance or completion record. The audience definition is what usually fails: nobody knows who to train because nobody knows who uses what. Completion records tied to roles
“Incidents are reported” A route that exists in the tool people already use, a definition of what counts as an AI incident, and a triage owner. A separate reporting channel that nobody has open is a channel with no incidents in it. One definitional line worth writing down early: the EU AI Act treats a serious incident — death, harm to health, disruption of critical infrastructure, breach of fundamental rights — as a separate category with its own reporting duties to authorities (Articles 73 and 26(5)), on deadlines. Your triage should know which bucket it is looking at before the clock matters. Incident records linked to the system

Every row is scoped by the first one. Assessment, monitoring, oversight, change control and training are all written per system. None of them can be demonstrated for systems that are not on a list — which is why the register is the control that decides how much of the rest is real. If the list is unreliable, see why manual registers decay.

The four parts of a control

A useful test when reading your own policy. For each sentence, ask:

Sentences that fail this test are not necessarily wrong. They are just not yet controls, and marking them honestly — as intent pending implementation, with an owner and a date — is a stronger position than leaving them ambiguous.

Free, no sign-up

Which obligations actually attach to a given system?

Before mapping controls, it helps to know what the law asks of each system rather than what the policy asks of all of them. The EU AI Act compliance checklist classifies one system and lists the obligations that follow, each with the evidence usually expected — a useful reality check on which policy sentences are load-bearing for that system and which are house rules.

Open the checklist

What to build first

Sequence matters more than coverage. A defensible order:

  1. The register, with a creation trigger. Everything else is scoped by it, and building it exposes how much of the policy is currently unenforceable.
  2. The intake step for new systems. Stopping the backlog from growing is cheaper than clearing it twice.
  3. Assessment attached to the entry. Even a short, honest assessment beats a thorough one that lives in an unlinked document.
  4. The gate on changes that matter. Pick the few change types that genuinely shift behaviour — model version, data source, scope of use — rather than gating everything and being routed around.
  5. Oversight that leaves a trace. The last one on the list and the one most often claimed first.

Three traps in the translation

Track this in your Jira

Controls in the tool the work already runs in

Model Inventory for Jira puts the register and the work around it in the same Jira: each AI system a work item with owner, purpose and classification; assessments and reviews as linked work with real assignees and due dates; workflow states as the gate; and an immutable change history as the record. The decisions stay with your people — what changes is that they leave a trace without anyone writing a report about it.

See how it works

FAQ

How do you turn an AI policy into actual controls?

Read it as a list of claims, and give each claim a trigger, an actor, an output and a record. “Models are monitored” becomes a metric, a threshold, an alert route, a named recipient and a log of what happened when it fired. Claims missing one of the four are intentions.

Why do approved AI policies stall in implementation?

Because nobody owns the translation from principles to mechanisms. The document is approved in the language it needed to be approved in, and the operational steps are left unassigned. Adding more policy text does not fix it.

What is the first control to implement after an AI policy is approved?

The register, with a creation trigger. Almost every other claim is scoped per system, and none of them can be evidenced for systems nobody has listed.

This page is a practical explanation, not legal advice. Confirm obligations against the official text of Regulation (EU) 2024/1689, the standards you work to, and where the stakes warrant it, qualified counsel.