Home Blog Governance
Governance

An AI governance policy template for automation teams (one page, copy it)

Most AI policies are twelve pages nobody reads. This is one page that a team lead can enforce. Copy it, change the bracketed parts and put an owner's name on it.

By The Cadrix team7 min read
A black pen on a printed form beside a black mug and a yellow notebook
Photo by 2H Media on Unsplash

A policy is only useful if it changes what someone does on Tuesday morning. The test is simple: can a new team member, reading it for the first time, tell whether they need to ask before building or running something? If not, it is a statement of intent.

Below is a one-page policy you can adapt, followed by notes on each section and how to turn the rules into settings in your tooling. It is deliberately small. Add detail only where your risks demand it.

The template#

[Company] policy for AI workflows and agents

Owner: [name, role]. Version: [1.0]. Last reviewed: [date]. Next review: [date, no more than 6 months out].

1. Scope. This applies to every workflow, agent or automation that uses an AI model to read, decide or produce something for [Company], whether built by IT or by a business team.

2. Inventory. Every such workflow is listed in [the register], with a named owner, its purpose, the systems it can reach, the model provider it uses, the approval tier (section 4) and the date of its last review. A workflow that is not in the register may not run against production data.

3. Roles. Builders may create and edit workflows in their workspace. Runners may trigger them. Approvers decide the steps assigned to them and are never the person who triggered the run. Owners answer for the workflow and may switch it off at any time. Access is given by role, reviewed every [quarter] and removed when someone changes job.

4. Approval tiers.

  • Tier 1, read only or internal drafts: no approval; logged.
  • Tier 2, changes an internal record or sends an internal message: approval for exceptions only, with a stated threshold; sampled review monthly.
  • Tier 3, sends something outside the company, spends or commits money, changes access, or touches personal data of customers or staff: a named approver decides each run before the action.
  • Tier 4, decisions about people (hiring, pay, discipline, credit, eligibility): not permitted to run without Legal and HR sign-off, and always with a human decision.

5. Data. Workflows may use only the data their purpose needs. Secrets live in the credential store, never in prompts, notes or documents. Personal data is not copied into agent memory or knowledge bases unless the register says why and for how long.

6. Records. Each run keeps its inputs, steps, outputs and any approval with who decided and when. Records are retained for [period]. A retry or re-run is a new record that links to the original; originals are not edited.

7. Testing before release. A workflow moves to Tier 2 or above only after it passes a test set of at least [N] realistic cases, including cases where the right answer is to refuse or escalate. Changes to the model, prompt or tools trigger the test again.

8. Incidents. Anyone may pause a workflow they believe is misbehaving. The owner is told at once, the run history is preserved, and a short review is held within [5 working days].

9. Review. The owner reviews the register entry every [quarter]: still needed, still accurate, approvals that were always accepted, failures, cost.

Why it is shaped this way#

Scope says "built by IT or by a business team." The workflows that cause trouble are often the ones someone built in an afternoon. If the policy only covers the official projects, it covers little.

The register is the control. Everything else hangs from it. Gartner's guidance on agent sprawl is built around the same idea, that organisations lose track of how many agents exist, who owns them and what they can do. You can run the register as a spreadsheet at first.

Approval tiers instead of "approve everything". A flat rule trains people to click through. Tiers put the human where the consequences are. The tier boundaries in the template mirror what most teams consider hard to undo: leaving the company, spending money, granting access, and personal data. Adjust them to your reality.

Tier 4 is a stop sign, not a process. Systems that rank job applicants or influence promotion and termination are listed as high-risk examples in Annex III of the EU AI Act, and credit scoring is on the same list. If you operate in the EU, or serve people who are, take advice before building anything in that tier. This line is not legal advice. It is a prompt to ask.

Testing includes refusals. Anthropic's guidance on agent evaluation recommends testing both cases where a behaviour should occur and cases where it should not, to avoid one-sided optimisation. For a business workflow, the "should not" cases are often the important ones: the refund that must be escalated, the email that must not be sent.

Mapping it to frameworks#

If your customers or auditors ask what your policy is based on, two public references are useful. The US National Institute of Standards and Technology publishes the AI Risk Management Framework, released on 26 January 2023 for voluntary use, organised around four functions: Govern, Map, Measure and Manage. NIST also released a generative AI profile in July 2024. ISO/IEC 42001 is an international standard for AI management systems, aimed at organisations that want a certifiable management system.

You do not need to adopt either to use the template. If you later want to, the register covers much of "Map", the tiers and tests cover "Measure" and "Manage", and the owner and review cycle are your "Govern".

Turning rules into settings#

A policy that lives only in a document will drift. Wherever possible, make the tool enforce it. In Cadrix:

  • Roles and permissions decide who can view, create, update, delete and configure each part of the product, enforced on the server.
  • Workspaces keep teams, data and spend apart under one organisation, so a Tier 3 workflow can sit in a workspace with fewer builders.
  • A Human Input step is the Tier 3 approval. The run pauses, shows as Awaiting approval, and the decision becomes part of the run trace.
  • A Condition before the approval implements the Tier 2 threshold.
  • Run history supplies the record in section 6. Retries and re-runs create new linked runs.
  • Datasets and Evaluations support section 7: a dataset of inputs and expected outputs, run against a workflow, with checks such as "contains", "does not contain" or "valid JSON" and measures like tokens and latency.
  • Usage limits put a ceiling on spend.

What no tool does for you: decide who the approvers are, set the thresholds, or read the register.

Where the human goes. Three people, by name. The owner of each workflow, who answers for it. The approver for each Tier 3 step, with a backup. And the policy owner, who runs the quarterly review and has the authority to switch things off.

Rolling it out#

  1. Start with the register. Ask each team to list what they already run. Expect surprises.
  2. Assign a tier to each entry and fix the ones with no owner.
  3. Add approval steps to anything in Tier 3 that lacks one.
  4. Pick the three workflows with the most reach and write test sets for them.
  5. Put the first review in the calendar before you publish the policy.

Sources#

Get new posts by email

Practical notes on governed AI workflows, in your inbox. Unsubscribe whenever you like.

Opens your email app to send the request. We use your address only to send the blog. See the privacy policy.

Keep reading