Responsible AI
Transparency by Audience and Decision
Design transparency for affected people, users, operators, auditors, regulators, executives, and the public according to their decisions.
By the end you can
- Explain why AI transparency should be designed for a specific audience, decision, timing, and action rather than measured by disclosure volume
- Distinguish Disclosure, Explanation, and Transparency infrastructure
- Identify evidence that connects affected person to public and society
- Design a review that moves from identify the decision to maintain and reconcile
Three articles, three different readers
Transparency is relational. Information has to be accurate, accessible, timely and useful to a particular reader making a particular decision. How much was disclosed does not answer whether that reader can understand, question, operate or govern the system. Accurate, accessible and timely are audience-relative words. One document can satisfy all three for a regulator and none of them for the person appealing a denial. The readers include affected people, users, operators, technical teams, procurement, risk, auditors, regulators, executives, workers and the public. Each needs different detail, timing, format, access, confidentiality and explanation of limits. Forty pages served the technical audience in the middle of that list. It failed the first one on it.
That split is written into law, and written three times over, for three readers who do not overlap. The AI Act requires at Article 13(2) that high-risk systems come with instructions for use. The information in them must be “relevant, accessible and comprehensible to deployers”. That is the deploying organisation, not the person in front of the system. Article 50(1) turns to that person. Providers must ensure that natural persons interacting directly with an AI system “are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect”.
Article 86(1) reaches a third reader, one who may never have interacted with anything at all: the person on the receiving end of the decision. It gives her a right against the deployer. “Any affected person subject to a decision which is taken by the deployer on the basis of the output from a high-risk AI system listed in Annex III, with the exception of systems listed under point 2 thereof, and which produces legal effects or similarly significantly affects that person in a way that they consider to have an adverse impact on their health, safety or fundamental rights shall have the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.”
Read the three side by side and the addressees do not overlap: the deployer, the person interacting, the person decided about. Note also what Article 86(1) owes that third reader. Not documentation — “clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken”. Forty pages of technical documentation discharge none of the three duties. Audience is a design input, not a formatting decision.
Three duties aimed at three different readers cannot be discharged by one document, however complete that document is.
Visual
Five rows, five different documents
An affected person needs to know what to do next. A regulator needs to know what was done. The same page cannot serve both, and the five rows below are five different documents.
A regulator has already published that claim as a document structure rather than as an argument. Guidance on explaining decisions made with AI came out on 20 May 2020, from the ICO with The Alan Turing Institute. It came in three parts, one per audience. “Aimed at DPOs and compliance teams, part one defines the key concepts and outlines a number of different types of explanations.” Part 2 is aimed at technical teams, Part 3 at senior management. The same guidance names six main types of explanation: rationale, responsibility, data, fairness, safety and performance, and impact. A programme choosing what to say can start from the explanation the reader needs rather than from what the model can produce.
Notice what the regulator did not do. Writing for three audiences, it did not write one longer document. It wrote three, and split the explanation types across them. The rows below apply the same discipline to five audiences: affected person, operator, assurance function, leadership, public and society. Each row names a decision. The information, the format and the delivery follow from the decision, not from the model.
- 1
Affected person
Notice, role of AI, relevant factors, consequences, rights, correction, and appeal.
- 2
Operator
Purpose, confidence, evidence, limitations, uncertainty, override, and escalation.
- 3
Assurance function
Version, data, controls, evaluations, incidents, exceptions, and owners.
- 4
Leadership
Risk posture, residual risk, trends, decisions, incidents, and resource needs.
- 5
Public and society
Purpose, scale, safeguards, aggregate impacts, accountability, and public-interest rationale.
Key idea
What evidence about AI transparency cannot prove
Transparency can do harm of its own: privacy leakage, security exposure, manipulation, information overload. The goal is transparency that fits the reader, not publishing every internal detail there is. Audiences can also want incompatible things. A programme should write down what it holds back and why. While it does, independent oversight and meaningful rights have to stay intact. Forty pages is genuinely more disclosure than a one-page notice. The applicant reading neither still cannot tell that a model was involved in the denial.
The converse cannot be proved from the record either. A complete published trail does not establish that what was withheld was rightly withheld. It does not establish that anyone owed “clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken” under Article 86(1) actually received them. Those are separate findings, and they come from separate tests.
No amount of published detail shows what a program was right to hold back.
Comparison
Disclosure, Explanation, or Transparency infrastructure?
Disclosure makes information available. Explanation interprets one output. Infrastructure preserves the trail. A programme that does only the first has published something rather than explained anything.
A numbered standard draws the same distinction in its own vocabulary. NIST released its Artificial Intelligence Risk Management Framework on 26 January 2023. It separates three questions. Transparency answers what happened in the system, explainability answers how a decision was made, and interpretability answers why it was made and what it means to the user. It then makes the audience the test of the first: “Meaningful transparency provides access to appropriate levels of information based on the stage of the AI lifecycle and tailored to the role or knowledge of AI actors or individuals interacting with or using the AI system.”
Two phrases in that sentence do the work. Access is tailored to the stage of the lifecycle, which is why a version log and an applicant's notice are not competing drafts of one artefact. And it is tailored to the role or knowledge of the reader, which is why volume is the wrong measure. A document can be complete at the wrong level for the person holding it. The three columns below are three mechanisms, not three grades of one.
Disclosure
Makes information available.
- Can support notice and accountability
- May be unreadable or poorly timed
- Can conflict with privacy and security
- Needs audience-specific design
Explanation
Helps interpret a specific output or behavior.
- Can support understanding and challenge
- May be post-hoc or unstable
- Does not establish causality automatically
- Must fit the decision question
Transparency infrastructure
Preserves traceable evidence across the lifecycle.
- Supports audit and incident response
- Includes versions, logs, records, and documentation
- Can expose sensitive details if uncontrolled
- Requires access and retention governance
Example
Who owes the applicant an explanation, and what it has to say
The applicant who cannot tell that a model was involved in a credit decision is not a hypothetical reader with an unmet need. Three instruments name her. Each answers a different question: which organisation owes her anything, whether she must be told the system was used at all, and how specific the reasons have to be.
- Which organisation owes the duty — Case C-634/21: A credit agency's automated probability value is itself automated individual decision-making under Article 22(1) GDPR, where the third party receiving it draws strongly on it. That was the holding in SCHUFA Holding ('Scoring'), decided by the Court of Justice of the European Union on 7 December 2023. Its reason is the audience problem exactly: otherwise “the data subject would not be able to assert, from the credit information agency which establishes the probability value concerning him or her, his or her right of access to the specific information referred to in Article 15(1)(h) of the GDPR, in the absence of automated decision-making by that company”. Read the other way: the agency is not the decision-maker, the bank does not hold the information, the duty falls in the gap between them, and the applicant receives nothing.
- Whether she is told at all — Article 26(11): The applicant does not have to work it out for herself. The AI Act puts the fact on the deployer: “Without prejudice to Article 50 of this Regulation, deployers of high-risk AI systems referred to in Annex III that make decisions or assist in making decisions related to natural persons shall inform the natural persons that they are subject to the use of the high-risk AI system.” An applicant who cannot determine that automation was used is therefore describing a breach of a named deployer duty, not merely an unmet need.
- How specific the reasons must be — 12 CFR 1002.9(b)(2): US credit law forbids the published-summary substitute outright. Regulation B requires the adverse-action statement of reasons to be specific and to indicate the principal reasons. It also rules out the score-based non-answer: “Statements that the adverse action was based on the creditor's internal standards or policies or that the applicant, joint applicant, or similar party failed to achieve a qualifying score on the creditor's credit scoring system are insufficient.” Architecture, metrics and general limitations are not principal reasons for this denial.
- Guidance can be withdrawn; the regulation was not: That duty was applied to uninterpretable 'black-box' credit models in Circular 2022-03. The Consumer Financial Protection Bureau issued the circular on 26 May 2022 and withdrew it effective 12 May 2025. It did not amend 12 CFR 1002.9(b)(2). The explanatory layer moved and the specificity requirement stayed where it was — a useful reminder about which artefact a compliance argument should be built on.
- Transparency failure: More information is available — architecture, metrics, general limitations, a public report — and none of it is addressed to any of the readers these three instruments name. That is the failure in one line: information published rather than delivered, to the wrong reader, and in the Article 86(1) case not delivered at all.
Example
Comprehension, timing, and what is withheld
Before running the exercise, note the base rate it is being run against. Explainability mostly serves engineers. Interviews with roughly fifty people at approximately thirty organisations, published in 2020 by Bhatt and colleagues, reported where the explanations actually went: “We find that, currently, the majority of deployments are not for end users affected by the model but rather for machine learning engineers, who use explainability to debug the model itself.”
Across those thirty-odd organisations, the reader who received the explanation was the engineer debugging the model. That is the default this matrix exists to interrupt: five audiences, five different decisions, and one page written for none of them.
- Audience matrix: For five audiences, list the decision each must make and the information required — then mark which row your existing explanations actually serve. Bhatt and colleagues found the majority of deployments serving the engineer's debugging row rather than the affected person's.
- Comprehension test: Ask representative users to explain the system role, consequence, and next action. Article 86(1) sets the bar in the same terms: the affected person is owed the role of the AI system in the procedure and the main elements of the decision. A test that produces neither has not measured the duty.
- Timing review: Identify disclosures that arrive after a meaningful choice has disappeared. A notice sufficient in content still fails as delivered if the appeal it describes can no longer be filed.
- Confidentiality rationale: Document what is withheld, why, and how independent oversight remains possible. Then check the rationale against who the withholding falls on. The reader with the least ability to compel disclosure is the affected person, not the auditor.
Steps
Start from the decision in front of the reader
Begin with the decision the audience in front of you actually faces. The information, the timing and the channel all follow from it: identify the decision, select the information, choose timing and channel, test comprehension and action, then maintain and reconcile.
Step three is where programmes usually fall back on judgement. It is also the step the law has already fixed. Article 50(5) sets both a deadline and a manner for audience-facing disclosure: “The information referred to in paragraphs 1 to 4 shall be provided to the natural persons concerned in a clear and distinguishable manner at the latest at the time of the first interaction or exposure.” The same paragraph requires the information to conform to applicable accessibility requirements. Format is part of the obligation, not a presentational afterthought.
Three phrases there are testable, and a timing review should test them one at a time: clear, distinguishable, and at the latest at the time of the first interaction or exposure. A disclosure can be clear and still late. It can be timely and still buried in surrounding text. Either failure is a failure of the step, not of the wording. Step five keeps the answers current: version the disclosures, protect the sensitive details, revisit after change or incident. The reader's decision does not stay the same as the system moves.
1. Identify the decision
Ask what the audience must understand or do.
2. Select information
Provide purpose, evidence, limitations, consequences, rights, or technical detail as needed.
3. Choose timing and channel
Deliver information before consent, decision, action, or appeal becomes impossible.
4. Test comprehension and action
Observe whether people can use the information correctly.
5. Maintain and reconcile
Version disclosures, protect sensitive details, and update after change or incident.
Comprehension is a measurement
Transparency is judged by whether somebody could actually act on it. That makes comprehension a measurement rather than an intention. The instruments in this lesson all measure the same way. Article 26(11) asks whether the person was informed. Article 86(1) asks whether the explanation covered the role of the system and the main elements of the decision. 12 CFR 1002.9(b)(2) asks whether the reasons given were specific. Article 50(5) asks whether the information arrived at the latest at the time of the first interaction or exposure. None of them asks how much was published.
Decide which comprehension, timing or confidentiality finding would force the reviewer to redesign, restrict, remedy or retire the system. Decide it before the finding arrives, while the answer is still cheap.
Key takeaways
- Transparency is useful only when the information reaches the right reader in time, and the AI Act splits that duty across three articles: Article 13 for the deployer, Article 50(1) for the person interacting, Article 86(1) for the affected person.
- Affected people, operators, auditors, leaders and the public need different evidence — the ICO and The Alan Turing Institute published their AI explanation guidance in three parts for three audiences rather than one long one.
- Disclosure, explanation and traceability are related but distinct; NIST's AI Risk Management Framework separates what happened, how a decision was made, and why it was made and what it means to the user.
- More information can create overload, privacy leakage or security risk, and a published technical report cannot supply the specific principal reasons that 12 CFR 1002.9(b)(2) requires.
- Comprehension and action should be tested rather than assumed: across approximately thirty organisations, Bhatt and colleagues found most explainability deployments served engineers debugging models, not the people affected by them.
- Confidentiality can be justified without eliminating independent oversight or individual rights — and Case C-634/21 shows a court asking first which organisation owes the applicant an explanation at all.