Swiss companies can deploy AI agents today, but an agent does not sit outside existing law. When it processes personal data, the Federal Act on Data Protection applies. The practical requirement is to understand the data flow, make the processing transparent, control providers and permissions, and preserve human review where an automated individual decision significantly affects someone.
This article is operational guidance, not legal advice. Review the actual use case with qualified counsel or your data-protection function before launch.
Does Switzerland have an AI law?
As of 19 September 2026, Switzerland does not have one overarching AI-specific statute. The Federal Council has chosen a sector-oriented approach and intends to incorporate the Council of Europe's AI Convention into Swiss law. A consultation draft is due by the end of 2026, with particular attention to transparency, data protection, non-discrimination and supervision (Federal Office of Communications).
No dedicated AI act does not mean no rules. Current obligations can arise from the FADP, employment law, intellectual-property law, contract law and sector regulation. Swiss companies serving or monitoring people in the EU may also fall within the scope of the GDPR, while certain AI systems connected to the EU market may trigger EU AI Act obligations.
What does the FADP mean for an AI agent?
The Swiss Federal Data Protection and Information Commissioner states that the FADP is technology-neutral and applies directly to AI-supported data processing. The FDPIC highlights transparency about purpose, functionality and data sources, as well as the ability to object to or request human review of certain automated individual decisions (FDPIC: AI and data protection).
An AI agent can create more exposure than a standalone drafting tool because it may retrieve data from several systems, infer new information, choose an action and write back into operational records. The compliance unit is therefore the complete workflow, not only the language model.
The 12-point deployment checklist
1. Define one exact business purpose
Write a one-sentence purpose that a non-technical reviewer can understand. “Improve operations with AI” is not enough. “Classify inbound support requests and prepare a response draft for an employee” creates a reviewable boundary.
2. Map every data movement
Record the source, data fields, processor, destination, storage location and retention period. Include prompts, retrieved documents, model outputs, logs, feedback and support access.
3. Classify the personal data
Identify whether the workflow processes ordinary personal data, sensitive personal data, employee data or information that could create a personality profile. Do not assume that removing a name always makes a record anonymous.
4. Establish the lawful and contractual basis
Confirm why each data category may be processed and whether existing notices, contracts and internal policies cover the new purpose. Purpose expansion deserves explicit review.
5. Make the processing recognisable
People should understand when they are interacting with an AI system and how their data is being used. The FDPIC says users have a right to know whether they are communicating with a machine and whether their inputs are used for model improvement or other purposes.
6. Assess automated individual decisions
If the workflow makes a decision without meaningful human involvement and the decision has legal consequences or significantly affects a person, Article 21 FADP may require information and human review. Recruitment, credit, insurance, pricing and eligibility processes require particular care.
7. Decide whether a DPIA is required
A data protection impact assessment is required when planned processing is likely to create a high risk to personality or fundamental rights. The FDPIC identifies new technology, large-scale sensitive-data processing and systematic surveillance among relevant factors (FDPIC: Data protection impact assessment).
8. Review every processor and sub-processor
Using a cloud or AI provider does not transfer the company's responsibility. The FDPIC says controllers must select processors carefully, instruct them appropriately and monitor them where necessary (FDPIC: Outsourcing data processing).
Review training settings, sub-processors, support access, deletion, security commitments, breach notification, audit rights and exit mechanisms.
9. Control cross-border disclosure
Document where data may be processed or accessed. If a recipient country does not provide an adequate level of protection, implement an appropriate legal mechanism and assess whether additional measures are needed. “Hosted in Europe” is not a complete data-flow analysis.
10. Apply least privilege
The agent should receive only the tools and records required for its job. Separate read, draft and execute permissions. A support assistant may retrieve customer history without receiving permission to issue refunds or change contracts.
11. Preserve meaningful human control
Human approval must be more than a button people click automatically. Give the reviewer the source evidence, proposed action, uncertainty and ability to correct or reject the output. Route unusual or high-impact cases to an accountable owner.
12. Log, monitor and retire
Record system version, inputs or evidence references, outputs, tool calls, approvals and failures in proportion to the risk. Review quality and incidents. Define who can pause the system and how data is deleted when the use case ends.
A simple permission model
| Level | Agent capability | Appropriate use |
|---|---|---|
| Read | Retrieve approved information | Knowledge search and case preparation |
| Draft | Prepare text or a proposed change | Customer replies, reports and CRM notes |
| Recommend | Rank options with evidence | Triage and exception handling |
| Execute reversible | Update a controlled internal state | Low-risk routing with complete logging |
| Execute consequential | Affect money, rights or external commitments | Human approval and stronger controls required |
Autonomy should increase only after evaluation demonstrates that the preceding level is reliable.
What should be in an AI register?
A lightweight register can contain:
- use-case name and purpose;
- accountable business owner;
- provider and model;
- data categories and systems;
- affected people;
- decision and approval level;
- risk assessment or DPIA reference;
- quality threshold and evaluation date;
- retention and deletion rule;
- current status and last review.
This register turns shadow AI into a manageable portfolio without requiring a large governance programme.
Common mistakes
Reviewing only the model. Most operational exposure sits in retrieval, permissions, integrations and downstream actions.
Treating a vendor's compliance page as your assessment. Certifications and contractual claims are inputs, not substitutes for understanding your own processing.
Keeping every prompt indefinitely. Logs need a purpose, access control and retention period too.
Calling a decision “human reviewed” when the reviewer lacks time or evidence. Meaningful review requires the authority and information to change the result.
Assuming Swiss hosting solves everything. Location matters, but so do access, sub-processing, security, retention and the underlying legal purpose.
Frequently asked questions
Can a Swiss company use a US AI provider?
Potentially, but it must assess the processor, cross-border disclosure, contractual safeguards, security and the sensitivity of the data. The answer depends on the exact service configuration and use case.
Must every AI project have a DPIA?
No. A DPIA is required when the planned processing is likely to create a high risk. Document the screening decision even when the threshold is not met.
Is a chatbot disclosure enough?
No. It helps make machine interaction recognisable, but the company must still address purpose, data use, processors, retention, security, permissions and relevant individual rights.
Can an AI agent make decisions automatically?
Some automation may be lawful, but decisions that significantly affect people can trigger transparency and human-review requirements. Sector-specific obligations may also apply.
Build the evidence before the autonomy
The safest deployment pattern is not to write a longer system prompt. It is to create a narrow purpose, explicit data map, limited permissions, evaluated behaviour and a real exception path. Those controls also improve reliability and operating ownership.
Swiss Product Studio builds AI agents and workflow automation with defined tool permissions, human checkpoints and operational visibility. Book an operations review to map one use case before selecting its architecture.