Data Governance Strategies for AI

A customer emails your support team and asks you to delete their data. You know exactly where it is: the customers table in S3. You delete the rows and reply.

Six weeks later a legal review lists where that customer's data actually was on the day of the request. The raw export in the landing zone. The curated table the deletion touched. The knowledge base chunks built from their support tickets, still sitting in the vector store as embeddings. The CloudWatch log group holding every prompt and completion from the assistant, including three conversations where an agent pasted the full account record into a prompt. A CSV a data scientist pulled to a notebook in March. And a fine-tuned model that read all of it during training.

You deleted one of six copies and told the customer it was done.

Nothing here was a security failure. Every bucket was encrypted, every role was scoped, every network path was private. What was missing was the other half: a set of rules saying how long each of those copies may exist, where it is allowed to live, what it may be used for, and who decides. That is data governance, and the exam guide names it directly under six words: data lifecycles, logging, residency, monitoring, observation, retention.

Governance is the rulebook, security is the lock

Keep these two apart, because they fail differently.

Security asks: can an unauthorized party reach this data? It answers with IAM, encryption, network isolation, and threat detection. The previous topic was almost entirely security.

Governance asks: what rules does this data live under, no matter who reaches it? How long may we keep it, which countries may process it, what purposes is it approved for, who signs off on a new use, and how do we prove any of that later.

A perfectly secured dataset can still be a governance failure. Nobody breached the log group in the story above. It was authorized, encrypted, and retained forever because nobody set a number. The lock worked; there was no rulebook.

That distinction is also why governance questions on the exam sound different from security questions. Security stems say "prevent access." Governance stems say "must not be kept longer than," "must remain within," "must be able to demonstrate."

The lifecycle, and where AI multiplies it

Every dataset moves through the same stages: it is created or acquired, stored, used, archived, and finally destroyed. Traditional applications keep that path narrow. One database, one backup, one archive.

AI systems fan it out. A single support ticket takes this path:

1. Lands as raw text in an S3 landing zone.
2. Gets redacted and written to a curated table in a second bucket.
3. Gets chunked and embedded into a vector store for retrieval.
4. Gets included in a fine-tuning corpus, and its content influences model weights.
5. Appears in a prompt at inference time, and the prompt and response land in a log.
6. Gets pulled into an evaluation set for a quality review.

Six locations from one record, with different owners, different storage services, and different natural lifespans. The governance question is not "do we have a retention policy." It is "does the policy name all six."

One of those six is different from the rest, and it is the one people forget. Steps 1 through 3, 5, and 6 hold data you can delete. Step 4 does not: what a model learned during fine-tuning cannot be removed by deleting a file. That is why the pre-ingestion controls from the previous topic are also governance controls. Anything you refuse to train on is a copy you never have to account for.

Retention: the setting that defaults to forever

Retention is where written policy meets an actual configuration value, and the defaults are rarely what your policy says.

Read the CloudWatch Logs row again. By default, log data is stored in CloudWatch Logs indefinitely. For an ordinary application log that is a cost problem. For an AI application with model invocation logging enabled, the log group contains full request and response bodies, which means it is a permanent store of everything users typed into the model and everything the model said back. It inherits the sensitivity of the conversation, not the sensitivity of a normal log.

A worked retention plan for one internal assistant looks like this:

Notice that "delete after N days" and "keep for N years" use the same tool from opposite directions, and that two of the six rows are not a lifecycle rule at all. Governance is not one feature.

One correction worth making explicitly, because it is a common assumption: setting a shorter retention period does not remove data instantly. CloudWatch marks expired events for deletion and typically completes the deletion within 72 hours. If a policy demands provable deletion by a deadline, build the deadline in.

Residency: where the data is allowed to be

Data residency is the requirement that data be stored, and often processed, inside a named geography. It shows up in banking, healthcare, and public sector work, and AWS answers it primarily with Region choice: you pick the Region, your data stays there unless you move it.

Generative AI adds a wrinkle that the exam likes, because it is the one place where an AWS service may process your request in a Region you did not name.

Cross-Region inference in Amazon Bedrock routes an inference request to whichever Region in a set has capacity, which raises throughput and absorbs traffic bursts. There are two kinds of profile, and only one of them respects a residency boundary:

AWS states the recommendation plainly: choose geographic when you have data residency requirements, global when you want maximum throughput and cost savings without geographic restrictions.

Three details keep this honest. Cross-Region inference can route to Regions you have not manually enabled in your account, so "we never turned that Region on" is not a control. All of the traffic stays on the AWS network and is encrypted in transit, so this is a jurisdiction question rather than an exposure question. And every cross-Region request is logged in CloudTrail in your source Region, with an additionalEventData.inferenceRegion field naming where it was actually processed, which is how you audit residency after the fact instead of assuming it.

If your organization needs the boundary enforced rather than chosen, that is a service control policy on aws:RequestedRegion at the AWS Organizations level, sitting above whatever any individual team configures.

Logging: two records of one AI call

For a normal AWS service, "enable logging" means one thing. For a generative AI call it means two, and they capture different halves.

The governance consequence of that last row is the one to carry. Turning on invocation logging is the right call for auditability and incident investigation, and it creates a new store of your most sensitive text. It needs the same treatment as the source data: a KMS key, a tight access policy, a retention setting, and a place in your deletion map. Teams enable it for compliance and then fail a different compliance check with the logs they created.

Monitoring and observation

The exam guide lists monitoring and observation as separate words, and the split is useful even though the boundary is soft.

Monitoring is threshold-based and automated. You define what "wrong" looks like as a number, and something pages when it happens. For an AI workload: invocation error rates and throttling in CloudWatch, guardrail intervention counts, cost per thousand invocations, latency at the 99th percentile, and a Config rule going noncompliant when someone disables model invocation logging.

Observation is the ongoing look at what the system is actually doing, including things you never wrote a threshold for. Data drift and model quality drift through SageMaker Model Monitor, bias metrics recomputed on live traffic through SageMaker Clarify, sampled human review of outputs, and periodic reading of the prompts users actually send. Observation is how you learn that the assistant is being used for something nobody designed it for, which is a governance finding no alarm was configured to catch.

Both matter, and the reason is specific to AI: an AI system does not fail cleanly. A misconfigured web server returns 500s. A drifting model returns fluent, well-formed, plausible answers that are getting worse. Availability monitoring will not notice.

The part that is not a service

Two governance elements have no AWS console, and both come first.

Classification puts every dataset in a tier (public, internal, confidential, restricted, for example) and attaches rules to the tier rather than to individual buckets. Encryption requirements, approved Regions, retention periods, and whether the tier may be used for model training all hang off that single label. Without it, every new dataset restarts the argument.

Ownership names a human accountable for each dataset. The data owner classifies the data, approves access requests, and approves new uses, including "may we fine-tune on this." AWS gives you the tooling to record and enforce those decisions, through tags, the Glue Data Catalog, and Lake Formation permissions. It cannot make them.

Tagging is where the two meet the machinery. A consistent tag such as DataClassification=Restricted on buckets, log groups, and training jobs is what lets a Config rule check compliance by policy tier instead of by resource name, and what lets cost and access reports break down by sensitivity.

Exam tips

• "Data governance" in a stem points at rules over data (retention, residency, purpose, ownership), not at access controls. If the scenario says "prevent unauthorized access," you are back in security.
• CloudWatch Logs retention defaults to never expire. That single fact answers several question shapes about logs growing forever or holding data past a policy deadline.
• CloudTrail Event history is 90 days of management events and is not configurable. Longer retention means a trail to S3 or a CloudTrail Lake event data store.
• S3 Lifecycle rules are the mechanism for both moving data to cheaper storage and deleting it on schedule.
• "Data must remain in the EU" plus Amazon Bedrock means a geographic cross-Region inference profile, not a global one.
• CloudTrail records the call; Bedrock model invocation logging records the content. A question asking what was in a prompt needs the second one, which is off by default.
• Drift, bias recomputation, and sampled human review are observation. Alarms and thresholds are monitoring.

The rule to carry: governance is the set of decisions that must exist before a control has anything to enforce. Retention periods, residency boundaries, classifications, and owners are inputs, and every service in the last lesson of this topic simply checks whether reality matches them. The next lesson covers where those decisions come from in the first place, starting with the framework AWS names for scoping a generative AI use case.