AI Agents — GDPR Art. 7(3) + AI Act Art. 14 talking points

This page is a sales- and legal-team-facing explainer for how Rakomi’s agent identity model satisfies the regulatory requirements your enterprise customers (and their DPOs / compliance officers) will ask about. Use it verbatim in RFPs, security questionnaires, and DPIA appendices.

The headline

Every AI agent that acts on a user’s behalf is a first-class identity in Rakomi — separately registered, separately revocable, separately audited. Users retain GDPR Art. 7(3) consent-withdrawal control over individual agents. Tenants retain bounded blast-radius (≤15-minute token TTL ceiling + admin-revoke-all-tokens-now). Auditors get one cohesive evidence stream: “which agent did what, on whose behalf, when, from where”.

Art. 5(2) — Accountability

Rakomi maintains a tenant-isolated agent activity feed (180-day retention) plus an immutable audit archive, retained for a minimum period determined by the accountability obligation it serves. Critical events (token issuance, revocation, blocked-on-revocation) are dual-written. Every action carries: actor user, agent client_id, JTI, scope, IP+UA SHA-256 prefixes (raw hashes never leave the server), and ISO timestamp.

Each end user has a self-service surface:

GET /v1/users/me/agents lists every agent that has ever acted on their behalf.
DELETE /v1/users/me/agents/{agentClientId} revokes consent for that specific agent. The revocation is recorded with reason='gdpr_art_7_withdrawal' and is idempotent (repeated revocation requests do not create duplicate records or audit entries).

The withdrawal takes effect at the next token-mint event for that (user, agent) pair (token-exchange and CIBA both check the revocation record before issuing). Already-issued tokens remain valid until their TTL expires — bounded by the agent’s agent_token_max_ttl_sec (≤900 seconds, project ceiling). Tenants requiring instant revocation across all users use the admin path (DELETE /v1/auth/dashboard/tenants/{slug}/agents/{agentId}) which inserts a denylist row consulted on every Bearer authentication.

Art. 15 — Right of access

Every user’s data export (DSAR) includes a section “Agent-mediated actions on your account” listing each recorded agent action together with the agent’s name. The CSV columns: agent name, action type, resource, created_at. PII-safe (no IP / UA shown — only their hashes’ 12-char prefixes if needed for fraud investigation context).

Art. 17 — Right to erasure

When a user account is hard-deleted, the actor reference on each recorded agent action is nulled. The agent-attribution timeline at tenant level survives — the data is now unattributable to the deleted user. This is a deliberate design: the tenant-side accountability record (Art. 5(2)) outlives the user account, but the user’s identifying link is severed.

Art. 35 — Data Protection Impact Assessment

The Agents surface is high-risk processing under Art. 35(3)(a) (systematic + extensive evaluation of personal aspects via automation). A DPIA supplement (eight sections; mapped against GDPR Art. 7(3) / 15 / 17 / 20) is maintained for it and is available to enterprise customers under NDA on request.

AI Act mapping (Regulation (EU) 2024/1689)

Art. 12 — Record-keeping

Where a customer’s agent is high-risk, the agent activity feed supplies the record-keeping material: the input scope, the actor user, the action type, the resource accessed and the timestamp — enough to reconstruct, after an incident, what an agent did, on whose behalf, and when.

Retention is the customer’s obligation. Art. 12 fixes no retention period at all. The obligation to keep logs “for a period appropriate to the intended purpose of the high-risk AI system, of at least six months” is stated in Art. 19(1), which is addressed to providers of high-risk AI systems. The matching duty for deployers is in Art. 26(6), in near-identical words. Both limbs are qualified: they reach the logs “to the extent such logs are under their control”. Whether logs a third party holds on a deployer’s behalf fall inside that qualifier is a question for the deployer’s own counsel; this page does not answer it.

The agent activity feed is not configurable, and on its own it does not reach that floor. Rows are swept 180 days after they are written. That period is fixed platform-wide — the same on every plan, in every compliance tier, with no per-tenant setting that raises it — and 180 days is short of six months on every calendar. So this feed alone cannot carry a six-month evidence horizon for anyone, on any plan, and there is nothing here to raise.

The plan-level event-retention limit and the per-tenant audit-log retention setting you may see described elsewhere govern the authentication and audit-log event families. Neither governs this feed.

Events can also be forwarded outward as they happen (agent.alert_triggered plus the corresponding audit events), which is the route for a customer whose evidence horizon is longer than the retention they have configured here. A batch forwarder for agent activity is on the roadmap and is not available today.

Art. 14 — Human oversight

Three primitives implement the human-oversight requirement:

Per-agent rate limits (agent_settings.rate_limits) cap the agent’s throughput; hits emit agent.rate_limited events for SOC review.
Tenant-admin revocation invalidates all of an agent’s tokens within ≤900 seconds. The denylist consult is on every Bearer authentication — no cache layer between revocation and enforcement.
Per-user revocation lets the human-in-the-loop withdraw at the (user, agent) granularity without a global revoke.

Art. 26 — Deployer notification and registration triggers

Rakomi’s agent.created audit + webhook event gives a deployer the trigger for whichever notification duty applies to them. Two distinct ones sit in Art. 26, and they are commonly conflated:

Art. 26(7) is a workplace duty — a deployer who is an employer must inform workers’ representatives and the affected workers before putting a high-risk AI system into service at the workplace.
Art. 26(8) is the registration duty, and it binds only deployers that are public authorities or Union bodies; it operates through Art. 49.

Feeding an internal AI registry from this event is good practice for any deployer, but it is not itself an Art. 26 obligation.

CRA — Cyber Resilience Act (Regulation (EU) 2024/2847)

The agents SDK module (together with the CIBA / token-exchange modules) is under CRA jurisdiction (Class I important products, Annex III — identity-management SDKs distributed under the CRE8EVE brand). Vulnerability records for these packages are retained for 10 years per Art. 14 and are available to auditors on request.

ISO 27001 + SOC 2 mapping

Framework	Control	Rakomi evidence
ISO 27001 A.9.2.5	Review of access rights	Activity timeline (180 days) + per-user revocation surface
ISO 27001 A.9.2.6	Removal / adjustment of access	`DELETE /v1/.../agents/{id}` — admin revoke-all-tokens-now
ISO 27001 A.12.4	Logging and monitoring	Agent activity feed + immutable audit archive (dual-write)
SOC 2 CC6.3	Logical access removal	Same as ISO A.9.2.6
SOC 2 CC7.2	Anomaly detection	`agent.rate_limited` + `agent.alert_triggered` events + per-agent alert configs

What to tell sales prospects

The two paragraphs to lead with on a customer call:

“Every AI agent in your tenant — whether an MCP server, an LLM, a voice client, or a CLI — gets registered as a first-class identity, with its own scoped credentials, its own short-lived token cap (max 15 minutes), and its own activity timeline. You see what each agent did, on whose behalf, when, from where. You can revoke any agent in one click and the revocation propagates to every issued token within seconds.”

“Your end users keep GDPR Art. 7(3) control. Without involving you, they can revoke any agent that has ever acted on their behalf via a standard endpoint or via your in-app account UI. Rakomi gates every future token-mint on the per-user revocation list — the agent is locked out for that user without affecting the agent’s other authorisations.”