AI Transparency and Explainability

AI transparency and explainability are two distinct pillars of responsible AI that the AIF-C01 exam treats as separate learning objectives. AI transparency and explainability are routinely conflated in industry blog posts, and that conflation is exactly the confusion the exam exploits. Transparency is disclosure about the model itself — what data trained it, what it is intended to do, what its known limitations are. Explainability is insight into a specific prediction — why did the model output this answer for this input. Both concepts live under Domain 4 (Guidelines for Responsible AI) of the AIF-C01 exam guide, and AWS has purpose-built services for each: Amazon SageMaker Clarify for feature attribution, Amazon SageMaker Model Cards and Amazon Bedrock Model Cards for model-level documentation, and AWS AI Service Cards for managed-service disclosures.

What is AI Transparency and Explainability?

AI transparency and explainability together answer two different stakeholder questions. A regulator asks "what is this model, who built it, how was it validated?" — that is transparency. An end user whose loan application was denied asks "why was my application denied?" — that is explainability. On AIF-C01 you will see both words in answer options, and picking the right one depends entirely on which question the scenario is answering.

AI transparency produces documents — model cards, service cards, data sheets, intended-use statements, limitation disclosures. AI explainability produces signals about individual predictions — feature importance scores, attribution heat maps, counterfactual examples, surrogate decision trees. Transparency is descriptive. Explainability is diagnostic. When the scenario mentions "disclose," "document," "intended use," or "training data provenance," the AI transparency and explainability answer tilts to transparency. When it mentions "why did the model predict," "which features drove this outcome," or "feature attribution," the answer tilts to explainability.

Why AI transparency and explainability matters for AIF-C01

Domain 4 of the AIF-C01 exam guide ("Guidelines for Responsible AI") carries a meaningful weight, and inside Domain 4 the transparency-and-explainability subtopic is the richest vocabulary set. AWS researchers have also flagged AI transparency and explainability as a high-confusion area on practice exams — candidates see "explainability" in one answer and "transparency" in another and pick whichever they studied most recently. Learning the precise boundary turns 3-4 extra questions into guaranteed points.

Scope of this topic vs adjacent topics

AI transparency and explainability sits between three neighboring topics. Bias and fairness (separate topic) is about measuring disparate outcomes across demographic groups. Model evaluation metrics (separate topic) is about accuracy, precision, recall, F1, perplexity, BLEU, ROUGE. Generative AI risks (separate topic) is about hallucination, prompt injection, toxicity, copyright. AI transparency and explainability focuses narrowly on disclosure and on explaining why predictions happened. Do not let exam scenarios pull you across the boundary.

Transparency vs Explainability — The Core Distinction You Must Memorize

This is the single most important section of this topic note. The transparency vs explainability distinction is the research-flagged pain point for AIF-C01, and a crisp mental model ends the confusion.

Transparency — disclosure about the model

Transparency is the quality of being open about what a model is. A transparent AI system ships with documentation that answers questions a stakeholder might have before even using the model:

What data was the model trained on, and does that data have known bias or licensing issues?
Who built the model, and when was it last updated?
What is the intended use case, and what are the out-of-scope use cases?
What accuracy, precision, recall, or toxicity scores did the model achieve on evaluation datasets?
What performance limitations and known failure modes has the vendor identified?
What governance, testing, and red-teaming process did the model go through before release?

Transparency is produced at training time and at release time, not at inference time. A model card is the canonical transparency artifact — a static document (often a PDF, a web page, or a JSON record) that accompanies a model the way a nutrition label accompanies a packaged food.

Explainability — insight into a specific prediction

Explainability is the quality of being able to understand why a specific prediction was made for a specific input. An explainable AI system can answer: "The model predicted 'decline' for this loan application because applicant income contributed -0.42 to the decision, credit history contributed -0.33, and employment tenure contributed +0.08."

Explainability is produced at inference time (or retroactively on past predictions). Feature attribution scores, saliency maps on image pixels, token-level attention visualizations, and counterfactual examples ("if income had been 20% higher, the decision would have flipped to approve") are all explainability outputs.

The one-sentence decoder

Transparency is about the model. Explainability is about the prediction. Transparency describes what. Explainability describes why. Memorize that pair.

Analogy — the food label vs the kitchen cam

A packaged sandwich in a shop carries a nutrition label listing ingredients, calorie count, allergens, and the factory where it was made. That label is transparency — it discloses what the sandwich is before you eat it. If you then get food poisoning and you ask the shop "what exactly in last Tuesday's sandwich made me sick?", the shop pulls the kitchen security camera footage and the chef's notes for that specific sandwich and traces the contaminated lettuce. That post-hoc trace is explainability — it explains why a specific outcome happened. The nutrition label is static and model-wide. The kitchen cam is dynamic and prediction-specific.

How AIF-C01 exam scenarios phrase each

Transparency scenarios use words like "disclose," "publish documentation," "intended use case," "inform end users about capabilities and limitations," "record training data provenance," "release notes for a new model version," or "help a compliance officer understand what the model does."

Explainability scenarios use words like "why did the model predict X," "feature importance," "feature attribution," "which inputs most influenced the decision," "explain an individual prediction to a customer," "compute SHAP values," or "understand the drivers of a specific outcome."

If the scenario centers on a document, it is transparency. If the scenario centers on a prediction, it is explainability.

Transparency answers "what is this model?" through disclosure documents like model cards and service cards. Explainability answers "why did the model produce this specific prediction?" through feature-attribution methods like SHAP and LIME. If the scenario mentions documentation, disclosure, intended use, or training data, choose transparency. If the scenario mentions feature importance, why a prediction happened, or SHAP/LIME, choose explainability. Reference: https://aws.amazon.com/machine-learning/responsible-machine-learning/

Plain-Language Explanation: AI Transparency and Explainability

Three analogies help the AI transparency and explainability distinction stick.

Analogy 1 — The kitchen (nutrition label vs incident report)

A packaged meal has a nutrition label on the box — ingredients, calories, allergens, manufacturing date, plant location. Anyone can read it before they decide to eat. That label is AI transparency. If a diner later asks "why did this dish taste salty?", the chef cannot point at the nutrition label; the chef has to reconstruct what went into this specific plate — which batch of soy sauce, how much salt, which pan. That reconstruction is AI explainability. Transparency is the label on the box. Explainability is the chef's reconstruction of one dish.

Analogy 2 — The library (book jacket vs marginal notes)

Every book on a library shelf has a jacket describing what the book is, who wrote it, the publisher, the edition, the intended audience, any content warnings. That jacket is the model card — AI transparency. Now a reader wants to know why the protagonist in chapter 7 made a certain choice. They flip open to chapter 7 and read the author's marginal notes explaining the scene. Those marginal notes are the explainability feature attributions — AI explainability, zoomed into one specific plot point rather than the whole book.

Analogy 3 — The workbench (tool catalog vs repair log)

A mechanic's workbench has a tool catalog in a binder — every wrench, its torque rating, calibration date, manufacturer, intended use. That is AI transparency: disclosure about the tools. The workbench also has a repair log that records every job, which tool was used at each step, and why the mechanic chose that tool for that bolt. The repair log is AI explainability — it traces a specific outcome back to the specific inputs that produced it. Both are written down. The catalog is timeless and tool-wide. The log is event-specific and per-job.

Analogy 4 — The courtroom (resume vs testimony)

A courtroom witness has a resume — their training, their certifications, their publications, their known biases. That resume is AI transparency. When the witness then testifies about a specific incident, the jury asks "how do you know? which observations led you to that conclusion?" and the witness walks through the specific evidence that drove their specific opinion. That walk-through is AI explainability. Transparency is credentials. Explainability is testimony.

Global vs Local Explanations — Another Boundary to Learn

Within AI explainability there is a second distinction the AIF-C01 exam loves: global vs local explanations. Memorize it alongside the transparency vs explainability split because answer options routinely mix all four terms.

Global explanations

A global explanation describes how the model behaves across all predictions. If you asked "which features does this credit-scoring model rely on most on average?" a global explanation would show "income is 35% of the signal, credit history is 30%, employment tenure is 15%, geographic region is 10%, age is 10%." Global explanations are computed on aggregated SHAP values or on permutation-importance runs across a validation set.

Local explanations

A local explanation describes why the model made one specific prediction. For applicant #1734, the local explanation might show "income pushed the score down by 0.42, credit history pushed it down by 0.33, and employment tenure pulled it up by 0.08, netting a final decline decision." Local explanations use per-instance SHAP values, LIME perturbations, or attention weights.

Exam scenario decoder

"The data science team wants to understand which features the model relies on overall" — global explanation. "A customer-service rep needs to tell one denied applicant why they were denied" — local explanation. Global is model-wide, local is prediction-specific, and both sit under the explainability umbrella (not transparency).

A global explanation describes the model's overall behavior across many predictions — typically using aggregated feature importance. A local explanation describes why the model produced a specific prediction for a specific input — typically using per-instance SHAP or LIME values. Both are forms of explainability. Neither is transparency. Reference: https://docs.aws.amazon.com/sagemaker/latest/dg/clarify-shapley-values.html

SHAP — The Most Important Explainability Technique on AIF-C01

SHAP (SHapley Additive exPlanations) is the single feature-attribution technique you must recognize on the AIF-C01 exam. Amazon SageMaker Clarify uses SHAP as its core explainability engine, and AWS documentation describes SHAP as the default method for feature attribution.

SHAP intuition

SHAP borrows from cooperative game theory. Imagine four chefs collaborated on a dish; one person tasted it and gave a rating. SHAP answers "how much credit does each chef deserve for the final rating?" by simulating every possible subset of chefs — sometimes cooking with all four, sometimes with three, two, one, or none — and measuring how much each chef's presence moved the final score. Each chef's SHAP value is the average contribution they made across every possible ordering.

Transposed to machine learning: each feature (income, credit history, employment tenure, region) is a chef. The final prediction is the dish rating. SHAP computes, for each feature, the average change in the prediction when that feature is "added" to every possible subset of other features. The result is an additive attribution — the sum of all feature SHAP values equals the difference between the model's prediction and the model's average prediction.

Why SHAP matters

SHAP has three properties that make it the explainability workhorse: local accuracy (attributions sum to the prediction), consistency (if a feature's true impact grows, its attribution cannot shrink), and missingness (a feature with no effect gets zero attribution). These mathematical guarantees are why Amazon SageMaker Clarify standardized on SHAP.

SHAP global vs SHAP local

SHAP is one method that produces both local and global explanations. A single prediction yields one set of per-feature SHAP values — that is a local explanation. Averaging the absolute SHAP values of every feature across a validation set yields feature importance rankings — that is a global explanation. On the exam, if you see "SHAP" in an answer option, do not eliminate it based on global-vs-local; SHAP covers both.

SHAP (SHapley Additive exPlanations) is the default feature-attribution method used by Amazon SageMaker Clarify. SHAP produces both local explanations (per-prediction feature contributions) and global explanations (aggregate feature importance). If the AIF-C01 scenario mentions "feature attribution" or "explain a prediction" on AWS, SHAP via SageMaker Clarify is the canonical answer. Reference: https://docs.aws.amazon.com/sagemaker/latest/dg/clarify-shapley-values.html

LIME — The Other Technique Worth Recognizing

LIME (Local Interpretable Model-agnostic Explanations) is the second explainability technique you should be able to recognize at AIF-C01 depth. You will not be asked to implement LIME, but you should know what it does and how it differs from SHAP.

LIME intuition

LIME works by perturbing the input around a specific prediction and fitting a simple, interpretable model (usually linear regression or a shallow decision tree) locally around that prediction. The simple model is only accurate in the tiny neighborhood of the one prediction being explained, but in that neighborhood it reveals which features pushed the decision which way.

LIME vs SHAP

LIME is fast and model-agnostic but its explanations are approximate and can be unstable across runs. SHAP is slower and has stronger mathematical guarantees (consistency, local accuracy) but is more expensive to compute on large models. In AWS services, SageMaker Clarify defaults to SHAP. LIME exists in the broader ecosystem and shows up in AIF-C01 answer lists as a distractor or a valid second choice. If the scenario asks specifically for an AWS-native approach, pick SHAP via Clarify. If the scenario is vendor-neutral and asks about local model-agnostic explanations, either SHAP or LIME can be correct.

When either will do

Both SHAP and LIME produce local explanations. Both can be aggregated (more naturally with SHAP) to approximate global explanations. Both are post-hoc — applied to a trained model without modifying it. For AIF-C01 memorization, treat SHAP as the AWS-preferred tool and LIME as the generic-ML alternative.

Interpretable Models vs Post-Hoc Explanation

There are two ways to achieve explainability: build a model that is inherently interpretable, or apply a post-hoc explanation technique to a black-box model. AI transparency and explainability on AIF-C01 includes both approaches.

Interpretable models

Linear regression, logistic regression, shallow decision trees, rule-based systems, and generalized additive models are inherently interpretable. A loan officer can look at the coefficients of a logistic regression and read off "every additional $10,000 of income raises approval odds by 8%." No extra tooling is needed — the model is the explanation. The trade-off is that interpretable models often have lower accuracy on complex tasks.

Post-hoc explanation

Deep neural networks, gradient-boosted tree ensembles, and foundation models are not inherently interpretable. For these, you train the black-box model for maximum accuracy and then apply a post-hoc explanation method — SHAP, LIME, integrated gradients, attention visualization — to extract insight. Amazon SageMaker Clarify is a post-hoc explanation tool. Amazon Bedrock foundation models require post-hoc methods because you cannot inspect their trillions of parameters directly.

Trade-off on the exam

AIF-C01 scenarios sometimes ask "the company values interpretability over accuracy — which model should they pick?" The right answer is a simple interpretable model (linear or decision tree), not a deep network with SHAP bolted on. And sometimes the scenario asks "the company has a black-box deep model and must explain individual predictions to customers — what should they do?" Then post-hoc SHAP via SageMaker Clarify is correct. Read the constraint before you answer.

Amazon SageMaker Clarify — AWS's Explainability Workhorse

Amazon SageMaker Clarify is the purpose-built AWS service for AI explainability (and for bias detection, though that is a separate topic). Any AIF-C01 explainability question that mentions AWS services should nudge you toward Clarify.

What Clarify computes

SageMaker Clarify runs as a SageMaker Processing Job against a trained model and a dataset. It produces three families of output: pre-training bias metrics (measured on the dataset before training), post-training bias metrics (measured on the model's predictions), and feature attribution scores (using SHAP). For this topic, the feature attribution output is the relevant one.

Global feature importance with Clarify

Clarify outputs a JSON report and a visual analysis in SageMaker Studio that ranks features by mean absolute SHAP value across the evaluation dataset. A feature with a high mean absolute SHAP value had a big impact on predictions on average — that is global explanation.

Local feature importance with Clarify

Clarify can also produce per-instance SHAP values for individual predictions. If a customer service team needs to explain why a specific loan application was denied, Clarify provides the per-feature contribution breakdown for that exact record.

Clarify in the SageMaker lifecycle

Clarify integrates at multiple points in the ML lifecycle. During data preparation, it detects pre-training bias. After training, it evaluates post-training bias and global feature importance. At deployment, Amazon SageMaker Model Monitor can use Clarify to continuously check for feature-attribution drift — a shift in which features the model is relying on in production. Drift detection is itself an explainability use case: if feature importance suddenly changes, the production distribution has shifted and the model may no longer be trustworthy.

Clarify and the model card workflow

Clarify outputs feed directly into Amazon SageMaker Model Cards. The model card's "Evaluation" section can embed Clarify's bias and explainability results, stitching together AI transparency and explainability in a single artifact — the card is transparency, the embedded Clarify report is explainability evidence.

If the question mentions AWS explainability, feature attribution, SHAP, or bias detection on a SageMaker model, the answer is Amazon SageMaker Clarify. Clarify uses SHAP under the hood and produces both global feature importance and local per-instance explanations. Reference: https://docs.aws.amazon.com/sagemaker/latest/dg/clarify-configure-processing-jobs.html

Amazon SageMaker Model Cards and Amazon Bedrock Model Cards — Transparency Artifacts

Model cards are the canonical AI transparency artifact. AWS offers two model-card services: Amazon SageMaker Model Cards (for models you train and deploy yourself) and Amazon Bedrock Model Cards (for foundation models you invoke via Bedrock).

What a model card contains

A model card is a structured document describing a specific model version. It contains sections such as: model details (name, version, owner, date), intended use (primary use cases, out-of-scope use cases, primary users), training data (source, date range, preprocessing, known bias), evaluation (datasets, metrics, fairness measurements), ethical considerations (risks, mitigations, failure modes), caveats and recommendations (known limitations, deployment guidance), and related regulatory disclosures.

Every field in that list answers a transparency question. No field answers "why did you predict X for this specific input" — that is explainability and belongs in Clarify output, not the card itself (though a card may link to Clarify reports).

Amazon SageMaker Model Cards

SageMaker Model Cards let you create, store, and retrieve model-level documentation inside SageMaker. A card ties a model artifact to its training data, evaluation results, and intended use in a single registry entry. Data scientists create cards as part of the MLOps pipeline; risk and compliance teams read them to approve deployments.

Amazon Bedrock Model Cards

Amazon Bedrock Model Cards provide AWS-generated documentation for the foundation models available in Amazon Bedrock — Anthropic Claude, Meta Llama, Cohere Command, Amazon Titan, Mistral, AI21 Labs, and others. Each card describes the model's architecture (where disclosed), training data characteristics, recommended use cases, known limitations, and evaluation results. Customers building generative AI applications on Bedrock consult these cards to select models that match their requirements and to document vendor due diligence.

Model card vs Clarify report — the transparency-explainability boundary

A model card is transparency — it describes the model. A Clarify report is explainability — it describes predictions. A strong responsible-AI workflow links them: the model card cites the Clarify report as evaluation evidence, but the two artifacts remain distinct. On the AIF-C01 exam, if the answer options include both "create a model card" and "run Clarify," choose the one the scenario's stakeholder actually needs. A compliance officer reviewing a model for release needs a model card. A customer service agent explaining a single decline needs Clarify output.

Amazon SageMaker Model Cards and Amazon Bedrock Model Cards document a model's training data, intended use, evaluation results, and known limitations. They do not explain individual predictions. For per-prediction explanation on AIF-C01, the answer is SageMaker Clarify with SHAP — not a model card. Reference: https://docs.aws.amazon.com/sagemaker/latest/dg/model-cards.html

AWS AI Service Cards — Transparency for Managed AI Services

AWS AI Service Cards are the transparency artifact for AWS's managed AI services — Amazon Rekognition, Amazon Transcribe, Amazon Textract, Amazon Comprehend, Amazon Polly, Amazon Lex, Amazon Personalize, Amazon Fraud Detector, and others. When you use a managed AI service, you are not training the model yourself, so you cannot produce a model card. AWS publishes service cards so customers can still discharge transparency obligations.

What a service card contains

An AWS AI Service Card covers: basic concepts (what the service does in plain language), intended use cases and limitations, design of the service (high-level architecture and how outputs are generated), responsible AI considerations (fairness, privacy, safety), and deployment best practices. Each card is authored and maintained by AWS.

Where to find service cards

AWS AI Service Cards are published on the AWS Responsible AI resources page. Current cards cover Amazon Rekognition face matching, Amazon Transcribe batch and streaming, Amazon Textract analyze-document, Amazon Comprehend detect toxic content, Amazon Titan text, and a growing list. AWS treats service cards as living documents — they are updated as services gain or change capabilities.

Service card vs model card — the scope boundary

A model card describes one specific model version trained by you or by a third party. An AWS AI Service Card describes an entire managed AWS AI service, which may be powered by multiple models internally. If the AIF-C01 scenario mentions Amazon Rekognition, Transcribe, Textract, or Comprehend and asks for transparency documentation, the answer is the AWS AI Service Card, not a SageMaker Model Card.

Amazon SageMaker Model Cards document models you train and deploy on SageMaker. Amazon Bedrock Model Cards document foundation models available via Bedrock. AWS AI Service Cards document AWS managed AI services such as Amazon Rekognition, Transcribe, and Textract. All three are AI transparency artifacts but they apply to different layers of the AI stack. Reference: https://aws.amazon.com/ai/responsible-ai/resources/

Documentation Practices That Support AI Transparency and Explainability

AI transparency and explainability in production requires more than running one Clarify job and publishing one model card. A mature ML organization bakes documentation into every stage of the ML lifecycle.

Data documentation

Record the provenance of every training dataset: source system, extraction date, preprocessing steps, schema, known quality issues, and any demographic composition analysis. Tools like Amazon SageMaker Feature Store and AWS Glue Data Catalog capture some of this automatically, but intentional data documentation is still a human responsibility.

Model versioning

Every trained model version needs a unique identifier, a link to the exact training dataset, the training hyperparameters, and the evaluation results. Amazon SageMaker Model Registry handles the mechanics; your team must ensure every registered version has a populated model card before it can be promoted to production.

Evaluation documentation

For every model version, document the evaluation dataset, the metrics used (accuracy, F1, precision, recall for classification; BLEU, ROUGE, perplexity for generation; disparate-impact ratio for fairness), and the measured results. Evaluation documentation is transparency input — it shows up in the Evaluation section of the model card.

Prediction-level logging

For explainability investigations after the fact, log every production prediction alongside its input features. Amazon SageMaker Model Monitor and Amazon CloudWatch can capture these logs. When a customer later contests a specific prediction, having the input features preserved lets you retroactively run SageMaker Clarify on that record and generate a local explanation.

Change log and incident log

Maintain a change log for every model update and an incident log for every production issue — hallucinations, biased outputs, prediction drift, downstream harms. Both logs feed future versions of the model card and improve trust with regulators and customers.

How AIF-C01 Exam Scenarios Phrase Transparency vs Explainability

Here is a catalog of phrasings to train your pattern recognition on AI transparency and explainability.

Transparency phrasings

"The compliance team needs a document describing the model's intended use, training data, and known limitations."
"A company wants to inform end users about the capabilities and limitations of the foundation model they are using in Amazon Bedrock."
"A regulator requires disclosure of the data sources used to train a customer-facing recommendation model."
"An internal governance committee needs to review a new model before it can be promoted to production."
"The company wants to publish a statement that describes Amazon Rekognition's fairness considerations and intended use."

All five are transparency. Answers include Amazon SageMaker Model Cards, Amazon Bedrock Model Cards, or AWS AI Service Cards depending on which layer of the stack is in play.

Explainability phrasings

"A customer asks why their loan application was declined. What AWS service should the bank use to explain the prediction?"
"The data science team needs to understand which features the fraud detection model relies on most."
"A physician asks which factors drove the model's recommendation for a specific patient."
"The risk team wants to measure how much each input feature contributed to a specific credit score."
"A company needs to compute SHAP values on predictions from a deployed SageMaker model."

All five are explainability. The AWS answer is Amazon SageMaker Clarify.

Mixed phrasings that test the boundary

"The company wants to be both transparent about how the model was built and able to explain individual predictions." — needs both model cards (transparency) and Clarify (explainability).
"The compliance officer wants to review model documentation and investigate a customer complaint about a specific prediction." — same combined answer.

If the scenario says "both," pick the answer that combines model cards plus Clarify. If the scenario emphasizes only one side, pick only that side.

Foundation Models, Generative AI, and Explainability Limits

AI transparency and explainability is harder for large foundation models than for classical ML. Candidates on AIF-C01 should know the practical limits.

Why foundation models are harder

A foundation model like Anthropic Claude or Amazon Titan has tens to hundreds of billions of parameters and is trained on trillions of tokens. Per-feature SHAP attribution on a trillion-token prompt is not practical, and attention weights — the partial signal you can extract — do not always correspond to human-interpretable reasoning. Transparency via model cards still works (describe architecture, training data, evaluation). Explainability via SHAP does not scale directly.

Practical substitutes for foundation-model explainability

For generative AI, practical explainability techniques include: citations and retrieval-augmented generation (RAG) that ground the answer in retrievable source documents, chain-of-thought prompting that asks the model to state its reasoning, prompt-level attention visualization for shorter inputs, and red-team probing to characterize model behavior on edge cases. None of these are full SHAP-style attribution, but they are the best available.

Amazon Bedrock features that support transparency

Amazon Bedrock provides Model Cards, model evaluation jobs (automatic and human-in-the-loop), and Guardrails for content filtering. Together these cover transparency (cards), evaluation (bias and accuracy measurements), and operational safety (guardrails) — but foundation-model-level per-prediction explainability remains an active research area.

What AIF-C01 expects here

The exam expects you to recognize that classical ML enjoys strong explainability via SHAP and that generative AI has weaker explainability requiring retrieval grounding, model cards, and guardrails. You do not need to implement anything — just recognize the vocabulary.

Responsible AI and the Amazon Bedrock / SageMaker Alignment

AI transparency and explainability does not live alone. AWS groups it under the responsible AI umbrella alongside fairness, privacy, safety, security, controllability, veracity, and governance. The AWS AI Cloud Adoption Framework (AWS CAF for AI) organizes these pillars and maps them to concrete AWS services.

Responsible AI pillars that interact with transparency and explainability

Fairness is evaluated via SageMaker Clarify bias metrics and disclosed via model cards.
Privacy is protected via Amazon Macie, KMS, and VPC endpoints and disclosed via model cards.
Safety is enforced via Amazon Bedrock Guardrails and content filtering and disclosed via service cards.
Governance is operationalized via Amazon SageMaker Model Registry, SageMaker Role Manager, and IAM.
Controllability shows up in inference-time tools like Guardrails and stop sequences.
Veracity is addressed via RAG, Amazon Bedrock Knowledge Bases, and citation patterns.

Transparency is the disclosure layer that wraps around every pillar. Explainability is the diagnostic layer that supports fairness and veracity investigations.

AWS Well-Architected Framework for ML

The AWS Well-Architected Machine Learning Lens includes a design principle for transparency and explainability. The lens recommends: document every model (model card), evaluate every model (Clarify), monitor every deployed model (Model Monitor), and log every production prediction (CloudWatch). On the exam, any question that asks "how do you align an ML workload with responsible AI best practices" should include these four verbs.

Key Numbers and Must-Memorize Facts

For AIF-C01 AI transparency and explainability you need a small fact set, not deep numeric mastery.

Amazon SageMaker Clarify uses SHAP as its default feature-attribution method.
Clarify produces both global (dataset-wide) and local (per-instance) feature importance.
Amazon SageMaker Model Cards, Amazon Bedrock Model Cards, and AWS AI Service Cards are the three AWS transparency artifacts.
Service cards cover managed AI services (Rekognition, Transcribe, Textract, Comprehend). Model cards cover models you train or access via Bedrock.
SHAP and LIME are both post-hoc methods that work on already-trained black-box models.
Interpretable models (linear regression, decision trees) do not need post-hoc explanation.
Transparency artifacts are produced at model release time. Explainability outputs are produced at inference time.
Amazon Bedrock Model Evaluation supports automatic and human-in-the-loop evaluation, feeding transparency artifacts.

Common Exam Traps

Beyond the top-line transparency-vs-explainability confusion, several other traps burn AIF-C01 candidates on AI transparency and explainability scenarios.

Trap — Clarify is only for bias

Wrong. Amazon SageMaker Clarify covers both bias detection and feature attribution (explainability). If the answer option says "SageMaker Clarify" and the scenario is about feature importance, it is still correct.

Trap — model cards explain individual predictions

Wrong. Model cards describe the model at release time; they do not explain individual predictions made after release. For per-prediction explanation, use SageMaker Clarify.

Trap — SHAP and LIME are the same

Close, but not identical. Both are post-hoc local explanation methods, but SHAP has formal mathematical properties (consistency, local accuracy) and is the method SageMaker Clarify uses. LIME is simpler, faster, and more approximate. On AWS-specific questions, pick SHAP.

Trap — transparency means open-source code

Not for the exam. Transparency here means documentation (model card, service card, intended use, training data disclosure), not open-sourcing the model weights or training code. Anthropic Claude is closed-source but has model cards — it is transparent in the AIF-C01 sense.

Trap — AWS AI Service Cards cover all AWS AI services

Not yet. Service cards exist for a growing subset of managed AI services. For SageMaker-trained models you still need SageMaker Model Cards. For Bedrock foundation models you need Bedrock Model Cards. Match the card type to the service layer.

Trap — global explanation means overall transparency

No. Both global and local explanations are forms of explainability. Transparency is a separate concept that lives in model cards and service cards. Do not let the word "global" drag an explainability scenario into the transparency bucket.

Picking "explainability" when the scenario is about disclosure (transparency) or picking "transparency" when the scenario is about explaining a specific prediction (explainability). Re-read the scenario. If the stakeholder is reviewing documentation or intended use, the answer is transparency. If the stakeholder needs to understand why the model predicted something for a specific input, the answer is explainability. Reference: https://aws.amazon.com/machine-learning/responsible-machine-learning/

Transparency and Explainability vs Adjacent Responsible-AI Topics

AI transparency and explainability sits next to bias/fairness and model evaluation. Keep these boundaries sharp.

Transparency and explainability vs bias and fairness

Bias and fairness is about whether the model produces disparate outcomes across demographic groups. Transparency is about disclosing whatever the bias measurements are. Explainability is about tracing a specific prediction back to input features. All three can live in the same conversation, but on exam day they are usually different answers. Bias detection on AWS uses SageMaker Clarify bias metrics. Explainability on AWS uses SageMaker Clarify feature attribution. Transparency uses model cards. Do not pick "model card" for a bias-metric question.

Transparency and explainability vs model evaluation metrics

Model evaluation metrics (accuracy, precision, recall, F1, BLEU, ROUGE, perplexity, disparate-impact ratio) measure how well the model performs. They feed into transparency artifacts (the Evaluation section of a model card). But the metric itself is not transparency; it is evaluation. If the scenario asks "which metric should the team compute?" the answer is an evaluation metric, not a model card.

Transparency and explainability vs generative AI safety

Generative AI safety covers hallucination, prompt injection, toxicity, and copyright. AWS addresses these with Amazon Bedrock Guardrails, content filters, and policy rules. These are operational controls at inference time, not transparency artifacts. A guardrail blocks a toxic response; a model card discloses that the model can produce toxic responses if un-guarded. Keep the inference-time control (guardrail) separate from the documentation artifact (card).

Practice Question Patterns — Mapped Exercises

Expect AIF-C01 exam items in these shapes on AI transparency and explainability:

"A bank needs to explain to a customer why their loan application was denied. Which AWS service should they use?" Answer: Amazon SageMaker Clarify (local explanation with SHAP).
"A compliance team needs documentation describing a foundation model's intended use, training data, and limitations before approving it for production." Answer: Amazon Bedrock Model Card.
"A data science team wants to understand which features their fraud detection model relies on most across all predictions." Answer: Amazon SageMaker Clarify global feature importance (SHAP).
"A company uses Amazon Rekognition and needs to show regulators the responsible AI considerations for that service." Answer: AWS AI Service Card.
"A risk officer wants both model-level documentation and the ability to explain individual predictions." Answer: Amazon SageMaker Model Cards plus Amazon SageMaker Clarify.
"What is the primary difference between AI transparency and AI explainability?" Answer: Transparency is disclosure about the model (training data, intended use, limitations); explainability is understanding why a specific prediction was made.
"A company values interpretability over maximum accuracy. Which modeling approach best fits?" Answer: an inherently interpretable model such as logistic regression or a decision tree.
"Which technique does Amazon SageMaker Clarify use to compute feature attributions?" Answer: SHAP (SHapley Additive exPlanations).
"A team needs local explanations for individual predictions without retraining the model." Answer: a post-hoc method such as SHAP (via SageMaker Clarify) or LIME.
"A generative AI application must ground its answers in source documents to improve explainability of generated responses." Answer: retrieval-augmented generation (RAG), for example via Amazon Bedrock Knowledge Bases.

FAQ — AI Transparency and Explainability Top Questions

Q1. What is the difference between AI transparency and AI explainability on AIF-C01?

AI transparency is disclosure about a model — its training data, intended use, evaluation results, and known limitations — captured in documents like Amazon SageMaker Model Cards, Amazon Bedrock Model Cards, and AWS AI Service Cards. AI explainability is understanding why a specific prediction was made — captured through feature-attribution methods like SHAP, delivered in AWS via Amazon SageMaker Clarify. Transparency answers "what is this model?" Explainability answers "why did it predict this?" The two concepts are complementary but solve different stakeholder problems.

Q2. Which AWS service should I use for feature attribution and why?

Amazon SageMaker Clarify. Clarify uses SHAP (SHapley Additive exPlanations) to compute both global feature importance (how much each feature matters on average across the dataset) and local feature importance (how much each feature contributed to a specific prediction). Clarify runs as a SageMaker Processing Job, integrates with SageMaker Model Monitor for drift detection, and feeds its outputs into SageMaker Model Cards for documentation.

Q3. What is the difference between global and local explanations?

A global explanation describes the model's overall behavior across many predictions — which features the model relies on most on average. A local explanation describes why the model produced one specific prediction for one specific input. Both are forms of explainability (not transparency) and both can be computed by Amazon SageMaker Clarify using SHAP. Global is model-wide; local is prediction-specific. Scenarios that mention "overall feature importance" want global. Scenarios that mention "why this specific customer was denied" want local.

Q4. When should I choose an interpretable model over a black-box model with post-hoc explanation?

Choose an inherently interpretable model (linear regression, logistic regression, shallow decision tree, generalized additive model) when the stakeholder values being able to read the model directly over squeezing out the last few points of accuracy, when the regulatory environment demands a model that any reviewer can inspect without extra tooling, or when the dataset is small enough that a simple model performs competitively. Choose a black-box model with post-hoc SHAP explanation when you need the extra accuracy and the stakeholder accepts a two-artifact workflow (the model plus the SHAP report).

Q5. What is the difference between Amazon SageMaker Model Cards and AWS AI Service Cards?

Amazon SageMaker Model Cards document a specific model version that you train, register, and deploy inside SageMaker — they apply to your own custom models. AWS AI Service Cards document AWS managed AI services such as Amazon Rekognition, Amazon Transcribe, Amazon Textract, and Amazon Comprehend — they are authored and maintained by AWS and published on the AWS Responsible AI resources page. If you trained the model, you need a model card. If you are consuming a managed AWS AI service, you consult the service card. Amazon Bedrock Model Cards are a third variant that covers foundation models available via Amazon Bedrock.

Q6. Can I explain generative AI outputs from Amazon Bedrock the same way I explain classical ML predictions?

Not directly. Classical ML models of modest size can be explained with SHAP via Amazon SageMaker Clarify, producing per-feature attribution scores. Foundation models underlying Amazon Bedrock have billions of parameters and trillions of training tokens, and SHAP does not scale to per-token attribution at that size. The practical substitutes are retrieval-augmented generation (RAG) to ground answers in citable source documents, Amazon Bedrock Model Cards for transparency, chain-of-thought prompting to surface reasoning, and red-team evaluation to characterize behavior. Amazon Bedrock Guardrails provide inference-time safety controls that complement but do not replace explainability.

Q7. Does AWS SageMaker Clarify handle both bias detection and explainability?

Yes. Amazon SageMaker Clarify covers both responsibilities. It computes pre-training bias metrics (on the training dataset), post-training bias metrics (on the model's predictions), and SHAP-based feature attributions for explainability. On AIF-C01, seeing "SageMaker Clarify" in an answer option is valid for both bias-detection scenarios and feature-attribution scenarios. Read the stem carefully to confirm which responsibility the question is asking about.

Q8. What should go into a model card to satisfy AI transparency requirements?

A complete model card should include: basic details (model name, version, owner, date), intended use cases, out-of-scope use cases, training data description (source, preprocessing, known bias), evaluation datasets and results (including any fairness metrics from Clarify), known limitations and failure modes, ethical considerations and mitigations, deployment recommendations, and any relevant regulatory disclosures. The goal is that a compliance officer, a downstream consumer, or an end user can read the card and understand what the model is and is not.