Bounded control exceptions
AI Exception Management Design
Design temporary AI control exceptions with eligibility rules, compensating measures, expiry enforcement and evidence-based closure.
An AI exception process governs a temporary, explicitly authorised departure from an internal requirement. It should make the missing control, operating boundary, alternative protection and end condition visible. Without that structure, “temporary approval” can become an indefinite operating model that nobody has consciously accepted.
Exception management is useful when a specific control cannot yet be implemented and the organisation has authority to consider an alternative. It is not a way to declare unknown legal requirements satisfied or let a project sponsor waive obligations beyond their delegation. The first question is whether the requested departure is eligible for an exception at all.
This guide helps Saudi governance leads, control owners and operations managers design that mechanism within AI governance setup. It uses a hypothetical document-tagging pilot with a missing automated log export to show how a bounded exception can be requested, tested, monitored and closed.
Distinguish an exception from an ordinary risk decision
An exception names a specific internal requirement that will not be met in its normal form. Risk acceptance names exposure the organisation decides to retain within an authorised boundary. They can be related, but they are not identical. A use can retain residual risk while meeting policy, and an exception request can be rejected even if a sponsor is willing to accept risk.
The NIST AI RMF Manage playbook includes different risk-response options. The procedure here is an original design for handling internal control departures. Its status, authority and allowed scope must be established through the organisation's own governance framework.
Require the requester to cite the precise requirement, version and affected activity. “Logging exception” is too broad. “Use manual capture of specified pilot execution evidence while the approved automated export is unavailable” gives the control owner something to assess. If no requirement exists, the issue may be a design decision or unresolved assessment rather than an exception.
Establish which requirements can be varied
Classify requirements by who owns them and what authority is needed to vary them. An internal procedural preference may be adaptable by its owner. A contractual obligation may require a contractual change. An applicable legal requirement cannot be removed by an internal exception record. Where applicability is unclear, obtain the appropriate determination rather than treating uncertainty as discretion.
Create a route for requests that are ineligible. Explain the reason and the alternatives: narrow the use, change the design, obtain a required external decision where applicable or defer the activity. A refusal should be specific enough for the team to act on, while preserving the requirement that caused it.
Connect eligibility to approval routes and delegated authority. The person who owns a control standard may not own the business exposure created by departing from it. Both perspectives may be needed, with a clearly identified final decision within the organisation's authority.
Require a concrete alternative, not just a deadline
An expiry date limits duration but does not protect the activity during the exception. Describe the compensating arrangement: what it does, who performs it, what evidence proves operation and what failure stops the use. Assess whether it addresses the same purpose as the missing control or merely creates administrative work.
For a missing automated log export, manual capture might be considered for a small, controlled pilot if every relevant run can be recorded accurately, access is restricted and completeness is reconciled. That arrangement may become impractical at production volume. The exception should state the workload and environment for which it was assessed.
Use a residual-risk acceptance record where the approved alternative leaves material exposure that must be accepted by the proper authority. Keep the connection explicit: the exception describes the departure and temporary arrangement; the risk record explains what remains and why the bounded decision is supported.
Build an exception record around enforceable boundaries
| Field | Required specificity |
|---|---|
| Requirement | Exact internal requirement and version |
| Reason | Why the standard control is currently unavailable |
| Affected use | Use-case and deployment identifiers |
| Permitted boundary | Users, data, actions, volume and environment |
| Alternative protection | Procedure, owner and evidence of operation |
| Remaining exposure | Known limitations and linked risk decision |
| Validity | Start, expiry, time zone and earlier stop conditions |
| Repair plan | Owner, deliverable and verification needed for closure |
| Decision | Authority, rationale and conditions |
| Review and closure | Monitoring evidence, renewal decision or verified end |
Use stable references to evidence, not unnecessary copies of personal or confidential material. The exception record can itself reveal control weaknesses, so restrict detailed access appropriately. Operators still need a clear implementation notice showing the permitted boundary, required actions and stop conditions.
Do not leave a condition as “until fixed”. That gives no reliable signal to an operator or tracking system. Record a defined expiry and what must happen if repair is incomplete. A later renewal, if permitted, is a new decision with current evidence rather than a silent edit to the original end date.
Worked example: a document-tagging pilot without automated export
Consider a fictional internal pilot that assigns proposed categories to non-critical reference documents. Two authorised reviewers inspect the tags before using them. The planned automated export of execution evidence is unavailable. The organisation's internal pilot standard normally requires that evidence to be retained in the approved repository.
The team requests a fourteen-day exception for the controlled pilot environment. It proposes a manual capture record for every run, including the input reference, configuration version, proposed tags, reviewer outcome and time. The record uses controlled identifiers rather than copying document contents unnecessarily. A separate person reconciles the run list with captured evidence before the next operating session.
The control owner tests the manual procedure on representative runs and checks that a failed or interrupted run is not omitted. The business authority considers the remaining exposure and limits the pilot to the specified document set and two reviewers. No unattended tagging, wider distribution or production throughput is authorised by the exception.
| Condition | Evidence | Effect of failure |
|---|---|---|
| Every run captured | Run list reconciled to manual records | Pause further sessions until the gap is resolved |
| Only the approved document set | Input references and access boundary | Do not process the additional material |
| Reviewer-only use | Named access and review outcomes | Remove unauthorised access and reassess exposure |
| Fixed fourteen-day validity | Explicit start and expiry in the record | Stop the excepted activity unless a new valid decision exists |
The fourteen days are an illustrative internal choice, not a regulatory period. If the automated export remains unavailable at expiry, the team cannot infer an extension from an open repair ticket. It needs an authorised renewal supported by current evidence, a different compliant boundary or a pause.
When export is repaired, closure requires evidence that it captures the required events and that the pilot has switched to it. Completing a development task is not enough. The record also states how the temporary manual evidence will be retained and who verifies that no unresolved run remains outside the agreed record.
Monitor the compensating control as an operating task
Assign the monitoring workload to a role with time and access. If manual evidence capture adds work to reviewers, include it in session planning. A control that depends on optional end-of-day effort may fail precisely when the team is busy. Test the failure path as well as the ideal sequence.
Define what the monitor checks: completeness, timing, permitted population and evidence quality. A count of uploaded files is not necessarily a reconciliation of execution records. A file may be duplicated, missing a failed run or refer to a different configuration. Use the underlying event or work-item identifier to establish correspondence.
Escalate early when the alternative control is becoming unsustainable. Increasing pilot volume can invalidate the original capacity assumption. Link that change to the change-trigger process rather than extending the same exception to a larger workload by habit.
Design expiry so it changes operation
Choose how expiry is enforced: an automated disablement, a release-control check or an accountable operational stop. The mechanism should suit the system and consequence. A calendar reminder alone may be insufficient where the activity can continue unattended.
Notify the owner and decision-maker before the end with the evidence needed for repair or renewal. Keep the expiry itself unchanged unless a new authorised decision takes effect. If a renewal is under review, that state should not be displayed as permission to continue.
Specify what happens to in-flight work. A task started before expiry may need a defined completion or reconciliation path. Do not assume either that all work must be abandoned instantly or that any queued work may run indefinitely. The exception should describe the operational boundary at the transition.
Prevent renewals from becoming permanent policy
A renewal should explain why the repair did not complete, whether the exposure or workload changed and what evidence shows the alternative still works. Review the cumulative duration and previous renewals. Repeated extension can indicate an unrealistic standard, an underfunded repair or a business decision that has never been made explicitly.
Set an escalation point appropriate to the organisation. The response may be to fund the standard control, narrow or retire the use, redesign the requirement through its proper owner or decline further extension. Avoid a universal maximum renewal count without considering context, but ensure repeated departures receive a different level of scrutiny.
Keep the original and renewal records linked. Rewriting the first date loses the history needed to understand how long the organisation operated outside its normal control. The governance metrics should reveal overdue and repeatedly renewed exceptions without implying that every exception is automatically unacceptable.
Separate remediation verification from exception closure
Repair completion is a technical or procedural fact; closing the exception is a governance state change based on that fact and remaining obligations. Identify who verifies the repair, who confirms migration to the standard control and who closes the record. Those roles can be combined only where authority and independence are appropriate.
If the use is retired instead of repaired, confirm that the excepted activity stopped and identify retained evidence, data or downstream commitments. Closing the ticket should not erase a residual obligation. Record the actual reason for closure so future reviews can distinguish fixed, superseded, withdrawn and ended uses.
A failed compensating control may trigger the incident response process as well as exception review. Do not use retrospective approval to disguise an event that happened outside the authorised boundary. Preserve the facts and apply the relevant response and notification decisions through their proper routes.
Test whether the temporary control can absorb the workload
For a manual compensating control, estimate work at the level the procedure actually requires. Include capture, reconciliation, correction and cover, not only the time spent entering a row. An arrangement that appears feasible for a demonstration can become unreliable when sessions increase or the same reviewer has other duties.
Use an explicitly illustrative capacity calculation for the tagging pilot. Assume forty runs in one operating period, five minutes of manual evidence work per run and thirty minutes for reconciliation. That is 40 × 5 + 30 = 230 minutes. If the team has a combined 240 minutes allocated to capture and reconciliation, the arithmetic leaves ten minutes of headroom under those assumptions, before any unexpected correction work. Check each role’s availability separately as well: pooled minutes do not establish that the independent reconciler is available when needed.
If the team proposes one hundred runs with the same procedure, the estimate becomes 100 × 5 + 30 = 530 minutes. It no longer fits the 240-minute capacity. The figures are hypothetical planning inputs, not a recommended throughput or observed service benchmark. Their purpose is to expose the capacity assumption on which the exception depends.
| Scenario | Estimated work | Implication |
|---|---|---|
| 40 runs | 230 minutes | Only 10 minutes below the assumed 240-minute allocation |
| 100 runs | 530 minutes | Exceeds the same allocation by 290 minutes |
| Unexpected corrections | Not included in either base estimate | Measure and reassess before relying on the apparent headroom |
Observe the procedure during the bounded pilot and compare actual effort with the estimate. If capture takes longer, reconciliation reveals gaps or the role is unavailable, revise the operating boundary or stop according to the decision. Do not treat the original spreadsheet as evidence that capacity remains adequate after the facts change.
Specify evidence for expiry, renewal and final closure
Create a small decision packet before the exception ends. It should show the current operating scope, control performance, unresolved gaps, repair status and the requested outcome. The requester should state whether they seek closure after repair, termination of the use or a new exception period. Those outcomes need different evidence and should not share an ambiguous “extend or close” status.
For renewal, ask whether the temporary arrangement has actually operated as agreed. In the tagging case, review reconciliation results and any failed captures. Explain delays in the standard export and whether the repair plan remains credible. If the alternative has failed, extending its date without changing the design does not resolve the reason it was considered acceptable.
For closure after repair, verify the standard export against the required event set and check the transition period. Confirm which runs were captured manually, which by the automated mechanism and whether any gap or duplicate requires reconciliation. Retain evidence of the switch so later investigation can locate the correct record source for an earlier run.
For termination, verify that the excepted activity has stopped and that accounts, scheduled jobs and remaining data are handled through the agreed process. The exception can end without the original defect being repaired, but the closure reason should make that clear. Otherwise a future team may assume the standard control was fixed and reuse the same configuration.
Assign who accepts each packet and how the operator receives the result. A control owner confirming that export works is not necessarily the authority to renew residual exposure. A business decision to stop does not itself disable a scheduled task. The final handoff should close both the governance record and the relevant operating action, with their different evidence preserved.
Test the process with uncomfortable cases
Rehearse a request that cites no requirement, one that seeks to vary an ineligible obligation, one with no credible compensating control and one that expires while repair is unfinished. Ask operators what they would do in each case. The process should produce clear dispositions rather than sending every difficult case to an undefined senior sponsor.
Test the permissions of the tracking tool: who can change dates, mark controls verified or close records? Administrative access should not become undeclared risk-acceptance authority. Retain the decision history and make later edits attributable.
Discuss AI exception management design with Open for AI using an actual control gap and the operating activity it affects. A useful design turns that gap into a bounded, visible decision with a tested alternative and a real end condition, while preserving the requirements the organisation has no authority to waive.
FAQ
Your questions, answered.
What makes a request an AI governance exception?
It identifies a specific internal requirement that will not be met in its normal form for a defined use and period. The request should cite the requirement and propose an eligible alternative. If no requirement exists, the issue may be a design choice or unresolved review rather than an exception.
Can an internal AI exception waive a legal obligation?
An internal record cannot remove an applicable legal obligation or create authority beyond the organisation’s delegation. Establish the requirement’s source and who can vary it. Where applicability is unresolved, seek the appropriate determination. The alternatives may be redesign, narrower scope or deferral rather than approval of the requested departure.
How is an AI exception different from residual-risk acceptance?
The exception records a departure from a requirement and its temporary alternative. Risk acceptance records exposure the proper authority decides to retain. They can be linked, but neither automatically establishes the other. A sponsor’s willingness to retain risk does not by itself make a requirement eligible for variation.
When can manual logs compensate for missing AI log export?
Only within a boundary where the procedure is credible, tested and sustainable. Define every event to capture, the responsible role, reconciliation, access controls and failure response. In the illustrative pilot, the arrangement applies to a limited document set and two reviewers. It should not silently expand to unattended or production-scale work.
Does an open repair ticket extend an AI exception?
No extension should be inferred. The exception ends according to its recorded validity unless a new authorised decision takes effect. A renewal needs current evidence about the alternative control, remaining exposure and repair delay. Operators need a defined stop or fallback when expiry arrives before the repair is complete.
What evidence closes an AI control exception?
Show that the standard control now performs the required function, the affected use has moved to it and remaining temporary obligations are handled. Name the verifier and closure authority. A completed development task or uploaded screenshot may be insufficient if it does not demonstrate the control’s actual operating coverage.
How should repeated AI exception renewals be handled?
Review cumulative duration, causes of delay, changed workload and evidence that the alternative still works. Escalate repeated departures through the appropriate authority. The response may be funding repair, narrowing use, revising the internal requirement properly or stopping the activity. Preserve the linked history instead of rewriting the original expiry.
What happens when an AI compensating control fails?
Apply the recorded stop or containment condition and assess whether the event also requires incident response. Preserve facts and the affected operating period. Do not use retrospective exception approval to conceal activity outside the authorised boundary. Restart or continuation requires the relevant evidence and decision through the proper route.