A gate that can be waived informally is a suggestion. Most AI governance checklists are thorough and still fail, because each gate fails in a predictable way: triage nobody runs, tiering where everything lands in the safe middle, a design review that rubber-stamps decisions already made, acceptance criteria written retrospectively to match what got built, and a release gate waived verbally on the afternoon of the launch with no record and no expiry. This checklist is built around those failures rather than around an ideal process, and every item names the artifact that proves it.
Three properties separate a checklist that holds from one that gets filled in afterwards. Each one is a deliberate constraint on how the document can be used.
The evidence column is what makes a gate enforceable and what turns the completed checklist into your audit trail. An approval on a release ticket, a CI run artifact, a screenshot or automated assertion that the AI disclosure shipped, a rollback test record with a timestamp. Never a memo stating that the control is performed.
A prohibited use. No legal basis for the data use. A contractual restriction not renegotiated. No named individual owner. A high-risk system with no human oversight design. Evaluation impossible because criteria were never agreed. No rollback. Each halts the work and escalates, and none is scored or averaged against anything else.
Most companies adopting this have a dozen systems in production. Run the first two gates on all of them to produce a tiered register in two to three weeks. Run the release gate retrospectively on high-risk systems as an audit, with failures becoming dated tickets rather than rollbacks. Four specific items on elevated-risk systems, register entry only on the rest.
Seven questions where teams already work, with low-risk answers auto-registering the system and anything else opening a review. It must cost nothing to comply with.
Assign a tier before development spend is committed and name the rubric dimension that set it. Tier then drives fourteen named requirements rather than a uniform review.
Evaluation results retained with model and dataset version, monitoring live, disclosure verified in the shipped interface, rollback tested rather than merely available.
Auto-create it when the release gate passes, dated thirty days out and assigned to the technical owner, so drift and rubber-stamped oversight get caught while they are cheap.
Different instruments for different moments. The assessment scores your programme and runs quarterly. This governs one system from idea to production and runs per launch. Merging them fails both ways: a scored programme assessment run per release becomes a ritual, and a pass or fail launch gate run annually governs nothing.
For low-risk work, no. Triage is ten minutes, self-service, and routes most use cases straight through with a register entry. For high-risk work it adds days rather than weeks. If your tiering is calibrated, roughly seven in ten use cases never reach a heavyweight gate. If everything is slowed, the rubric is the problem.
Low-risk approves at engineering manager, elevated-risk at the AI risk owner, high-risk at the executive sponsor with legal on the design gate. The day-thirty review sits with the AI risk owner at every tier. The matrix is meant to be published, because an unpublished approval path gets routed around by accident.
Normal. Run the first two gates across everything to produce a tiered register in two to three weeks, then the release gate retrospectively on high-risk systems as an audit with findings as dated tickets rather than rollbacks. Resist doing more on low-risk systems; that capacity is better spent elsewhere.
Yes, and pretending otherwise is how gates get ignored. Write the rules first: who may waive, in what form, and when it expires. The recommendation is executive sponsor only, in writing, thirty days maximum, with a named closure owner. What does not work is a verbal waiver on the afternoon of the launch.
Only lightly, through a threat model requirement and an adversarial testing item. The AI Security Readiness Checklist is the counterpart and applies a different standard of proof: a governance item passes when the artifact exists, a security item passes only when somebody tried to defeat it and failed.
Drop your details and we'll send AI Governance Readiness Checklist straight to your inbox - no spam, unsubscribe anytime.
Bring us the gate that keeps getting waived and we will work through why with your engineering leads. A working session, not a sales pitch. SECTION 7 - FAQ - 5 to 8 questions
Talk to our engineers