Transparency and Explainability

Certification Blueprint

Field	Coverage
Exam	AWS Certified AI Practitioner (AIF-C01), exam guide v1.1
Domain	Content Domain 4 — Guidelines for Responsible AI
Exam weight	14% of scored content
Task statement	4.2 Recognize the importance of transparent and explainable models
Objectives	4.2.1 differences between transparent/explainable models and those that are not · 4.2.2 tools to identify them · 4.2.3 tradeoffs between model safety and transparency · 4.2.4 principles of human-centered design for explainable AI

What This Chapter Covers

Chapter 13 named what responsible AI requires. Chapter 14 covered how you detect it failing. Both chapters assumed you could look at the model and see what it was doing.

This chapter is about when you cannot.

The objective's title puts two words together — transparent and explainable — and the single highest-value thing you can take from this chapter is that they are not the same property, and neither one implies the other.

Transparency is visibility into how the model was built: its architecture, its training data, its licence, its documented limitations.

Explainability is the ability to account for why one particular output appeared: which inputs drove this decision, and how much.

One is about the model. The other is about an output. Because they are independent, all four combinations exist — and two of them are the ones candidates do not expect.

The Four Combinations

What to remember from this diagram: the two questions are asked independently, which is why the branch structure repeats. A model does not move along a single scale from opaque to open. It has two separate properties, and knowing one tells you nothing about the other.

	Explainable	Not explainable
Transparent	Open-weight model with a published model card and per-decision attribution	Open weights and full data disclosure, but no account of why a given output appeared
Not transparent	Vendor black box returning attributions per decision, publishing nothing else	Closed model, no documentation, no per-decision account

The top-right and bottom-left cells are the ones that earn marks.

• Transparent but not explainable is the ordinary condition of large open-weight models. You can download the weights, read the training-data description and check the licence — and still have no way to say why this particular prompt produced this particular answer.
• Explainable but not transparent is the ordinary condition of commercial risk-scoring products. Every decision arrives with a ranked list of contributing factors, and the vendor tells you nothing about what the model is.

If your instinct is that publishing the weights would make the first case explainable, that instinct is the error this chapter exists to correct. Disclosure is not accounting. A hundred billion published parameters explain nothing about one output.

Why the exam cares about the distinction

Because the remedies differ. A transparency gap is closed by documentation and disclosure — a model card, a licence, a data statement. An explainability gap is closed by attribution tooling or a simpler model. A scenario that describes one gap and offers the remedy for the other is the most reliable distractor shape in this task statement.

Interpretability, and where it sits

You will meet a third word. Interpretability is the property of a model whose mechanism can be read directly — a shallow decision tree, a linear model with a handful of coefficients. An interpretable model is explainable by construction: you do not need a tool to account for its output, because you can follow it.

Interpretability is therefore one route to explainability, not a synonym for it. The other route is attribution tooling applied to a model you cannot follow. Objective 4.2.3 is about what the first route costs.

Tools That Establish These Properties

Objective 4.2.2 names four things. They are not interchangeable, and each answers a different question.

What to remember from this diagram: the first branch is the one that decides everything. Are you asking about the model, or about one of its outputs? Nearly every tool question in this objective is answered by getting that branch right.

Tool	The question it answers	Property it serves
SageMaker Model Cards	What is this model for, what was it built from, and where should it not be relied on?	Transparency
SageMaker Clarify	Which inputs drove this prediction, and by how much?	Explainability
Amazon Bedrock Model Evaluations	How do candidate models compare, and can someone else check that comparison?	Transparency (through the retained artefact)
Open source models, data, licensing	Can the model be inspected at all, without asking permission?	Transparency (by construction)

SageMaker Model Cards

A model card is a durable document recording a model's intended use, training data, limitations and evaluation results in one place. It is the canonical transparency artefact: it exists so a reader who did not build the model can decide whether to trust it, and for what.

⚠️ Model Cards appear again in Domain 5, under Objective 5.1.2 on source citation and documenting data origins. Same artefact, different job: here it documents the model so a reader can judge it; there it records where data came from so provenance can be traced. A question asking "which use belongs to this task statement" is testing that boundary, and the wrong answer will usually be true — just true of the other domain.

SageMaker Clarify

Clarify computes feature attributions: for an individual prediction, which input features pushed the result and in which direction.

⚠️ Clarify appeared in Chapter 14 as a bias-detection tool. That is not a duplicate listing. Bias detection asks a question about the model's behaviour across groups. Attribution asks a question about one prediction. Same service, two jobs, two objectives — and the exam expects you to know which one a scenario is asking for.

Amazon Bedrock Model Evaluations

Chapter 12 taught this as the way to measure whether a foundation model is good enough. Here it is listed as a transparency tool, and the difference is worth being precise about.

What makes it belong to this task statement is the artefact, not the activity. Running an evaluation tells you something. Retaining a documented comparison across candidate models leaves evidence another reader can check — which is what transparency means. The evaluation is a performance instrument; the retained record of it is a transparency one.

Open source models, data and licensing

The other three tools all depend on somebody electing to publish something. Open source removes the election.

Open source delivers transparency by construction rather than by disclosure. There is nothing a provider must choose to reveal, because the artefact is already inspectable.

Two things it does not do, both of which appear as distractors:

• It does not guarantee explainability. Published weights of a large transformer are completely transparent and no more accountable per decision than a closed one.
• It does not remove the need for a model card. Source code does not state intended use or documented limitations. Those are judgements about the model, not facts recoverable from it.

Licensing is named in the objective for a reason. A model you can download but cannot lawfully use for your purpose is not usable transparency. The licence is part of what makes the disclosure meaningful.

The Trade-offs

Objective 4.2.3 asks you to identify tradeoffs. Note the verb. It does not ask you to resolve them with a rule, and options offering a rule are usually wrong.

There are two distinct trades, and the objective's example — measure interpretability and performance — names the first.

Interpretability against performance

What to remember from this diagram: the trade-off is not always paid. When no per-decision reason is required, take the performance — nothing is being traded. The trade only becomes real at the bottom node, and at that point it is a business and legal decision, not a technical one.

A simpler model is easier to account for and usually scores worse. A more complex model scores better and resists accounting. Adding attribution tooling recovers some explainability at some cost and does not fully close the gap — an attribution is a description of behaviour, not the model's reasoning.

Safety against transparency

What to remember from this diagram: every path converges on one question, and none of them converges on an answer. There is no setting that maximises both properties.

Everything published that helps an auditor understand the model also helps an adversary predict it: which inputs it is sensitive to, where its thresholds sit, what it was trained on. This is why a provider can be acting responsibly and declining to publish, and why "publish everything" is not automatically the responsible answer.

Publishing more	Publishing less
External audit becomes possible	The model is harder to game or evade
Claims can be independently verified	Attack surface is smaller
Users can make informed decisions	Training data is less exposed
Cost: adversaries learn the same things	Cost: nobody outside can check any claim

The distractor both trades produce

Because these are genuine trades, an option asserting that two competing properties are both maximised is describing something this task statement does not have. Watch for phrasings like "with no downside", "while also improving", or "eliminating the trade-off entirely". They are the strongest single tell in Objective 4.2.3.

Human-Centered Design for Explainable AI

Objective 4.2.4 names two things: user-feedback mechanisms and AI decision transparency. Both are easy to read as sentiment. Neither is.

What to remember from this diagram: the loop closes. Feedback that is collected and not acted on is not a human-centered design mechanism — it is a survey. The two outputs on the right, the design update and the audit trail, are what make it one.

User-feedback mechanisms

The property that matters is attachment, not frequency. Feedback tied to a specific decision the person is disputing is evidence. A satisfaction score collected continuously is still sentiment.

A mechanism that satisfies this objective lets an affected person challenge, correct or escalate a particular decision, and records that challenge against the decision it disputes. That record is reviewable, auditable and actionable. A five-star rating is none of those things, no matter how often you collect it.

AI decision transparency

This is about what the affected person is told, at the moment it matters: that AI was involved, and on what basis.

It has a deliberately modest bar, and two common over-answers:

• It is not full architectural disclosure to every affected person. That would be useless to them and collides directly with the safety trade above.
• It is not human review of every decision. Human-in-the-loop review changes who decides. It does not change what the person is told — a human-reviewed decision delivered without explanation is exactly as opaque to its recipient.

Decision Rules and Exam Signals

The scenario says	Reading	Answer direction
"We cannot see what data it was trained on"	A transparency gap	Model card, open source, licensing disclosure
"We cannot tell the customer why they were declined"	An explainability gap	Clarify attribution, or an interpretable model
"The vendor gives us factor rankings but tells us nothing else"	Explainable, not transparent	Name the quadrant; do not call it a black box
"The weights are public but nobody can account for this output"	Transparent, not explainable	Disclosure does not produce accounting
"The simpler model scores worse"	Objective 4.2.3, interpretability trade	Ask whether a per-decision reason is required
"Publishing details would help attackers"	Objective 4.2.3, safety trade	Name the trade; do not deny it
"Users can rate their satisfaction"	Not a 4.2.4 mechanism	Attachment to a decision is what is missing
"Users can dispute a specific decision"	A 4.2.4 mechanism	Evidence, reviewable and auditable
"…with no downside"	Constructed option	Objective 4.2.3 exists because trades are real

Distractor Patterns

Pattern	What it looks like	How to defuse it
Treating the two words as one	An option where explainability implies transparency, or the reverse	Ask: about the model, or about one output?
Disclosure offered as accounting	"Publish the weights so decisions can be explained"	Published parameters account for no individual output
The trade-off denied	"Improves accuracy and explainability, with no downside"	4.2.3 names trades; an option denying one is constructed
Right tool, wrong question	Clarify offered for a documentation gap; a model card for a per-decision one	Match the tool to the question, not to the topic
The other domain's true answer	A correct description of a model card's lineage use	True, but Domain 5's use — check the task statement
Invented product history	"The service gained a transparency mode later"	Guides list tools by question answered, not changelog
Human review substituted for transparency	Review of every decision offered as decision transparency	Review changes who decides, not what is disclosed
Cadence substituted for attachment	"Collected continuously" offered as the 4.2.4 property	Frequency is not attachment to a decision
Absolute quantifiers	"Explainability is required in every deployment"	Requirements are conditional on use and consequence

Scenario Walkthrough

A health insurer automates part of its prior-authorisation decisions. It licenses a vendor model that returns, with each decision, a ranked list of the clinical and administrative factors that moved the outcome; the vendor publishes nothing about training data, architecture or licence terms. Regulators require that any member receiving an adverse decision be told the basis for it and be able to contest it. The insurer's data science team has an in-house model that is directly readable but performs several points worse on the same task. Its security team objects to publishing model details, arguing that providers would learn to shape submissions to pass. The member portal currently offers a five-star rating after each decision.

Requirement	Reading	Decision
Vendor gives per-decision factors, discloses nothing else	Explainable, not transparent	Name the quadrant — the explainability requirement is already met
Members must be told the basis and be able to contest	Objective 4.2.4	Decision transparency plus a real feedback mechanism
In-house model readable but several points worse	Objective 4.2.3, interpretability trade	Only pay it if the vendor route fails the requirement — it does not
Security objects to publishing details	Objective 4.2.3, safety trade	A legitimate position; name the trade rather than overruling it
Five-star rating after each decision	Not a 4.2.4 mechanism	Replace with per-decision dispute, logged against the decision

The row that catches people is the third. A candidate who has decided "interpretable is the responsible choice" swaps in the weaker model and loses accuracy for an explainability requirement that was already satisfied. The requirement was a per-decision reason, and the vendor already supplies one. The trade-off is only paid when the requirement is actually unmet.

The second-hardest row is the fourth. The security team is not obstructing responsible AI; it is describing Objective 4.2.3 correctly. The right answer names the trade and routes it to whoever owns that risk.

Key Concepts

Concept	What it means	Why it matters on the exam
Transparency	Visibility into how the model was built	One half of 4.2.1; closed by documentation
Explainability	Accounting for why one output appeared	The other half; closed by attribution or simplicity
Interpretability	The mechanism can be read directly	A route to explainability, and what 4.2.3 costs
Model card	Durable record of intended use, data, limits, evaluations	The canonical transparency artefact; also in Domain 5
Feature attribution	Which inputs moved this prediction, and how much	Clarify's explainability job, distinct from its bias job
Retained evaluation	A documented, checkable model comparison	What makes evaluation a transparency tool
Safety-transparency trade	Disclosure informs auditors and adversaries alike	4.2.3; no setting maximises both
Decision transparency	The person is told AI was involved and on what basis	4.2.4; not architecture disclosure, not human review
Feedback as evidence	A challenge tied to the decision it disputes	4.2.4; attachment, not frequency

Revision Flashcards

Say the answer aloud before revealing it.

1. State the difference between transparency and explainability in one sentence each. → A. Transparency is visibility into how the model was built — architecture, training data, licence, documented limitations. Explainability is the ability to account for why one particular output appeared, such as which inputs drove this decision and by how much. One is a property of the model; the other is a property of an output.

2. Name the two combinations people do not expect, with an example of each. → A. Transparent but not explainable — a large open-weight model whose weights and training data are fully published, where nobody can say why one prompt produced one answer. Explainable but not transparent — a commercial risk-scoring product that returns ranked contributing factors with every decision while publishing nothing about how it was built.

3. Does publishing a model's weights make it explainable? → A. No. Disclosure is not accounting. A hundred billion published parameters are complete transparency and explain nothing about any individual output. This conflation is the most reliable distractor in the task statement.

4. What is interpretability, and how does it relate to explainability? → A. Interpretability is the property of a model whose mechanism can be read directly, such as a shallow decision tree or a small linear model. It is one route to explainability — the model is accountable by construction — and the other route is attribution tooling applied to a model you cannot follow. It is not a synonym.

5. Name the four tools in Objective 4.2.2 and the question each answers. → A. SageMaker Model Cards — what is this model for and where should it not be relied on. SageMaker Clarify — which inputs drove this particular prediction. Amazon Bedrock Model Evaluations — how candidate models compare, in a record someone else can check. Open source models, data and licensing — can the model be inspected at all without asking permission.

6. SageMaker Clarify appeared in Chapter 14. What is different about its use here? → A. In Chapter 14 it detects bias, which is a question about the model's behaviour across groups. Here it produces feature attributions, which is a question about one individual prediction. Same service, two jobs, two objectives — and a scenario will be asking for one of them specifically.

7. Why is Bedrock Model Evaluations listed as a transparency tool when Chapter 12 taught it as a performance tool? → A. Because the artefact matters here rather than the activity. Running an evaluation tells you whether the model is good enough. Retaining a documented comparison across candidate models leaves evidence another reader can check, and being checkable by someone else is what transparency means.

8. What does open source give you that the other three tools do not, and what does it not give you? → A. It gives transparency by construction rather than by disclosure — nothing is left for a provider to elect to reveal. It does not guarantee explainability, because published weights account for no individual output, and it does not remove the need for a model card, because source code does not state intended use or documented limitations.

9. State the interpretability-performance trade-off, and say what settles it. → A. Simpler models are easier to account for and usually score worse; complex models score better and resist accounting. What settles it is whether a per-decision reason is genuinely required. If it is not, take the performance and no trade is being made. If it is and the interpretable option misses the accuracy bar, the decision is a business and legal one rather than a technical one.

10. Why does publishing more about a model reduce its safety? → A. Because everything that helps an auditor understand the model also helps an adversary predict it — which inputs it is sensitive to, where its thresholds sit, what it was trained on. This is why a provider can be acting responsibly and still decline to publish, and why there is no setting that maximises safety and transparency together.

11. What makes a user-feedback mechanism satisfy human-centered design? → A. Attachment, not frequency. The feedback is tied to a specific decision the person is disputing, which makes it evidence that can be reviewed, audited and acted on. A satisfaction rating collected after every decision is still sentiment, however often it is gathered.

12. What does "AI decision transparency" require, and what two things is it not? → A. It requires that the affected person is told AI was involved and on what basis. It is not full architectural disclosure to every affected person, which would be useless to them and collides with the safety trade. It is not human review of every decision, which changes who decides rather than what the person is told.

The Five-Beat Answer

The core question this chapter prepares you for: "This model makes decisions about people. Is that acceptable?"

Five beats, checked in this order. Missing a beat is a failure state — you will be probed on whichever one you skipped.

1. Separate the two properties — say whether the concern is transparency, explainability, or both. Naming the quadrant first is what distinguishes a designed answer from "it's a black box".
2. Establish what is actually required — a per-decision reason, or a documented account of the model? The requirement selects the remedy, and the two remedies are different.
3. Choose the tool from the question — model card and licensing for the model; Clarify attribution for the output; a retained evaluation when someone else must be able to check.
4. Name the trade-off you are making — interpretability against performance, disclosure against adversarial exposure. State who owns the decision. Do not claim you avoided it.
5. Close the loop with the affected person — decision transparency at the point of impact, and a feedback mechanism attached to specific decisions, feeding review and an audit trail.

Why This Helps You

Beyond the exam, this is the chapter that keeps you honest in a design review.

"Explainable AI" is used loosely enough in industry that two people can agree a system has it and mean entirely different things — one meaning the vendor published a whitepaper, the other meaning a customer can be told why they were declined. Those are different builds with different costs. Being able to say which property is missing, and what closes it, is the difference between a requirement that gets met and one that gets nodded at.

The trade-off framing matters just as much. A team that believes transparency is free will publish until security stops them, then treat security as the obstacle. A team that knows the trade is real decides deliberately, and records who decided.

Chapter Checklist

• State the difference between transparency and explainability in one sentence each
• Place a described system in the right quadrant, including the two unexpected ones
• Explain why publishing weights does not produce explainability
• Define interpretability and say how it relates to explainability
• Name the four tools in Objective 4.2.2 and the question each answers
• Distinguish Clarify's bias use from its attribution use
• Say why a retained evaluation record is a transparency artefact
• Say what open source does and does not give you
• State the interpretability-performance trade and what settles it
• State the safety-transparency trade and why neither side is free
• Recognise "with no downside" as a constructed option
• Distinguish a feedback mechanism from a satisfaction survey
• Say what AI decision transparency requires, and the two things it is not
• Place a model card's use in Task 4.2 versus its use in Domain 5

After the Chapter

Complete parts 52-54 of your Decision Sheet while the quadrant is fresh — the placement test in part 52 is the one you will actually run against exam stems.

Then take the quiz closed-book. If you miss questions 1, 2 or 10, do not move on: those three are the same error in three costumes, and it is the error that costs the most marks in this task statement.

Next — Chapter 16: Securing AI Systems, and Controlling Hallucination (Domain 5, Task 5.1). This chapter asked whether you can understand a model. The next asks whether you can defend one — IAM, encryption, the shared responsibility model, the AI-specific threat surface including prompt injection and data leakage, and the v1.1 addition of hallucination detection and grounding. Note the connection: Objective 4.2.3's safety trade is the reason Domain 5 exists as a separate concern.