GDPR Architecture & Specs

Manual deletion scripts are the leading cause of GDPR violations in SaaS products — someone always forgets a table, a backup, or a webhook log. Aeion OS automates the "Right to be Forgotten" via a deterministic, schema-aware erasure cascade that resolves the subject across every registered collection, categorizes each hit, and applies the legally-correct action per category. - Reverse-Link Identification: The cascade does not depend on an engineer remembering which of 45+ modules a person ever touched. A resolver walks a reverse-link index built into the schema engine to find every record referencing the subject, then sorts each into one of three buckets: delete candidates (records the subject owns outright), anonymize candidates (records they touched but don't own — orders, message threads, audit rows), and retain candidates (records under a legal hold, e.g. financial transactions under tax-retention law). - In-Place Redaction vs Deletion: Relational databases break when foreign keys are abruptly dropped. When the cascade hits a record tied to an AI session invocation, it does not delete the row. Instead, it performs in-place redaction: excerpted transcript content is cleared, the identifying user reference is overwritten with a redacted marker, and the row is flagged with the redaction reason. This preserves the aggregate metrics (e.g., token cost) for billing audits while utterly destroying the PII link. - Grace Window Before Execution: Between operator approval and irreversible execution, a configurable grace window (7 days by default) keeps the account suspended but the data intact. This gives the controller a window to verify the request is genuine — satisfying Art. 17(3) "compelling legitimate grounds" — and lets a subject rescind a request or a DPO halt a malicious-cancel attack before anything is destroyed. - Media Destruction: If the system detects that the deleted user was the sole participant in a recording session, it initiates a hard-delete cascade, permanently purging the encrypted media file from cloud storage — honoring provider-side Object Lock where retention hasn't yet expired.

The gdpr-strict profile acts as a physical firewall against unauthorized cross-border data transfers. - Region Pinning: The OS reads the tenant's active region allowlist and mathematically prevents a session operating under gdpr-strict from spinning up on servers outside of approved regions (e.g., blocking a US region in favor of an EU one). - Sub-Processor Flow-Down: GDPR Article 28 requires that all downstream processors adhere to the same DPA terms. Each compliance profile declares a fixed allowlist of permitted LLM/TTS/STT providers. When an AI agent is summoned into a session, the kernel checks the agent's configured providers against the session's effective profile allowlist and refuses the summon — logging a compliance audit event — if a provider isn't permitted, preventing undocumented data sharing with unapproved processors. - SCC / DPF Runtime Gating: For workloads that legitimately need a US-resident provider (e.g. a payment processor), the kernel doesn't just trust configuration — it checks the provider's transfer basis at call time. Providers with an executed Standard Contractual Clauses agreement pass; providers certified under the EU-US Data Privacy Framework pass on that basis; anything else is hard-blocked with a compliance alert rather than silently falling back to an uncovered endpoint. - Residency Audit Trail: Every cross-region write records its legal basis (SCC, DPF, or derogation) to the residency audit trail, giving the DPO a reviewable ledger of exactly which transfers happened and under what justification — the evidence an Article 44-49 review actually asks for.