AI Policy Review Cadence, in depth: tiered intervals, event triggers, review packs, policy as code and cadence metrics

Why a fixed annual review fails for AI

An annual review is the default in many compliance programmes, and for AI it is usually too slow and too blind. Too slow because a policy that names an approved model, a data-retention setting or a list of permitted tools can be wrong within weeks of a vendor release. Too blind because a fixed date does not notice that something changed; it only notices that time passed.

The opposite failure is reviewing everything constantly, which burns the reviewers' time on stable documents and trains everyone to rubber-stamp. A useful cadence therefore has two parts: a calendar whose interval depends on how fast each policy's subject changes, and a set of triggers that pull a specific policy forward when an event makes it suspect. Both feed the same review process, and both end in a recorded decision.

Roles keep this from depending on goodwill. Each policy has one owner who assembles the review pack and proposes a decision, a small set of required reviewers fixed by tier (security, legal, privacy, the affected system owners), and an approver who can accept residual risk: for tier 1 and 2 policies that is usually the governance council, for tier 3 and 4 a named engineering or security lead. Separately, each trigger has a watcher, the person or automated feed responsible for noticing the event. Policies that bind every employee, such as an employee AI usage policy, also need a communications owner, because an amendment nobody hears about changes nothing.

Inventory and tier your policies

Start with an inventory. List every AI-related policy, standard and procedure, its owner, the controls that enforce it, and the systems it covers. Then tier each by volatility of the subject and severity of being wrong. A principles document changes rarely; a list of approved models and their permitted data classes changes constantly. The intervals below are a reasonable starting point, not a standard; adjust them after a year of data on how often reviews actually change anything.

The lower tiers should derive from the higher ones. If an operational list contradicts a standard, that is a finding for the review, not a judgment call for whoever notices.

Event triggers

Triggers are what make a cadence responsive. Write them down as a catalogue with an owner who watches for each and a deadline by which the affected policies must be reviewed. A starting set:

Regulatory triggers show why dates must be tracked, not assumed. The EU AI Act entered into force in August 2024 with obligations phased in over several years, and in 2026 EU lawmakers agreed a "Digital Omnibus" package that defers the main high-risk obligations, reported as moving the stand-alone high-risk date from August 2026 to December 2027. Check the text as finally published in the Official Journal before relying on any date. A team that had hard-coded the original date into a policy needed a triggered review either way.

Incidents are the richest trigger. Every post-incident review, as described in AI incident response, should end with an explicit question: which policy should have prevented this, and does it need to change?

The review pack and the three decisions

A review is only as good as what the reviewers see. Assemble a standard review pack for each policy so that reviews compare evidence with text rather than reread text alone:

• The current version, its change history and the decision record from the last review.
• Exceptions granted since then, with their age and whether they were renewed.
• Incidents, near misses and red-team findings that mention the policy's subject.
• Enforcement data: what the controls actually allowed and blocked, for example tool calls denied, prompts redacted, models used by traffic share.
• Drift: differences between what the policy says and what configuration enforces.
• External changes since the last review: vendor notices, regulatory updates, new published attacks.

Every review ends in one of three decisions. Keep re-dates the policy and records why. Amend creates a new version with a diff, an effective date, and a rollout plan for the controls, training and attestations it touches. Retire removes the policy and, just as importantly, its now-pointless controls and exceptions. A decision that never reaches enforcement is not finished; track rollout to completion as part of the same record.

Policy metadata enforced in CI

Cadence fails silently when due dates live in someone's calendar. Store policy metadata next to the policy text in version control and let CI enforce it:

# policies/approved-models.yaml
id: POL-OPS-007
title: Approved models and permitted data classes
tier: 3
owner: platform-security@example.com
version: 4.2
last_reviewed: 2026-08-20
interval_days: 60
triggers: [vendor_model_change, new_capability, high_redteam_finding]
controls: [gateway.model_allowlist, dlp.prompt_classes]
open_triggers: []

# ci/check_policy_cadence.py
import datetime as dt, pathlib, sys, yaml

today = dt.date.today()
problems = []
for path in pathlib.Path("policies").glob("*.yaml"):
    pol = yaml.safe_load(path.read_text())
    due = pol["last_reviewed"] + dt.timedelta(days=pol["interval_days"])
    if today > due:
        problems.append(f"{pol['id']} overdue since {due} (owner {pol['owner']})")
    for trig in pol.get("open_triggers", []):
        if today > trig["review_by"]:
            problems.append(f"{pol['id']} trigger {trig['kind']} past {trig['review_by']}")
    if not pol.get("controls"):
        problems.append(f"{pol['id']} has no enforcing control")
if problems:
    print("\n".join(problems))
    sys.exit(1)

Run the check nightly and on every change. When a trigger fires, the person who watches it adds an entry to open_triggers with a review_by date; the review clears it. The same metadata lets you generate the review calendar, find policies without enforcing controls, and show an auditor every review with its date and decision from git history alone.

Worked example: a vendor retires a model

A company runs a customer-support assistant on a hosted model. Its tier 3 approved-models policy allows that model for data up to "customer confidential" because the vendor contract excludes training on inputs and retains logs for 30 days. On 1 September the vendor announces the model version will be retired in 90 days and recommends a successor.

The platform owner records a vendor_model_change trigger with a review date of 1 October, well ahead of retirement. The review pack shows that the successor is offered under the same contract but with a different default log retention, that red-team prompts from last quarter succeed at a different rate against it, and that two teams already hold exceptions to use the successor in staging. The reviewers amend the policy to version 4.3: the successor is approved for the same data classes on condition that retention is set explicitly in the account configuration, the regression suite of injection prompts must pass before switching, and the staging exceptions expire on the switch date.

The rollout record lists three tasks: the gateway allowlist change, the retention setting with a screenshot or API output as evidence, and the regression run attached to the change. The review is closed only when all three are done. Two months later the calendar review finds nothing new and is a five-minute keep, which is what a well-triggered cadence should make common.

Measuring whether the cadence works

Measure the cadence itself, monthly, and report it to the governance body:

• Overdue rate: share of policies past their calendar date. Should be near zero.
• Trigger latency: days from a trigger firing to its review decision, against the deadline.
• Change rate by tier: share of reviews that amend. Near zero for a tier suggests the interval is too short; very high suggests it is too long or the policy is too detailed.
• Exception load: open exceptions per policy and their median age. Growth means policy and practice have diverged.
• Rollout completion: days from an amend decision to enforcement evidence.
• Drift findings: mismatches between policy text and enforced configuration found by checks.

Frameworks expect this kind of evidence. ISO/IEC 42001, the AI management system standard, requires internal audits and management reviews at planned intervals. The NIST AI Risk Management Framework's GOVERN function calls for planned ongoing monitoring and periodic review of the risk management process, with defined roles and review frequency. Neither prescribes your intervals; both expect you to set them, follow them and show the record, which is what an AI compliance audit will ask for.

Failure modes

• Calendar-only cadence. Reviews happen on time and miss the model change that happened the week after the last one.
• Review without evidence. Reviewers reread the text, find it reasonable, and re-date it, while enforcement has drifted.
• Decisions that never ship. An amended policy whose gateway configuration was never changed is worse than no change, because records say the risk is handled.
• Exception sprawl. Permanent exceptions become the real policy. Give every exception an expiry and count it in the review pack.
• Orphaned policies. The owner leaves and nothing is reviewed again. Treat owner changes as a trigger and fail CI on unknown owners.
• Review fatigue. Too-short intervals on stable policies produce rubber stamps. Use the change rate to lengthen them.

Trade-offs

What to do next

1. Inventory every AI policy, standard and procedure with its owner and enforcing controls.
2. Assign each a tier and an initial interval, and record the reasoning.
3. Write the trigger catalogue with a watcher and a review deadline for each trigger.
4. Define the review pack and build the queries that fill it automatically.
5. Move policy metadata into version control and add the overdue check to CI.
6. Require every decision to name its rollout tasks and close only on enforcement evidence.
7. Give every exception an expiry date and report exception load per policy.
8. Report overdue rate, trigger latency and change rate monthly, and retune intervals after a year.
9. Re-check regulatory effective dates against the official texts whenever legal guidance changes.