Gate

a gate without enforcement is just a sign that says “please don’t” and everyone walks past it.

"we have a deployment gate. it requires sign-off from three people. the model went to production last tuesday. nobody signed anything. nobody noticed."
"our governance process includes a risk review gate. the risk review is a fifteen-minute meeting where everyone says 'looks fine' and then the model ships."
"engineering asked if they could skip the testing gate because the deadline is friday. we said no. they deployed on thursday. the gate was not in the CI/CD pipeline. it was in a confluence page."
Share this one
Canonical Definition

A mandatory checkpoint that must be passed before an AI system can progress to the next stage. Gates are binary: pass or fail. A gate without enforcement is a suggestion, not a control. Each gate defines what must be true, who approves, what evidence is produced on passage, and what happens on failure.

Why It Matters

Gates are where governance becomes structural. Every organisation has governance processes — risk reviews, approval workflows, compliance checks. The question is whether those processes can actually prevent an AI system from reaching production when the criteria are not met. In most organisations, they cannot. The deployment proceeds anyway, and the governance process catches up after the fact, if at all.

The problem is not that organisations lack checkpoints. It is that checkpoints are implemented as social conventions rather than technical enforcement. A gate that exists only in a process document can be bypassed by anyone with deployment access and a deadline. A gate embedded in the CI/CD pipeline, the deployment workflow, or the model registry cannot be bypassed without triggering an audit event.

Gates also serve an evidence function. When a gate is passed, it produces an artifact: who approved, when, what criteria were evaluated, what the result was. This artifact flows to the Evidence Factory. When a gate fails, it produces a different artifact: what failed, why, what remediation is required. Both outcomes generate governance evidence. A process without a gate generates neither.

The Stress Test

Your organisation has a documented deployment gate requiring risk assessment sign-off, bias testing completion, and technical review before any AI model enters production. An engineering team has built a customer-facing recommendation engine. The business deadline is the end of the quarter. Risk assessment is pending — the risk team is understaffed. Bias testing found an issue that requires retraining. The technical reviewer is on leave.

The engineering lead deploys to production. The gate was documented in the governance framework but was not enforced in the deployment pipeline. No technical mechanism prevented the deployment. No alert was triggered. The governance team discovers the ungated deployment three weeks later during a routine check.

The model has been serving recommendations to customers for twenty-one days without passing its mandatory governance checkpoint. The question is not whether the model is compliant. The question is whether the gate exists as a control or as a wish.

In the Wild

Software Engineering — DevOps, 2010–Present
The Lesson from Deployment Gates in Software Delivery

The software industry learned the gate lesson over two decades of DevOps practice. Organisations that implemented deployment gates as documentation requirements found they were routinely bypassed under pressure. Organisations that implemented gates as automated pipeline stages — blocking deployment until tests pass, security scans complete, and approvals are recorded — achieved both higher compliance and faster delivery, because the gate removed ambiguity about what “ready” means.

The AI governance field is recapitulating this lesson. Gates documented in governance frameworks but not enforced in deployment infrastructure are functionally identical to having no gates.

Software engineering spent twenty years proving that a gate without technical enforcement is a suggestion. AI governance is learning the same thing, with higher stakes.

Aviation — Stage-Gate in Safety-Critical Systems, Ongoing
Why Aviation Does Not Have Optional Checkpoints

Aviation certification uses a stage-gate process where aircraft systems cannot proceed to the next development phase without formal certification authority approval. DO-178C (Software Considerations in Airborne Systems) defines verification objectives that must be satisfied before software is approved for flight. These gates are non-negotiable: no amount of schedule pressure, business rationale, or executive mandate can override a certification gate. The consequence of bypassing a gate is not a governance finding — it is criminal liability.

Aviation does not have a gate compliance problem because the consequences of non-compliance are unambiguous. AI governance often has a gate compliance problem because the consequences are still being defined.

Financial Services — Model Validation Gates, 2021–2024
The Model That Skipped Validation and Made It to Production

Multiple banks have disclosed supervisory findings where models entered production without completing independent model validation — the financial services equivalent of a deployment gate. In each case, the validation policy existed, the validation team existed, and the validation process was documented. But the model registry did not enforce validation completion as a prerequisite for production deployment. Models could be promoted by anyone with the correct permissions, regardless of validation status.

After findings, institutions that embedded validation gates in their model lifecycle management platforms saw bypass rates drop to near zero.

The policy said validation is required. The system allowed deployment without it. Only one of those facts mattered.

How to Govern It

A gate is not a meeting. It is a technical enforcement point with a binary outcome and an evidence trail.

Within the AI Control Index, gates operate across GRC (S1) and AI Engineering (L5):

  • Gate criteria — Each gate defines explicit, measurable criteria. Not “risk has been assessed” but “ART-06 (Risk & Impact Record) exists, is current, and has been signed by the risk owner.” Vague criteria produce vague gates.
  • Technical enforcement — Gates are embedded in deployment pipelines, model registries, or governance workflow platforms. A gate that can be bypassed by deploying through a different path is not a gate. It is a detour sign.
  • Binary outcome — Pass or fail. No conditional pass, no “pass with caveats,” no “approved pending.” If the criteria are not met, the system does not progress. If the organisation needs an exception process, that process produces its own evidence and requires explicit authority approval.
  • Evidence on passage — When a gate is passed, an artifact is produced: approval record, criteria evaluation, timestamp, approver identity. This artifact is deposited in the Evidence Factory.
  • Failure procedures — When a gate fails, the framework defines what happens: remediation requirements, re-evaluation timeline, escalation path. A gate without a failure procedure is a one-way door with no instructions on the other side.

When It's Relevant

Every lifecycle transition of an AI system. Gates are the structural mechanism that prevents ungoverned systems from reaching production and ensures that governance obligations are satisfied before progression, not after.

Gates are most critical at:

  • Development-to-staging transition (has the system been evaluated against its testing plan?)
  • Staging-to-production transition (have all mandatory artifacts been produced and approved?)
  • Model update deployments (does the updated model meet the same governance criteria as the original?)
  • Periodic re-certification (does the system still meet its governance obligations after N months in production?)
  • Incident response (has the root cause been resolved and verified before the system returns to service?)

See gates in the framework. Gate controls are operationalised through S1 (GRC) and L5 (AI Engineering) in the AI Control Index v6.0.

Open Framework →

Related Terms

References

  1. [1] Cooper, R.G. (2008) ‘Perspective: The Stage-Gate Idea-to-Launch Process — Update, What’s New, and NexGen Systems’, Journal of Product Innovation Management, 25(3), pp. 213–232.
  2. [2] European Parliament and Council (2024) Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act). Official Journal of the European Union, L series. Articles 9 (Risk Management), 43 (Conformity Assessment).
  3. [3] RTCA (2011) DO-178C: Software Considerations in Airborne Systems and Equipment Certification. Radio Technical Commission for Aeronautics.
  4. [4] Board of Governors of the Federal Reserve System (2011) SR 11-7: Guidance on Model Risk Management. Federal Reserve, Washington, D.C.
  5. [5] Forsgren, N., Humble, J. and Kim, G. (2018) Accelerate: The Science of Lean Software and DevOps. Portland: IT Revolution Press.
  6. [6] ISO/IEC (2023) ISO/IEC 42001:2023 — Artificial intelligence — Management system. International Organization for Standardization. Clause 8.1 (Operational Planning and Control).
  7. [7] Raji, I.D., Smart, A., White, R.N., Mitchell, M., Gebru, T., Hutchinson, B., Smith-Loud, J., Theron, D. and Barnes, P. (2020) ‘Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing’, Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency (FAT*), pp. 33–44.

AI Control Index v6.0 · Glossary · June 2026 · i-DEPOT 158508 (BOIP) · CC BY-NC-ND 4.0

By Jeroen Janssen, Apparens