Security, Compliance, and Governance

The controls in roughly the order they matter:

• Identity and access management: who may invoke what. Almost always too broad at first, and the cheapest thing to tighten.
• Encryption in transit and at rest: table stakes, and still worth confirming for AI workloads specifically because prompts and outputs are frequently overlooked.
• Private connectivity: keeping traffic off the public internet.
• Guardrails: enforced filtering of input and output.
• Sensitive data discovery: finding personal data you did not know you were holding.

The shared responsibility model applies to AI as everywhere else: the provider secures the infrastructure, you secure what you build on it: your data, your access control, your application. The AI-specific twist is that "your data" now includes prompts and generated outputs, which land in logs people did not think of as sensitive.

Secure data engineering: assess data quality, apply privacy-enhancing techniques, control access, and maintain integrity. Note that data quality appears here as a security concern, not just a quality one, poisoned or corrupted training data is an attack.

The AI-specific concerns AWS lists, which are the ones missing from a conventional security review:

• Prompt injection: instructions hidden in content the system processes
• Data leakage: the system revealing context it should not
• Output filtering and validation: checking what comes out before it acts or is displayed
• Toxicity: harmful generated content
• Audit trails for AI interactions: logging prompts and responses, which is both a security requirement and a privacy obligation in tension with it

That last tension is worth carrying: you need enough logging to investigate, and every log of a prompt is a store of whatever the user typed into it.

Data lineage and cataloguing answer "where did this come from?" For an AI system that question has teeth: when an output is challenged, you need to trace it back to the source material and, ideally, the model version and prompt that produced it. Systems built without lineage cannot answer that, which turns a single complaint into an unbounded investigation.

Hallucination detection and grounding is treated here as a security and compliance concern rather than merely a quality one, which is the right framing, a confidently wrong answer that a customer relies on is a liability event.

The techniques:

• Retrieval grounding: answer from supplied source material rather than from training. The primary control.
• Output validation: check the response before it is used. Schema checks, fact checks against source, policy classification.
• Confidence scoring: surface how well-supported an answer is, so low-confidence responses route to a human.

Citation is the practical companion to all three. Requiring the model to point at the passage supporting each claim makes verification fast and makes unsupported claims harder to generate in the first place.

The services that support this work by function: configuration tracking (is the environment still as approved?), vulnerability assessment, audit evidence collection, compliance artifact access, and API activity logging. You do not need to configure them for this exam; you need to know which question each answers.

Data governance strategies cover the full lifecycle:

• Lifecycle: how data enters, moves, and is disposed of
• Residency: which jurisdiction it may live in, frequently a hard constraint on architecture
• Retention: how long, and the deletion obligation that follows
• Logging and monitoring: what is recorded about access and use
• Observation: ongoing visibility rather than point-in-time review

Residency and retention are the two that most often constrain design, and they do so early. "The data cannot leave this region" and "we must be able to delete a customer's data everywhere" both rule out architectures before you build them, so they belong in the first design conversation rather than a pre-launch review.

Governance protocols are the human process: written policies, a defined review cadence, a scoping framework for classifying what kind of AI use case you are dealing with, transparency standards, and team training requirements.

The scoping framework idea is worth taking away even without the specific name: not every AI use case needs the same governance. A team using a public assistant to draft internal emails and a team building a customer-facing system on proprietary data represent very different risk, and applying identical process to both means either strangling the first or under-governing the second.