CF06-002: Explainability Evaluation & Documentation

AI Control Library / CF-06: Transparency & Explainability

Designation: Core | Control types represented: Operational and Technical

Control requirement

Evaluate and document whether AI explanations accurately represent the supported process or result and meet the intended audience’s needs. Record method limits, test conditions and changes that could invalidate the assessment.

Why this matters

Fluent explanations can mislead even when users find them convincing. Evaluation needs to examine evidential accuracy and usefulness, not merely satisfaction with the wording.

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

Explanation methods, interfaces and generated rationales used to support consequential interpretation, operation or review.

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 explanation owner coordinates technical and domain evaluation; qualified reviewers assess evidence and audience understanding.

Implementation guidance

Trace explanation statements to recorded inputs, rules, methods or other evidence appropriate to the actual system.
Test representative and adverse cases, identifying instability, misleading certainty and explanations that disagree with observed decisions.
Evaluate understanding with intended audiences and accessibility needs, keeping usefulness separate from technical fidelity.
Document findings and limitations, approve the supported scope and repeat relevant evaluation after model or interface 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
Compare an explanation with its decision record	Material statements agree with available evidence.
Vary a relevant case or configuration	The method’s limitations and unstable results are identified.
Review user testing	Participants can interpret the stated limits rather than merely rating the explanation persuasive.

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 method and version
Fidelity and adverse-case results
Audience evaluation
Approval and limitation 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 materially false or misleading explanations to system and decision owners. Remove affected claims, provide corrected information and assess outcomes influenced by the misleading account.

Example in practice

Hypothetical example: An assistant invents a reason for a declined request. Testing replaces unsupported narrative with verified decision facts and routes unresolved reasoning questions to a qualified reviewer.

Related controls

Framework mappings

CSA AICM (GRC-14)
NIST AI RMF (MEASURE 2.6)
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