Data privacy and data residency for AI

Hannah opened her session with a slide that said only: "The dog is not the data subject." Jonah laughed, then realized she was serious. In the United States, privacy laws protect information about identifiable people, through a patchwork of state laws and sector rules. A pet's weight and vaccine history are not, on their own, personal information about a person. But the record also holds the owner's name, address, phone number, payment details and sometimes notes about the household, and a call recording captures a person's voice and words. "The animal makes the data feel harmless," Hannah said. "The owner makes it personal."

This lesson covers privacy and data residency for AI systems: the privacy principles that apply, how AI projects create new privacy risks, privacy-enhancing techniques, where data is processed, and the data governance strategies the exam guide lists, such as life cycles, retention and residency.

Privacy principles that apply to AI

Privacy laws differ by place, but they share principles that apply directly to AI projects. The United States has no single federal privacy law for most businesses. Several states, including Colorado, have comprehensive consumer privacy laws that apply above certain size thresholds, the Federal Trade Commission treats unfair or deceptive data practices as violations, and sector rules such as PCI DSS govern payment card data. The principles below appear in some form almost everywhere.

Hannah applied them to the call-note summarizer. Purpose: summarizing calls helps veterinarians care for the animal, which is the reason the call was made. Consent and notice: the emergency line's greeting already said calls were recorded; she added a sentence saying recordings may be transcribed and summarized by an automated system. Minimization: the summarizer needs the clinical content, not the caller's card number. Retention: transcripts are deleted after 90 days, once the confirmed summary is in the record.

New privacy risks from AI

AI projects create privacy risks that ordinary systems do not.

• Data gathered into new places. Training and evaluation datasets copy data out of the systems where it was protected. Lesson 7 showed Macie finding card numbers in a transcript bucket.
• Memorization. Models can sometimes reproduce parts of their training data. A model fine-tuned on raw call transcripts might, in rare cases, repeat a phone number from training.
• Leakage through outputs. A generative system with access to records might include personal details in an answer to someone who should not see them.
• Inference. Models can infer things people never disclosed, such as financial difficulty from payment patterns. Inferences can themselves be personal information.
• Third-party processing. Sending data to an external model service raises questions about who can see it, where it goes and whether it is used for training.

Privacy-enhancing techniques

The exam guide asks you to describe privacy-enhancing technologies as part of secure data engineering. Several are practical for a team like Cascade Ridge's.

• Masking and redaction replace sensitive values with placeholders, such as turning a phone number into [PHONE]. Amazon Bedrock Guardrails can mask personal information in prompts and responses, Amazon Comprehend can detect personal information in text, and Amazon Transcribe can redact it from transcripts.
• Pseudonymization replaces identifiers with consistent tokens, so records can still be linked without revealing who they belong to. Pseudonymized data is still personal information if someone holds the key.
• Aggregation uses counts and averages instead of individual records where that is enough.
• Synthetic data is artificial data generated to resemble real data in its patterns, useful for testing and development.
• Differential privacy adds carefully measured noise to results or training so that no individual's presence can be reliably detected. It is more advanced and is mentioned here so you recognize the term.

import re
# Mask phone numbers and card-like numbers in a (fake) transcript line.
line = "Caller: my number is 555-201-0182, and you can bill card 4111 1111 1111 1111 for the visit."
phone = re.compile(r"\b\d{3}-\d{3}-\d{4}\b")
card = re.compile(r"\b(?:\d{4}[ -]?){3}\d{4}\b")
masked = card.sub("[CARD]", phone.sub("[PHONE]", line))
print(masked)

Caller: my number is [PHONE], and you can bill card [CARD] for the visit.

Pattern matching like this is a first step; real systems use detectors that understand context, such as Comprehend's personal information detection or a guardrail's sensitive information filter, plus checks for spoken numbers that transcription writes out in words. Minimization comes before any of this: the best way to protect a field is not to collect it.

Minimization also makes everything else in this lesson easier. A dataset with fewer personal fields is cheaper to protect, simpler to explain in a notice, quicker to search when someone asks about their data, and less damaging if it is ever exposed. When Noor rebuilt the no-show training data, she replaced exact birth dates of owners, which the model did not need, with nothing at all, and replaced client numbers with pseudonymous tokens that only the booking system could map back. The model's accuracy did not change. The privacy assessment got a page shorter.

Data residency

Data residency means keeping data stored and processed in a particular geographic location, usually for legal, contractual or policy reasons. In the autumn, Cascade Ridge chose US West (Oregon), with US East (Ohio) for recovery, keeping client data in the United States by board decision. AI raised new residency questions.

Model availability. Not every foundation model is offered in every AWS Region. If the best model for a task is not available in the home Region, using it would mean sending data elsewhere. Noor checked model availability in the home Region before shortlisting models.

Cross-Region inference. Amazon Bedrock offers cross-Region inference, which can route requests to other Regions to handle demand. Some profiles keep routing within a geography, such as a set of Regions in one country or area; others are global. Whether that is acceptable depends on the residency commitment. Hannah's rule was that any cross-Region profile had to keep processing within the United States, and that the choice was recorded in the model card.

Logs and copies. Residency applies to everything: logs, evaluation datasets, backups and knowledge base content, not only the main database. A model invocation log stored in another Region would break the commitment as surely as the data itself.

Gwen enforced the Region choice with a service control policy that denies AI service calls outside approved Regions, as lesson 7 described. Residency then did not depend on every developer remembering it.

Data governance strategies

The exam guide lists data governance strategies for AI: data life cycles, logging, residency, monitoring, observation and retention. Noor turned them into a short checklist for every AI dataset.

S3 Lifecycle rules delete transcripts automatically after 90 days, so retention does not depend on someone remembering. Lesson 11 covers logging in more detail, including the tension between keeping enough to investigate problems and not keeping more personal information than necessary.

How AWS AI services handle your content

Before sending call recordings to Amazon Transcribe, Hannah checked how AWS handles the content. The answer differs by service, which is exactly why it is worth checking. For Amazon Bedrock, AWS states that prompts and responses are not used to train the foundation models and are not shared with model providers. Some of AWS's other AI services, such as Transcribe, Comprehend, Translate and Rekognition, have historically allowed AWS to store and use customer content to improve the service unless the customer opts out, as described in the AWS service terms and each service's FAQ.

AWS Organizations provides AI services opt-out policies for this. A policy attached at the root of the organization tells the covered AI services not to store or use content for service improvement, for every account at once. Gwen attached one during the account setup, before any recording reached Transcribe, and Hannah recorded the setting in the privacy assessment. The exact list of covered services changes over time, so the current documentation is the source of truth; the habit to remember is to check data use terms for every AI service before sending it personal information.

A privacy impact assessment

For any AI use in the medium or high review tier, Hannah required a short privacy impact assessment: a structured look at what personal information the system uses, why, how it flows, what could go wrong and what controls reduce the risk. Several US state privacy laws, including Colorado's, require data protection assessments for certain higher-risk processing, and the practice is useful even where it is not required.

The summarizer's assessment ran to four pages. It mapped the flow from phone call to confirmed note, listed every copy and where it lived, recorded the notice wording and the retention periods, and named the residual risks with their owners. It took Hannah and Noor an afternoon. "Most of the work was asking questions we should have asked anyway," Noor admitted.

When people ask about their data

Privacy laws give people rights to know what is held about them, and in many places to correct or delete it. AI systems must be designed so these requests can be met. Hannah asked Noor a pointed question: if a client asked to see everything Cascade Ridge held about them, would the evaluation dataset be included? It would. That was another reason to mask the evaluation data and keep it small: a well-minimized dataset is easier to search, explain and delete from.