Agentic AI is no longer just a conversational interface with a bit of memory. An agent can read context, call tools, interact with other services, trigger actions and keep work traces. That ability to act is exactly what turns data protection into an architecture issue.
The note published by CNIL and CIANum puts the discussion at the right level. Agents can move personal data across services, create new histories, enrich profiles and make responsibility harder to follow. In a classic chatbot, the user usually sees what they provide. In an agentic system, a request can become a sequence of operations the user does not directly control.
Why the shift is real
An agent connected to an information system does not work in a vacuum. It can consult a CRM, search internal documents, open a ticket, read conversation history, call a business API and propose an action. Each of those steps carries a different level of sensitivity.
Risk comes from the combination. Information that is harmless in one tool can become sensitive when combined with another context. Data that helps answer a question can also be retained too long, reused in another flow or exposed in a technical log. Governance cannot be reduced to a "personal data" checkbox at the end of the project.
The trap of adding a layer too late
Many experiments start by placing an agent on top of existing tools. The prototype works quickly: the agent finds documents, drafts answers and creates tasks. But if permissions, logs and validation rules are not designed from the start, the team later discovers that the system can access too much or act in poorly defined areas.
That trap is common because the agent feels like a single interface. In reality, it amplifies the rights of the systems it connects to. If a connector grants access to an entire document space, the agent may use that context even when the request does not justify it. If an action is technically available, the team must decide whether it is functionally available.
Put permissions into the architecture
Least privilege needs to become an agentic reflex. An agent that classifies documents does not need the same access as an agent that edits a customer record or triggers a payment. Roles should be separated, scopes limited and sensitive actions placed behind explicit validation.
Design should also distinguish reading, preparing and executing. Letting an agent draft a message is not the same as authorizing it to send one. Allowing it to detect an anomaly is not the same as allowing it to modify production data. Those distinctions should appear in components, not only in instructions.
Memory, logs and explainability
Agent memory can improve the experience, but it adds responsibility. What is stored? For how long? Who can review the history? How can data be deleted? How can a decision be explained if the agent used several sources and tools?
Logs need to be complete enough to audit an action, but restrained enough that they do not become another pool of sensitive data. The goal is to reconstruct a chain: initial request, sources consulted, tools called, proposed output, possible validation and final action.
A product decision as much as a legal one
Agent governance is not only for the DPO or security team. It directly affects user experience. A product that delegates too much without explanation creates distrust. A product that asks for validation at every click becomes unusable. The right balance depends on risk level: assistance, recommendation, action preparation or autonomous execution.
AI agents can make tools more efficient, but they force teams to make autonomy visible. Data, permissions and validation must be treated as core features. That is the condition for agentic AI to move from impressive prototype to usable service.
