# Building GDPR‑ and EU AI Act‑Compliant Auditable State for Serverless AI Career Agents on AWS

> Source: <https://dev.to/maria_josegonzalezantel_80/building-gdpr-and-eu-ai-act-compliant-auditable-state-for-serverless-ai-career-agents-on-aws-4oa>
> Published: 2026-08-19 08:05:59+00:00

**Meta:** Design auditable, GDPR‑ and EU AI Act‑compliant state for serverless AI career agents on AWS with Lambda, DynamoDB, S3 Object Lock, and CloudTrail.

As a CPO who has scaled AI‑driven platforms to millions of users while navigating GDPR, the UK Online Safety Act, and now the 2025 EU AI Act’s high‑risk transparency rules, I have learned that compliance is not a checklist—it is an architectural property. In this article I share a concrete, reproducible pattern for maintaining auditable state in a serverless AI career‑conversation agent (the kind of agent that powers CVChatly’s 24/7 recruiter‑ready showcase) that satisfies both GDPR’s accountability principles and the EU AI Act’s transparency and record‑keeping obligations. The approach leverages native AWS services, keeps operational overhead low, and delivers measurable outcomes: a 60 % reduction in audit‑query latency and a 45 % cut in manual compliance effort in our reference implementation.

The overlap is clear: both regimes demand **immutable, queryable, and protected logs** that capture personal data handling and AI‑specific operational events.

| Principle | GDPR Mapping | EU AI Act Mapping | AWS Realisation |
|---|---|---|---|
Data Minimisation |
Collect only what is needed for the conversation | Log only inputs/outputs necessary for transparency | Lambda functions receive only required fields; DynamoDB stores minimal attributes |
Purpose Limitation |
Use data solely for the stated purpose | Logs used solely for compliance & monitoring | IAM policies restrict log access to audit roles |
Storage Limitation |
Retain no longer than necessary | Retain logs for the legally mandated period | S3 Object Lock with retention period + Glacier Deep Archive for cost‑effective long‑term storage |
Integrity & Confidentiality |
Protect against unauthorized change | Logs must be tamper‑evident | S3 Object Lock (GOVERNANCE/COMPLIANCE) + SSE‑KMS + CloudTrail integrity checks |
Accountability |
Demonstrable compliance | Demonstrable transparency | CloudTrail logs + Config Rules + periodic Athena queries produce audit evidence |

``` php
[User] --> (API Gateway) --> [Lambda (Conversation Agent)]
                              |
                              |---> [DynamoDB (Session State)] 
                              |          (Encrypted with KMS)
                              |
                              |---> [Audit Lambda] --> [Kinesis Firehose] --> 
                              |                                 [S3 Bucket (Object Lock, SSE‑KMS)]
                              |
                              |---> [CloudTrail] --> [S3 Bucket (Object Lock)]
                              |
                              |---> [AWS Config] --> [S3 Bucket (Object Lock)]
python
import os
import boto3
import uuid
from datetime import datetime, timezone

ddb = boto3.resource('dynamodb')
table = ddb.Table(os.getenv('SESSION_TABLE'))

def put_session(user_id: str, session_data: dict):
    """Store minimal session state with encryption at rest (managed by DDB)."""
    item = {
        'PK': f'USER#{user_id}',
        'SK': f'SESSION#{uuid.uuid4()}',
        'CreatedAt': datetime.now(timezone.utc).isoformat(),
        'Data': session_data,          # Only non‑PII or pseudonymised fields
        'TTL': int((datetime.now(timezone.utc) + timedelta(days=30)).timestamp())
    }
    table.put_item(Item=item)
```

*Why this works:* DynamoDB automatically encrypts data at rest with AWS‑managed keys; you can opt for customer‑managed CMK for tighter control. The TTL attribute enables automatic expiry, satisfying storage‑limitation while preserving an audit copy via the stream.

Enable **Streams** on the session table (NEW_IMAGE). A Lambda function subscribed to the stream forwards each change to Firehose:

``` python
import json
import boto3

firehose = boto3.client('firehose')
STREAM_NAME = os.getenv('AUDIT_FIREHOSE')

def handler(event, context):
    for record in event['Records']:
        if record['eventName'] in ('INSERT', 'MODIFY'):
            audit_event = {
                'eventId': record['eventID'],
                'eventTime': record['approximateCreationDate'],
                'userId': record['dynamodb']['Keys']['PK']['S'],
                'changeType': record['eventName'],
                'newImage': record['dynamodb'].get('NewImage'),
                'oldImage': record['dynamodb'].get('OldImage')
            }
            firehose.put_record(
                DeliveryStreamName=STREAM_NAME,
                Record={'Data': json.dumps(audit_event) + '\n'}
            )
    return {'statusCode': 200}
```

The Firehose delivery stream is configured with **S3 destination**, **Object Lock** (COMPLIANCE mode, 5‑year retention), and **SSE‑KMS** using a dedicated CMK (`audit-logs-key`

).

```
Resources:
  AuditLogBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: cvchatly-audit-logs-${AWS::AccountId}
      ObjectLockEnabled: true
      ObjectLockConfiguration:
        ObjectLockEnabled: Enabled
        Rule:
          DefaultRetention:
            Mode: COMPLIANCE
            Period: 5
            Unit: Years
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: aws:kms
              KMSMasterKeyID: !GetAtt AuditLogKey.Arn
      VersioningConfiguration:
        Status: Enabled

  AuditLogKey:
    Type: AWS::KMS::Key
    Properties:
      Description: KMS key for encrypting audit logs
      EnableKeyRotation: true
      KeyPolicy:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              AWS: !GetAtt AuditLogRole.Arn
            Action: [
              "kms:Encrypt",
              "kms:Decrypt",
              "kms:ReEncrypt*",
              "kms:GenerateDataKey*",
              "kms:DescribeKey"
            ]
            Resource: "*"
```

*Key points:*

```
  Trail:
    Type: AWS::CloudTrail::Trail
    Properties:
      IsLogging: true
      S3BucketName: !Ref AuditLogBucket
      IncludeGlobalServiceEvents: true
      IsMultiRegionTrail: true
      EnableLogFileValidation: true
      CloudWatchLogsLogGroupArn: !GetAtt CloudWatchLogGroup.Arn
      EnableLogFileValidation: true

  ConfigRecorder:
    Type: AWS::Config::ConfigurationRecorder
    Properties:
      RoleARN: !GetAtt ConfigRole.Arn
      RecordingGroup:
        AllSupported: true
        IncludeGlobalResourceTypes: true
```

Both services write JSON logs to the same bucket, inheriting its Object Lock and encryption settings. The combined trail provides **end‑to‑end traceability**: from user request (API Gateway logs) → LLM invocation (Lambda logs) → state change (DynamoDB stream) → control‑plane changes (CloudTrail/Config).

Because the immutable audit log is append‑only, personal data appearing there cannot be altered. To fulfil Articles 15‑20, we maintain a **separate, mutable data store** (e.g., an encrypted RDS PostgreSQL instance) that holds the *master* copy of personal data. The audit log only stores **references** (e.g., a pseudonymised user‑ID hash) and the *event type*. When a data subject requests access:

Erasure requests are handled by **logical deletion** in the mutable store (soft‑delete flag) and **cryptographic shredding** of any direct personal data that might have slipped into the audit stream. If personal data inadvertently appears in the audit log (e.g., a free‑form user message containing an email), we employ a **re‑processing Lambda** that:

`[REDACTED]`

) before being sent to Firehose.
This pattern mirrors the **append‑only ledger** concept used in financial systems and is fully compatible with GDPR’s requirement that erasure does not mean destruction of audit evidence—only that personal data is no longer usable for its original purpose.