BlogGovernance

Conditional approval for AI systems — making conditions stick

Conditional approval is the most common disposition for AI systems that are not ready for unrestricted production. The conditions are the whole point — and most conditional approvals are written in a way that makes the conditions unenforceable.

Drel Research15 December 202410 min read

Conditional approval is the disposition most often reached for AI systems that are not ready for unrestricted production — which, in practice, is most AI systems reviewed before their first deployment. Some control is not yet in place. Some evidence is outstanding. The system is ready enough to go forward, but not without conditions.

The problem is not with the conditional approval as a mechanism. The problem is with how conditions are written. In assessed systems we have reviewed, conditional approvals routinely contain conditions that are unenforceable — either because they describe intent rather than state, because they have no owner, because they have no deadline, or because there is no mechanism to verify whether they have been met.

An unenforceable condition is not a condition. It is documentation of what was hoped for at the time of approval. The distinction matters enormously when something goes wrong and the question is asked: were the conditions actually met?

What conditional approval means

Conditional approval means: the system may proceed to the named deployment scope on the condition that specific, named requirements are in place by a specific date, verified by a specific mechanism. The approval is not for the system as it will be — it is for the system as it is now, with defined requirements for what must change before the approval is complete.

This is different from approval with follow-up actions. Follow-up actions are desirable improvements that will be addressed after deployment. Conditions are requirements whose absence means the approval should not have been granted — and whose continued absence means the approval should be reviewed.

Five things that make a condition stick — and three that cause it to be forgotten

Makes it stick

Named ownerThe condition has a specific, named individual responsible for fulfilling it — not a team, a role title, or 'the vendor'.

Specific deadlineA date by which the condition must be met — not 'before production' or 'within a reasonable timeframe'. A specific calendar date that can be tracked and escalated.

Verifiable evidence requirementThe condition specifies the exact evidence that confirms it has been met — a test result, a document, a configuration excerpt. 'Implemented' without evidence means nothing.

Consequence for non-fulfilmentThe condition states what happens if it is not met by the deadline — suspension of the deployment, escalation to the committee, automatic re-classification of the disposition.

Registered in the disposition recordThe condition exists as a structured entry in the governance record — not in meeting minutes, not in an email thread. It must be reviewable and auditable.

Anti-patterns

Ownership assigned to a team — Teams don't have accountability. When the condition is not met, no individual is responsible. The condition is effectively unenforceable.

Deadline is a lifecycle phase — 'Before production' is not a date. It becomes whatever date the team decides production is ready, decoupling the condition from time-bound accountability.

No follow-up mechanism — Conditions that exist only in a document no one reviews are forgotten. Without a registered follow-up date or owner alert, conditions expire silently.

The conditions are the point

The conditions in a conditional approval are the substantive output of the review. They represent the gap between the system as assessed and the standard required for unconditional production approval. Each condition corresponds to a specific control gap, evidence gap, or scope limitation that the review identified.

The conditions are also the mechanism that makes a conditional approval defensible. An auditor or regulator examining the approval will not just ask whether the system was approved — they will ask what conditions were attached, whether those conditions were met, and how that was verified. The conditions must be specific enough to answer those questions with documented evidence.

A conditional approval with vague conditions gives the appearance of governance without providing the substance. It is worse than a clear approval with documented residual risks — because it creates the false impression that the conditions adequately address the identified gaps.

Common condition failures

Three condition failure modes appear repeatedly in conditional approval records:

Intent-based conditions.Conditions that describe what will be done rather than what must be in place: “The team will implement access controls before the end of the quarter” rather than “Role-based access controls limiting model output access to [named user groups] must be in place and verified by [named reviewer] before the system is deployed to [named scope].” Intent-based conditions describe a future state that may or may not be achieved. Enforceable conditions describe a present state that can be verified.

Conditions without owners or deadlines. A condition with no named owner is a condition no one is responsible for. A condition with no deadline is a condition that can be deferred indefinitely. Both failures allow conditions to remain unmet without triggering any governance response. Conditions without owners or deadlines in assessed systems are almost never verified.

Conditions without verification methods.“Compliance will be confirmed” is not a verification method. The verification method must specify who verifies, how they verify (what evidence they examine), and what the outcome looks like. Without a verification method, condition closure becomes a declaration rather than a demonstration.

Writing enforceable conditions

An enforceable condition has five required elements:

The requirement:What must be in place — specific, not general. “All model outputs that influence customer-visible decisions must pass through a human review step before presentation” is specific. “Human oversight must be maintained” is not.
The owner: The named person or role responsible for ensuring the condition is met and maintained. Not a team — a role within a team.
The deadline: The date by which the condition must be met, and the date by which it will be verified. These may differ — a condition may need to be in place by T+30 and verified by T+45.
The verification method: How the condition will be verified — what evidence, by whom, and what the evidence must show.
The consequence of non-compliance: What happens if the condition is not met by the deadline. The most defensible consequence is automatic suspension of the conditional approval — the system returns to the review queue until the condition is met.

Verification mechanisms

Verification mechanisms confirm that a condition has been met after the conditional approval is issued. The verification must be independent of the team responsible for meeting the condition — a team verifying its own conditions is self-certification, not governance.

Common verification mechanisms by condition type:

Technical controls: The security engineer named in the review tests the control against the specification — for example, confirming that access to the model output channel is limited to authorised roles by attempting access with an unauthorised account.
Process controls: Evidence from the first operational cycle — for example, logs showing that the human review step was executed for all model outputs during the first week of production.
Documentation conditions: A named reviewer confirms that the required document exists, is current, and covers the required scope.
Training or awareness conditions: Completion records showing that named users or roles have completed the required training.

When conditions fail

Condition failure occurs when a condition is not met by its deadline, or when verification reveals that a condition that was marked as met is in fact not in place. Both cases require a defined response.

The default response to condition failure should be suspension of the conditional approval — the AI system moves from “conditionally approved” to “under review” until the condition is met. This default prevents the condition from becoming nominal — it creates a real operational consequence for condition non-compliance.

For systems where suspension would be operationally significant, an alternative is possible: the governance committee meets to evaluate whether an extension is warranted and under what additional conditions. This requires an active committee decision — it cannot happen by default. The alternative must not be easier than meeting the original condition.

The governance record

The governance record for a conditional approval must contain:

The deployment scope to which the conditional approval applies.
Each condition, with owner, deadline, verification method, and consequence of non-compliance.
The date and authority for the conditional approval.
The log of condition closures — date verified, verifier, evidence reference, outcome.
The date the conditional approval converts to a full production approval (when all conditions are closed) or returns to review (if conditions fail).
The re-assessment triggers that apply to the fully approved system.

For the broader structure of the disposition record that the conditional approval sits within, see What makes an AI decision record defensible.

Blog

Get new posts in your inbox

AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.

Write conditions that actually stick

Drel structures conditional approvals with specific, verifiable conditions — each with an owner, deadline, verification method, and consequence — so governance holds over time.

Request early access See the demo dossier

A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.