AI Release Governance Framework

A practitioner framework for turning evaluation, control, operational, and risk evidence into an accountable AI release decision.

The repository is deliberately broader than a checklist and narrower than an enterprise governance operating model. It focuses on the release boundary: what proposition is being approved, which evidence supports it, what remains uncertain, and who owns the decision, conditions, exceptions, residual risks, and rollback.

Start here

Artifact	Use it for
docs/release-decision-record.md	decision outcomes, evidence fields, finding dispositions, conditions, exceptions, and residual-risk acceptance
docs/nist-rmf-mapping.md	cautious practitioner cross-reference to NIST AI RMF functions
release-checklist	executable YAML validation for a narrower set of release-readiness fields
governance-playbook	broader organizational operating model and recurring governance forums

A release decision is scoped

“Release” should always identify:

• system and version;
• model, prompt, retrieval, data, tools, and permissions in scope;
• environment and infrastructure configuration;
• user population and geography;
• enabled actions and external effects;
• rollout stage and exposure limit;
• evidence cutoff date;
• decision owner and authority;
• conditions, exceptions, and expiry;
• changes that invalidate the decision.

Approval of one configuration should not be interpreted as approval of future model, prompt, data, tool, permission, or population changes.

Lifecycle

purpose and risk context
        ↓
release proposition and scope
        ↓
evidence plan and hard gates
        ↓
evaluation and control verification
        ↓
operational / containment readiness
        ↓
release decision and dispositions
        ↓
staged rollout and verification
        ↓
monitoring, incident, change, and retirement

Release governance begins before the final review. The evidence plan, owners, hard gates, and invalidation triggers should be agreed before teams optimize against a convenient metric set.

Gate design

A gate should ask a decision-relevant question, identify the evidence needed, and define the possible dispositions.

1. Purpose, scope, and risk context

Evidence should establish:

• intended use, users, and prohibited uses;
• affected people and foreseeable misuse;
• authority, data, and tool boundaries;
• reversibility and worst credible consequences;
• applicable internal and external obligations;
• owner and release authority.

2. Evaluation validity

Evidence should establish:

• task and risk coverage;
• operating-population assumptions and exclusions;
• hard-gate and quality-measure definitions;
• evaluator validity and adjudication;
• repeated-run policy and uncertainty;
• slice results and material failures;
• regression coverage.

Do not rely on an aggregate score without reviewing critical failures and non-compensable conditions.

3. Security, privacy, safety, and policy controls

Evidence should establish that relevant controls are:

• defined against the actual system scope;
• enforced in the deployment path;
• tested under normal, adversarial, and failure conditions;
• attributable to a current version;
• supported by exception and incident processes;
• subject to named ownership and change control.

Avoid prescribing a particular tool or explanation technique as universally required. The evidence method should fit the system, decision, and risk.

4. Operational and containment readiness

Evidence should cover:

• service objectives and capacity assumptions;
• observability at the agent, tool, workflow, and outcome levels;
• rollback, disable, and credential-revocation paths;
• partial and uncertain external actions;
• data and state recovery;
• on-call and incident decision rights;
• user support and redress where applicable;
• evidence retention with privacy controls.

A rollback test should verify the resulting state, not only demonstrate that an earlier software version can be redeployed.

5. Decision and follow-through

The review should distinguish:

Term	Meaning
Hard gate	non-compensable requirement
Blocker	unresolved condition preventing the current decision
Evidence gap	missing or unreliable support for a proposition
Required action	follow-up work accepted under a bounded conditional release
Condition	enforceable limit on scope or operation
Exception	authorized deviation with compensating controls and expiry
Residual risk	remaining risk accepted by an authorized owner
Observation	improvement that does not currently change the decision

See docs/release-decision-record.md for a template and review questions.

Decision outcomes

Outcome	Use when
Release	required hard gates pass and no conditions remain
Release with conditions	no blocker remains, but enforceable constraints or required actions limit the release
Hold	evidence, remediation, or control readiness is insufficient
Do not release	critical failure, prohibited condition, or unacceptable residual risk remains
Defer decision	the owner postpones judgment until specified evidence or dependency is available

A conditional release must not relabel an unresolved blocker as a future action. Conditions should state scope, owner, measurement, stop trigger, and expiry.

Evidence quality

For each material conclusion, record:

• proposition or control being assessed;
• system scope and version;
• evidence source, author, date, and location;
• method and reviewer;
• result and uncertainty;
• coverage and exclusions;
• freshness and invalidation trigger;
• owner and disposition.

A current document can contain stale evidence. Freshness depends on whether the reviewed system and operating conditions have changed, not only the file date.

Staged release

A staged rollout is a control only when it has:

• a defined population and exposure limit;
• monitoring linked to plausible failures;
• named go/no-go decision points;
• stop and rollback authority;
• minimum evidence for expansion;
• user support and incident response;
• conditions that prevent silent scope growth.

“Pilot” should not become an indefinite production state without renewed evidence and an accountable decision.

Change control

Re-evaluate when material changes occur to:

• model or provider;
• prompt, policy, routing, or orchestration;
• retrieval corpus or data distribution;
• tools, permissions, identities, or action authority;
• infrastructure or deployment region;
• user population or use case;
• evaluator, rubric, threshold, or test set;
• relevant law, policy, or internal control;
• known failure or incident evidence.

The prior decision record should state which changes invalidate it.

Maturity and scope

This is a practitioner framework for planning and reviewing AI releases. It is not a certified release process, safety case, regulatory approval, legal determination, or substitute for qualified security, privacy, safety, compliance, operational, and domain review.

References to NIST AI RMF and other governance concepts are practitioner mappings. Verify official sources and adapt the framework to the actual authority, population, risk, and jurisdiction.

Related repositories

Repository	Distinct role
release-checklist	working config validator
agent-eval	evaluation validity and decision semantics
accountability-patterns	decision rights, human review, provenance, and redress
regulated-ai	starter repository structure and templates

---

Maintained by Sima Bagheri.