Does AWS Bedrock invocation logging satisfy EU AI Act Article 12?

No. Bedrock invocation logging captures model inputs and outputs to S3 or CloudWatch, but it fails Article 12 compliance for three reasons: records lack subject_id indexing (organized by timestamp, not by affected person), S3 storage is mutable by default (not tamper-evident without explicit Object Lock configuration), and records are not structured for the post-hoc reconstruction Article 12 requires. Article 12 compliance requires per-decision records indexed by the person affected, tamper-evident storage, and structured fields (decision_type, context, reasoning, action) that enable deterministic reconstruction of each AI decision.

Where should I add compliance logging for Bedrock Agents?

Lambda action group handlers are the primary integration point. Bedrock Agents invoke action groups via Lambda, and the Lambda handler has access to all relevant compliance data: agent_id, session_id, action_group name, api_path, and action parameters. Add ghost.capture() in the Lambda handler with subject_id (extracted from action parameters or session attributes), decision_type (the api_path), context (parameters), action (result), and decision_id (session_id). For direct InvokeModel calls (not Agents), wrap the boto3 call with a compliance capture function.

Does Bedrock Guardrails satisfy compliance logging requirements?

Partially. Guardrails captures content blocking events — when a request is blocked, you can capture this as a compliance event with action=GUARDRAIL_BLOCKED. This satisfies EU AI Act Article 14 documentation requirements for safety control documentation. However, Guardrails does not capture the positive decision path — it fires only when blocking. For complete compliance coverage, you need: Guardrail block events AND per-decision records for all requests that proceed through Guardrails. Both types of records should share the same session_id (decision_id) for complete pipeline audit.

How do I use the Bedrock session_id as a compliance correlation key?

Bedrock Agent sessions are inherently correlation units — a session represents one user interaction or pipeline run. Use the session_id as your compliance decision_id: generate it before the first invoke_agent call (or use the Bedrock-generated session ID from the response), include it in the boto3 sessionState.sessionAttributes, and access it in Lambda handlers via event.get('sessionId'). Every ghost.capture() call in every action group Lambda handler and every boto3 wrapper invocation for the same session uses the same session_id as the decision_id — enabling full pipeline reconstruction by querying by session_id.

AWS Bedrock Agents Compliance: How to Add Audit Logging to Amazon Bedrock Pipelines

AWS Bedrock provides invocation logging, CloudTrail, Guardrails, and Agent Trace — none of which satisfy EU AI Act Article 12, HIPAA §164.312(b), or SOC 2 CC7.2 compliance requirements as primary records. The gaps: no subject_id indexing, mutable S3 storage by default, not structured for per-person post-hoc reconstruction, and Agent Trace is a debugging tool not a compliance artifact. The integration approach is to add Ghost SDK compliance capture in Lambda action group handlers (the natural integration point for Bedrock Agents) and in boto3 invoke_agent wrapper code. The session_id serves as the decision_id correlation key across all agent interactions in a session.

Why Bedrock Invocation Logging Doesn't Satisfy Article 12

Bedrock invocation logging captures model inputs and outputs to S3 or CloudWatch. It falls short of EU AI Act Article 12 for three reasons: (1) no subject_id — records are organized by invocation timestamp, not by affected person; reconstructing per-person history requires full log scan; (2) mutable S3 storage by default — S3 invocation logs can be deleted by IAM principals with S3 permissions; immutable S3 Object Lock (compliance mode) satisfies WORM requirements but must be explicitly configured; (3) unstructured for post-hoc reconstruction — raw input/output text does not contain the structured compliance fields (subject_id, decision_type, reasoning, action, confidence) required for Article 12 reconstruction. CloudTrail captures API-level service calls — infrastructure audit, not decision audit. Agent Trace captures reasoning steps for debugging, not for compliance — it is mutable and not per-person organized.

Lambda Action Group Integration Pattern

Bedrock Agents call action groups via Lambda functions — Lambda action group handlers are the primary compliance integration point. The Lambda event contains agent_id, session_id, action_group name, api_path, and parameters. Extract subject_id from the parameters (customer_id, patient_id, applicant_id) or from session attributes set by the calling application. Before executing the action logic, call ghost.capture() with subject_id, decision_type (api_path), context (action parameters), action (result), and decision_id (session_id). The Lambda pattern is the correct integration point: it fires synchronously per action invocation, has access to all inputs and outputs, and requires no changes to Bedrock configuration.

Boto3 invoke_agent Compliance Wrapper

When calling Bedrock Agents from application code via boto3, wrap invoke_agent with a compliance capture function. Generate or receive the session_id before the invocation — it becomes the decision_id for all interactions in this pipeline. After receiving the streaming response, call ghost.capture() with the aggregated final response text. Also capture failed invocations as compliance events — invocation failures are themselves compliance-relevant events. The session_id approach means all action group Lambda captures and the wrapper-level capture share the same decision_id, creating a complete audit trail from application entry through every action invocation to final response.

Bedrock Guardrails Compliance Capture

Bedrock Guardrails can block requests that violate content policies. When a Guardrail intervenes (amazon-bedrock-guardrailAction: GUARDRAIL_INTERVENED), capture the rejection as a compliance event with decision_type set to the original decision type plus _guardrail_blocked, action set to GUARDRAIL_BLOCKED, and confidence set to 1.0 (the Guardrail fired with certainty). This satisfies EU AI Act Article 14 documentation requirements — the system's safety controls are part of the compliance record. Guardrail rejection records share the session_id (decision_id) with the normal decision path, so auditors can see both successful decisions and blocked attempts in the full pipeline audit trail.