An agent does not process data only when it sends a prompt to a model. Context assembly, retrieval, durable memory, tool calls, retries, traces, exports and vendor telemetry can each create another copy and purpose. Data minimization means shaping that whole system around what a specific task actually needs, then making retention and data-subject workflows work across every store.
The GDPR is technology-neutral. Its principles apply whether personal data sits in a CRM, vector index, agent transcript, tool result, observability platform or model-provider endpoint. Article 5 requires data to be adequate, relevant and limited to what is necessary for the purpose, and to be kept in identifiable form no longer than necessary. The European Data Protection Board’s 2026 summary of data protection by design and default emphasizes operationalising the principles through the processing lifecycle. For engineering, that turns into a concrete inventory and control problem, not a prompt-writing exercise.
This is an engineering guide, not legal advice. A controller must determine purposes, legal basis, transparency, roles and applicable rights for the specific deployment. An agent framework or privacy setting cannot decide those questions for an organisation.
Draw arrows in both directions: retrieval and tool results bring personal data back into context, where it may be copied again.
Build the map per processing purpose and per data category. Include transient buffers and derived data, not only database tables. A free-text summary can still identify someone; an embedding is not automatically anonymous; a pseudonymous user ID remains personal data when it can be linked back. The EDPB’s AI-model opinion treats anonymity as a case-by-case assessment, including whether individuals can be identified or personal data extracted through queries.
Start with the task contract. A support agent asked to explain a delivery delay may need an order status and estimated date, not a full account record, unrelated tickets, payment credentials or years of chat history. Retrieve fields by allowlist, filter on purpose and authorization before ranking, and return the smallest useful record to the model. Where possible, use a backend tool to perform a narrow operation and return a result code instead of exposing its underlying personal data.
Do not treat a larger context window as permission to send more. Add explicit maximum age, source, purpose and sensitivity rules to retrieval. Redact or transform identifiers only when the task still works and the transformation is appropriate; hashing a stable email does not make it anonymous if records remain linkable. Avoid using personal conversations for model training or cross-user memory by default. A different purpose needs its own assessment, transparency and controls.
Separate conversation state, user-requested preferences, operational records and learned model parameters. They have different purpose, access, retention and erasure behavior. Keep short-lived task state in a TTL-bound store; persist a preference only when there is a clear feature need and user-facing expectation; keep required business records in the system of record rather than silently promoting them into agent memory.
Memory entries should carry provenance, purpose, data category, source record, creation time, expiry and subject or tenant reference where appropriate. Use tenant and user boundaries in both the metadata filter and the storage authorization layer. Test for retrieval leakage across sessions, stale facts resurfacing, and a deletion request removing the source row while leaving searchable chunks behind.
Logging every prompt is attractive during a prototype and dangerous as a permanent default. Prefer structured events such as task type, model version, tool name, latency, result status and a correlation token that is not a reusable account identifier. If content capture is necessary for a defined debugging purpose, gate it, limit access, redact, set a short retention window and record why the exception exists. Review the processor terms, region, subprocessors, retention and support-access paths for each model or observability provider.
Rights handling cannot be implemented as “delete the conversation row.” A request may require searching account-linked records across source systems, agent memory, vector indexes, caches, event stores and vendor services. Access and portability also need a meaningful way to assemble relevant records. Erasure has legal conditions and exceptions; some business records may need to be retained, and the controller must assess the request rather than promise unconditional deletion from every system.
Design an orchestrated workflow with a verified subject key, scoped searches, store-specific adapters, idempotent actions, a review queue for ambiguous matches and an auditable completion report. Propagate deletion tombstones to asynchronous consumers so an old event cannot recreate an erased embedding. For backups, define expiry and restore controls: a recovery process should reapply deletion records before restored data is made available.
Not every AI-assisted action is an Article 22 decision. That provision concerns decisions based solely on automated processing, including profiling, that produce legal or similarly significant effects, subject to the GDPR’s conditions and safeguards. Still, consequential agent workflows deserve an explicit decision inventory: what the agent can recommend, what it can execute, whether a person meaningfully reviews it, and how affected people can challenge or correct the result.
Use least-privilege tools, narrow action schemas, transaction confirmation and policy checks outside the model. A natural-language claim that the user agreed is not a reliable authorization record. Keep the model from expanding its own scope, and treat tool output and retrieved documents as untrusted data rather than instructions.
| Agent artifact | Minimisation control | Retention / rights concern | Test |
|---|---|---|---|
| Prompt context | Task-specific allowlist and retrieval filters. | Model provider may receive personal data. | Assert excluded fields never appear in request payload. |
| Conversation summary | Keep only facts needed for the active purpose. | Summaries can preserve sensitive or stale data. | Inspect summary after correction and expiry. |
| Vector memory | Tenant-scoped index, source link and TTL. | Deletion must cover chunks and derived indexes. | Search after deletion and after backup restore. |
| Tool arguments and results | Narrow schemas and server-side authorization. | Retries, queues and audit logs create extra copies. | Trace every retry and remove payload from routine logs. |
| Evaluation dataset | Synthetic or properly controlled test records. | Test fixtures can become long-lived personal-data stores. | Scan fixtures, exports and access permissions. |
I would add a data-flow registry to the agent platform: each task declares purpose, permitted fields, retrieval sources, tools, stores, processors and retention. A policy layer checks the declaration before context assembly; a privacy filter redacts outputs; event hooks attach retention and subject metadata to persisted artifacts; and a rights orchestrator fans requests out to registered adapters. CI tests would inspect provider payloads and exercise delete, correction and restore scenarios against seeded synthetic data.
Keep the registry useful rather than ceremonial. Make it answer operational questions: where can this task send data, which artifacts can be recalled, what expires automatically, and who owns a failed deletion adapter? Dashboards should show coverage and exceptions, not claim “GDPR compliant” from a green checklist.
For AI agents, minimisation is a property of the entire data path: what enters context, which tools can see it, what the agent remembers, what telemetry records, which suppliers receive it and whether copies can be found later. Scope each task, make memory expire, keep observability content-light and build rights workflows across stores. The strongest privacy control is often an architectural decision not to create an unnecessary copy in the first place.
Editorial note: This article translates GDPR principles and EDPB material into engineering controls. It does not determine a controller’s lawful basis, obligations or response to a specific rights request; involve qualified privacy and legal professionals for those decisions.