A policy with no exception path does not produce compliance; it produces workarounds. When a team has a real deadline and a rule that blocks it, and the only official answer is "no," the practical answer becomes a personal account, an unapproved tool, or a quiet reinterpretation of the rule. An exception process converts that pressure into something governable: a documented, time-boxed, compensated deviation that an auditor can read and a reviewer can revoke. Here is a structure to adapt.
What an exception request must contain
Keep the request to one page with six mandatory fields:
The restriction being excepted — cited by policy section, so nobody later argues about what was waived. The business need — what breaks or what is lost if the exception is denied, stated concretely. Scope — which team, which use case, which data, which platform; an exception without boundaries is a policy change in disguise. Duration — every exception expires; 90 days is a common default, with renewal requiring a fresh look rather than an automatic rubber stamp. Compensating controls — what reduces the risk the original rule was managing: extra review, tighter access, added logging, reduced data scope. A named owner — one person accountable for operating within the exception and for winding it down.
Who approves, and where it is recorded
Route approval to the function that owns the risk, not the function that wants the exception: data-handling exceptions to privacy, security-control exceptions to security, output-reliance exceptions to the business risk owner, with anything cross-cutting or precedent-setting escalating to the AI steering committee. Record every granted exception in an exception register — ideally a field on the use case's entry in your AI registry — with the request, the approval, the expiry, and the compensating controls. Review the register on a cadence: expired exceptions get closed or consciously renewed, and any exception renewed twice is a signal the underlying policy needs amending. That last point deserves emphasis — a healthy exception process feeds policy revision. Exceptions are how a policy learns.
A worked example the platform can enforce
Some exceptions can be enforced by configuration rather than trust, which is the strongest kind. A real example from the Claude API: suppose your organization has a zero-data-retention (ZDR) arrangement as a standing control, and one team has a strong need for Claude Fable 5 — which is a designated Covered Model requiring 30-day data retention and is not available under ZDR. Requests from an organization whose retention configuration does not meet that requirement simply fail with a 400 invalid_request_error.
The documented resolution maps exactly onto a scoped exception: a ZDR organization can enable 30-day retention for a single workspace (in the Console under Settings > Workspaces > Privacy controls), allowing that one team to use the model there while every other workspace keeps ZDR. The exception register entry and the platform configuration then describe the same reality — scope (one workspace), deviation (30-day retention instead of ZDR), and enforcement (the API rejects the model everywhere else). Where your platform offers this kind of scoped configuration, prefer it over exceptions that live only on paper.
Fast exceptions without losing the audit trail
Urgency is the usual argument against process, so build the fast path in: a designated approver-on-call for time-critical requests, a 48-hour target for straightforward cases, and a rule that emergency verbal approvals must be registered within two business days or they lapse. If most requests are arriving marked urgent, that is diagnostic — either the policy is too broad or the standard path is too slow, and both are fixable.
Where to go next
Exceptions complement the fast-track review path — one bends a rule with controls, the other right-sizes review for low-risk work. See also department-level policies for why addenda must never smuggle in permissions that belong here.