Plenty of Swiss companies are quietly running AI agents that touch EU personal data — qualifying inbound enquiries, processing customer support tickets, triaging CVs. Most have done very little to check whether any of it is defensible under GDPR.
That is a gap that is straightforward to close, provided you know which questions to ask before you deploy rather than after a supervisory authority sends you a letter.
This article maps the key GDPR obligations to the agent deployments Swiss companies most commonly build, and shows what “built to comply” actually looks like in practice.
Why “Swiss Company” Does Not Mean “GDPR Doesn’t Apply”
Switzerland is not in the EU. But GDPR’s territorial scope (Article 3) extends to any organisation that processes personal data of individuals located in the EU in connection with offering goods or services, or monitoring behaviour. If your agent handles enquiries from German or French prospects, processes Italian customers’ orders, or runs outreach into any EU market, GDPR applies — regardless of where your servers sit.
The Swiss nFADP runs in parallel and covers Swiss residents specifically. The nFADP and GDPR share principles of data minimisation and purpose limitation, but there is a key structural difference: the nFADP does not require private-sector controllers to identify a specific legal basis for every processing activity — processing is generally permitted unless it infringes personality rights. Designing for GDPR compliance therefore addresses most nFADP obligations, but a dedicated nFADP review is advisable alongside GDPR design. We cover nFADP specifics in the companion article on Swiss data protection.
For now: assume GDPR applies to your agent if it touches EU data subjects. The question is what that means operationally.
What “Processing Personal Data” Looks Like Inside an Agent
An AI agent processes personal data whenever it reads emails, CRM records, or chat transcripts containing names and identifiers; generates outputs that reference individuals; stores data in memory, vector stores, or logs; or calls third-party APIs that receive that data.
Each of those actions is “processing” under GDPR Article 4(2). The regulation does not care whether it happens intentionally or incidentally — a support agent logging every conversation is subject to the same rules as a manually-maintained database.
Most agent deployments hit at least three of these simultaneously. That is not a reason to avoid agents. It is a reason to architect them deliberately.
The Four Obligations That Matter Most for AI Agent Deployments
1. Lawful Basis — Know Why You’re Allowed to Process
Every instance of processing needs a lawful basis under Article 6. For business AI agents, the three relevant bases are:
- Legitimate interests (Art. 6(1)(f)) — the most common basis for B2B use cases. Requires a Legitimate Interests Assessment (LIA) balancing your interests against the data subject’s rights. Generally defensible for B2B sales outreach and internal operations agents.
- Contract performance (Art. 6(1)(b)) — where processing is necessary to deliver a contracted service (e.g., an order agent processing a customer’s address to fulfil a purchase).
- Consent (Art. 6(1)(a)) — needed for B2C marketing where ePrivacy applies, and for particularly sensitive use cases. Must be freely given, specific, and revocable.
The failure mode is using a single vague basis (“legitimate interests”) for every processing activity without running the LIA. That does not survive scrutiny. Each agent workflow with distinct data inputs and outputs should have its lawful basis documented separately.
2. Data Processing Agreements with Every AI Provider in the Chain
When your agent sends personal data to an LLM API — OpenAI, Anthropic, Google, or any other — that provider becomes a data processor under Article 28. You are required to have a signed Data Processing Agreement (DPA) with them before any personal data flows their way.
Most major LLM providers offer a DPA, but you often have to actively request it or opt into the right service tier. Standard consumer API terms generally do not qualify. Check that the DPA covers your data types, includes sub-processor lists, and that the provider’s input retention policy aligns with your own.
This extends to the full processor chain. Orchestration platforms, third-party vector databases, and managed tool-calling services each need a DPA if they receive personal data — or a documented rationale for why they do not (typically because you have anonymised the data upstream).
3. Data Residency — Where Your Agent’s Data Actually Lives
Switzerland and the EU have an EU adequacy decision (confirmed most recently on 15 January 2024) that permits data to flow freely from the EU/EEA to Switzerland without additional safeguards. Transfers between the two are generally unproblematic. But if your agent infrastructure runs on US-based cloud services or calls US-based LLM APIs, you are making international transfers to a third country — and each of those needs a transfer mechanism, typically Standard Contractual Clauses embedded in the DPA.
The practical steps: map where personal data flows from ingestion through every API call and storage layer; confirm each cross-border hop has an adequacy decision, SCCs, or Binding Corporate Rules; and document it. If a supervisory authority ever asks you to demonstrate compliance, that data flow map is the first thing they want.
Hosting agent infrastructure in Switzerland or the EU removes most of this complexity — one reason clients with sensitive data processing requirements often prefer Swiss or EU-region deployments over US defaults.
4. DPIAs — When You Need a Formal Risk Assessment
A Data Protection Impact Assessment (DPIA) is required under Article 35 whenever processing is “likely to result in a high risk to the rights and freedoms of natural persons.” For AI agent deployments, trigger points include:
- Automated decisions with significant individual effects (Article 22) — a recruitment screening agent that ranks or rejects candidates, or any credit-related agent
- Special category data at scale (health, biometric, political views)
- Systematic monitoring of individuals’ behaviour
- Personal data processing at large scale
Done properly, a DPIA forces you to articulate specific risks and the controls that mitigate them. The Article 22 question deserves particular attention. Where an automated decision produces legal or similarly significant effects on a person, they generally have the right not to be subject to purely automated processing. Under Article 22(3), even where exceptions apply — contract necessity, legal authorisation, or explicit consent — suitable safeguards are mandatory, including the right for the individual to obtain human intervention, express their view, and contest the decision. For most deployment contexts, building in a human review step is the simplest way to satisfy this.
Who Is Responsible: Controller, Processor, or Both?
If you deploy an agent for your own operations, you are the data controller — you determine the purpose and means of processing. LLM providers and other services you call are your processors.
If you are a service provider deploying an agent on behalf of a client, the controller/processor split depends on the contractual structure. This matters because controllers carry the primary GDPR accountability — responding to data subject rights requests, notifying supervisory authorities of breaches. Get it defined in writing. A joint-controller arrangement under Article 26 is frequently overlooked in agent projects and carries its own obligations.
What Compliant Agent Architecture Looks Like
Good GDPR compliance for an AI agent is not primarily about legal documents. It is built into the system design:
- Minimise data at ingestion. Strip or pseudonymise personal identifiers before they reach the LLM where the use case allows. A support triage agent often does not need a customer’s full name to classify a ticket.
- Log purposefully. Agent frameworks that log every prompt and response by default create retention liabilities. Configure retention windows and decide upfront which logs are operationally necessary.
- Document data flows before you build. A one-page diagram showing what enters the agent, which APIs it calls, what it stores, and where outputs go is both a design document and the foundation of your Article 30 records of processing activities.
- Build in human review checkpoints wherever the agent’s output significantly affects an individual. This is especially important for recruitment, credit, and healthcare use cases.
GDPR compliance sits inside the broader frame of AI agent governance — how you oversee agents in production, manage model updates, and handle failures. Security controls that prevent data exfiltration or prompt injection are also directly relevant; see the related piece on AI agent security risks.
GDPR Is Not the Only Regulation in Play
The EU AI Act adds a tiered risk framework affecting certain deployments independently of data protection law — particularly systems used in hiring, credit, or law enforcement. For a focused look at what that means operationally, the EU AI Act and AI Agents article covers the classification logic and compliance timeline.
AI agent projects built with regulatory structure from the start are faster to deploy, easier to audit, and far less likely to need expensive retrofitting later.
What a Defensible Deployment Actually Requires
The minimum viable GDPR posture for an AI agent touching EU personal data:
- A documented lawful basis for each distinct processing activity
- A signed DPA with every AI provider and sub-processor that receives personal data
- A data flow map covering ingestion, processing, storage, and transfer
- A DPIA where the processing is high-risk (automated decisions, special category data, large scale)
- A retention policy applied to logs, memory, and outputs
- Human review built into any workflow with significant individual-level decisions
None of this is exotic. It does require treating compliance as a design phase rather than a post-launch review.
Ready to Build an Agent That Your Legal Team Can Sign Off On?
Orange ITS builds custom AI agents for Swiss and European companies — compliance architecture is part of every build, not an optional extra. If you are assessing a deployment and want a clear picture of where the GDPR exposures sit, book a 30-minute call with our team. We will map your use case against the relevant obligations and tell you honestly what needs to be in place before you go live.