The CNIL's July 20, 2026 exploratory note on agentic AI serves as a warning. When your AI systems autonomously orchestrate tasks, call external services, and maintain persistent memory across sessions, traditional GDPR compliance approaches may not suffice. The General Data Protection Regulation applies to these systems, but the challenge is ensuring your current controls can demonstrate compliance when decision-making is distributed and data flows are opaque.
This checklist translates the CNIL's technical observations into actionable compliance requirements. If you're deploying or planning to deploy agentic AI systems that process personal data, work through each item with your development, legal, and security teams.
Prerequisites
Before you begin this checklist, ensure you have:
- System architecture documentation showing all agents (orchestrator and specialized), their memory instances, context handling, and external integrations.
- Current Data Protection Impact Assessment template (you'll need to extend it).
- Inventory of personal data categories your agentic system will access, including emails, browsing history, files, and interaction logs.
- Identified controller(s) and processor(s) across your AI value chain, foundation model provider, agent orchestration platform, specialized agent developers, and your organization.
Checklist Items
1. Map Every Memory Instance in Your Agentic Architecture
Requirement: Article 5(1)(a) transparency and Article 30 records of processing activities
Document each agent's memory (persistent storage) and context (session-based storage) separately. Record what personal data categories it stores, retention period, and which other agents can access it.
Good looks like: A data flow diagram showing that your customer service orchestrator agent maintains conversation history in context (deleted after 24 hours), while your personalization agent maintains user preference memory (retained for 12 months with quarterly review), and you can trace which specialized agents share access to each memory instance.
2. Establish Traceability for Every Autonomous Decision
Requirement: Article 5(1)(a) transparency and Article 22 automated decision-making accountability
Implement logging that captures: the personal data used, agents involved, third-party services called, the sequence of exchanges, and timestamps. This reconstruction capability must cover the entire decision-making workflow.
Good looks like: When a user asks why their loan application was declined, you can produce a log showing the orchestrator agent sent financial data to your risk assessment agent, which called an external credit scoring API, and returned a recommendation based on specific data points, with every step timestamped and traceable.
3. Define Purpose Boundaries for Each Agent
Requirement: Article 5(1)(b) purpose limitation
Document the specific purpose for each specialized agent. Configure technical controls that prevent agents from accessing data or performing actions outside their defined purpose.
Good looks like: Your code generation agent is restricted to accessing repository files and cannot read customer emails. Your customer support agent can access support tickets but cannot initiate financial transactions. These restrictions are enforced at the API level, not just documented in policy.
4. Implement Data Access Controls with User Override
Requirement: Article 5(1)(c) Data Minimisation and Article 25 data protection by design
Give users granular control over which data categories each agent can access. Require explicit consent for sensitive data categories. Build partitioning so agents only access data necessary for their specific task.
Good looks like: Before your scheduling agent accesses calendar data, users see a permission prompt specifying exactly what calendar information will be shared. Users can deny access to personal events while allowing access to work meetings. Your system documents these permission decisions and respects them across all agents.
5. Verify Human Supervision Meets SCHUFA Standards
Requirement: Article 22 prohibition on solely automated decisions with legal or similarly significant effects
For decisions producing legal or similarly significant effects, ensure human intervention is meaningful. The human must be capable of influencing the decision based on independent assessment.
Good looks like: When your agentic HR system recommends rejecting a job candidate, the hiring manager reviews the underlying data points (not just the recommendation), can request additional information the agent didn't consider, and documents their independent reasoning. The final decision isn't predetermined by the agent's output.
6. Build Data Subject Access Request Handling into Agent Design
Requirement: Article 15 right of access and Articles 16-21 other data subject rights
Create mechanisms to identify which agents hold personal data about a specific data subject, extract that data from distributed memory instances, and execute deletion or rectification requests across all agents and memory stores.
Good looks like: When processing a Data Subject Access Request, your system queries all agent memory instances, retrieves stored personal data, and presents it in a structured format showing which agent collected it, when, and for what purpose. Deletion requests propagate to every memory instance, including shared memories, with confirmation logging.
7. Configure Automated Retention and Deletion
Requirement: Article 5(1)(e) storage limitation
Set maximum retention periods for each memory instance. Implement automated expiry. Partition memory by agent and by process to prevent indefinite accumulation.
Good looks like: Context data deletes automatically at process completion. Memory instances have defined size limits (e.g., 10,000 interactions per user) and time limits (e.g., 18 months). Your system logs when data is purged and can demonstrate that no orphaned personal data remains in deprecated agent memory stores.
8. Deploy Prompt Filtering at Every Model Invocation
Requirement: Article 5(1)(c) Data Minimisation and Article 32 security of processing
Apply detection and filtering not just to initial user prompts, but whenever any agent invokes an LLM. Block transmission of personal data categories that aren't necessary for the specific task.
Good looks like: When your document summarization agent processes a contract, filtering mechanisms strip out personal identifiers (names, addresses, account numbers) before sending text to the LLM, unless those identifiers are necessary for the summarization task. Logs show what was filtered and why.
9. Implement Risk-Tiered Authorization for Agent Actions
Requirement: Article 32 security of processing and Article 25 data protection by design
Classify agent actions by risk level. Require human approval for high-risk actions (financial transactions, data deletion, external data sharing). Allow autonomous execution only for low-risk actions.
Good looks like: Your expense management agent can automatically categorize receipts (low risk) but requires explicit user approval before submitting reimbursement requests over €500 or sharing expense data with external accounting systems (high risk). The risk classification is documented and regularly reviewed.
10. Provide a User-Accessible Kill Switch
Requirement: Article 25 data protection by design
Build an immediately accessible mechanism for users to halt all agent processing, revoke all permissions, and prevent further autonomous actions.
Good looks like: A clearly labeled "Stop All AI Processing" control in your user interface that immediately suspends all agent activity, prevents new data access, and queues a notification to your data protection team for manual review before any agent processing resumes.
Common Mistakes
Treating context and memory as equivalent: Context is session-based and should delete automatically. Memory is persistent and requires retention justification under Article 5(1)(e). Don't retain everything in memory "just in case."
Assuming the foundation model provider is the controller: Under the General Data Protection Regulation, the entity determining purposes and means is the controller. If you're directing the agentic system to process personal data for your purposes, you're likely the controller, even if you're using a third-party model.
Documenting theoretical human oversight without implementing it: Post-hoc review of agent outputs doesn't satisfy Article 22 requirements if the human can't realistically influence the decision. Build intervention points into the workflow, not just audit trails.
Relying on agent-level permissions without user-level controls: Your internal access controls aren't sufficient. Data subjects must be able to control what personal data your agents access about them.
Next Steps
The European Data Protection Board and European Commission are preparing guidelines on General Data Protection Regulation and EU AI Act interplay, expected by the end of 2026. Your current implementation shouldn't wait for those guidelines, but your compliance program should:
- Schedule quarterly architecture reviews as your agentic systems evolve.
- Monitor EDPB guidance following Opinion 28/2024 on AI models.
- Update your Data Protection Impact Assessment template to address distributed agent architectures.
- Train your development teams on the distinction between context and memory in data protection terms.
The CNIL's note makes one thing clear: agentic AI amplifies existing data protection risks through scale and opacity. Your compliance program must match that scale with equally systematic controls.
