Transparency, Explainability, and Accountability
Scope
This domain tests the distinctions between transparency, interpretability, explainability and accountability, and your ability to match the disclosure to the audience and the stakes of the decision.
Definitions that earn marks
- Transparency: information about the system's existence, purpose, data and logic is available.
- Interpretability: a property of the model - how readily a human can follow its internal logic.
- Explainability: the ability to produce an account of a specific output that a person can evaluate and act on.
- Accountability: an identifiable actor can answer for outcomes and be remedied against.
Instruments
- Model cards (Mitchell et al.) document intended use, evaluation data, disaggregated metrics and limitations. Datasheets for Datasets (Gebru et al.) document provenance, collection and recommended uses.
- Local explanations: LIME, SHAP, counterfactual and contrastive accounts. These are approximations, and SHAP values can be unstable and do not establish causation. Global methods describe overall behaviour.
- Algorithmic impact assessments are required for public-sector or high-risk systems under several regimes, including Canada's Directive on Automated Decision-Making and various US state AI laws.
- Legal hooks: GDPR Arts 13 to 15 require specified information; Art 22 requires safeguards including meaningful information about the logic involved. The so-called right to explanation is contested: the text supports ex ante disclosure of logic more clearly than ex post explanation of a particular decision, although regulators read Art 22 broadly.
- Frameworks: the NIST AI RMF (Govern, Map, Measure, Manage) is voluntary but widely adopted as the governance backbone; the EU AI Act imposes transparency duties on limited-risk systems such as chatbots and deepfakes and documentation duties on high-risk ones.
- Contestability: an explanation a person cannot act on is not accountability. Logging, audit trails and a named owner convert explanation into remedy.
Worked example
A lender denies credit through a model. The regulator needs model documentation and validation evidence. The applicant needs specific, actionable adverse-action reasons, as ECOA and Reg B require, plus a route to appeal. The board needs risk appetite and drift monitoring. One explanation cannot serve all three; a defensible system produces differentiated disclosures for each audience.
Traps
Assuming explainability always costs accuracy; equating open-source code with transparency; offering post-hoc rationalisation as explanation; ignoring that explanation quality is judged by the recipient's ability to contest the outcome.