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 together they require that AI platforms do more than provide an audit trail — they must actively support data subject rights and demonstrate that each AI component has been assessed and classified by risk level. This post covers both obligations and the operational controls that make compliance tractable.
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.
What GDPR Article 17 Actually Requires of an AI Platform
The right to erasure — often called the right to be forgotten — requires that organizations erase a data subject's personal data on request, without undue delay, when one of the Article 17 grounds applies. For most SaaS applications, this means deleting database records. For AI platforms, the problem is more complex.
Personal data flows into AI pipelines in several ways: as inputs to agents, as context stored for retrieval, as content embedded in conversation histories, and as audit events tied to the subject's identity. A naive DELETE on one table leaves data scattered across logs, embedded representations, and event streams. A compliant erasure must be comprehensive and demonstrable.
The most defensible technical approach combines two mechanisms: cryptographic erasure of any data that was encrypted under a per-subject key, and direct deletion of plaintext records. When you encrypt sensitive fields under a data subject's unique key, rendering that key inaccessible makes the encrypted ciphertext unreadable — the data is effectively erased without touching every table that might contain a derived copy. You then separately delete or anonymize the plaintext records you can locate.
Praesidia implements this two-pronged approach. Each data subject's sensitive content is protected under a per-subject encryption key. 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.
EU AI Act: 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.
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.