Release, conditionally release, hold, or stop an AI system on explicit evidence

A release gate is not a certification

The gate answers whether one system, use, version, and operating environment has enough evidence for a named decision. It does not certify the organization, guarantee performance, or make future changes safe automatically.

NIST's AI RMF and Generative AI Profile emphasize lifecycle risk management and context-dependent oversight, supporting a bounded, evidence-based decision rather than a universal checklist claim. [S1] [S2]

Ten evidence gates

The checklist below is designed to expose missing evidence rather than manufacture a passing score. A high-consequence gap can block release even when most items are complete.

Four decision outcomes

Use explicit outcomes so teams do not turn unresolved risk into a vague launch recommendation.

• Release: approved for the named scope with current controls and monitoring
• Conditional release: approved only within stated limits, remediation, review, and expiry conditions
• Hold: more evidence or remediation is required before use
• Stop: the use is not justified, cannot be controlled, or should be retired

Material-change triggers

Define changes that reopen the gate: model or provider, prompt or policy, retrieval source, memory design, tool or permission, data class, user population, workflow, autonomy, coordination topology, human-review design, operating region, security control, or performance threshold.

Evidence quality

Record who produced the evidence, source and version, environment, test population, limitations, reviewer, and expiry. Model-generated evaluation or summaries should not silently approve themselves.

Post-release monitoring

The gate should name the metrics, traces, samples, reviewer cadence, incident thresholds, and rollback authority that keep the release decision current. NIST's deployment-monitoring report highlights gaps around drift, changing context, distributed logs, and human monitoring scale. [S3]

Research boundary

This checklist is an educational artifact. It must be adapted to the organization's risk, sector, contracts, law, security, accessibility, domain safety, and operational environment. It is not a legal or compliance opinion.