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 (Enterprise), 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, hash-chained audit trail of the decisions Praesidia makes, signed under the default configuration (an operator can turn signing off), with an offline verifier. A signed record shows it was not changed afterwards, not that every action was captured; calls that do not pass through Praesidia are not recorded. | Signed bundle export plus verifier result, reproducible by a regulator or auditor. |
| Art. 17 — Right to erasure | An erasure workflow on every plan in which one authorized operator initiates and a different one confirms (an organization with only one person who can confirm has that person confirm later, from a new session); 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 (Advanced tier and Enterprise) 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 that can block content in line, before it reaches the model or leaves in a response; no implicit trust between entities (every connection is declared); PII redaction is not on by default: it is one of the recommended guardrails an organization applies in one step on a paid plan, after which detected PII is redacted organization-wide in input and output. | Default control configuration; guardrail log entries for the rules evaluated, kept separately from the audit trail; audit records for the agent tasks a guardrail blocked and decision records for those a connection policy refused; recording is not guaranteed, so a block can go unrecorded. A request an IP allowlist rejects is not recorded in the audit trail. |
| 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 and alert rules (Advanced tier and Enterprise), a chain view that traces an agent-to-agent chain hop by hop (Enterprise), 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 (Advanced tier and Enterprise) 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 at the organization level: each organization is assigned one residency region, and any deployment whose region differs from the organization's refuses that organization's API requests, while requests that carry no organization, and the model gateway's own calls, are not checked against the region (Praesidia does not filter requests by geographic origin); 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. | The organization's assigned residency region; 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. Calls that do not pass through Praesidia are not recorded, and your Article 30 register should reflect the actual paths.
Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. A signed record shows it was not changed afterwards. It does not show that every action was captured. 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 where your organization has them, 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 on every plan: one authorized operator initiates and a different one confirms, and where an organization has only one person who can confirm, that person confirms later, from a new session. 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.
Praesidia does not filter requests by geographic origin. What it enforces is data residency at the organization level: each organization is assigned one residency region (EU, US or AP) when its account is created, and its requests are served only by the deployment configured for that region. Regulated deployments can also hold their own audit-signing keys under bring-your-own-key custody. Hosting is described on the trust center, and which residency regions are available is discussed during evaluation. 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.