AI Control Library / CF-08: Testing & Robustness
Designation: Core | Control types represented: Operational and Technical
Control requirement
Test AI outputs for factual support, task correctness, misleading invention and appropriate handling of insufficient evidence. Use representative and adverse cases, treating generated confidence and citations as claims requiring verification.
Why this matters
A fluent answer can invent a fact, source or action result. Reliability evaluation must examine whether the output is supported and useful in its actual task, not just well written.
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
Generated answers, summaries, code, structured outputs and recommendations used for factual or operational reliance.
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 output-quality owner coordinates domain reviewers and evaluation specialists; system owners apply release conditions.
Implementation guidance
- Define correctness and harmful-error criteria by task, including unsupported claims, omitted qualifications and fabricated references.
- Build representative and insufficient-evidence cases with reliable expected outcomes or qualified human assessment.
- Evaluate repeated outputs where variability matters and validate automated evaluators against independent checks.
- Test abstention, verification and escalation, recording residual limitations and retesting after model, retrieval or prompt changes.
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 |
|---|---|
| Assess a known-answer case | Material claims and required qualifications match reliable evidence. |
| Remove necessary evidence | The system does not invent missing facts or citations. |
| Inspect an evaluation score | Qualified checks support the scoring method and relevant failure categories. |
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
- Correctness criteria and evaluation set
- Source or reviewer evidence
- Variability and evaluator checks
- Release and regression decisions
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 consequential unsupported outputs to domain and system owners. Restrict affected reliance, correct exposed content and address the evidence or workflow failure.
Example in practice
Hypothetical example: An assistant cites a real contract but invents a termination clause. Claim-level testing rejects the response and tests how the system should respond when the required provision is absent.
Related controls
- CF06-006: AI Source Citation & Attribution
- CF06-009: AI Output Uncertainty & Confidence Disclosure
- CF09-007: AI Output Quality Monitoring
Framework mappings
- NIST AI RMF (MEASURE 2.2)
- OWASP LLM Top 10
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