Executive leadership

Give Every AI Exception an Owner and an Expiry Date

A practical exception record helps leaders bound temporary AI permissions, assign accountability and decide what happens when approval ends.

Top One Percent AI · Practical guidance with linked sources.

An AI workflow can change while its original approval stays untouched. A small internal audience becomes several departments. A temporary workaround survives its sponsor's departure. A missing control remains on a backlog because nobody has to decide whether the exception should continue.

For a leadership team, the useful question is specific. Which departures from normal AI controls are operating today, who is accountable for them, and what happens when their permission ends?

An exception means temporary permission to depart from an internal requirement that the organisation is allowed to waive. It is different from a model error or a service incident. It cannot override law, contractual obligations, required consent or a prohibition that the approver lacks authority to change.

Turn permission into a reviewable decision

NIST's AI Risk Management Framework calls for documented responsibilities and communication routes under GOVERN 2.1, and planned monitoring and periodic review under GOVERN 1.5. These are voluntary risk-management outcomes, not a prescribed exception form. A named owner and expiry date are practical ways to put that guidance to work. Read the NIST AI RMF Core.

Keep the exception record short enough to use, but specific enough that another person could act on it. Include six elements.

• The exact boundary. Name the workflow, affected requirement, permitted users, data and actions. Explain why the standard control cannot currently be met. “AI experimentation” is too broad to approve or monitor.
• The accountable owner and approver. Identify the person responsible for monitoring and closing the exception, a backup, and the person authorised to accept the remaining risk. An owner should have enough authority and capacity to carry out the promised work.
• The remaining risk. Describe what could go wrong, who could be affected and what evidence supports the assessment. Avoid treating a low number of complaints as proof that harm is absent.
• The temporary safeguards. State what replaces the missing control, how its operation will be checked and where evidence will be kept. A safeguard that depends on review also needs assigned review time.
• The expiry and earlier triggers. Choose a bounded period justified by risk and the remediation plan. Specify changes that require review sooner, such as a new data source, audience, capability or incident.
• The closure route. Explain how the standard control will be restored, what evidence will establish completion, and which safe alternative takes over if approval ends.

These fields make the decision inspectable. They also expose weak proposals before approval, such as a mitigation with no staff or a repair with no delivery owner.

Make expiry change something

Consider an illustrative internal FAQ assistant. Its approved reporting dashboard is not ready, but the organisation's policy permits a temporary alternative reporting method. The team requests limited use with approved, non-sensitive reference material and a manual record of review outcomes.

The exception might cover a named user group for two weeks, require daily checks of that record, and forbid expansion to customer information. The service owner maintains the record; the policy owner decides whether the substitute control is adequate. A completed dashboard test closes the exception. A missing manual check or proposed data change triggers an earlier review.

Before the permission expires, the approver chooses among closing it, renewing it on fresh evidence, narrowing it or ending the affected use. Renewal should record what changed and why the original remediation is incomplete. Copying the previous approval should not silently extend permission.

If approval lapses, the documented fallback should take effect. That might mean returning to the existing manual FAQ process, rather than abruptly disabling a service people rely on. NIST's MANAGE guidance supports planned bypass and deactivation procedures that consider downstream consequences and continuity. Read the NIST AI RMF Playbook.

Run an exception review workshop

Organisers can turn this into a 35-minute leadership exercise. Invite an operational owner, the relevant policy or risk owner, a technical representative and someone who understands the people affected.

Use five minutes to introduce a fictional or sanitised exception. Spend ten completing the six fields. Allow ten for challenges: the owner becomes unavailable, demand doubles, or the intended repair slips. Use the final ten to document the decision required, the evidence still missing and the person authorised to resolve it.

The workshop output is a usable decision record, not permission granted by whoever happens to be in the room. Confirm formal approval through the organisation's normal route.

At the portfolio level, review repeated renewals and clusters of similar exceptions. They may indicate an unrealistic policy, an underfunded shared control or a workflow that should be redesigned. The leadership task is to resolve that pattern while keeping each individual permission bounded and accountable.