AI Control Library / CF-06: Transparency & Explainability
Designation: Core | Control types represented: Operational and Contextual
Control requirement
Communicate material AI capabilities, limitations, intended uses and situations requiring caution or alternate handling, using claims supported by relevant evaluation and tailored to the audience.
Why this matters
A general warning that AI can make mistakes does not tell users which tasks or conditions are unsupported. Useful notices connect actual limits to concrete decisions about reliance.
How the control types work together
Operational controls establish ownership, review and handling procedures. Contextual controls shape the information, expectations and operating environment that guide how people interpret and use the system.
When it applies
AI interfaces, operating instructions, product descriptions and training materials influencing how people use or deploy the service.
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 system owner maintains supported claims with evaluation, domain and communications reviewers.
Implementation guidance
- Derive capability and limitation statements from the deployed configuration, evaluation coverage and known failure modes.
- Identify which limits users need before use or at a specific decision point, including unsupported languages, data conditions or actions.
- Provide actionable guidance and an alternative path instead of burying material limits in generic disclaimers.
- Review notices after changes, incidents and new evidence, correcting claims across all relevant channels.
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 |
|---|---|
| Compare a material claim with evaluation | Evidence supports its stated use and conditions. |
| Present an unsupported-use scenario | The notice guides the intended restriction or alternative. |
| Change a capability or configuration | Affected notices are updated consistently. |
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
- Capability and limitation register
- Supporting evaluations
- Published notices and instructions
- Review and correction history
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 unsupported capability claims to system and release owners. Remove or narrow the claim and restrict affected reliance while evidence or safeguards are developed.
Example in practice
Hypothetical example: A model tested on English invoices is advertised as multilingual. Review narrows the claim and directs other languages to a supported workflow until relevant evaluation is complete.
Related controls
- CF01-015: AI Model Documentation
- CF06-001: Explainability Requirements Definition
- CF06-009: AI Output Uncertainty & Confidence Disclosure
Framework mappings
- NIST AI RMF (GOVERN 4.1)
- EU AI Act (Art. 13(3))
- ISO 42001 (Cl. 8.4, A8.2)
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.
Back to Transparency & Explainability
Version 1.0