The Spanish DPA's guidance on agentic AI: 76 pages that read like a specification for governing automations

In February 2026 the Agency published the first regulator-grade treatment of AI agents from a data-protection angle. We read it end to end. Here is what it asks for, why it matters beyond AI, and where Kimetai does — and does not — answer it.

Seven insights, and where Kimetai fits

If you only read one section, read this one. Each card states what the guidance asks for, in its own terms, and then what that means for a company running agents and automations — with Kimetai's contribution and its limit stated plainly. The rest of the article is the long version.

• 01 · Governance first

  The Agency identifies the root threat: deploying agents without the company managing them as one more system within its governance. When that happens — the text says — “there is no control of who, when, where, for what purpose and which personal data is being processed”.

  Kimetai — that sentence is the inventory: discovery of every agent and workflow, an accountable owner per automation, and a record of what each one touches. Limit: discovery covers connected platforms, not every local secret on a laptop.

• 02 · The Rule of 2

  An agent has three risk properties — receiving untrusted input, accessing sensitive data, and acting automatically — and must never hold all three at once. At most two, and each possible pair carries a mandatory compensating control.

  Kimetai — this is a policy: classify each automation on the three axes, and route anything that touches all three to REVIEW or BLOCK before execution. Limit: the policy decides; the blocking happens only where the integration applies it at the point of execution.

• 03 · Identity and least privilege

  Cryptographic identity verification for agents, granular RBAC/ABAC, short-lived credentials, no privilege delegation between agents outside predefined flows, mutual authentication in agent-to-agent interactions.

  Kimetai — a W3C DID and a signed Verifiable Credential per automation, scoped to actions, naming a backing human, revocable globally. Limit: revoking the Kimetai identity does not revoke the SaaS token unless the connector does it.

• 04 · Control points before sensitive actions

  Define criteria and control points “especially before sensitive actions are executed”: high-impact, irreversible, or legally consequential operations require human approval. The four-eyes principle for the gravest.

  Kimetai — this is the entire purpose of the Kimetai gateway: a signed ALLOW / REVIEW / BLOCK verdict before the action, with a human approval step bound to the exact operation. Limit: an approval must be tied to the parameters; if the destination changes, re-evaluate.

• 05 · Service catalogue and whitelists

  Keep a catalogue of every service an agent may call — models, tools, internal repositories, external APIs — and limit each processing activity to the maximum set of tools it needs.

  Kimetai — the orchestration profile of each automation lists what triggers it and which applications it acts on; policies express the allowed set per automation. Limit: enforcing the whitelist requires the runtime to honour it.

• 06 · Traceability with integrity

  Data lineage across the whole lifecycle, and an integrity-controlled record of responsibilities, decisions and actions — with strict retention, selective no-log policies and pseudonymised users.

  Kimetai — a hash-chained, eIDAS-sealed audit trail that holds identity, policy version, parameters, approver and result — and treats itself as processing: minimised payloads, retention you configure. Limit: integrity proves the record was not altered, not that it was complete.

• 07 · Do not hide behind the supervisor

  Human oversight cannot be used to shift responsibility for systemic design failures onto the person watching. Supervisors have a role “within limits” — the controller's diligence in design is not delegable.

  Kimetai — REVIEW exists for the few actions that deserve a human, not for every diff at machine speed; the routine ones are decided by policy, so the person in the loop can actually look. Limit: which actions go to REVIEW is a design decision the controller owns.

What the document is, and is not

“Inteligencia artificial agéntica desde la perspectiva de protección de datos” (v1.2, February 2026) is 76 pages long, and its executive summary sets the tone: an AI agent is a system that uses language models to fulfil a goal, and the document's purpose is not to assess any one processing activity but to explain the peculiarities that enter a processing activity when it is implemented, wholly or partly, with agents. It is explicitly for controllers and processors deciding whether and how to use them.

It arrived three months before the Agency's 2025 Annual Report, which showed breach-related proceedings jumping from 30 to 77. We analysed that report separately: The Spanish DPA more than doubled its breach proceedings. Read together, one document says what supervision found; this one says what the Agency expects you to build.

Two framing choices matter. First, the Agency refuses both reflexes: “irrational rejection” and “uncritical acceptance” of agents are both called harmful, and it insists that agents can themselves be privacy-enhancing technology when designed well. Second, it is not a compliance checklist and not a certification — it is an orientation. The measures in chapter VII are things a controller “could adopt”, selected according to the risk of each processing activity. Nothing in it makes a specific tool mandatory. What it does is name, with unusual precision, the properties a governed agent must have.

The structure follows a risk-management arc: what agents are (chapter II), how they enter processing activities (III), the vulnerabilities they add (IV), the GDPR obligations they touch (V), the threats that exploit the vulnerabilities (VI), and the measures that address them (VII). We follow the same arc below.

Four vulnerabilities specific to agents

Chapter IV is where the document earns its length. Rather than repeating what is already known about generative AI, it isolates what changes when a model is given the ability to act. Four families:

• A · Interaction with the environment

  The agent reads organisational and user data, and perceives and acts outside the organisation. Every connection is both a data route and an actor with reach.

• B · Service integration

  Agents are easy to deploy and chain to external services. The Agency flags the ease itself as a vulnerability: services multiply faster than they are managed.

• C · Memory

  Working memory and long-term memory accumulate personal data across tasks and users. Uncompartmented memory means one processing activity leaks into another — and data-subject rights become hard to honour.

• D · Autonomy

  Task planning, agent-to-agent interaction, non-repeatable behaviour, and the capacity to act on behalf of the user or the organisation. The output cannot be reviewed the way a report can — it has already happened.

Notice what the four have in common. None is about the quality of the model. All four are about the agent's authority in the environment: what it can read, what it can call, what it remembers, and what it can do without asking. That is the axis Kimetai was built on — and it is also why, as we argue at the end, three of the four apply just as much to a deterministic workflow with no model in it.

The Rule of 2

The most operational idea in the document is borrowed — the Agency credits Chromium's 2021 “rule of 2” for browser security and its later reformulation for agents — and it is presented as a “minimum threshold of guarantees that must never be crossed”. An agent has three dangerous properties. It may have at most two.

The Agency's own example is an agent that auto-replies to email: it receives untrusted messages (1), can reach sensitive data in the user's systems (2), and can send replies or rewrite records (3). That is the forbidden triangle. The support-triage automation in our Home page is the same shape — which is why the risk surface there lands where it does.

The document is careful to add that this is a security floor, not a data-protection ceiling: even a compliant pair still needs minimisation, accuracy of inputs, and the extra limits that apply to special categories and to minors. But as a first sort of an inventory it is remarkably useful — and it is a classification a governance platform can compute for every automation it discovers.

Compliance: roles, the record, Article 22

Chapter V walks the GDPR. Three points are worth lifting out.

Roles multiply. An agent stack involves the model developer, the agentic platform provider, external tool providers, and the organisation deploying it. The guidance asks the controller to determine who is controller, processor or joint controller for each — and, in the governance measures, to “formalise relations with the third parties that allow agents to be deployed”, clarifying obligations, service levels and the “functionalities to maintain control”. A processor you cannot see in your inventory is a processor you have not formalised.

The record of processing activities must follow the agent. Article 30 does not have an exception for software that reconfigures itself. If an agent begins reading a new repository or writing to a new destination, the RoPA is out of date the moment it does. The guidance treats keeping the record current as a live obligation, which in practice means the inventory that feeds it has to be live too.

Automation is not always an automated decision — but you must know which is which. The guidance is precise here: an agent that summarises industry news for employees by declared interest is not an Article 22 decision. One that affects a person's circumstances, has a lasting impact, or can exclude or discriminate, is — and then Art. 22.2–22.4 conditions, the transparency duties of Arts. 13 and 14, and the extra limits on special categories and minors all apply. You cannot make that call for an automation you have not classified.

The threats the Agency names

Chapter VI splits threats into those arising from the authorised processing itself and those from unauthorised processing (prompt injection, external service failure, illicit access to agent memory). The first group is the more interesting one, because it is entirely about the organisation's own choices. In the Agency's order:

• →Lack of governance and policies — the base threat, quoted in insight 01.
• →Immature development — complex flows built with unqualified people or immature methods breach privacy by design.
• →No data-access policy for organisational and user data, especially unstructured repositories.
• →No control of the reasoning process or of access to external information; shadow-leak exfiltration.
• →Shifting all responsibility onto the user or the human supervisor — insight 07.
• →Uncompartmented memory, unfiltered unstructured data and metadata, excessive retention.
• →Automation bias, profiling of the agent's own users, availability and resilience, access by unqualified users, supply-chain compromise.

Read that list against what a European mid-market company actually has running and it stops being abstract. The marketing team's scheduled agent against the CRM has no data-access policy because nobody wrote one. The finance workflow that replicates invoices was built by someone who has left — immature development, no supervision, no owner. The support bot's memory holds every customer conversation since launch — excessive retention, uncompartmented. Every item on the Agency's list has a counterpart in a real inventory.

The measures, read as a spec

Chapter VII runs from page 54 to 73 and is organised in nine blocks: governance and management processes; continuous evidence-based evaluation; data minimisation; memory control; automation; control of the agent by design; consent; transparency; literacy. Three of them read almost like product requirements.

Governance (VII.A) opens with a line worth framing — “accept the possibility of failure” — and then lists what the organisation's governance must absorb: assign roles for agents; anticipate side effects; define use cases and user profiles per processing activity; set selection criteria for agents, components and external connections; control the redesign of processing activities when agents enter them; formalise third parties; control deployment, monitoring, maintenance and retirement; integrate with incident management and breach obligations; and maintain “continuous monitoring, supervision and audit” with clear response procedures.

Automation (VII.E) is the block a CTO should read twice: decide the degree of autonomy per processing activity; design reasoning chains safely; keep a service catalogue and whitelist; limit accessible services per processing activity; control tool execution — parameters in, responses out, human action for high-impact tools; define control points before sensitive actions; ensure reversibility; provide escalation routes; apply the four-eyes principle for the gravest cases.

Control by design (VII.F) is the block a CISO should read twice: integrity-controlled documentation of responsibilities, decisions and actions; qualified professionals; traceability as full data lineage; verification and validation tests; standard operating procedures for prompts; repeatability mechanisms; identity, authentication and privilege management under least privilege; strict control of updates; sandboxing; error-detection protocols and contingency plans; control of data-extraction flows; circuit breakers and hard step limits; calibration and alignment checks between reasoning steps.

Measure by measure against Kimetai

We would rather be specific than reassuring. The table maps the measures that fall within a governance platform's remit to what Kimetai does, and states the condition under which each one is actually effective. Measures that belong elsewhere — memory hygiene inside the model runtime, prompt SOPs, sandboxing of development, consent management, literacy — are out of scope for us and are not listed.

The right-hand column is the honest part. The guidance itself makes the same distinction when it says a PDP “decides” and a PEP “enforces”: a governance platform contributes control exactly where its decision is applied at the point of execution, and contributes visibility everywhere else. Both are valuable. They are not the same thing, and we will not describe them as if they were.

Why this applies to your workflows too

The document is about agents. But go back to its four vulnerabilities and ask which of them require a language model. Interaction with the environment does not: a webhook reads and writes across systems. Service integration does not: an n8n scenario chains five SaaS APIs. Autonomy — acting on behalf of the organisation without a human clicking — does not either. Only memory is specific to models, and even that has a deterministic cousin in the staging tables nobody purges.

The same holds for the measures. Identity and least privilege, service whitelists, control points before sensitive actions, circuit breakers, traceability, integration with incident response — none of these care whether the thing being governed decides with a model or with an if-statement. What the agent adds is variability in how it reaches its goal, which raises the bar. It does not change the subject.

The Agency wrote a specification for governing agents. Read with the model removed, it is a specification for governing automation — and most of yours have no model in them.

That is why we built Kimetai for both species from the first connection, and why the inventory — not the policy engine, not the audit trail — is where every conversation with a customer starts. The guidance's own base threat says it in one line: without governance, there is no control of who, when, where, for what purpose and which personal data is being processed. You cannot govern what you have not discovered.