GDPR and AI Agents: Data Privacy in Agentic Commerce

When an AI agent buys a pair of running shoes on your behalf, it processes your name, shipping address, payment details, and purchase history. The GDPR has clear rules about this — but applying them to autonomous AI agents creates new questions that European regulators are only beginning to answer.

Why GDPR and Agentic Commerce Collide

The General Data Protection Regulation was written in an era when data processing meant a human filling out a web form or a company analyzing customer databases. Agentic commerce introduces a fundamentally different paradigm: an AI agent that autonomously collects, transmits, and processes personal data across multiple services — often in milliseconds, without direct human oversight.

This creates friction at several points:

• Multiple parties, unclear roles: A single agent transaction can involve the user, the agent platform (e.g., ChatGPT), the LLM provider, the merchant, the payment processor, and a logistics partner. Who is the controller? Who is the processor?
• Implicit data sharing: When an agent queries multiple shops to compare prices, it may transmit the user's preferences, location, and budget to merchants the user never chose to interact with.
• Automated decisions with real consequences: An agent that autonomously selects and purchases a product is making an automated decision with legal and financial effects — exactly the scenario Art. 22 GDPR was designed to regulate.
• Cross-border data flows: Most LLM providers are US-based. Every agent interaction that passes through their servers constitutes a transatlantic data transfer subject to the EU-US Data Privacy Framework (or its successor).

The Relevant GDPR Articles

Several GDPR provisions are directly relevant to agentic commerce. Here is how each applies:

Art. 6 — Lawful Basis for Processing

Every processing of personal data needs a legal basis. For agentic commerce, the most relevant bases are:

• Art. 6(1)(a) — Consent: The user consents to the agent processing their data. This is the typical basis for the agent platform.
• Art. 6(1)(b) — Contract fulfillment: Processing is necessary to fulfill a purchase contract. This is the merchant's typical legal basis once a purchase is initiated.
• Art. 6(1)(f) — Legitimate interest: May apply to fraud prevention, security logging, and analytics — but requires a balancing test.

Art. 5 — Data Processing Principles

The principles of purpose limitation, data minimization, and storage limitation apply to every party in the agent transaction chain. An agent that stores a user's complete purchase history "just in case" violates data minimization. An LLM provider that uses agent transaction data to train models violates purpose limitation unless explicitly consented to.

Art. 13/14 — Transparency and Information Duties

Users must be informed about how their data is processed — before the processing begins. For merchants, this means your privacy policy must explain that AI agents may access your product data and initiate transactions. For agent platforms, it means clearly communicating which merchants the agent will contact and what data it will share.

Art. 28 — Data Processing Agreements

Every controller-processor relationship requires a Data Processing Agreement (DPA). In agentic commerce, this creates a web of DPAs: the agent platform needs DPAs with its LLM provider, with each merchant it interacts with, and potentially with payment processors and logistics partners.

Art. 22 — Automated Individual Decision-Making

This is perhaps the most consequential article for agentic commerce. Art. 22 gives individuals the right not to be subject to decisions based solely on automated processing that produce legal effects or similarly significant effects. An AI agent that autonomously selects and purchases a product is making exactly such a decision.

The safeguards required under Art. 22(3) — the right to obtain human intervention, express a point of view, and contest the decision — translate directly into UX requirements: agents should present their recommendation and let the user confirm before executing a purchase.

Consent When AI Agents Act on Behalf of Users

Consent in agentic commerce operates on two levels:

Level 1: User-to-Agent Consent

When a user sets up an AI shopping agent, they consent to the agent processing their personal data for purchasing purposes. This consent must meet GDPR standards: it must be freely given, specific, informed, and unambiguous (Art. 4(11)). Generic "I agree to everything" checkboxes do not suffice.

Best practice: present a clear scope of what the agent will do (search products, compare prices, initiate purchases), what data it will process (name, address, payment method, purchase history), and which third parties will receive data (merchants, payment processors). The user should be able to revoke consent at any time.

Level 2: Agent-to-Merchant Interaction

When an agent interacts with a merchant, it acts on behalf of the user. The merchant's legal basis for processing the transaction data is typically contract fulfillment (Art. 6(1)(b)), not consent — just as it would be for a human customer. However, the merchant must still provide the required Art. 13 transparency information, which is complicated when the "customer" is an AI agent, not a human reading a privacy policy.

Emerging best practice: merchants expose a machine-readable privacy policy (linked via Schema.org or MCP) that the agent can parse and present to the user when relevant.

Data Processing Agreements with LLM Providers

The relationship between merchants and LLM providers in agentic commerce is legally complex. When an AI agent powered by Claude or GPT processes a transaction on your shop, does the LLM provider process personal data on your behalf?

The answer depends on the architecture:

• Cloud-hosted agents (ChatGPT, Gemini): The LLM provider operates the agent and processes user data through its models. The provider is typically a controller or joint controller, not a processor. Merchants need to verify that the provider's data practices comply with GDPR.
• Self-hosted agents (OpenClaw): The merchant hosts the agent and sends API calls to the LLM provider. The provider processes conversation data as a processor under Art. 28, requiring a DPA. Most major providers offer standard DPAs — ensure yours is signed.
• Hybrid architectures: Some setups involve multiple providers (e.g., one LLM for conversation, another for product recommendations). Each relationship needs its own DPA and legal basis assessment.

Key DPA provisions to verify with your LLM provider:

• Training data: Does the provider use your agent's conversation data to train its models? If yes, this requires explicit consent from the data subjects.
• Data retention: How long does the provider retain conversation logs? Ensure this aligns with your own data retention policy.
• Sub-processors: Which sub-processors does the provider use, and where are they located? This affects cross-border transfer assessments.
• Data deletion: Can you request deletion of specific conversation data? Art. 17 (right to erasure) requires this capability.

SharedPaymentTokens and Data Privacy

The SharedPaymentToken mechanism in the Agentic Commerce Protocol was designed with privacy in mind. Instead of sharing raw payment credentials, the agent generates a cryptographic one-time token bound to a specific amount, merchant, and session.

From a GDPR perspective, SharedPaymentTokens offer several advantages:

• Data minimization: The merchant receives only the token, not the underlying payment method. They cannot see the user's card number, bank account, or payment history.
• Purpose limitation: The token is bound to a single transaction. It cannot be reused for other purchases or stored for future transactions.
• Pseudonymization: The token acts as a pseudonym for the payment method, reducing the risk associated with data breaches.

However, SharedPaymentTokens do not solve all privacy concerns. The merchant still receives the user's name and shipping address — personal data that must be processed in compliance with GDPR. And the payment processor (typically Stripe) sees the full transaction chain, making them a data processor that requires a DPA.

Mandates: Delegation and GDPR

Mandates — structured authorization objects that define what an AI agent is allowed to do — are a key concept in agentic commerce protocols like AP2. From a GDPR perspective, Mandates can actually support compliance:

• Purpose limitation: A Mandate that restricts the agent to "purchase office supplies up to 50 EUR from approved vendors" inherently limits the scope of data processing.
• Transparency: Mandates document the user's intent and the agent's authorized scope, creating an audit trail.
• Control: Users can modify or revoke Mandates at any time, supporting the GDPR requirement for ongoing control over data processing.

Best practice: treat Mandates as part of your GDPR documentation. They demonstrate that the user explicitly authorized a specific scope of agent activity — which helps establish the legal basis for processing.

Practical Compliance Checklist

For merchants entering agentic commerce, here is a practical checklist for GDPR compliance:

• Update your privacy policy to cover agent interactions. Explain that AI agents may access your shop's product data, initiate purchases, and process personal data on behalf of users.
• Review your legal basis for processing. For direct customer transactions initiated by agents, Art. 6(1)(b) (contract fulfillment) typically applies. For analytics on agent behavior, conduct a legitimate interest assessment.
• Sign DPAs with all parties that process personal data in the agent chain: LLM providers, payment processors, and any third-party agent platforms.
• Implement data minimization in your MCP server and Checkout API. Only return the data that agents actually need. Do not include customer purchase history, browsing behavior, or internal analytics in agent-facing responses.
• Support data subject rights: Ensure you can fulfill Art. 15-22 requests (access, rectification, erasure, portability) for data collected through agent interactions.
• Document automated decisions: If agents make autonomous purchase decisions on your platform, document the logic, safeguards, and human review options as required by Art. 22.
• Conduct a DPIA (Data Protection Impact Assessment) under Art. 35 if agent transactions involve large-scale processing of personal data or systematic monitoring.
• Monitor cross-border transfers: If your agent infrastructure involves US-based LLM providers, ensure adequate safeguards (EU-US Data Privacy Framework, Standard Contractual Clauses) are in place.

Conclusion

GDPR compliance in agentic commerce is not optional, and it is not as daunting as it might seem. The regulation's principles — transparency, purpose limitation, data minimization, and user control — are well-suited to the agentic commerce model when applied thoughtfully.

The key is to treat AI agents as what they legally are: automated systems acting on behalf of data subjects. The user retains their rights. The merchant retains their obligations. The novelty is in the middle — the agent and its infrastructure — where clear DPAs, limited data sharing, and transparent processing create the legal framework for compliant agentic commerce.

Merchants who get this right will not just avoid fines. They will build the trust that is essential when asking customers to delegate purchasing decisions to AI agents. In agentic commerce, privacy compliance is not a cost — it is a competitive advantage.