AI governance in practice: what to define before giving a system autonomy

Giving an AI system autonomy in a critical operation is a governance decision, not just a technology one. The good news is that governing AI doesn't have to be bureaucratic: a small set of explicit definitions addresses most of the risks.

1. Autonomy levels

Not every action carries the same risk. Classifying the actions AI can perform into levels makes the debate concrete. The model we use has four levels:

• Executes: low-risk, reversible actions (query, classify, generate drafts)
• Executes and notifies: routine actions within limits (renew a license below a given amount)
• Proposes and waits: actions that need human approval (significant movements, policy changes)
• Never executes: actions out of scope by explicit decision

2. Access scope

AI should only access the systems and data required for approved use cases. This limits the impact of a mistake and simplifies auditing. The principle is the same one applied to people: least privilege.

3. Explainability and records

Every action needs to be reconstructible: which data was consulted, which rules were applied, what the reasoning was and what the outcome was. Without that, there's no way to audit, learn from mistakes or be accountable to regulators.

4. Roles and review

Define who approves changes to the guardrails, who reviews exceptions and how often performance is evaluated. A small committee and a periodic ritual are enough for most operations.

5. Safe stop

It must be possible to pause the AI at any time without impacting systems. It sounds obvious, but it needs to be tested — not just declared.