Security, Compliance, and Governance for AI Solutions

Chapter 16 — Securing AI Systems, and Controlling Hallucination

Certification Blueprint

Field	Coverage
Exam	AWS Certified AI Practitioner (AIF-C01), exam guide v1.1
Domain	Content Domain 5 — Security, Compliance, and Governance for AI Solutions
Exam weight	14% of scored content
Task statement	5.1 Explain methods to secure AI systems
Objectives	5.1.1 AWS services and features to secure AI systems · 5.1.2 source citation and documenting data origins · 5.1.3 best practices for secure data engineering · 5.1.4 security and privacy considerations · 5.1.5 hallucination detection and grounding
Service families	AWS IAM · AWS KMS and encryption · Amazon Macie · AWS PrivateLink · Amazon Bedrock Guardrails · Amazon Bedrock AgentCore Identity and Policy · Amazon SageMaker Model Cards

What This Chapter Covers

Five earlier chapters made a promise and pointed here. Chapter 07 named hallucination as a disadvantage of generative AI and did not say what to do about it. Chapter 09 built a knowledge base and deferred securing it. Chapter 10 taught four prompt risks, said plainly that prompt-level defences are advisory rather than enforcing, and handed the real controls to Domain 5. This chapter is where all of that is paid off.

Everything in it follows from one observation, and it is worth stating before any service name:

An AI system is an ordinary system plus one component that can be confidently wrong. Every control you would apply to any other application still applies, unchanged — identity, encryption, network isolation, data access control. What is new is that the model is not a trusted component: it will repeat what it was shown, obey whatever text reaches it, and assert things that were never in its inputs.

That single difference explains the shape of the whole task statement. Six of the ten considerations in Objective 5.1.4 are ordinary security applied to an AI workload. Four exist only because a foundation model sits in the path. Being able to tell which kind a question is asking about decides a surprising number of marks.

What to remember from this diagram: the model sits in the middle, labelled untrusted, and there are controls on both sides of it. Everything above it is security you already know. Everything below it exists because the thing in the middle cannot be relied upon to be right. A scenario that describes a problem after generation is asking about the lower half.

Objective 5.1.1 — The Services, by the Layer They Defend

The objective names eight things. Memorising them as a list is the slow way; each one defends a specific layer, and the layer is what a scenario actually describes.

Service or feature	Layer	What it answers
IAM roles, policies, permissions	Identity	Who may invoke the model, read the data, or call the tool
Encryption (at rest and in transit)	Data	Whether readable data survives a stolen disk or an intercepted connection
Amazon Macie	Data	What sensitive data is actually in there — discovery and classification in Amazon S3
AWS PrivateLink	Network	Whether traffic to the service crosses the public internet at all
AWS shared responsibility model	All	Where AWS's obligation stops and yours starts
Amazon Bedrock AgentCore Identity	Identity	Who an agent is when it acts on a user's behalf
Policy in AgentCore	Identity	What that agent is permitted to do once identified
Amazon Bedrock Guardrails	Input and output	What content is allowed to reach, or leave, the model

The shared responsibility model, and the line that moves

AWS secures the cloud; you secure what you put in it. For AI workloads the exam cares about where the line sits for different consumption models, because it moves.

What to remember from this diagram: three things never become AWS's problem no matter which service you pick — who may call it, what data you chose to send, and what you do with the output. A distractor that assigns any of those three to AWS is wrong regardless of the service in the stem.

You are running	AWS secures	You secure
A managed API (Amazon Bedrock)	Model hosting, patching, the underlying infrastructure	Access control, the data you send, the use of the output
A self-hosted model (SageMaker AI, EC2)	The facility, hardware, hypervisor	The OS, the container, patching — plus everything in the managed column

The exam signal: a scenario that moves from Bedrock to a self-hosted model and asks what changes is asking about this table. The answer is that responsibilities are added, never removed.

Identity for agents — AgentCore Identity and Policy

Chapter 06 introduced agents that call tools and reach external systems. That raises a question ordinary IAM was not designed for: when an agent acts for a user, who is acting?

• AgentCore Identity establishes the agent's identity as a first-class thing — so an agent's actions can be attributed rather than appearing as one shared service principal.
• Policy in AgentCore constrains what the identified agent may do, which is where least privilege actually gets enforced for agentic workloads.

Why this matters and is examinable: an agent that can call tools is an agent that can be made to call tools by injected text. Identity and policy are what stop a hijacked agent from doing anything worse than producing bad text. This is the enforcing control that Chapter 10 said the prompt could not provide.

Amazon Macie and AWS PrivateLink

Two named services that are easy to confuse because both sound like general protection.

	Amazon Macie	AWS PrivateLink
Question it answers	What sensitive data is in my storage?	Does my traffic touch the public internet?
Layer	Data	Network
Typical scenario wording	"We do not know whether personal data reached the training set"	"Traffic to the model endpoint must not traverse the internet"

Macie discovers and classifies — it finds the sensitive data you did not know you had, which is the control that prevents an entire class of problem in Objective 5.1.3.

Objective 5.1.2 — Source Citation and Documenting Data Origins

Three named mechanisms, and the reliable way to keep them apart is the question each one answers.

What to remember from this diagram: the chain ends at a single question — where did this answer come from? Each mechanism answers one link of it, and a scenario usually names the broken link rather than the mechanism.

Mechanism	The question it answers	Broken when
Data cataloging	What data do we have, and where does it live?	Nobody can say what is in the corpus at all
Data lineage	Where did this particular record come from, and what transformed it on the way?	A bad record is found and its origin cannot be traced
Source citation	Which source produced this specific claim in this answer?	The answer is plausible and unattributable
SageMaker Model Cards	What was this model built from, what is it for, and what are its limits?	Nobody can say what the deployed model was trained on

Source citation is the one with a second job. It documents origin, and it also gives a reader the means to check — which makes it a hallucination control as well as a provenance one. That overlap is why Objective 5.1.5 and this objective touch, and the exam does exploit it.

The distinction that is tested: lineage is about data on the way in; citation is about claims on the way out. A scenario asking how a wrong figure got into the corpus is lineage. A scenario asking how a reader could verify a figure in an answer is citation.

Objective 5.1.3 — Secure Data Engineering

Four named practices. Each one prevents a specific, nameable failure.

Practice	What it means	The failure it prevents
Assessing data quality	Checking that data is accurate, complete, current and representative before it is used	A model confidently trained or grounded on wrong data — and a wrong answer with no bug anywhere in the code
Implementing privacy-enhancing technologies	Anonymisation, pseudonymisation, masking, tokenisation, aggregation — reducing what identifies a person while keeping the data useful	Personal data reaching a model that will later repeat it
Data access control	Least privilege over the data itself, not only the application	Broad read access turning one compromised credential into full corpus exposure
Data integrity	Ensuring data has not been altered without authorisation, in transit or at rest	Poisoned or tampered source material silently changing what the model says

Data quality is a security practice here, not only a model-accuracy one. This surprises people. The exam guide places it in a secure data engineering objective because unverified data is an untrusted input, and an untrusted input that reaches a model becomes an untrusted output. Chapter 10 called the same phenomenon poisoning; this is the discipline that prevents it.

Privacy-enhancing technologies are the pairing with Macie. Macie finds the sensitive data; PETs are what you then do about it. A scenario naming both a discovery problem and a remediation is usually naming these two in sequence.

Objective 5.1.4 — The Considerations, Split Two Ways

The objective names ten things. Six are ordinary security; four exist only because a model is in the system. This split is the single most useful thing to carry into the exam from this objective.

Conventional — would exist without any AI	AI-specific — exists because of the model
Application security	Prompt injection
Threat detection	Data leakage prevention
Vulnerability management	Output filtering and validation
Infrastructure protection	Toxicity
Encryption at rest and in transit
Audit trail and logging (but with an AI twist — see below)

The conventional five, stated briefly

They are examinable but they are not the difficulty. Application security covers the API, authentication and the usual web surface. Threat detection and vulnerability management are the ongoing disciplines of noticing attacks and fixing known weaknesses. Infrastructure protection is network and host controls. Encryption at rest and in transit protects data in storage and on the wire.

The exam's use for them is mostly as correct-but-irrelevant distractors: an option offering "enable encryption at rest" against a scenario describing a model repeating another customer's data is proposing a real control for the wrong problem.

The four that are genuinely new

Prompt injection. Chapter 10 classified it. This chapter defends against it.

What to remember from this diagram: every control shown sits outside the prompt. That is the whole difference between Chapter 10 and this chapter. Telling the model to resist override attempts is more text in the same string; validating input, constraining what the application may do, and filtering output are enforcing controls that do not depend on the model cooperating.

The most important of the four defences is the third, and it is the one candidates skip: least privilege on what the application may do with the answer. If a hijacked model can only produce text, the damage is bounded. If it can trigger a payment because the application executes whatever the model returns, the injection became a transaction. Chapter 06's agents are exactly this risk, which is why AgentCore Policy appears in Objective 5.1.1.

Data leakage prevention. The model repeats what it was given — training data, retrieved context, another user's session. Controls: keep sensitive data out (PETs, Macie), scope retrieval to what the requesting user may see, and filter output.

⚠️ The retrieval scoping point is the one most often missed. A knowledge base that retrieves from the whole corpus regardless of who is asking will happily ground an answer in a document the asker has no right to read. Access control has to apply at retrieval time, not only at the document store. This is the specific control Chapter 09 deferred to this chapter.

Output filtering and validation. Inspecting what the model produced before it reaches anyone. This is where Amazon Bedrock Guardrails does security work: content filters, denied topics, sensitive-information filtering and redaction. Note the contrast Chapter 10 drew — a negative prompt asks the model to avoid something; output filtering removes it after generation. Only the second is enforcing.

Toxicity. Harmful, abusive or otherwise unacceptable content, either reaching the model or leaving it. Guardrails filters it in both directions. It is named separately from output filtering because it is a category of content rather than a mechanism.

Audit trail and logging for AI interactions

Logging is ordinary. Logging AI interactions is not, and the objective names it specifically.

An AI audit trail must capture	Why
The prompt as assembled, including retrieved context	The input is constructed at request time and is not reproducible from the user's text alone
The model and version invoked	The same prompt against a different model is a different system
The response returned	The output is non-deterministic, so it cannot be regenerated for an investigation
Which sources were retrieved	Without this, no claim in the answer can be traced

The exam signal: a scenario asking how you would investigate an incident after the fact in a generative system is naming this. The trap answer is "reproduce it" — you cannot, because generation is non-deterministic and the assembled prompt no longer exists unless it was logged.

Objective 5.1.5 — Controlling Hallucination

Chapter 07 named hallucination as a disadvantage of generative AI. This objective turns it into something you engineer against. It names three techniques, and they are three rungs of one ladder, not three alternatives.

What to remember from this diagram: there are two decision diamonds after the model generates. Grounding alone stops at the box labelled "generates" — everything that actually verifies happens downstream of it.

Rung	Technique	What it does	What it does not do
1	RAG grounding	Supplies real retrieved passages the answer must be built from, so the model is recalling rather than inventing	Guarantee the model used them, or used them correctly
2	Output validation	Checks each claim in the answer against the retrieved sources, and suppresses or refuses what is unsupported	Judge how confident the system should be
3	Confidence scoring	Attaches a strength-of-support score, so low-confidence answers route to human review instead of to the user	Make the answer correct — it decides who sees it

Grounding is a reduction, not a guarantee. This is the examinable point and it is why the objective names three things rather than one. A grounded model can still misread a passage, blend two sources, or answer from parametric memory when retrieval returned nothing useful. If a scenario demands that an incorrect answer must never reach a customer, grounding alone is not the answer — validation and a human path are.

Source citation appears again here, and that is not an accident. Citing the passage behind each claim is simultaneously a provenance mechanism (5.1.2) and a hallucination control, because an unattributable claim is exactly what an unsupported one looks like. If a question offers citation as an option, check which objective the stem is really in.

Amazon Bedrock Guardrails does hallucination work too — its contextual grounding check evaluates whether a response is actually grounded in the supplied source material. That makes Guardrails the one service in this task statement that appears at three separate points: input filtering, output filtering, and grounding verification.

Decision Rules and Exam Signals

Rule 1 — an AI system is an ordinary system plus one untrusted component. Every classic control still applies; the new ones exist because the model may repeat, obey, or invent.

Rule 2 — classify the control by the layer it acts on. Identity, network, data, input, output, grounding. The layer named in the scenario picks the service.

Rule 3 — three things never move to AWS: who may call it, what data you send, what you do with the output. Any option assigning those to AWS is wrong.

Rule 4 — self-hosting adds responsibilities and removes none.

Rule 5 — lineage is data on the way in; citation is claims on the way out.

Rule 6 — data quality is a security practice. Unverified data is an untrusted input, and an untrusted input becomes an untrusted output.

Rule 7 — six of the ten considerations are ordinary security. Ask whether the control would exist if there were no model. If yes, it is conventional and probably not what a model-specific scenario is testing.

Rule 8 — enforcing controls live outside the prompt. Input validation, least privilege on actions, output filtering. An instruction to the model is advisory.

Rule 9 — bound what the model can do, not only what it can say. A hijacked model that can only emit text is a content problem; one wired to execute is an incident.

Rule 10 — access control must apply at retrieval time. Otherwise the knowledge base grounds answers in documents the asker may not read.

Rule 11 — you cannot reproduce a generative incident. Log the assembled prompt, the model and version, the retrieved sources, and the response.

Rule 12 — grounding reduces hallucination; it does not eliminate it. If the requirement is a guarantee, the answer includes validation and a human path.

Distractor Patterns

Pattern	What it looks like	How to defuse it
The right control for the wrong problem	"Enable encryption at rest" against a model repeating another user's data	Encryption protects stored bytes; it does nothing about what a model says. Match the control to the layer
AWS secures it for you	Managed service offered as removing responsibility for access or data	Identity, the data you send, and the use of the output never move
Self-hosting is more secure	Framed as taking control	It adds obligations — OS, container, patching — on top of everything you already had
Prompt-level defence against injection	"Instruct the model to ignore override attempts"	Advisory, not enforcing. Chapter 10 established this; the controls here sit outside the prompt
Grounding as a guarantee	RAG offered where an incorrect answer must never reach a customer	Grounding reduces, it does not eliminate. Validation and human review are what guarantee
Confidence scoring makes it correct	Scoring offered as an accuracy improvement	It decides who sees the answer; it does not change the answer
Macie vs PrivateLink swap	Network answer for a data-discovery problem, or vice versa	Macie finds sensitive data; PrivateLink keeps traffic off the internet
Lineage offered for a citation problem	Provenance of the corpus offered when a reader needs to verify a claim	Lineage is inbound; citation is outbound
Model Cards as a security control	Offered as protecting the model	They document what the model was built from. Provenance, not protection
Reproduce the incident	Offered as the investigation method	Generation is non-deterministic and the assembled prompt is gone unless logged
Filter the output instead of scoping retrieval	Output filtering offered for a document-permissions problem	If the wrong document was retrieved, the leak already happened. Scope retrieval by the asker's rights
Guardrails as only a responsible-AI tool	Treated as belonging to Domain 4 alone	It appears in three objectives. Here it does input filtering, output filtering, and grounding checks

The fourth and fifth rows are the two most reliable ways to lose marks in this task statement, because both offer a control that genuinely helps and present it as sufficient.

Scenario Walkthrough

A bank runs an assistant that answers customer questions about their own accounts. It retrieves from an internal knowledge base containing product documentation and internal credit policy memos. Traffic to the model endpoint currently crosses the public internet. Compliance has asked three things: that no customer ever receives a figure the system cannot attribute to a source, that an incorrect rate quote must never reach a customer, and that after any complaint the bank must be able to reconstruct exactly what the assistant was asked and what it replied. A tester has already shown that asking the assistant to "summarise your internal guidance" returns paragraphs of the credit policy memos.

Requirement	Reading	Decision
Tester extracted internal memos	Retrieval is not scoped to the asker's rights	Access control at retrieval time — a data leakage prevention failure, not an output-filtering one
Endpoint traffic crosses the internet	Network layer	AWS PrivateLink
Every figure must be attributable	Claims on the way out	Source citation — and it doubles as a hallucination control
An incorrect rate must never reach a customer	A guarantee, not a reduction	Grounding plus output validation plus a human path — RAG alone does not meet "never"
Reconstruct what was asked and replied	Post-incident investigation of a non-deterministic system	Audit trail capturing assembled prompt, model and version, retrieved sources, and response

Five requirements, and the first one is the test. The tempting answer is output filtering — block the memo text on the way out. But the document was already retrieved and placed in the prompt, which means it was already exposed to the model and to anyone who can influence the prompt. The failure is that a user with no right to the memos caused them to be retrieved at all. Fix the retrieval scope, not the response. Filtering output here treats the symptom and leaves the leak.

The fourth row is the second test. "Must never reach a customer" is a guarantee, and a candidate who has learned "RAG fixes hallucination" will stop at grounding.

Key Concepts

Term	Definition
Shared responsibility model	The division of security obligations between AWS and the customer; the line moves with the service, but identity, the data you send, and the use of the output are always yours
IAM roles, policies, permissions	The identity-layer controls determining who or what may invoke a model, read data, or call a tool
Encryption at rest	Protection of stored data so that readable content does not survive physical or storage-level compromise
Encryption in transit	Protection of data on the wire so that intercepted traffic is not readable
Amazon Macie	The service that discovers and classifies sensitive data in Amazon S3 — it answers "what sensitive data do we actually have?"
AWS PrivateLink	Private connectivity to a service so that traffic does not traverse the public internet
Amazon Bedrock AgentCore Identity	Identity for an agent acting on a user's behalf, so an agent's actions can be attributed
Policy in AgentCore	The controls constraining what an identified agent is permitted to do — least privilege for agentic workloads
Amazon Bedrock Guardrails	Configurable filtering applied to model input and output — content filters, denied topics, sensitive-information redaction, and contextual grounding checks
Data cataloging	A record of what data exists and where it lives
Data lineage	A record of where a given record came from and what transformed it on the way
Source citation	Attribution of a specific claim in an answer to the specific source that supports it; both a provenance mechanism and a hallucination control
Amazon SageMaker Model Cards	Documentation of what a model was built from, its intended use, and its limitations
Privacy-enhancing technologies	Techniques such as anonymisation, masking, tokenisation and aggregation that reduce identifiability while keeping data useful
Data integrity	Assurance that data has not been altered without authorisation, in transit or at rest
Prompt injection	Untrusted text reaching the prompt and being read as instruction; defended outside the prompt, never within it
Data leakage prevention	Controls stopping the model from surfacing training data, retrieved context, or another user's data
Output filtering and validation	Inspection of generated content before release — enforcing, unlike a negative prompt
Toxicity	Harmful, abusive or unacceptable content, filtered on the way in and on the way out
RAG grounding	Supplying retrieved source passages the answer must be built from, so the model recalls rather than invents
Output validation	Checking each claim in a response against the retrieved sources and suppressing what is unsupported
Confidence scoring	Attaching a strength-of-support score so low-confidence answers route to human review rather than to the user

Revision Flashcards

Say the answer aloud before revealing it.

1. State the one sentence this whole chapter follows from. → An AI system is an ordinary system plus one component that can be confidently wrong. Every classic control — identity, encryption, network isolation, data access control — applies unchanged. What is new is that the model is untrusted: it repeats what it was shown, obeys whatever text reaches it, and asserts things that were never in its inputs.

2. Which three responsibilities never move to AWS, whichever service you choose? → Who may call it, what data you choose to send, and what you do with the output. The shared responsibility line moves with the service — a managed API takes hosting and patching off your plate — but those three are always the customer's, and an option assigning any of them to AWS is wrong regardless of the stem.

3. What changes when you move from a managed API to a self-hosted model? → Responsibilities are added, never removed. You take on the operating system, the container and patching, on top of everything you already owned in the managed case. "Self-hosting is more secure because we control it" is a distractor; control and obligation are the same thing here.

4. Distinguish Amazon Macie from AWS PrivateLink. → Macie is a data-layer control that discovers and classifies sensitive data in Amazon S3 — it answers "what sensitive data do we actually have?" PrivateLink is a network-layer control determining whether traffic to a service crosses the public internet. They are swapped in distractors precisely because both sound like general protection.

5. What do AgentCore Identity and Policy in AgentCore each provide? → AgentCore Identity establishes who an agent is when it acts on a user's behalf, so its actions can be attributed rather than appearing as one shared principal. Policy in AgentCore constrains what that agent may do. Together they are the enforcing control that bounds a hijacked agent — the thing Chapter 10 said a prompt could not provide.

6. Tell data cataloging, data lineage and source citation apart. → Cataloging answers "what data do we have and where does it live?" Lineage answers "where did this particular record come from and what transformed it?" Citation answers "which source produced this specific claim?" Lineage is data on the way in; citation is claims on the way out.

7. Why is assessing data quality placed in a secure data engineering objective? → Because unverified data is an untrusted input, and an untrusted input that reaches a model becomes an untrusted output. A model grounded on wrong data produces a wrong answer with no bug anywhere in the code. Chapter 10 called the deliberate version of this poisoning; data quality assessment is the discipline that prevents both the deliberate and accidental forms.

8. Objective 5.1.4 names ten considerations. What is the split, and why does it matter? → Six are ordinary security that would exist without any AI — application security, threat detection, vulnerability management, infrastructure protection, encryption at rest and in transit, and audit logging. Four exist only because a model is present: prompt injection, data leakage prevention, output filtering and validation, and toxicity. Questions are frequently decided by noticing which kind the scenario describes, because the conventional ones make excellent correct-but-irrelevant distractors.

9. Where do enforcing defences against prompt injection live, and name the one most often skipped. → Outside the prompt — input validation, Guardrails on the input, output filtering, and least privilege on what the application may do with the answer. That last one is the skipped one and the most important: if a hijacked model can only produce text the damage is bounded, but if the application executes what the model returns, the injection became a transaction.

10. A knowledge base retrieves from the whole corpus regardless of who is asking. What is the failure, and what is the wrong fix? → The failure is data leakage through unscoped retrieval — access control must apply at retrieval time, not only at the document store. The wrong fix is output filtering: by the time you are filtering the response, the document has already been retrieved and placed in the prompt. Filtering treats the symptom and leaves the leak.

11. Why can you not investigate a generative incident by reproducing it? → Because generation is non-deterministic and the assembled prompt no longer exists. The same user text produces a different prompt once retrieval has run again, and the same prompt produces a different response. The audit trail must capture the assembled prompt including retrieved context, the model and version invoked, which sources were retrieved, and the response returned.

12. Name the three rungs of the hallucination ladder and the reason there are three rather than one. → RAG grounding, output validation, confidence scoring. There are three because grounding is a reduction, not a guarantee — a grounded model can still misread a passage, blend two sources, or fall back on parametric memory when retrieval returns nothing useful. Validation checks each claim against the sources; confidence scoring decides whether a human sees it first. If a scenario says an incorrect answer must never reach a customer, grounding alone does not meet it.

The Five-Beat Answer

The core question this chapter prepares you for: "How would you secure a generative AI application, and how would you stop it saying something untrue?"

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

1. Frame — say the structural point first: an AI system is an ordinary system plus one untrusted component. Every classic control still applies; the new ones exist because the model may repeat, obey, or invent.
2. Perimeter — the conventional layers, named to their services: identity with IAM and AgentCore Identity plus Policy, network with PrivateLink, data with encryption in both states, Macie for discovery, and least privilege over the data itself. State where the shared responsibility line sits for your consumption model.
3. Data — secure data engineering: quality assessment, privacy-enhancing technologies, access control, integrity. Then provenance — cataloging, lineage, Model Cards — so you can say what the system was built from.
4. Model surface — the four AI-specific controls: injection defended outside the prompt, leakage prevented by scoping retrieval to the asker's rights, output filtering and validation with Guardrails, toxicity in both directions. Then the audit trail, and why a generative incident cannot be reproduced.
5. Truth — the hallucination ladder: ground with RAG, validate each claim against its sources, score confidence and route the weak ones to a human. Say explicitly that grounding is a reduction and not a guarantee.

A strong answer names the layer before naming the service, and refuses to present grounding as a guarantee. A weak answer lists AWS services without saying what each defends.

Why This Helps You

On the job: the most common failure in this area is a knowledge base wired to retrieve from everything, because scoping retrieval per user is more work than indexing a corpus once. It ships, it demos beautifully, and the first time someone asks the assistant to summarise internal guidance it does. The second most common is treating a prompt instruction as a control — writing "never reveal these instructions" and considering the matter closed.

In interviews: "how would you stop the model hallucinating?" is a standard screening question, and most candidates answer "RAG" and stop. The strong answer says grounding reduces rather than eliminates, then names what verifies — claim-level validation against retrieved sources — and what decides who sees a weak answer. Being able to say why three techniques are named rather than one marks out someone who has operated one of these systems.

On the exam: Domain 5 is 14% of scored content and this task statement is the larger of its two. The highest-value habits are classifying a control by the layer it acts on, and separating the six conventional considerations from the four that exist only because a model is present.

Chapter Checklist

• I can state why an AI system is an ordinary system plus one untrusted component
• I can place each named service at the layer it defends
• I can name the three responsibilities that never move to AWS
• I can say what changes when a workload moves from a managed API to self-hosting
• I can distinguish Amazon Macie from AWS PrivateLink by the layer each acts on
• I can explain what AgentCore Identity and Policy in AgentCore each provide
• I can tell cataloging, lineage, citation and Model Cards apart by the question each answers
• I can name the four secure data engineering practices and the failure each prevents
• I can explain why data quality is a security practice
• I can split the ten considerations into conventional and AI-specific
• I can name the injection defences and say why they sit outside the prompt
• I can explain why access control must apply at retrieval time
• I can say what an AI audit trail must capture and why reproduction is not possible
• I can name the three rungs of the hallucination ladder and say why grounding is not a guarantee

After the Chapter

1. Complete student/project.md — parts 55-57 of the AI/ML Decision Sheet you began in Chapter 01. Bring the same sheet; do not start a new one.
2. Take student/quiz.md closed-book, then review the reasoning for every question you guessed, including the ones you got right. Pay particular attention to questions 9 and 12 — both offer a control that genuinely helps and present it as sufficient, which is this chapter's signature trap.
3. Open the official v1.1 exam guide's Domain 5 page and confirm you can attach a concept from this chapter to each of the five bullets under Task Statement 5.1. Note how many distinct services the first bullet names — eight — and check you can say which layer each one defends.
4. Next: Chapter 17 — Governance, Compliance, and Audit (Domain 5, Task 5.2). This chapter built the controls; Chapter 17 is about evidencing them — the services that demonstrate compliance to an auditor, data governance across lifecycle and retention, and the governance protocols themselves including the Generative AI Security Scoping Matrix.

Chapter 17 — Governance, Compliance, and Audit

Certification Blueprint

Field	Coverage
Exam	AWS Certified AI Practitioner (AIF-C01), exam guide v1.1
Domain	Content Domain 5 — Security, Compliance, and Governance for AI Solutions
Exam weight	14% of scored content — shared with Task 5.1
Task statement	5.2 Recognize governance and compliance regulations for AI systems
Objectives	5.2.1 AWS services for governance and compliance · 5.2.2 data governance strategies · 5.2.3 processes to follow governance protocols

What This Chapter Covers

Chapter 16 gave you controls. Encryption, identity, isolation, guardrails, output filtering — the machinery that stops the bad thing happening.

This chapter asks the question that always follows:

Can you prove it?

An auditor does not accept "encryption is enabled." They accept a record showing it was enabled on the date in question, a record of who could have changed it, and a document stating that enabling it was the policy. Governance is the discipline that produces those three things.

That is the whole subject, and it has a shape worth holding from the start:

Objective	The question it answers
5.2.1 Services	Where does the evidence come from?
5.2.2 Data governance	What are the rules for the data itself?
5.2.3 Protocols	How does an organisation keep following its own rules?

A warning about this task statement specifically. Every service named in 5.2.1 is real, and every one of them has a genuine governance role. You cannot eliminate by spotting the invented option, because there isn't one. You eliminate by asking what kind of evidence the question needs.

The Six Services, by the Evidence They Produce

Objective 5.2.1 names six services. Learners routinely memorise six one-line definitions and then find that all six sound applicable to any compliance scenario — because at the level of "helps with compliance," they are.

The discrimination that works is narrower:

What artefact does this service hand you, and what question does that artefact answer?

What to remember from this diagram: the first split is the one that decides most questions. Before comparing any of the five customer-side services, ask whether the scenario is asking about AWS's compliance or yours. Artifact answers only the first, and it is the only one that does. Everything below that split is about your own workload.

Service	The artefact it produces	The question it answers
AWS Config	A time-stamped record of resource configuration and every change to it	"What was this set to on the 3rd, and when did it change?"
AWS CloudTrail	A record of API calls — identity, action, time, source	"Who did this?"
AWS Audit Manager	Evidence assembled and mapped to a framework's controls	"Show me our evidence against control 4.2"
AWS Artifact	AWS's own third-party audit reports — SOC, ISO, PCI	"Prove that AWS is compliant"
Amazon Inspector	Vulnerability findings against workloads	"What here is exploitable?"
AWS Trusted Advisor	Checks against recommended practice	"Where do we deviate from best practice?"

The first cut: whose compliance is being questioned?

AWS Artifact is the odd one out, and knowing why is worth marks.

Every other service on the list generates evidence about what you built. Artifact does not generate anything — it is a portal where you download reports AWS had produced about itself by external auditors. You cannot use Artifact to show that your model endpoint was encrypted. You use it to show that the underlying platform is certified.

This lands directly on the shared responsibility model from Chapter 16. Artifact covers AWS's side of the line. Config, CloudTrail, Inspector, Trusted Advisor and Audit Manager cover yours.

The exam signal: a scenario where an auditor or customer asks for a SOC 2 report, an ISO certification, or "evidence of the provider's compliance" is an Artifact question, and nothing else on the list can answer it.

The pair that decides the most questions: Config versus CloudTrail

These two are confused more than any other pair in Domain 5, and one word separates them.

What to remember from this diagram: Config records state; CloudTrail records actions. Both saw 14:02. Config knows what the setting became; CloudTrail knows who made the call. Neither can answer the other's question, and a real audit almost always needs both — which is why a question offering only one is usually testing whether you know which artefact was asked for.

	AWS Config	AWS CloudTrail
Records	Resource configuration and its history	API calls
Answers	What was it set to, and when did that change?	Who called what, when, from where?
Natural question	"Was this bucket public on the 3rd?"	"Who made it public?"
Also supports	Compliance rules that evaluate configuration continuously	Forensic reconstruction of an incident
The word in the stem	configuration, setting, state, drift, compliant resource	who, which user or role, API call, action taken

The practical test: if you can imagine the answer being a value — enabled, disabled, us-east-1, kms-key-abc — the question is Config's. If the answer is a name — a user, a role, a service — it is CloudTrail's.

Audit Manager assembles; it does not observe

Audit Manager is the service most often mis-filed, because it sounds like the general-purpose compliance service and it is not.

AWS Audit Manager continuously collects evidence from other services and maps it to the controls of a named framework, so that an audit against that framework can be answered with assembled evidence rather than a manual scramble.

It does not watch your resources itself. It consumes what Config, CloudTrail and others produce, and organises it against a control set. That is the reason for the dashed arrows in the first diagram.

The exam signal is the word framework or a named standard — an audit against a specific control set, with evidence needing to be mapped to specific controls. If a scenario names the framework and complains about the effort of assembling evidence for it, that is Audit Manager.

Inspector and Trusted Advisor: two kinds of "you should fix this"

These two both hand you a list of things to improve, and are separated by what kind of problem is on the list.

	Amazon Inspector	AWS Trusted Advisor
Finds	Vulnerabilities — known CVEs, unintended network exposure	Deviations from recommended practice across cost, performance, security, fault tolerance and service limits
The underlying question	"What here could be exploited?"	"Where are we not following AWS's advice?"
Nature of a finding	A specific security weakness with a severity	A recommendation, often not a security issue at all

Trusted Advisor is the broader and shallower of the two, and the only one on this list whose findings are frequently about cost rather than compliance. Inspector is narrow and security-specific. A scenario about unpatched software or an exploitable workload is Inspector's; a scenario asking whether the account follows AWS's general recommendations is Trusted Advisor's.

Data Governance

Objective 5.2.2 names six things: data lifecycles, logging, residency, monitoring, observation, and retention.

They are not six parallel items, and reading them as a flat list is the mistake this objective punishes. Three are stages or properties of the data's life; three are disciplines that run across all of it.

What to remember from this diagram: logging, monitoring and observation are not a stage. They are drawn touching every stage because they run continuously across the whole lifecycle. A learner who memorises the six as a sequence will look for the "logging step" in a scenario and not find it.

Item	What it governs	Where it lives
Data lifecycle	The stages data passes through — ingestion, classification, storage, use, retention, disposal	The frame the rest sit in
Residency	Where data physically lives, and which jurisdiction's law applies to it	A property of the store stage
Retention	How long data is kept, and the basis for keeping it	A property of the retain stage
Logging	What is recorded about access and use	Across every stage
Monitoring	Watching for conditions that need action	Across every stage
Observation	Being able to see the system's behaviour at all	Across every stage

Residency and retention: different words, different questions

The exam builds questions on the confusion, and the distinction is simple once stated.

• Residency asks where. Data must remain within a stated geography — a country, a region, an economic area — because a law or contract requires it.
• Retention asks how long. Data must be kept for a stated period, or deleted after one.

They are independent, and a scenario can constrain both at once. A requirement to keep records for seven years says nothing about which region they sit in; a requirement that data never leave a country says nothing about when it may be deleted.

The exam signal: the words jurisdiction, region, cross-border, must not leave, sovereignty point at residency. The words how long, retain, delete after, records must be kept point at retention. A stem containing a duration is a retention stem.

Why residency is harder for AI systems

Worth understanding rather than memorising, because it explains several plausible-looking distractors.

An AI system moves data further than a database does. Data may be collected in one place, used to build an index in another, sent to a model endpoint in a third, and logged in a fourth. Each of those is a copy, and each copy has a location. A residency requirement applies to all of them — including the inference logs, which is the copy most often forgotten because nobody thinks of a log as customer data.

Logging, monitoring and observation

These three are related, listed together, and not the same thing.

	What it is	Failure mode when absent
Logging	Recording that something happened	Nothing to reconstruct after the fact
Monitoring	Watching recorded signals for conditions that need action	The record exists but nobody notices the condition
Observation	Being able to see what the system is doing at all	You cannot answer a question you did not anticipate

Logging without monitoring is the most common real failure. The evidence was captured and nobody was watching it, which produces the audit finding that the organisation "had the data" and did not act on it. That sequence — recorded, unwatched, discovered later — is worth recognising in a stem.

Governance Protocols

Objective 5.2.3 names policies, review cadence, review strategies, governance frameworks such as the Generative AI Security Scoping Matrix, transparency standards, and team training requirements.

The unifying idea is that a policy is not a governance protocol. A policy is a document. A protocol is what makes the document take effect and stay current.

What to remember from this diagram: the two dashed arrows are the protocol. Without the first, policies never get revised and drift out of date. Without the second, a review keeps finding the same failure and treating it as an operating problem when it is a training problem.

Element	What it is	What its absence looks like
Policies	The written rules, with a named owner	Practice varies by team, and nobody is wrong because nothing was agreed
Review cadence	How often the rules and the evidence are examined	Review happens after an incident, which is not a cadence
Review strategies	How review is conducted — what is sampled, by whom, against what	Review is a meeting, not a method, and finds whatever is raised
Governance frameworks	A structured model for scoping and comparing obligations, such as the Generative AI Security Scoping Matrix	Every use case is assessed from scratch and inconsistently
Transparency standards	What the organisation discloses about its AI systems, to whom, in what form	Disclosure is decided case by case, usually under pressure
Team training requirements	Ensuring the people applying the policy know it	The policy exists and is not followed, which looks like defiance and is ignorance

Cadence and strategy are separate requirements

The guide names both, and they are commonly collapsed into one.

• Cadence is how often. Quarterly, on every model change, on every new data source.
• Strategy is how. Full review or sample, self-assessment or independent, evidence-based or interview-based.

A review that happens reliably and examines whatever someone happens to raise has a cadence and no strategy. A rigorous review that only happens after an incident has a strategy and no cadence. Both failures are examinable, and they look different in a stem.

Transparency standards are a disclosure obligation, not a model property

This boundary is worth stating carefully, because Chapter 15 used a similar word for a different idea.

• Chapter 15, Objective 4.2: transparency and explainability are properties of a model — can its behaviour be understood and accounted for? Model Cards, Clarify, open weights and licensing.
• Here, Objective 5.2.3: transparency standards are a governance protocol — what the organisation commits to disclosing about its AI systems, to whom, and in what form.

An organisation can run a fully explainable model and have no transparency standard, because it never decided what it would tell anyone. The reverse also happens: a clear disclosure policy about a model nobody can explain.

The Generative AI Security Scoping Matrix

This is the one framework named in the guide by name, which makes it the one you must actually know rather than recognise.

The Generative AI Security Scoping Matrix groups generative AI solutions into five scopes, numbered 1 to 5, representing least ownership to greatest ownership. Scopes 1 and 2 are buying generative AI; scopes 3, 4 and 5 are building it.

What to remember from this diagram: the split between Scope 2 and Scope 3 is the buy/build line, and the number measures ownership, not risk. A Scope 1 use case can carry enormous risk — employees pasting confidential material into a public chat application is Scope 1 — while a carefully run Scope 5 project may carry less. The number tells you how much of the thing is yours to govern.

Scope	Name	What it means
1	Consumer app	Your business consumes a public third-party service. You do not see or own the model or its training data and cannot modify it
2	Enterprise app	You use a third-party enterprise application with GenAI features embedded, and a business relationship exists with the vendor
3	Pre-trained models	You build your own application on an existing third-party foundation model, integrated through an API
4	Fine-tuned models	You refine a third-party foundation model with your own data, producing a new specialised model
5	Self-trained models	You build and train a model from scratch on data you own. You own every aspect of the model

The matrix also names five security disciplines that apply across all scopes, with requirements that change as the scope changes: governance and compliance, legal and privacy, risk management, controls, and resilience.

Scoping is the first governance step, not a later one

The reason the framework exists is that the same question — "who is responsible for the training data?" — has a different answer in each scope, and answering it wrongly is how obligations get missed.

The question	Scope 1	Scope 4
Who selected the training data?	The provider, invisibly to you	You did, for the fine-tuning set
What can you tell an auditor about it?	Only what the provider publishes	Everything, because you assembled it
Where does your obligation start?	At what your staff put into it	At the data, the tuning, and the output

Chapter 11's warning lands here. Fine-tuning is Scope 4, which means the organisation owns the training data question — and training data cannot be removed from weights. The scoping step is what surfaces that obligation before the fine-tuning job runs.

Decision Rules and Exam Signals

Rule 1 — ask what artefact the question needs. Six real services; the discrimination is by evidence produced, never by which sounds most like "compliance."

Rule 2 — Artifact is about AWS, everything else is about you. This single split resolves a large share of 5.2.1 questions on its own.

Rule 3 — Config records state, CloudTrail records actions. If the answer is a value, it is Config. If the answer is a name, it is CloudTrail.

Rule 4 — Audit Manager assembles, it does not observe. The signal is a named framework and the effort of mapping evidence to its controls.

Rule 5 — Inspector finds vulnerabilities; Trusted Advisor finds deviations from advice. Only Trusted Advisor routinely reports things that are not security issues at all.

Rule 6 — residency is where, retention is how long. A duration in the stem means retention.

Rule 7 — logging, monitoring and observation run across the lifecycle, they are not stages in it. Logging without monitoring is the classic real-world failure.

Rule 8 — a policy is not a protocol. Cadence, strategy, training and review are what make a policy operative.

Rule 9 — cadence and strategy are separate. How often and how fail independently.

Rule 10 — transparency standards are disclosure, not explainability. Chapter 15 owns the model property; this objective owns the organisational commitment.

Rule 11 — the Scoping Matrix numbers ownership, not risk. 1 to 5 is least to greatest ownership, with the buy/build line between 2 and 3.

Rule 12 — governance evidence and model quality evidence are different artefacts. A strong evaluation score is not a compliance record.

Distractor Patterns

Pattern	What it looks like	How to defuse it
Artifact offered for your own workload	Using Artifact to evidence that your endpoint was encrypted	Artifact delivers AWS's reports about AWS; it generates nothing about what you built
CloudTrail offered for a configuration question	"Which service shows whether the bucket was public on the 3rd?"	That is a state question — Config. CloudTrail would show who changed it
Config offered for an identity question	"Which service identifies who disabled encryption?"	That is an action question — CloudTrail
Audit Manager as a monitoring service	Described as continuously watching resources for drift	It assembles evidence against a framework; Config evaluates configuration
Trusted Advisor for a vulnerability	Offered for unpatched software or an exploitable workload	Inspector finds vulnerabilities; Trusted Advisor checks practice
Residency answer to a retention stem	A region or jurisdiction control offered for "records kept seven years"	A duration is retention; region is residency
Retention answer to a residency stem	A deletion schedule offered for "data must not leave the country"	Deleting on time does not constrain location
Logging treated as a lifecycle stage	A sequence in which logging happens after storage and before use	Logging runs across every stage; it is not positioned in the sequence
A policy offered as the complete answer	"Publish a policy" for a repeated compliance failure	Ask what makes it operative — training, cadence, review strategy
Explainability offered for transparency standards	Model Cards or Clarify offered for a disclosure obligation	Those are Chapter 15's model properties, not an organisational commitment
Scope number read as risk	"Scope 1 is safest because you own least"	The number measures ownership; Scope 1 carries real risk from what staff put in
Fine-tuning scoped as 3	An organisation tuning an FM on its own data, called pre-trained	Producing a new specialised model from your data is Scope 4

The first three are a matched set and the highest-value marks in this objective. All three are answered by one question: is the evidence a state, an action, or AWS's own certification?

Scenario Walkthrough

A healthcare group has fine-tuned a third-party foundation model on de-identified clinical notes to draft appointment summaries. A regulator has opened a review. It asks for four things: proof that the cloud platform itself holds a recognised security certification; evidence that the model endpoint had encryption enabled throughout the period under review; the identity of whoever disabled endpoint logging for six days in March; and the organisation's evidence mapped to the control set of a named healthcare framework. Separately, the group's own counsel notes that clinical notes must remain within the country and that inference logs are currently written to a bucket in another region. Nobody outside the platform team has been briefed on the model's disclosure policy.

Requirement	Reading	Decision
Platform holds a recognised certification	Evidence about AWS, not about you	AWS Artifact — download the relevant report
Encryption enabled throughout the period	A configuration state over time	AWS Config
Who disabled logging in March	An action and an identity	AWS CloudTrail
Evidence mapped to a named framework's controls	Assembly against a control set	AWS Audit Manager
Notes must stay in-country; logs are elsewhere	Residency, and it is being breached by a copy	Inference logs are customer data; fix the log destination
Nobody briefed on the disclosure policy	Team training, not a policy gap	The policy exists; the protocol around it does not

Six requirements, and four different services, none of them interchangeable. The scenario is built so that "a compliance service" is not an answer — each row names the artefact it needs.

Two rows are the real test. The residency row is a breach nobody entered deliberately: the logs were configured once, and nobody classified a log as clinical data. The training row is the failure that looks like non-compliance and is not — the policy was written and never reached the people it governed.

And one thing worth naming: the group fine-tuned the model, which is Scope 4. That is why the training-data questions are theirs to answer rather than the provider's.

Key Concepts

Term	Definition
AWS Config	Records resource configuration and its change history, and can evaluate configuration against rules continuously; answers what a resource was set to at a given time
AWS CloudTrail	Records API calls — which identity performed which action, when, and from where; answers who did something
AWS Audit Manager	Continuously collects evidence and maps it to the controls of a named framework, so an audit can be answered with assembled evidence rather than manual collection
AWS Artifact	A portal for downloading AWS's own third-party audit reports and certifications, such as SOC and ISO; evidence about the provider, not about your workload
Amazon Inspector	Scans workloads for vulnerabilities such as known CVEs and unintended network exposure, returning findings with severities
AWS Trusted Advisor	Checks an account against AWS recommended practice across cost, performance, security, fault tolerance and service limits; the broadest and least security-specific of the six
Data lifecycle	The stages data passes through from ingestion and classification, through storage and use, to retention and disposal
Data residency	The requirement that data remain within a stated geography or jurisdiction; a property of where data is stored, including every copy and log
Data retention	The requirement that data be kept for, or deleted after, a stated period; a property of duration rather than location
Logging	Recording that something happened, so it can be reconstructed later; runs across the whole data lifecycle rather than occupying a stage in it
Monitoring	Watching recorded signals for conditions that require action; the discipline whose absence produces evidence that nobody read
Observation	The ability to see what a system is doing at all, including in ways not anticipated when it was built
Review cadence	How often governance rules and their evidence are examined; distinct from how the review is conducted
Review strategy	How a review is carried out — what is sampled, by whom, and against what standard
Transparency standards	An organisation's commitment about what it discloses regarding its AI systems, to whom and in what form; a governance protocol, not a model property
Team training requirements	Ensuring the people who must apply a policy know it exists and how to apply it; the element whose absence makes a real policy look like defiance
Generative AI Security Scoping Matrix	An AWS framework grouping GenAI solutions into five scopes representing least to greatest ownership — consumer app, enterprise app, pre-trained models, fine-tuned models, self-trained models — with scopes 1-2 buying and 3-5 building

Revision Flashcards

Say the answer aloud before revealing it.

1. What single question discriminates the six governance services in Objective 5.2.1? → What artefact does this service hand you, and what question does that artefact answer? All six are real services with genuine compliance roles, so elimination cannot work by spotting a fake option. Config produces configuration state, CloudTrail produces an API call record, Inspector produces vulnerability findings, Trusted Advisor produces best-practice deviations, Audit Manager produces evidence mapped to a framework's controls, and Artifact delivers AWS's own audit reports.

2. Why is AWS Artifact the odd one out among the six? → Because it is the only one producing evidence about AWS rather than about your workload. It generates nothing — it is a portal for downloading reports that external auditors produced about AWS itself, such as SOC and ISO certifications. It sits on the provider side of the shared responsibility model, so it can never evidence that your model endpoint was configured correctly.

3. Separate AWS Config from AWS CloudTrail in one sentence each. → Config records what a resource was configured as and when that changed; CloudTrail records which identity called which API, when, and from where. The practical test is the shape of the answer: if the answer is a value such as enabled, disabled or a region name, the question is Config's; if the answer is the name of a user, role or service, it is CloudTrail's.

4. What does AWS Audit Manager actually do, and what is its exam signal? → It continuously collects evidence from other services and maps it to the controls of a named framework, so an audit against that framework can be answered with assembled evidence rather than a manual scramble. It does not observe resources itself. The signal is a named framework or standard, plus a complaint about the effort of mapping evidence to specific controls.

5. Distinguish Amazon Inspector from AWS Trusted Advisor. → Inspector finds vulnerabilities — known CVEs, unintended network exposure — and returns security findings with severities. Trusted Advisor checks the account against AWS recommended practice across cost, performance, security, fault tolerance and service limits, and is the only service on this list that routinely reports things which are not security issues at all.

6. Which of the six things in Objective 5.2.2 are not lifecycle stages? → Logging, monitoring and observation. They run continuously across every stage rather than occupying a position in the sequence. A learner who memorises the six as an ordered list will look for the logging step in a scenario and fail to find it, because it is not there — it touches ingestion, storage, use and disposal alike.

7. Residency versus retention — what does each ask? → Residency asks where data lives and which jurisdiction's law applies to it. Retention asks how long it is kept and on what basis. They are independent and a scenario can constrain both at once. A duration anywhere in the stem is a retention signal; words like jurisdiction, cross-border or must not leave are residency signals.

8. Why is residency harder to satisfy for an AI system than for a database? → Because an AI system makes more copies. Data may be collected in one place, indexed in another, sent to a model endpoint in a third and logged in a fourth, and every one of those copies has a location the requirement applies to. The inference logs are the copy most often missed, because nobody thinks of a log as customer data.

9. What is the difference between logging and monitoring, and which failure is most common? → Logging records that something happened; monitoring watches recorded signals for conditions needing action. Logging without monitoring is the common real failure: the evidence was captured and nobody was watching, producing the audit finding that the organisation held the data and did not act on it.

10. Why is a policy not a governance protocol? → Because a policy is a document and a protocol is what makes it take effect and stay current. The protocol is the surrounding machinery — team training so the rule reaches the people applying it, a review cadence so it is examined regularly, a review strategy so the examination is a method rather than a meeting, and a revision path so findings change the rule.

11. Review cadence and review strategy are listed separately. What does each mean and how does each fail? → Cadence is how often review happens; strategy is how it is conducted — what is sampled, by whom, against what. They fail independently. A review that occurs reliably and examines whatever someone raises has a cadence and no strategy. A rigorous review that only happens after an incident has a strategy and no cadence.

12. How do transparency standards differ from explainability? → Explainability is a property of a model, examined under Objective 4.2 in Chapter 15 with Model Cards, Clarify and licensing. Transparency standards are an organisational commitment about what is disclosed regarding AI systems, to whom, and in what form. An organisation can run a fully explainable model with no transparency standard, because it never decided what it would tell anyone.

13. Name the five scopes of the Generative AI Security Scoping Matrix in order. → Scope 1 consumer app, Scope 2 enterprise app, Scope 3 pre-trained models, Scope 4 fine-tuned models, Scope 5 self-trained models. Scopes 1 and 2 are buying generative AI; scopes 3, 4 and 5 are building it. The numbering runs from least ownership to greatest ownership.

14. What does the Scoping Matrix scope number measure, and what does it not measure? → It measures ownership — how much of the solution is yours to govern. It does not measure risk or sophistication. A Scope 1 use case can carry enormous risk, since employees pasting confidential material into a public chat application is Scope 1, while a carefully run Scope 5 project may carry less.

15. An organisation fine-tunes a third-party foundation model on its own data. Which scope, and what follows from it? → Scope 4, fine-tuned models. It follows that the training-data questions are the organisation's to answer rather than the provider's — data selection, consent, licensing and representativeness all become theirs. Chapter 11's warning applies directly: training data cannot be removed from weights, so scoping must surface that obligation before the tuning job runs.

The Five-Beat Answer

The core question this chapter prepares you for: "How would you govern an AI system?"

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

1. Scope it first — say which of the five scopes the use case falls into, and therefore how much of it you own. Governance obligations follow from ownership, and scoping before anything else is what stops obligations being missed rather than discovered.
2. State the rules as policy — name what is written down, who owns it, and what it covers. A governance answer that starts with tooling has skipped the part that decides what the tooling is for.
3. Place the data on its lifecycle — where it is stored and under whose jurisdiction, how long it is kept, and what happens at disposal. Say residency and retention separately; they are different obligations.
4. Name the evidence and where it comes from — configuration state from Config, actions from CloudTrail, vulnerabilities from Inspector, framework mapping from Audit Manager, the provider's certifications from Artifact. Evidence you cannot produce is a control you cannot claim.
5. Say how it stays true — review cadence, review strategy, team training, and the path by which findings revise the policy. This is the beat that separates governance from a one-off compliance exercise, and it is the one most answers omit.

A strong answer scopes before it selects and treats evidence as the deliverable. A weak answer names a service in the first sentence.

Why This Helps You

On the job: the expensive governance failures are rarely a missing control. They are a control that existed and could not be evidenced, a log that was written and never read, or a policy that was correct and never reached the team applying it. All three are invisible until someone asks — which is exactly when they become expensive.

In interviews: "how do you know that control was in place last quarter?" is a question that separates people who have been through an audit from people who have not. The strong answer reaches for a specific artefact and names where it comes from. Being able to separate Config from CloudTrail in one sentence is a reliable marker.

On the exam: Domain 5 is 14% of scored content, split with Task 5.1. This task statement's questions are unusually service-heavy, and all six services in 5.2.1 are genuine — so the elimination habit of finding the invented option does not work here. The candidates who do well are the ones who convert each option into the artefact it produces before comparing them.

Chapter Checklist

• I can name all six governance services and the artefact each one produces
• I can say why AWS Artifact is the odd one out, and what it can never evidence
• I can separate AWS Config from AWS CloudTrail with the state-versus-action test
• I can say what Audit Manager assembles and what its exam signal is
• I can distinguish Amazon Inspector from AWS Trusted Advisor
• I can name the six items in Objective 5.2.2 and say which three are not stages
• I can separate residency from retention and name the signal words for each
• I can explain why residency is harder for AI systems than for a single datastore
• I can distinguish logging, monitoring and observation, and name the common failure
• I can say why a policy is not a governance protocol
• I can separate review cadence from review strategy and describe how each fails
• I can distinguish transparency standards from explainability
• I can name all five scopes of the Generative AI Security Scoping Matrix in order
• I can say what the scope number measures, and what it does not

After the Chapter

1. Complete student/project.md — parts 58-60 of the AI/ML Decision Sheet you began in Chapter 01. Bring the same sheet; do not start a new one. These are the last parts you will add.
2. Take student/quiz.md closed-book, then review the reasoning for every question you guessed, including the ones you got right. Pay particular attention to questions 2 and 3 — they are deliberate mirror images, and missing both means the state-versus-action split has not landed.
3. Open the official v1.1 exam guide's Domain 5 page and confirm you can attach a concept from this chapter to each of the three bullets under Task Statement 5.2. Note that the guide names the Generative AI Security Scoping Matrix explicitly — it is the one framework you are expected to know rather than merely recognise.
4. Then go back through the whole Decision Sheet, parts 1-60, before Chapter 18. This is the last teaching chapter, and the practice exam samples all five domains at their published weights. Re-reading the sheet end to end is a better use of your time than re-reading any single chapter.
5. Next: Chapter 18 — Full Practice Exam and Exam-Day Strategy. A full-length practice exam sampled at the official domain weights, with elimination walkthroughs for every question, timing strategy for all four question types, what compensatory scoring means for triage, and a final readiness checklist.