AWSAWS Certified Generative AI Developer - Professional2026-103.3 Implement AI governance and compliance mechanisms

Automate governance without losing decision evidence

Completed by the knowledge check

Learning objective

Automate governance alerts, token-level redaction, response logging, policy filters, and remediation with auditable evidence.

Core idea

Governance automation needs both a release boundary and an evidence boundary. A policy filter decides what can proceed. A protected record explains what was evaluated, what the application released, and what happened afterward. An alert starts a response, while verified remediation closes it. Combining those responsibilities into one success flag loses the facts you need during review.

Treat token-level redaction in this objective as selective removal or replacement of sensitive text. Bedrock Guardrails documents sensitive-information masking of detected spans; it does not provide a promise that every individual model token is redacted before any consumer receives it. Streaming mode, content type, tool fields, and logging destinations all affect that boundary.

How it works

Enforce policy before releasing content

Use the Guardrails policies appropriate to the approved use case, with the detailed policy choices covered in 3.1.1. For independent enforcement, ApplyGuardrail takes the approved guardrailIdentifier and guardrailVersion, content, and source: INPUT | OUTPUT. The response includes action, assessments, outputs, and actionReason.

Route on the complete assessment and application policy rather than assuming every intervention means refusal. action can be NONE or GUARDRAIL_INTERVENED. An intervention can reflect a configured masking decision as well as a blocking decision. Your application must distinguish the allowed transformed output from a blocked response and release only the approved representation. See 3.1.2 for enforcement paths and their failure handling.

A failed assessment is not a clean assessment. Define the outcome when evaluation cannot complete, such as withholding a sensitive response and escalating. Keep that service failure separate from a policy finding, or an outage can distort your violation rate and trigger the wrong remediation.

Mask sensitive spans at the correct boundary

Sensitive-information filters operate on text and can use built-in personally identifiable information (PII) types or custom regex. In sensitiveInformationPolicyConfig, piiEntitiesConfig and regexesConfig configure action: BLOCK | ANONYMIZE | NONE. Direction-specific inputAction, outputAction, inputEnabled, and outputEnabled let you distinguish input and response handling.

ANONYMIZE replaces detected sensitive information with its PII type, such as {EMAIL}. BLOCK blocks the request or response rather than selectively preserving its remaining text. NONE returns detection information without taking that enforcement action. Selective masking can preserve useful context, but the documented detector is probabilistic and context-dependent; it is not a guarantee of complete anonymization.

Sanitize excluded tool fields separately before using or recording them; see 3.2.6. Masking before streamed delivery requires synchronous processing or application buffering; see 3.1.2. Configure those boundaries as part of the approved release, then test the published response rather than inferring compliance from an intervention flag.

Record responses without creating another exposure

Use PutModelInvocationLoggingConfiguration and loggingConfig.textDataDeliveryEnabled to configure required response evidence, with a CloudWatch Logs log group or an S3 bucket in the same account and Region; see 3.2.8. Protect original invocation inputs and trace matches separately from masked responses; see 3.2.9.

Maintain a separate application decision record that identifies the release, policy version, correlation identifier, assessment outcome, transformation, and published response representation. Sanitize that record before writing it. A model response log alone cannot prove which text your gateway finally returned after additional checks or transformations.

Protect log access and configure data protection before collecting incident evidence; see 3.2.9.

Turn findings into owned alerts

Use LogEventsWithFindings to investigate leakage into logs, separately from custom metrics for released policy violations; see 3.2.9. Keep alert thresholds and observation baselines aligned with 3.3.6.

CloudWatch emits alarm state-change events to EventBridge. The documented event uses source: aws.cloudwatch, detail-type: CloudWatch Alarm State Change, and the new state in detail.state.value. Match the relevant alarm and detail.state.value: ALARM; do not trigger destructive remediation for every state change, including recovery.

Attach an owner and protected evidence reference to the incident. Preserve the event’s id, alarm identity, state timestamp, affected release, and baseline identifier together. These application record fields join the alert to the observation window and decision records; they are not a claim that the alarm event itself contains your release metadata.

Before remediation, resolve the affected route and retrieve only the protected evidence needed for diagnosis. Distinguish an increase in blocked requests, released policy violations, and leakage into logging: they require different responses. Record the classification and its supporting evidence instead of choosing rollback merely because the alarm is in ALARM.

Verify remediation rather than declaring it

Run bounded remediation as a STANDARD Step Functions workflow. Start it with StartExecution, an approved state machine ARN, and an incident identifier in input. A version-qualified ARN pins the workflow version. For STANDARD workflows, the same execution name and input are idempotent while the execution is running; closed executions or different input return ExecutionAlreadyExists. EXPRESS does not have that API idempotency behavior.

Record the executionArn returned by StartExecution against the same incident, then append approval, attempted action, and verification references. Preserve the original alarm and candidate identifiers when retries add attempts; do not overwrite them with the configuration observed after recovery.

Standard execution history is retrievable through the Step Functions API for up to 90 days after completion, then removed; AWS also permits reducing this period to 30 days through a quota request. Export the execution record to your retained evidence store or enable state-machine CloudWatch Logs logging with appropriate retention when the audit period exceeds the available history. Express execution history is not captured by Step Functions and requires CloudWatch Logs logging.

Use incident identity to prevent duplicate actions. Gather evidence, request approval for consequential changes, restore approved configuration, and rerun the affected evaluation. See 2.1.9 for human approval and 1.2.8 for rollback mechanisms rather than assuming every alert should deploy a replacement model.

Preserve the triggering event, workflow execution, operator or approver decision, attempted action, and verification result. A workflow that completed a rollback request has not yet proved that policy-compliant responses resumed. Close the incident only after observing the intended state and retaining that evidence; otherwise record failed or incomplete remediation explicitly. Compare verification with the incident’s approved baseline, not a baseline silently changed by the repair. Record whether the observed condition cleared, whether affected routes resumed acceptable behavior, and whether evidence delivery succeeded. An alarm returning to normal can support recovery, but missing observations cannot prove it.

An incident closes only after verification observes the intended state, not when the remediation workflow completes.

Key distinctions and trade-offs

Masking versus blocking: Masking replaces detected spans. Blocking rejects content. Both can produce intervention, so inspect the configured policy and returned result.

Displayed output versus stored evidence: A masked response can coexist with raw request or trace data. Protect each destination and distinguish generated text from the final published response.

Alert versus cause: An alarm signals a measured condition. Correlated decision evidence supports diagnosis and selects remediation.

Remediation request versus verified recovery: Execution success records workflow progress. Recovery requires checks of the resulting application behavior.

Bound automatic changes to the affected route and an approved configuration. Escalate when the diagnosis is uncertain.

Architecture / decision scenario

A service assistant must mask personal contact details before displaying answers. It uses approved sensitive-information filters with ANONYMIZE, synchronous streamed assessment, and independent validation of tool arguments. The application records the transformed response and policy outcome, while restricting any intentionally retained raw invocation evidence.

LogEventsWithFindings rises after a trace-export change, although displayed responses remain masked. A CloudWatch alarm transitions to ALARM, and an EventBridge rule routes the incident to remediation. The workflow correlates affected records and identifies raw trace matches as the source instead of changing the answer model.

The operator fixes the export sanitizer through the approved release path. Verification checks both the displayed response and sanitized exported records. The incident retains its alarm, workflow execution, approval, release, and verification evidence. If the same event is delivered again, incident identity prevents another unreviewed change or a false second closure.

Common exam traps

Promising masking in asynchronous Guardrails streaming mode.
Treating every GUARDRAIL_INTERVENED result as a blocked answer.
Assuming sensitive-information filters sanitize tool arguments and tool results.
Assuming invocation logs or trace matches contain only masked values.
Treating log masking as retroactive deletion of sensitive data.
Closing an incident when the remediation request succeeds without verifying recovery.

What to remember

Apply policy and masking before the content boundary you must protect.
Treat span masking, streaming delivery, and log protection as separate mechanisms.
Correlate alerts with sanitized decision and release evidence.
Bound remediation, preserve incident identity, and retain approval where required.
Verify the resulting behavior before declaring recovery.