CF01-011: AI Change Authorization

AI Control Library / CF-01: Lifecycle Governance

Designation: Core | Control types represented: Operational and Technical

A successful test is not permission to deploy. Authorization connects technical evidence with business accountability and prevents a different candidate or expanded permission set from inheriting an earlier approval.

Control requirement

Authorize AI changes before implementation through identified approvers with appropriate authority. Bind approval to the specific change scope and candidate baseline, and prevent implementation outside the approved conditions.

Why this matters

The control is effective when its required decisions and safeguards can be demonstrated in the actual workflow. An approved document or completed form alone is insufficient if the described actions are not performed.

How the control types work together

Operational controls define the process and decision authority; Technical controls enforce boundaries or produce the system evidence needed to verify it.

When it applies

Production and other consequential changes, including emergency changes and changes performed by external operators.

Tailor depth and review frequency to potential impact, system authority and uncertainty. Document the reason for any exclusion; a supplemental designation does not make an otherwise applicable safeguard optional.

Ownership

The designated release authority is accountable; implementers execute approved changes and reviewers verify scope and evidence.

Implementation guidance

  1. Define approvers and delegation limits by impact, separating proposal and approval where practical.
  2. Present the exact release candidate, test outcome, open risks and restoration plan to the appropriate authority.
  3. Record approval conditions and validity; use deployment permissions or gates to prevent unauthorized changes and substitution of candidates.
  4. Capture the implemented version and compare it with the approval; require fresh authorization when scope or material conditions change.

How to verify it

Use a representative sample of actual records or an authorized controlled exercise. A reviewer with suitable expertise should compare observed practice with the approved scope and acceptance criteria.

Test Expected result
Attempt a release without approval in a controlled test The deployment path blocks or escalates the action.
Compare approved and deployed baselines They match, including prompts, tools and permissions.
Inspect an emergency release Authorized expedited decision and follow-up review are recorded.

Record a finding when a required result is absent, evidence cannot substantiate the claim, or practice differs materially from the approved conditions. An exception may record accepted risk, but does not turn a failed safeguard into an effective one.

Evidence to retain

  • Authorization matrix
  • Approval bound to candidate scope
  • Deployment gate configuration
  • Implementation and reconciliation records

Protect evidence according to its sensitivity and approved retention requirements. Retain enough detail to substantiate the assessment without unnecessarily duplicating confidential or personal information.

If the control fails

Escalate unauthorized deployment to the system owner and change authority. Contain expanded access and assess restoration; retrospective approval must not erase the unauthorized event.

Example in practice

Hypothetical example: A release approved for read-only retrieval is accidentally packaged with write permissions. Baseline reconciliation detects the mismatch and blocks deployment rather than treating the model approval as blanket authorization.

Related controls

Framework mappings

  • CSA AICM (CCC-04)
  • NIST AI RMF (MANAGE 4.2)
  • EU AI Act (Art. 9(2)(d))
  • ISO 42001 (Cl. 8.2)

Review and maintenance

Review at the interval approved by the control owner and after a material change, relevant incident or failed assessment. Reassess the affected scope, update records and verify corrective actions before closing findings.

Back to Lifecycle Governance

Version 1.0

Scroll to Top