Two European regulations now shape how teams build and operate AI systems: the General Data Protection Regulation's Article 17 right to erasure, and the EU AI Act's risk-based obligations for AI systems. Neither is optional, and the most efficient way to handle them is a single combined readiness programme — because the two regulations share controls (audit trails, retention, access review, evidence collection) that you should build once, not twice. This post covers how to run that combined programme. For the complete guide to GDPR erasure mechanics on their own, see GDPR for AI Systems: Data Subject Rights and Erasure.
As of July 2026, the EU AI Act side of the programme has a split timeline following the May 2026 Digital Omnibus: Article 50 transparency obligations and Article 49 registration obligations take effect on 2 August 2026, while the Annex III high-risk obligations were delayed to December 2027. GDPR, of course, has been fully applicable since 2018 — which is exactly why sequencing the combined programme matters.
Praesidia is designed to make both sets of obligations tractable, with dedicated compliance surfaces for erasure workflows, EU AI Act risk classification, and the evidence collection that auditors ask for.
The GDPR Workstream: Erasure as an Operational Capability
The right to erasure requires that organizations erase a data subject's personal data on request, without undue delay, when one of the Article 17 grounds applies. In an AI platform, personal data is scattered across agent inputs, retrieval context, conversation histories, and audit events — so a compliant erasure must be comprehensive and demonstrable, not a single table delete. The full technical treatment of these mechanics, including per-subject encryption keys and derivative data, is in GDPR for AI Systems: Data Subject Rights and Erasure.
From a readiness-programme perspective, what matters is that erasure exists as a rehearsed operational capability with evidence attached. Praesidia implements a two-pronged approach: each data subject's sensitive content is protected under a per-subject encryption key, and the erasure workflow — requiring two authorized parties to initiate and confirm — permanently invalidates that key and removes plaintext personally identifiable information from the associated records. Authentication events tied to the subject are cascaded through the same deletion.
The Two-Person Erasure Control
Requiring two authorized people to complete a destructive, irreversible operation is a standard safeguard borrowed from financial and operational disciplines. It prevents a single compromised account from wiping records unilaterally, and it creates an accountability trail for the erasure itself.
Praesidia's erasure flow runs through the platform administration surface. One operator initiates the request, identifying the data subject. A second operator with appropriate authority confirms and executes. Both actions are logged to the tamper-evident audit trail, so you can demonstrate to a regulator exactly when the erasure was initiated, who confirmed it, and when it completed. The confirmation step is the point of no return — after key destruction, the encrypted data cannot be recovered.
The EU AI Act Workstream: Risk Classification as a First-Class Operation
The EU AI Act establishes four risk tiers for AI systems: unacceptable risk (prohibited), high risk (subject to conformity obligations), limited risk (transparency obligations), and minimal risk (no specific obligations). Which tier an AI agent falls into depends on its use case, the data it processes, and the domain in which it operates. Sequence this workstream against the post-Omnibus dates: registration and transparency obligations land 2 August 2026, high-risk conformity work by December 2027.
The practical challenge for engineering teams is that classification is not a one-time exercise. As you deploy new agents, change their capabilities, or connect them to new data sources, the risk classification may change. A support agent that gains access to health-related data might move from limited to high risk. An orchestration agent that influences consequential decisions may fall into high-risk categories. You need a way to track classifications per agent, record the reasoning behind each assessment, and generate reports that map to the regulation's requirements. For a full engineering-oriented breakdown of the regulation, see the EU AI Act explained for engineering teams.
Praesidia includes a dedicated EU AI Act compliance surface. For each agent registered in the platform, a compliance officer can open an assessment dialog that captures the risk classification and the justification. Classifications are stored per agent and versioned. The summary view shows the current risk distribution across your entire agent fleet. The report surface lets you export this classification data in a format suited to regulatory submissions or internal audit.
The assessment is explicitly scoped per organization and per agent. If you use the API for programmatic assessment — useful when you're classifying large numbers of agents or integrating with a broader compliance workflow — the same cross-organization access controls apply. One organization's classifications are never visible to another. For how to structure the broader agent inventory that feeds this classification exercise, see Building an AI Agent Inventory.
Compliance Frameworks: SOC 2, ISO 27001, NIST AI RMF, ISO 42001
Regulatory exposure for AI platforms rarely stops at GDPR and the EU AI Act. Security audits ask about SOC 2 controls. Enterprise procurement requires ISO 27001 evidence. AI-specific frameworks like NIST AI RMF and ISO 42001 are becoming standard references for responsible AI programs. See ISO/IEC 42001 for AI management systems for a closer look at how that standard maps to platform-level controls.
Praesidia's compliance center surfaces security events, access policies, and evidence collection against these frameworks. The ISO 42001 mapping view shows how your configuration and evidence maps to each control in the standard and highlights gaps where controls have not yet been evaluated or evidenced. You can attach evidence directly to gap items, linking the control requirement to the artifact that closes it.
Reports can be generated per framework. These are not static documents — they draw from live platform state, including your security events, access policy configurations, audit retention settings, and the signed audit log. This means when an auditor asks for a point-in-time compliance report, the data behind it reflects what actually happened in the platform, not a manually assembled spreadsheet.
Retention Policies and the Data Minimization Principle
GDPR's data minimization principle requires keeping personal data only as long as necessary for the purpose for which it was collected. For audit logs and AI interaction histories, this creates tension: you want sufficient history for security investigations and compliance evidence, but not unlimited accumulation of personal data.
Praesidia's audit retention policy lets you configure per-organization retention periods for different event categories. When a retention period expires, the relevant records are purged. Setting a retention period of zero means records are kept indefinitely — which is a choice, not a default — so teams are forced to make a deliberate decision about each category rather than accumulating data passively.
Access Reviews: Keeping Permissions Current
One of the most common compliance gaps in AI platforms is stale access. A user who changed roles three months ago may still have permissions appropriate to their old role. An agent that was provisioned for a pilot may still have active credentials. Access reviews are the mechanism for periodically catching and correcting these situations.
Praesidia generates access reviews on demand or based on inactivity detection. A reviewer sees the current access state and approves or revokes each entry. Approved and revoked decisions are recorded in the audit trail. The inactivity-based review surfaces accounts that haven't been used recently — often the clearest signal that access has gone stale.
Common questions
Does cryptographic erasure satisfy GDPR's right to erasure? Regulatory guidance and technical consensus generally accept that rendering encrypted data permanently inaccessible — by destroying the key under which it was encrypted — constitutes effective erasure of that data. The practical requirement is that you can demonstrate the key has been irreversibly destroyed and that no unencrypted copy of the data persists elsewhere. Praesidia's erasure workflow is designed around both requirements: key shredding and direct deletion of plaintext records. For your specific legal position, you should obtain advice from a data protection professional familiar with your jurisdiction and the nature of the data involved.
How does EU AI Act risk classification relate to conformity assessments? The EU AI Act requires high-risk AI systems to undergo conformity assessments before being placed on the market or put into service. The classification stored in Praesidia is your operational record of having made the risk determination and the reasoning behind it. This feeds into, but does not replace, the broader conformity assessment process, which may involve technical documentation, quality management systems, and in some cases a notified body. Think of per-agent classification in Praesidia as the inventory layer that makes the broader assessment process manageable.
What happens to audit events when a data subject is erased? Authentication events and activity records tied to the data subject are cascaded through the erasure process. Where those records are needed for the integrity of the audit chain itself, they may be anonymized rather than deleted outright — the event that something happened is preserved, but the identifying attributes are removed. The specific behavior is configurable in the erasure workflow to match your data protection policy.
Mapping Obligations to Operational Practice
The gap between regulatory text and day-to-day engineering practice is where most compliance programs struggle. GDPR and the EU AI Act both require documented processes, not just technical controls. The compliance center in Praesidia is designed to close that gap by making the evidence collection, report generation, and access review processes part of normal platform operation rather than a fire drill before an audit.
Read tamper-evident audit logs with cryptographic proofs for the technical design behind immutable compliance records, or see how to audit AI agent activity for a practical guide to building the audit practices that support these compliance workflows.