GDPR Compliance for AI Memory Systems

AI memory systems pose unique challenges for GDPR compliance. When an AI remembers everything about a user, who controls that data? How do you handle deletion requests when memories might be embedded in vectors or connected in a graph?

We built takizen's legal infrastructure to answer these questions. Here's what we implemented.

Audit Logging

Article 30 of GDPR requires records of processing activities. Our audit_log table is append-only by design — SQL rules block UPDATE and DELETE operations.

Every significant action is logged:

• Memory creation, update, and archival
• API key generation and revocation
• Namespace configuration changes
• Access patterns for compliance review

The log includes who performed the action, when, from where (IP), and what changed. It's immutable evidence of processing activities.

Consent Management

Article 7 requires demonstrable consent. Our tos_acceptances table version-tracks every Terms of Service acceptance.

When a user signs up:

1. They explicitly accept the current ToS version
2. We record the acceptance with timestamp, IP, and user agent
3. Future ToS updates require fresh acceptance

This creates a complete audit trail of consent — critical if questions arise about lawful basis for processing.

Data Subject Requests

Articles 15-17 give data subjects rights to access, rectify, and erase their data. Our gdpr_requests table manages these requests with deadline tracking.

The flow:

1. User submits request via dashboard or email
2. System creates request record with 30-day deadline
3. Request is queued for processing
4. Upon completion, we record what was done and by whom

For erasure requests, we:

• Archive affected memories to KV (for audit trail)
• Delete vectors and links from PostgreSQL
• Log the operation in audit_log
• Mark the request as complete

Technical Safeguards

Beyond the tables, we implemented several protections:

• RLS policies: Deny_all for anon and authenticated roles — only service_role from our Worker can access data
• Namespace isolation: Every query is filtered by namespace_id, preventing cross-tenant access
• Key hashing: API keys are SHA-256 hashed; only key_prefix (first 10 chars) is stored in plaintext for identification
• No PII in logs: Audit logs reference IDs, not content

The Hard Problems

Some GDPR questions in AI memory don't have clear answers yet:

Vector embeddings: If we delete a memory's text but its vector influenced model training or neighbor relationships, has erasure really occurred? We're conservative: full deletion plus decay of any derived signals.

Graph connections: Links between memories might reveal information even if content is deleted. Our approach: delete links alongside memories, but preserve anonymized structural metadata for research.

CoT Feedback: Effectiveness scores are derived from user interactions. Are they personal data? We treat them as such: subject to erasure, but aggregated statistics remain.

Ongoing Work

Compliance isn't a checkbox; it's ongoing. We're working on:

• Automated DSR processing for common request types
• Data Protection Impact Assessments for new features
• Transparency reports on request volumes and response times

If you have questions about takizen's compliance posture, contact us at privacy@takizen.xyz.