This page is for data protection officers, privacy engineers, and the engineering leads who own AI agents that process personal data of people in the EU or UK. It maps the controls Praesidia provides to the GDPR articles that agent deployments touch most often, and it lists the evidence you can export for each.
GDPR predates agents and applies to them without modification. An agent that reads a CRM record, drafts an email, and calls a ticketing tool is processing personal data at each step, under your purposes and on your legal basis. The articles that bite are the principles in Article 5 (purpose limitation, data minimisation, storage limitation, integrity and confidentiality, accountability), the data-subject rights in Articles 15 to 22 with erasure under Article 17 the hardest to engineer, data protection by design and by default in Article 25, processor obligations in Article 28, records of processing in Article 30, security of processing in Article 32, breach notification in Articles 33 and 34, and data protection impact assessments in Article 35.
Agents make three of these harder than a conventional application does. Erasure is hard because personal data flows through prompts, tool results, and logs that were never designed to be searched per subject. Minimisation is hard because an agent given broad tool access will read more than the task needs. Accountability is hard because the record of what happened is often a log an administrator can edit. The GDPR for AI systems post covers the rights in depth; the combined GDPR and EU AI Act readiness post shows how the two regimes overlap for agents.
Control mapping
| Requirement / criterion | What Praesidia provides | Evidence you can produce |
|---|---|---|
| Art. 5(1)(b) — Purpose limitation | Declared connections and permitted tools per agent, so an agent can only reach the systems its stated purpose requires; intent rules can block a tool that has no role in the current task. | Connection and tool-authorization configuration per agent; out-of-scope block records. |
| Art. 5(1)(c) — Data minimisation | PII detection and redaction in both directions, so personal data the agent does not need is removed before it reaches the model or leaves in a response; per-tool authorization on MCP servers restricts read scope. | Redaction decision records; tool-authorization rules. |
| Art. 5(1)(e) — Storage limitation | Per-organization retention policies across event categories, configured by you. | Your retention configuration and an export of the audit records for the period. |
| Art. 5(1)(f) and Art. 32 — Integrity, confidentiality, and security of processing | Non-human identity per agent with just-in-time ephemeral credentials, rotation, and single-agent revocation; strict tenant isolation; vaulted secrets never read back in plaintext; SSO, MFA, and passkeys for administrators; signed webhooks. | Audit records of credential issuance, rotation, and revocation; role and MFA settings. |
| Art. 5(2) and Art. 24 — Accountability | An append-only, attributable record of every request, response, and policy decision on routed connections, with optional cryptographic tamper-evidence and an offline verifier. | Signed bundle export plus verifier result, reproducible by a regulator or auditor. |
| Art. 17 — Right to erasure | A dual-authorization erasure workflow (initiate, then confirm); erasure requests are executed against the data subject's records and produce a completion record; audit records keep their integrity with the subject's personal data redacted. | Erasure record showing initiation, confirmation, and completion with operator identities. |
| Art. 15 and 20 — Right of access and portability | Customer control; Praesidia contributes forensic search over the audit corpus so activity relating to a subject can be located, and API access so results can be assembled into your response. | Search results for the subject; export used in the response. |
| Art. 22 — Automated individual decision-making | Customer control; Praesidia contributes human approval gates before consequential actions, so a person decides before an agent executes a decision with legal or similarly significant effect. | Approval decisions with approver identity and timestamp; gate configuration. |
| Art. 25 — Data protection by design and by default | Guardrails enforced in-line with fail-closed block verdicts; no implicit trust between entities (every connection is declared); PII redaction available as a default control on new connections. | Default control configuration; denied-request records demonstrating the default holds. |
| Art. 28 — Processor obligations | Customer control; Praesidia contributes operation by an EU-incorporated company under GDPR, a published subprocessor list on the security page, and processor terms available on request via legal@praesidia.ai. | Your executed processor terms; subprocessor list snapshot in your vendor file. |
| Art. 30 — Records of processing activities | Customer control; Praesidia contributes the inventory of agents, connections, and tools as a machine-readable source for the processing activities your agents perform. | Inventory and connection export feeding your Article 30 register. |
| Art. 33 and 34 — Breach notification | Customer control; Praesidia contributes forensic search, hop-by-hop attribution across agent chains, alerting, and a tamper-evident record so the facts of an incident can be established quickly and defended later. | Incident-period export with chain views; alert history. |
| Art. 35 — Data protection impact assessment | Customer control; Praesidia contributes per-agent risk classification and scope records as inputs, and behaviour data (redaction hits, denied requests) as evidence of residual risk. | Classification and scope export; metrics for the assessment period. |
| Chapter V — International transfers | Data-residency controls per connection; per-region bring-your-own-key custody for audit-signing keys; bring-your-own-key model-provider access so the provider relationship, and its transfer terms, stay with you. | Residency configuration; key-custody settings; provider configuration. |
What this mapping is not
This mapping supports your assessment and does not constitute certification or legal advice. GDPR has no product certification that transfers to a customer's processing; Article 42 certifications, where they exist, attach to specific processing operations and are your undertaking. Whether a given agent's processing is lawful, which legal basis applies, whether Article 22 is engaged, and whether an incident is notifiable are determinations for your DPO and counsel.
The controller's obligations stay with the controller. Praesidia redacts personal data you configure it to detect; it cannot know which fields are personal data in your domain. Praesidia erases what passed through the platform; personal data your agents wrote into downstream systems is erased by you. Praesidia records activity on connections routed through it; agent traffic that bypasses the platform is not visible to it, and your Article 30 register should reflect the actual paths.
When cryptographic signing is enabled, the offline verifier proves that exported records were not altered after signing. It does not prove that every action was captured in the first place. Those limits are stated at /security/verify-your-audit-trail, and a supervisory authority will take a stated limit better than a discovered one.
Getting started
- Register the agents that touch personal data at /start, following the getting-started guide, and declare only the connections and tools each one's purpose requires.
- Turn on PII redaction in both directions on those connections and set retention per event category to the periods your legal basis supports. Send one request containing test personal data and confirm the redaction decision appears in the trail.
- Rehearse an erasure request end to end with two authorized operators, then export the period and verify it offline as described at /security/verify-your-audit-trail; from agent action to audit evidence shows the export path.
- Update your Article 30 register and DPIA from the inventory export, and review the data residency post for the provider-side questions the platform cannot answer for you.
Common questions
For the content your agents send through the platform, you decide purposes and means, so you are the controller and Praesidia acts as a processor under Article 28. Praesidia is operated by an EU-incorporated company under GDPR, and its current processors are published on the subprocessor list. Processor terms are available on request via legal@praesidia.ai; this page is not a substitute for them.
Praesidia supports Article 17 erasure through a dual-authorization workflow: one authorized operator initiates, a second confirms. Erasure requests are executed against the data subject's records and produce a completion record; audit records keep their integrity with the subject's personal data redacted, and the erasure itself is written to the tamper-evident audit trail. Data your agents copied into systems outside Praesidia is yours to erase separately.
It can if it accumulates personal data indefinitely. Praesidia supports per-organization retention policies across event categories, so you set the periods your legal basis supports rather than keeping everything forever, and PII redaction in guardrails keeps much personal data out of the record in the first place. Storage limitation under Article 5(1)(e) is your policy decision; the platform gives you the levers.
Data-residency controls apply per connection, and regulated deployments can hold their own audit-signing keys under per-region bring-your-own-key custody. Which model provider processes prompts, and where, is governed by the provider relationship you bring; the residency post linked below covers the questions to ask.
A tamper-evident, independently verifiable record of what each agent did, which guardrails fired, and who took what response action, exportable for the incident period and checkable offline. Whether a breach is notifiable under Article 33, and what goes in the notification, remains a judgment for your DPO and counsel.