Transparency, Explainability, and Accountability
This domain covers how organizations make data and algorithmic decisions visible, understandable, and answerable. Candidates must distinguish transparency (disclosure of data, methods, and decisions), explainability (why a specific output occurred), and accountability (who answers and how redress is provided). Know the difference between global explanations (how the model behaves overall) and local explanations (why this prediction), and between interpretable models (inherently explainable) and post-hoc explanation methods (feature importance, surrogate models, counterfactuals) that approximate but do not fully reveal model behavior.
Traps: (1) equating transparency with explainability - publishing source code does not explain a decision to an affected person; (2) assuming post-hoc explanations are faithful - they can be unstable or misleading; (3) treating "the algorithm decided" as accountability - someone must own the design, deployment, and remedy; (4) ignoring contestability - people need a way to challenge decisions; (5) confusing explanation to regulators/auditors with explanation to end users, which differ in depth and framing.
Rule of thumb: match the explanation to the audience and purpose - a data subject needs a meaningful reason and a route to contest; an auditor needs documentation, lineage, and validation evidence; a developer needs debugging detail. Accountability means a named owner plus a redress mechanism.
Worked example: A loan model denies an applicant. Transparency might publish the factors used; explainability gives the applicant the specific reasons (e.g., debt-to-income); accountability names the responsible function and offers an appeal. All three are required - none substitutes for the others.