CNIL's Agentic AI Note: Traceability, Memory Ringfencing, and Risk-Based Action Classification for GDPR

On July 20, 2026, France's data protection authority — the CNIL — and the Conseil de l'IA et du Numérique (CIANum, France's AI and Digital Council) published a 16-page joint note titled "IA agentique et protection des données personnelles : équation à inconnues multiples pour les utilisateurs" — roughly, "Agentic AI and personal data protection: an equation with multiple unknowns for users." It is explicitly labeled exploratory (non-binding, no enforcement value on its own), and it says so itself in the closing paragraph. But it's also the most concrete thing a EU data protection authority has published so far on what a GDPR-compliant agent architecture should actually look like — down to naming specific technical patterns like per-agent memory isolation, session-scoped memory, and risk-tiered human confirmation.

Almost everything published on agentic AI compliance to date has been framed around the EU AI Act's risk classification. This note is different: it's squarely about GDPR, written by the authority that enforces it, and it reads less like a policy paper and more like a partial engineering spec. We read the full French text directly (not a secondary summary) and translated its four concrete recommendations into a checklist you can actually build against.

How CNIL defines "agentic AI" — and why the definition matters for what you build

The note opens with an architecture description that will look familiar to anyone who has shipped a tool-calling system: an orchestrator agent that handles natural-language interaction with the user, one or more specialized agents coordinated by the orchestrator (code generation, document processing, payments, etc.), and connections to external services — apps, databases, web search — reached through standardized protocols. The note names two examples explicitly: MCP, developed by Anthropic, and ACP, developed by OpenAI.

More important for compliance purposes is a distinction CNIL draws between two separate data mechanisms that every agentic system implements, whether or not the team building it thought of it in these terms:

• "Context" — the record of a single request: conversation history, instructions received (from the user or from another agent), and the interactions with every other agent and service involved. Context is deleted at the end of the process.
• "Memory storage" — information that persists and is reused across processes, notably data about the user. Memory can be fed or edited directly by the user, or enriched automatically from the system's own interactions. It is persistent and independent of any single process's execution.

Each agent — orchestrator or specialized — has its own context and its own memory. In some architectures, a memory is shared across multiple agents.

This distinction isn't academic. GDPR's storage-limitation principle asks "how long is this data kept, and why." If your system doesn't structurally separate "state that dies at the end of this request" from "state that survives across sessions," you cannot actually answer that question — you don't know, architecturally, which category a given piece of state falls into. That's the first thing worth auditing before anything else in this post.

The GDPR Article 5 principles CNIL says are under strain

The note walks through GDPR Article 5(1)'s core principles one by one and explains, in plain terms, why an agentic architecture makes each one harder to demonstrate — not impossible, but harder. We've mapped each one to a concrete engineering check.

The note also flags Articles 15–22 — the data subject rights (access, rectification, erasure, restriction) — as harder to fulfill "completely and traceably" once data is scattered across several agents' memory spaces. The example CNIL itself gives is worth sitting with: a user deletes a sensitive file from a folder shared with their agentic AI, but has no reliable way to confirm the data has actually been purged from every memory instance the system built from it. If you can't answer "which agent holds a copy of this, and where" for a specific piece of user data, you can't fulfill an erasure request against it with any confidence — you're guessing.

When "the agent decided on its own" isn't a defense: Article 22 and the SCHUFA standard

Because agentic systems can execute a full multi-step task with no assistance step in between, the note flags a real risk of drifting into Article 22 territory — automated individual decisions, including profiling, that produce legal or similarly significant effects on a person. CNIL is direct about the ambiguity this creates: given how many actions and agents are typically chained together to complete one task, "the assessment of the real degree of supervision in the decision-making process remains a delicate question." Critically, the note states that the mere existence of a human review step at the output stage is not automatically enough to escape Article 22 classification.

The note grounds this in the CJEU's SCHUFA ruling (Case C‑634/21, December 7, 2023): human intervention must be real, effective, and capable of influencing the final decision — a purely formal or automatic validation is not sufficient.

For a team shipping an agent flow, that's a concrete design constraint, not a legal abstraction: a "Confirm" button your UI shows before an agent executes an action does not get you out of Article 22 scope if the person clicking it doesn't have enough context or time to meaningfully evaluate what they're approving, or if the UX is designed so people rubber-stamp it out of habit. If your agent's output can meaningfully affect eligibility, pricing, access, or anything resembling a credit-style decision, you need either a genuine Article 22(2) exception (contract necessity, a law authorizing it, or explicit consent) or a review step someone can actually exercise judgment in — not a decorative one.

The case CNIL itself cites: an agent that couldn't be stopped

One footnote in the note is worth flagging on its own. CNIL cites a reported case (via Business Insider) of an employee at a large tech company whose agentic AI autonomously deleted a large number of her professional emails, and who had difficulty interrupting the process remotely. CNIL uses it to make a narrow but sharp point: "the capacity to quickly identify the origin of an action, correct it, and limit its effects becomes an essential element of control over the system." That's the CNIL's own argument for why a kill switch and pre-execution gating on high-impact actions aren't optional extras — they're the difference between a bug and an unrecoverable incident.

Who's liable when the agent chain goes wrong

Section III of the note is a rare instance of a regulator openly admitting a gap rather than papering over it. Multiplying the number of interacting models, agents, and third-party services doesn't just complicate GDPR compliance — it blurs the traditional mechanisms for attributing responsibility for a harm and widens the attack surface. GDPR itself doesn't change here: a controller must remain identifiable and able to guarantee compliance, full stop. What gets harder is figuring out which actor — developer, model provider, integrator, deployer, end user — is playing that role for a given piece of processing, which complicates the controller/processor split and the accountability obligations that follow from it.

Beyond GDPR, the note is blunt that the wider liability picture is unresolved: the EU's dedicated AI Liability Directive proposal was abandoned in 2025. The AI Act itself doesn't establish an express liability regime — it imposes risk-based conformity obligations tied to a role in the value chain, which can help identify who did what but isn't a liability regime on its own. Absent a dedicated EU instrument, France falls back on ordinary civil law: fault-based tort liability (Art. 1240 of the Code civil), liability for things under one's custody (Art. 1242), contractual liability, or the EU's revised strict product-liability regime (Directive (EU) 2024/2853, October 23, 2024), which now explicitly extends to software and AI.

The practical takeaway is one CNIL states almost as an aside but that's genuinely actionable: document, per action type, which actor made or triggered which decision. Without that record, nobody in an agent chain — including you — can prove who's actually accountable when something breaks, and right now that ambiguity doesn't protect anyone.

The four technical controls CNIL recommends, as an engineering checklist

Section IV of the note is the part worth building against directly. It groups its recommendations into detection/filtering, memory and environment segregation, human oversight, and evaluation. Here's each one translated into something you can implement.

1. Filter and monitor at every agent hop, not just the initial prompt. CNIL recommends combining models specifically trained/instructed to refuse prohibited or illicit use with request-filtering measures — recognizing and blocking suspicious requests, monitoring agent actions in real time, alerting on unusual behavior, and robustness-testing before and throughout deployment. The note is explicit that this filtering needs to apply every time a generative model is invoked through any agent — orchestrator or specialized — not only at the user's original prompt. A common gap: teams filter the initial user input carefully and then trust everything an internal agent hands to another agent by default.

2. Ringfence memory, and sandbox the execution environment. This is the note's most concrete recommendation, and the one most directly translatable into architecture:

• Each agent should have its own dedicated, isolated memory, with no automatic access to another agent's memory.
• Cap memory size, auto-expire entries after a defined period, and replace stale entries with more recent data instead of accumulating indefinitely.
• Run a periodic consistency check between agents' memories to catch divergent, contradictory, or outdated data before it drives a decision.
• To limit over-personalization, scope memory per task or per session rather than one persistent global store — the note's own suggestion is literally to create a dedicated session per processing activity, so usage and the data it touches stay separated.
• Sandbox the deployment environment itself. A dedicated, isolated execution environment per agent or task reduces access to only what's strictly necessary, shrinks the risk perimeter, and caps what could actually be exfiltrated if one component is compromised, to just the data reachable inside that sandbox.

3. Classify agent actions by risk, and gate the risky ones behind real human confirmation. CNIL suggests classifying every action an agent can take against a connected service by risk level — access, modification, deletion, sending data outside the system — cross-referenced with the sensitivity of the data involved (financial, health, etc.). A minimal version of that classification looks like this:

Add a kill switch — a way to interrupt an in-progress agentic process at any point given unexpected behavior or an identified risk. Given the email-deletion example above, this isn't a nice-to-have; it's the control that turns a bad decision into a recoverable one.

4. Log a full traceability chain per completed task. For every task an agentic system executes, CNIL says the user should be able to identify which personal data was mobilized, which agents were involved, which third-party services were called, and the chronology of exchanges. This does double duty: it's the transparency mechanism required to make Article 5(1)(a) meaningful for a system this complex, and it's also the accountability record that makes the liability question in the section above answerable rather than a shrug.

A lower-priority fifth item the note mentions but frames as longer-horizon: extending existing independent AI model/system evaluation practices to specifically assess data-protection posture and security, and considering publishing the results to build trust. CNIL is upfront that this needs dedicated budget and cross-actor coordination — reasonable for a platform vendor, out of reach for most small teams building on top of one.

What's still open

A few things this note deliberately leaves unresolved, and that you shouldn't wait on before building the checklist above:

• It has no binding force on its own. It's a joint exploratory note, not a CNIL deliberation, recommendation, or sanction basis.
• EDPB and European Commission guidelines on how GDPR and the AI Act actually interlock are in drafting, expected by the end of 2026 — not published yet, and not guaranteed to land exactly on CNIL's framing.
• The AI Act doesn't define "agentic AI" as its own category. General risk-based, value-chain obligations apply to agentic systems, but there's no agent-specific chapter — some legal scholars are actively arguing that should change, but it hasn't yet.
• There is still no dedicated EU AI liability regime. The Directive proposal was abandoned; the fallback is ordinary civil liability plus the revised product-liability directive, as described above.
• A competitive angle worth weighing separately from compliance: the note flags that agent vendors reusing data generated or supplied by their users to train or improve their own models risks concentrating both data and market power among a small number of players — a "sovereignty dilemma" worth factoring into which agent framework or vendor you build on, independent of the GDPR question.

The practical takeaway

None of this note is enforceable today, and CNIL says so itself. But it's the clearest technical blueprint a EU regulator has published for what a defensible agentic-AI architecture looks like, and the four recommendations — ringfenced, TTL'd memory per agent; risk-tiered actions with a real (not decorative) human gate on the critical ones; a traceability log per task; and a sandboxed execution environment — are also just sound multi-agent engineering on their own merits. Building them now, while the EDPB guidance is still in draft, is considerably cheaper than retrofitting them after a binding version lands or after your own version of the email-deletion incident happens to one of your users.

See Also

• EU AI Act Agentic AI Memory & RAG Compliance: GDPR Art.17 Erasure, Vector Stores & Automated Decisions — the complementary deep dive on vector-store memory, erasure, and Art.22 for RAG-based agent pipelines specifically.
• EU AI Act Agentic AI: Human-in-the-Loop Art.14 Implementation Patterns — the AI Act's own human-oversight requirement, useful alongside the Art.22 standard covered here.
• GDPR Art.21–22: Right to Object, Automated Decision-Making & Profiling — a full breakdown of Article 22's scope and exceptions.
• MCP's Stateless Rewrite and the Cyber Resilience Act: Why It's Article 13, Not Article 15 — for teams building on the same MCP protocol CNIL names explicitly in its architecture description.
• Is Your PaaS a Joint Controller? What CNIL's May 2026 Cloud Guidance Actually Says — CNIL's other 2026 guidance most relevant to teams building on managed infrastructure.

Sources

• CNIL & CIANum — "IA agentique et protection des données personnelles : équation à inconnues multiples pour les utilisateurs", published July 20, 2026 (primary source for all quotes, examples, and recommendations above)
• CNIL — announcement page for the note
• GDPR Art.5 — Principles relating to processing of personal data
• GDPR Art.6 — Lawfulness of processing
• GDPR Art.22 — Automated individual decision-making, including profiling
• CJEU Press Release No. 186/23 — Case C-634/21, SCHUFA Holding (Scoring), December 7, 2023