Manage AI governance exceptions properly

Updated 17 October 2026. This article has been revised to separate the policy timeline from the product argument. See the current AI Act timeline for the category-specific dates and primary reference.

An exception should be visible enough to review and narrow enough to end. Otherwise it becomes the normal process with a more reassuring name.

Manage exceptions as decisions

Start by identifying the rule or control being varied and the reason. Record who may approve the exception and whether they have the authority to do so. Internal approval cannot waive an obligation the organisation is legally required to meet.

For an illustrative test deployment, an exception might permit a limited group to use a new tool under additional review. The record should specify the users, data, actions and expiry. A vague exception for “innovation” is difficult to evaluate or revoke.

Define the evidence needed to close the exception. That might be a completed permission test or a change to the workflow. If closure depends only on the passage of time, the team may be waiting rather than learning.

Review renewals against what changed. If the same exception is extended repeatedly, ask whether the original control is impractical, the remediation is under-resourced or the deployment should be restricted. Each answer calls for a different decision.

What to do with this

An exception register should expose unresolved work. If it makes unresolved work easier to forget, it has become part of the problem it was meant to manage.

Record the decision, the responsible owner and the evidence still missing. The decision-record example shows a lightweight way to do that. Where a claim concerns system behaviour, connect it to evaluation evidence. These are proposed product practices, not a finding that a system complies with the law.

Primary timeline reference: European Commission, AI Act. The operational recommendations above are my analysis.