AI Control Library / CF-06: Transparency & Explainability
Designation: Core | Control types represented: Operational and Contextual
Control requirement
Define explanation requirements for AI outputs and processes according to audience, decision, risk and applicable obligations. Specify the evidence, level of detail and delivery needed for understanding, appropriate reliance and challenge.
Why this matters
A developer, operator and affected person need different information. A plausible generated narrative may satisfy none of them if it is not grounded in the actual decision process.
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 uses requiring explanation for operation, assurance or affected-person understanding, including human decisions supported by AI.
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 approves requirements with domain, user-experience, assurance and legal or privacy specialists.
Implementation guidance
- Identify explanation audiences, their tasks and the decisions they must understand, separating system-level information from individual outcome review.
- Define the facts, evidence and limitations needed for each audience, avoiding claims to reveal internal reasoning that cannot be substantiated.
- Set acceptance criteria for accuracy, usefulness, accessibility and timely availability, with a route for unanswered questions.
- Include requirements in acquisition and design, reassessing when purpose, audience or decision authority 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 |
|---|---|
| Inspect an explanation specification | It identifies audience, purpose and verifiable information needs. |
| Ask an affected user to interpret a sample | The sample supports the intended understanding or challenge. |
| Review an unsupported explanation claim | It is removed or qualified before release. |
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
- Explanation requirements and audiences
- Evidence and acceptance criteria
- User and specialist review
- Change and approval records
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 unmet material explanation needs to the system and decision owners. Restrict consequential reliance or provide a supported alternative when the required explanation cannot be delivered.
Example in practice
Hypothetical example: A screening model’s feature chart helps engineers but not applicants. Requirements add a plain-language account of the actual decision factors and an accessible review route.
Related controls
- CF06-002: Explainability Evaluation & Documentation
- CF06-011: Automated Decision Explanation Rights
- CF04-014: AI Decision Record & Traceability
Framework mappings
- CSA AICM (GRC-13)
- NIST AI RMF (GOVERN 4.1)
- EU AI Act (Art. 13(1))
- ISO 42001 (Cl. 8.4, A8.1)
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