AWSAWS Certified Generative AI Developer - Professional2026-103.2 Implement data security and privacy controls
Detect personal data at each boundary
Completed by the knowledge check
Learning objective
Detect PII in S3 source data with Macie and in application text, prompts, or outputs with Comprehend and Bedrock Guardrails.
Core idea
For an architect designing a foundation model (FM) application, personally identifiable information (PII) detection is a boundary decision. You need to discover sensitive source objects, inspect application text, and enforce a policy around model requests and responses. Amazon Macie, Amazon Comprehend, and Amazon Bedrock Guardrails address different parts of that path.
A discovery finding does not sanitize an object. A text detector does not prevent a later tool from exposing a value. A masked answer does not prove that the original prompt never entered a log. Choose each detector by the data it actually inspects, then assign an application action to its result. See 3.2.7 for transformation choices and 3.2.9 for log sanitization.
How it works
Discover sensitive source objects
Macie sensitive data discovery jobs analyze objects in S3 general purpose buckets. You select the source scope and the sensitive data types through managed data identifiers, custom data identifiers, or both. Custom identifiers let the discovery job recognize organization-specific patterns. Allow lists exclude known exceptions; review those exceptions because an overly broad exclusion creates a detection gap.
The CreateClassificationJob operation makes the scope concrete. Its s3JobDefinition defines buckets and object selection, jobType distinguishes ONE_TIME from SCHEDULED, and samplingPercentage controls the percentage of eligible objects analyzed. Below 100, Macie selects objects randomly up to that percentage. A sample can inform estate-wide risk assessment, but it cannot establish that every object released for ingestion was inspected.
Jobs produce sensitive data findings and sensitive data discovery results. A finding reports sensitive data in an object. A discovery result records analysis for each object configured for analysis, including objects with no finding and objects that could not be analyzed. Distinguish those outcomes in your ingestion decision. No finding with failed analysis is different from completed analysis with no detected match.
Coverage also depends on storage class and format. Macie does not analyze objects in S3 directory buckets or objects using unsupported classes such as S3 Glacier Deep Archive. A job skips unsupported objects as unclassifiable. Macie also offers automated sensitive data discovery, which selects only eligible objects; unclassifiable objects are excluded from selection and analysis. Maintain a separate route for those objects instead of treating the discovery job’s completion as approval for the entire source estate.
Your application owns quarantine and release. Record the source object identity, analysis outcome, and policy decision before admitting its content into retrieval. If the source changes after inspection, require evidence for the changed content rather than reusing an earlier decision. This is an application integrity rule, not a claim that Macie turns a bucket into a synchronous admission gate.
Inspect application text
Use Comprehend DetectPiiEntities for real-time text analysis. The request carries Text and LanguageCode; the PII documentation specifies English and Spanish. The text limit is 100 KB of UTF-8 input. Do not infer broader PII language support from the general language enum printed in the API reference.
The response’s Entities entries contain Type, Score, BeginOffset, and EndOffset. Score estimates the probability that a detected span has the assigned entity type. The offsets locate characters in the analyzed text. They give your application enough information to replace a span, reject a request, or send an uncertain result for review.
The real-time operation detects entities; your application performs any replacement. For asynchronous document redaction, Comprehend offers StartPiiEntitiesDetectionJob with Mode: ONLY_REDACTION; see 3.2.7 for its transformation contract. Apply real-time detection to the exact text that the next component consumes. Reusing offsets after changing that text risks masking the wrong span.
Treat confidence as a detection signal, not proof of absence. Evaluate representative names, identifier formats, languages, and context lengths. If oversized text must be segmented, preserve enough surrounding context and reconcile offsets against the original document. Those segmentation and acceptance rules belong to your application.
Enforce a prompt and response policy
Bedrock Guardrails sensitive information filters inspect text in input prompts and model responses. They offer built-in PII types and custom regular-expression patterns. The documented modes block content or mask detected values with type placeholders such as {EMAIL}. Use the enforcement paths in 3.1.2 rather than inventing a separate policy for each interface.
The filter is context-dependent and probabilistic. More context can improve detection, and isolated strings can be ambiguous. Custom patterns help with application-specific identifiers, but they are pattern matches rather than general semantic understanding.
The documented boundary is critical for agents: sensitive information filters do not evaluate model-generated tool-call arguments, tool results returned by the application, or supplied tool definitions. In Converse terms, this includes toolUse.input, toolResult, toolSpec.description, and toolSpec.inputSchema. Inspect those application-controlled surfaces separately. Guardrails also leave original values in invocation-log inputs and PII trace matches; see 3.2.9.
Key distinctions and trade-offs
Stored discovery versus runtime enforcement: Macie inventories and reports sensitive S3 content. Comprehend provides text spans for application decisions. Guardrails can enforce a block or masking policy around model text. None substitutes for the other two boundaries.
Analysis coverage versus positive findings: Findings establish that a detector matched content. Missing findings establish little unless you also know the object was eligible, selected, accessible, and successfully analyzed.
Built-in types versus custom patterns: Built-in detection uses documented entity categories. Custom identifiers or regex filters address your formats, but broad patterns increase false positives and narrow patterns miss variants. Test both against the application’s real inputs.
Architecture / decision scenario
A claims assistant ingests S3 documents and accepts typed customer questions. The ingestion service runs Macie discovery over the selected source objects and records discovery results before release. It holds unclassifiable or failed objects for a separate inspection route, and it transforms detected personal data according to the ingestion policy.
At runtime, the application calls DetectPiiEntities on supported-language question text before constructing context. Bedrock Guardrails then enforce the approved sensitive-information policy on prompt and response text. A tool adapter separately validates and sanitizes customer identifiers in tool arguments and results because those fields are outside the filter’s coverage.
The release test submits one identifier in each surface: a source document, a typed question, a generated answer, and a tool parameter. Success requires evidence at each intended boundary, including safe handling of an analysis failure. A clean answer alone cannot satisfy this test.
Common exam traps
- Choosing Macie as a synchronous filter for arbitrary application text.
- Treating sampled discovery as proof that every source object is safe.
- Assuming
DetectPiiEntitiesrewrites its input text. - Generalizing Comprehend PII support to every language listed in its API enum.
- Assuming Guardrails inspect tool arguments, results, or definitions.
- Equating no detected PII with guaranteed absence of personal data.
What to remember
- Use Macie for eligible S3 source-object discovery and review analysis outcomes.
- Use Comprehend entity types, scores, and offsets for application text decisions.
- Use Guardrails for the documented prompt and response text boundary.
- Inspect tools, logs, and failed or unsupported inputs independently.
Knowledge check
Before a claims assistant builds context, its code must replace each personal identifier in a typed English question with a type label, and it needs the position of every detected value to do so. Which service fits?
DetectPiiEntities on the question textStartPiiEntitiesDetectionJob in redaction modeDetectPiiEntities analyzes text in real time and returns each entity’s type, score, and offsets, which the application uses to replace spans itself. Macie discovers sensitive data in S3 objects, not live text; a guardrail blocks or masks inside the model call rather than handing spans to the application; and the redaction job is asynchronous document processing.A Macie discovery job over the assistant’s source bucket runs with samplingPercentage set to 100 and reports no findings. Some of the bucket’s objects use the S3 Glacier Deep Archive storage class. What can the team conclude about those objects?
A sensitive information guardrail masks customer email addresses in prompts and answers. In testing, the model passes a customer’s email address to a ticketing tool, which stores it unmasked. What closes the gap?
A support desk adds Japanese-language questions to the assistant and plans to reuse its DetectPiiEntities step unchanged. What should the team decide?
LanguageCode enum lists more languages. Without support, an empty result says nothing about absence, and splitting text addresses the size limit, not the language contract.