AI Control Library / CF-01: Lifecycle Governance
Designation: Core | Control types represented: Operational and Technical
An average benchmark improvement can hide a serious regression in a narrow but consequential task. Testing must examine the changed workflow and its boundaries, not just compare headline model scores.
Control requirement
Test proposed AI changes against defined, risk-based acceptance criteria before release. Preserve evidence of the candidate version, test conditions, results, unresolved defects and the decision to accept or reject the change.
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
Behavioral and technical AI changes, including prompts, retrieval data, model providers, integrations and permissions.
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 system owner defines acceptance criteria with domain and security specialists; a qualified reviewer assesses results before release approval.
Implementation guidance
- Define intended improvements and unacceptable regressions before running tests; cover task quality, safety, access boundaries and affected groups as appropriate.
- Use representative and adversarial cases tied to the change, retaining the exact candidate baseline and relevant test-data provenance.
- Compare against approved thresholds and prior behavior; analyze consequential failures separately from aggregate performance.
- Resolve blocking defects and record residual limitations; require a new evaluation when the candidate or relevant test conditions materially 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 |
|---|---|
| Reproduce a release evaluation | The tested candidate and conditions are identifiable and results can be substantiated. |
| Inspect a blocking defect | Release is held until remediation or a properly authorized risk decision. |
| Review an autonomy-expanding change | Tests include the newly available actions and their restrictions. |
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
- Acceptance criteria and test plan
- Candidate baseline and results
- Defect and remediation records
- Quality review decision
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 failed acceptance criteria to the release authority. Prevent routine approval based solely on aggregate improvement; restrict the changed functionality while material regressions remain unresolved.
Example in practice
Hypothetical example: A new model produces better summaries but sometimes invents payment terms. The quality gate rejects release despite improved overall scores until the contract-specific reliability criteria are met.
Related controls
- CF01-009: AI Change Management Policy & Procedures
- CF01-011: AI Change Authorization
- CF08-013: AI Output Reliability & Hallucination Testing
Framework mappings
- CSA AICM (CCC-02)
- NIST AI RMF (MEASURE 2.5)
- EU AI Act (Art. 9(6))
- 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.
Version 1.0