AI Control Library / CF-08: Testing & Robustness
Designation: Core | Control types represented: Operational and Technical
Control requirement
Harden AI models and serving configurations against relevant attacks and misuse while verifying intended task performance. Apply controlled, evidence-based changes and document residual limitations.
Why this matters
A model refusal or adjusted safety setting does not replace access enforcement. Hardening should reduce relevant model-level exposure without creating unsupported claims about the surrounding application.
How the control types work together
Operational controls define scope, authority and the actions required when conditions are not met. Technical controls produce evidence or enforce the relevant boundaries. Both must apply to the same deployment and operating conditions.
When it applies
Model configurations, adaptations and serving behavior under organizational control; provider-managed models require assessment of available safeguards and constraints.
Define the assessed boundary, dependencies and evidence limitations. Tailor depth and review frequency to potential impact, and document why a particular safeguard or exclusion is appropriate to the actual deployment.
Ownership
The model owner implements hardening with security and domain review; release authorities assess evaluation evidence.
Implementation guidance
- Derive hardening objectives from applicable attacks, use constraints and known failures.
- Apply appropriate configuration, adaptation or model replacement through controlled versions, limiting unnecessary exposed capabilities.
- Evaluate adversarial resistance and legitimate-task regressions with independent or held-out cases where feasible.
- Retain defense limits and additional application controls, reviewing changes as new attacks or capabilities emerge.
How to verify it
Use representative records and authorized controlled tests. Identify the relevant version, operating conditions and expected result before testing, and retain enough evidence to support the conclusion.
| Test | Expected result |
|---|---|
| Retest a relevant failure scenario | The change improves the targeted protection under stated conditions. |
| Evaluate legitimate tasks | Hardening has not introduced unacceptable performance or access regressions. |
| Inspect claims | They stay within tested model behavior and do not imply universal containment. |
Record a finding when required results cannot be demonstrated or practice differs materially from the approved conditions. Missing evidence limits the conclusion; it should not be treated as a successful test.
Evidence to retain
- Hardening objectives and baseline
- Configuration or adaptation records
- Adversarial and regression results
- Residual-risk approval
Protect evidence according to its sensitivity, access needs and retention rules. Avoid unnecessary copies of personal information, secrets or confidential material, while preserving the records needed for authorized review.
If the control fails
Escalate ineffective protection or harmful regression to model and risk owners. Restrict use or revert through an approved safe path while alternative defenses are evaluated.
Example in practice
Hypothetical example: A model update reduces unsafe completions but also suppresses valid incident reports. Regression testing identifies the issue before the new configuration is accepted.
Related controls
- CF08-004: Adversarial Attack Analysis
- CF08-006: AI System Guardrails
- CF01-010: AI Change Quality Testing & Approval
Framework mappings
- CSA AICM (MDS-07)
- NIST AI RMF (MEASURE 2.5)
- EU AI Act (Art. 9(4))
- ISO 42001 (Cl. 8.2)
- MITRE ATLAS
Review and maintenance
Review at the interval approved by the control owner and after relevant changes, incidents or failed assessments. Update affected procedures and configuration, address evidence gaps and verify corrective action before closing findings.
Version 1.0