CF06-010: High-Risk AI System Transparency Requirements

AI Control Library / CF-06: Transparency & Explainability

Designation: Core | Control types represented: Governance and Operational

Control requirement

Identify and implement transparency requirements applicable to legally classified high-risk or equivalent AI uses, documenting role, required information, recipients, timing and evidence. Keep legal classification separate from an internal risk label.

Why this matters

A general product description may not satisfy use-specific external disclosure duties. The requirement depends on what the system does, who operates it and which obligations apply.

How the control types work together

Governance controls establish applicable binding external rules, laws and regulations. Operational controls translate those obligations into owned activities, review and decisions supported by relevant evidence.

When it applies

AI uses potentially subject to specific high-risk transparency or documentation duties, including changed purposes or deployment roles.

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

Legal or compliance validates applicability; the accountable service owner and communications teams implement reviewed requirements.

Implementation guidance

  1. Record the use, organizational role and jurisdiction and obtain qualified classification and obligation review.
  2. Translate applicable requirements into information, operating instructions, delivery and recordkeeping criteria.
  3. Check provider documentation against the actual deployment, adding customer-specific information and addressing material gaps.
  4. Verify delivery and reassess after legal, role, purpose or capability changes before reusing earlier approval.

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
Trace an applicable requirement Owned content and delivery evidence address its scope.
Inspect a generic provider notice It is not treated as sufficient for unrelated deployment conditions.
Change the intended purpose Classification and transparency requirements are reconsidered.

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

  • Classification and obligation review
  • Disclosure and instruction specification
  • Delivery and gap records
  • Reassessment 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 unmet applicable disclosure conditions to legal and release authorities. Hold affected use where required information or delivery cannot be demonstrated.

Example in practice

Hypothetical example: A general assistant becomes part of a consequential screening workflow. Review reassesses that use and supplies relevant operating information rather than reusing the original chatbot notice.

Related controls

Framework mappings

  • NIST AI RMF (GOVERN 4.1)
  • EU AI Act (Art. 13, Art. 49, Annex III)
  • 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

Scroll to Top