S8.04 - Gating

S8.04 ? Gating

flowchart LR
    A[Background problem:
policy without operational control] --> B[RAIDT:
run-level evidence framework]
    B --> C[[Gating:
operational release control]]
    C --> D[Evidence pack]
    C --> E[RAIDT score profile]
    C --> F[Proceed / Hold / Escalate / Redesign]
    D --> G[Reviewer reconstruction]
    E --> H[Governance readiness]
    F --> H
    I[Healthcare]
    J[Finance]
    K[Public services]
    L[Cybersecurity]
    M[Enterprise productivity]
    I --> C
    J --> C
    K --> C
    L --> C
    M --> C
    H --> N[Audit readiness]
    H --> O[Organisational learning]
    H --> P[Policy alignment]

? Star S8 - Implementation and Operations

Star context: Shows how RAIDT can be adopted manually, semi-automatically or through orchestration, and how it becomes part of real governance routines. In this star, gating explains how RAIDT moves from assessment to operational control by determining whether a specific GenAI run may proceed, must be reviewed, or should be stopped.

Academic picture

Definition / background

Gating means that a run, workflow, or release step cannot proceed unless predefined governance conditions are satisfied. In RAIDT, those conditions are not limited to a general sign-off or a high-level policy statement. They are tied to run-level evidence, documented review criteria, and minimum thresholds that indicate whether a specific use of a generative AI system is sufficiently supported for the intended context.

Conceptually, gating comes from control practices in safety-critical systems, software delivery, quality assurance, and regulated organisational workflows, where progression is conditional rather than automatic. The RAIDT adaptation is important because generative AI introduces variable outputs, context-sensitive risks, and frequent changes in prompts, models, data inputs, and use conditions. A governance framework therefore needs a way to stop weakly evidenced runs from being treated as operationally acceptable merely because they are technically possible.

Gating differs from monitoring, which observes behaviour during or after operation, and from post-run review, which examines performance retrospectively. Gating is pre-deployment or pre-release control at the point of decision. It answers the question: should this run be allowed to proceed to publication, deployment, user-facing use, or organisational reliance?

Inside RAIDT, gating belongs centrally because RAIDT treats the run as the unit of governance. A gate uses the run-level evidence pack and the five-pillar score profile to decide whether a run is ready, conditionally ready, or not ready. In that sense, gating is the operational bridge between evidence generation and governance action.

Why this concept matters

Many AI governance approaches fail at the moment of operational decision. They define principles, expectations, or review ideals, but they do not specify what actually prevents a weakly evidenced GenAI run from going live. Gating solves that problem by introducing a practical control point. It turns governance from something advisory into something enforceable.

Without gating, an organisation may still collect logs, discuss ethics, or produce model documentation, yet allow low-quality or poorly understood runs to influence decisions, communications, or services. This creates a false sense of governance maturity. The presence of paperwork does not by itself stop a problematic output from being used.

For organisations using GenAI in real work, the absence of gating increases the risk of avoidable release errors, undocumented exceptions, inconsistent reviewer behaviour, and poor accountability when something goes wrong. A gate also reduces ambiguity: it clarifies who decides, on what basis, with what evidence, and according to which threshold.

RAIDT uses gating to move governance from principles and assertions toward evidence, reviewability, contestability, and audit readiness. It matters because it creates a repeatable way to say not only what responsible use should look like, but also what must be true before a run is allowed to count as operationally acceptable.

Key idea: Gating matters because it makes RAIDT actionable by tying release decisions to run-level evidence rather than organisational optimism.

What this item controls

Whether a specific GenAI run may proceed to deployment, publication, user-facing release, or organisational reliance.
Whether the available run-level evidence is sufficient for the intended task, context, and risk level.
Whether score thresholds across the RAIDT pillars are high enough, or whether exceptions require explicit review.
Whether weak evidence triggers hold, escalation, redesign, or additional testing rather than silent progression.
Whether governance is enacted consistently across manual, semi-automated, and orchestrated implementation modes.
Whether reviewers can later reconstruct why a release decision was made and on what evidence base.

Practical example / likely audience question

Audience question

How is RAIDT operationally enforced rather than treated as a descriptive framework that teams can ignore when deadlines become tight?

Answer

The concern behind this question is that many governance frameworks produce guidance but do not change behaviour at the point where release pressure is highest. The direct answer is that RAIDT is operationally enforced through gating: if the evidence pack is incomplete, if key thresholds are not met, or if unresolved risks remain, the run does not proceed as normal.

For example, suppose a team uses a GenAI system to draft external policy briefings for a public-sector department. The output quality appears strong, but the run record shows limited prompt traceability, no documented human verification for high-impact claims, and weak evidence on dependability across repeated tests. Under RAIDT, that run should not simply proceed because the text looks plausible. The gate can require additional review, stronger evidence, or restriction of use until governance conditions are met.

RAIDT handles this better than a generic AI governance approach because it does not rely on broad claims such as ?we have responsible AI principles? or ?a human is in the loop?. Instead, it asks what happened in this run, what evidence exists, how the run scored, and whether those findings justify release in this context. That makes enforcement specific, reviewable, and contestable.

Practical example in RAIDT terms

Consider a healthcare trust using a generative AI assistant to draft discharge-summary text for clinicians. The run-level issue is not whether the model is generally useful, but whether this particular run is suitable to support clinical communication at this moment, with this patient context, under this workflow.

The evidence needed for gating would include the prompt and configuration used, the model version, the source material supplied to the system, checks for unsupported clinical statements, human reviewer sign-off, and documented handling of patient-data constraints. RAIDT would also examine whether the run achieved acceptable scores in Responsibility, Dependability, and Traceability, with Auditability and Interpretability providing additional assurance for later review.

If the evidence pack shows gaps, such as unclear provenance of input text, inconsistent reviewer feedback, or poor repeatability across similar test runs, the gate should hold the output from clinical use. If the evidence is strong, the run may proceed with recorded approval conditions. In governance-readiness terms, gating improves the organisation's ability to justify why a given AI-assisted output was allowed into practice, not merely why the tool was procured in the first place.

Detailed link to RAIDT

Gating links to RAIDT in four ways.

First, it connects directly to RAIDT's core idea that governance should operate at the level of the run, not only at the level of the model, policy, or platform.
Second, it uses run-level evidence to decide whether a specific configured use of a GenAI system is acceptable in a specific task and context.
Third, it depends on the evidence pack and the RAIDT score profile to translate documentation into an operational decision.
Fourth, it strengthens reviewability, contestability, audit readiness, and organisational learning because each gate decision can be reconstructed and challenged.

Gating ? Run-level evidence ? Evidence pack ? RAIDT score profile ? Governance readiness

This chain matters because gating is the point at which RAIDT evidence acquires practical consequence. Without that link, evidence remains descriptive. With the link, evidence informs operational permission.

Link to the five RAIDT pillars

Responsibility

Gating supports Responsibility by making someone answerable for whether a run is suitable to proceed. It prevents vague ownership by requiring explicit release conditions and clear escalation routes.