Speed without control is recklessness. Control without speed is irrelevance. The model balances both by defining exactly five decision points between an AI idea and a model in production, and by refusing to let any of them become a meeting that approves whatever is put in front of it.
The components are not decoration. They are the structural skeleton that prevents a gate from collapsing into a meeting that approves whatever is presented to it. A checkpoint without a rejection path is not a checkpoint. It is a status update with a signature line.
Should we build this at all?
Taken before the institution spends design effort. It confirms that the use case aligns with strategy, risk appetite and regulatory constraints. Entry requires a business case, a use case description, and an initial risk assessment covering personal data, cross-border flows and high-impact decisions.
Approval sits with the AI Governance Committee, or with a designated approver for low-risk cases under a fast-track the Committee has authorized. Rejection is not failure here. It is the cheapest rejection available, because nothing has been built yet.
Will this design survive validation?
Taken before development begins, because development is where the institution spends the largest share of its data science labor. Gate 2 exists to stop that spend being committed to a design that cannot pass Gate 3. Entry requires the model design specification, a data sourcing plan, a compliance checklist including a data protection impact assessment where required, and vendor assessment where third-party models are involved.
Authority is split deliberately: the Model Validation Forum for technical review, the AI Governance Office for compliance review. Rejection sends the work back to redesign, or escalates to the committee where there is genuine disagreement on technical feasibility.
Is what the team claims about this model actually true?
The moment the institution either confirms or denies the development team's claims. It is independent by design. Entry requires completed training, the model card, complete bias testing with documented results, tested explainability with sample explanations and a coverage assessment, and performance metrics meeting the design thresholds.
Evidence is the heaviest of any gate: validation report, bias audit with statistical tests and demographic breakdowns, explainability documentation, a drift detection plan specifying how drift will be monitored after deployment, and the monitoring dashboard specification. For Islamic finance institutions Sharia verification happens here, inside the gate rather than beside it. The Sharia Supervisory Board reviews the validation report for Riba, Gharar and Maysir alignment, and the validation team cannot approve a Sharia-critical system without that sign-off.
Are we ready to own the decisions this will produce?
The moment of institutional commitment. Once the model is in production it is producing decisions the institution will own. Entry requires approved validation, a production environment that is genuinely ready, a documented runbook covering incident response and escalation and rollback, completed training for users and support and governance reviewers, and any required regulatory notifications already sent.
All production deployments route through the AI Governance Committee. For systems classified Critical, the board must be informed before deployment: not as an approval request, but as an assertion that the board is aware of what the institution is about to commit to.
What did production reveal that testing could not?
Gate 5 closes the loop. It verifies the deployed model performs as expected in production, identifies what was not visible in testing, and feeds the institution's learning back into subsequent gates. Review runs at thirty, sixty and ninety days, then quarterly. Exit is continue, enhance monitoring, retrain, or retire.
Gate 5 has no rejection path, and that is deliberate, because Gate 5 is review rather than approval. The model is already live. Its findings can trigger Gate 3 re-validation or retirement, which is a stronger consequence than a rejection would be.
Deployment velocity is measured across the whole run, from Gate 1 to Gate 4, with targets below ninety days for low-risk systems and below one hundred and eighty days for high-risk ones. The gates are meant to be timed, not merely passed. An institution that cannot say how long its own gate run takes is not operating the model, it is describing it.
Every framework has limits, and a framework published without them asks to be adopted on faith. These are the two ways a gate model fails in practice, both of which are structural rather than procedural.
Forms filled, boxes checked, no genuine challenge. This happens when the reviewing function lacks the authority to delay a deployment, or when business pressure overrides risk judgment often enough that reviewers learn the political price of saying no. The remediation is structural, not cultural: explicit veto authority for high-risk systems, board-level backing when a reviewer escalates, and escalation thresholds that fire automatically regardless of anyone's judgment about whether escalation is warranted.
The veto is the load-bearing element. A committee that has never refused anything is not evidence of good submissions. It is evidence that the gate is decorative, and an examiner will read it that way.
Run every system through the full five-gate sequence regardless of risk and the business will correctly identify the model as overhead, then route around it. The documented remediation is a fast-track for low-risk systems, one week against the two-week standard, with the full process reserved for medium and high risk. That requires a working risk classification upstream, which means the gate model depends on a capability outside itself. An institution that cannot classify risk consistently cannot operate a tiered gate, and a gate that is not tiered will eventually be bypassed.
The Five-Gate Deployment Model is original work by Dr. Nabeel A. Khan, specified in AI Governance and Compliance Frameworks for the Middle East. It is one component of the governance operating model, which is in turn one of the six pillars of the MESA Framework's third layer, the Operational Machinery.
It is applied commercially through the AI governance consulting practice. In the AI Governance Teardown the gate model is one of the things the examination reads an institution against: whether the gates exist, whether they carry all five components, whether anything has ever been rejected at them, and whether the run is timed.
You can locate your own governance maturity against the wider framework with the free Readiness Self-Assessment. The gate model sits under its Layer 3 questions.
Gate 1 is Use Case Approval, taken before design effort is spent. Gate 2 is Design Approval, taken before development begins. Gate 3 is Validation Approval, the independent confirmation that the model performs as claimed. Gate 4 is Deployment Approval, the final go or no-go before production release. Gate 5 is Post-Deployment Review, which closes the loop at thirty, sixty and ninety days and then quarterly.
It is designed not to, and the model is explicit that speed without control is recklessness while control without speed is irrelevance. Deployment velocity is measured from Gate 1 to Gate 4, with targets below ninety days for low-risk systems and below one hundred and eighty days for high-risk ones. Where business units have objected to Gate 1 as a velocity tax, the documented remediation is a fast-track for low-risk systems at one week against the two-week standard, with the full process reserved for medium and high risk.
Explicit veto authority. The approving committee must be able to refuse a deployment that does not meet governance standards, and that authority is the structural condition under which Gate 4 is not a rubber stamp. Without it, and without board-level backing when the second line escalates, the gate degrades into governance theater: forms filled, boxes checked, no genuine challenge.
Because Gate 5 is review rather than approval. The model is already in production by then, so the question is not whether to admit it but what to do about what production revealed. Its findings can trigger Gate 3 re-validation or retirement of the model, and they feed back into how subsequent Gate 1, 2 and 3 reviews are conducted.
Sharia compliance verification is a component of Gate 3 rather than a parallel process. The Sharia Supervisory Board reviews the validation report for Riba, Gharar and Maysir alignment, and the validation team cannot approve a Sharia-critical system without that sign-off. Dual validation is a non-negotiable gate component, not an ethical overlay applied afterwards.
It sits inside MESA. Layer 3 of the MESA Framework, the Operational Machinery, has six pillars, and the governance operating model is one of them. The Five-Gate Model is how that pillar converts a strategic intention to deploy AI into a sequence of decisions someone is accountable for. MESA tells you which layer is failing; the gate model is part of what Layer 3 looks like when it is working.
Most institutions that describe a gate process have some of the gates, some of the components, and no record of anything ever being rejected. That is not a process problem to be fixed with a better template. It is a question about where authority actually sits, which is what the examination is for.