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

A developer detailed a serverless architecture on AWS for building GDPR- and EU AI Act-compliant auditable state for AI career agents, using Lambda, DynamoDB, S3 Object Lock, and CloudTrail. The reference implementation achieved a 60% reduction in audit-query latency and a 45% cut in manual compliance effort.

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.