Swiss FADP vs GDPR: Implications for AI Service Providers

The FADP can apply to processing that produces effects in Switzerland, including processing carried out abroad. GDPR can apply through an EU establishment or through a provider outside the EU offering goods or services to people in the EU or monitoring their behaviour there. A person's nationality alone does not determine the answer. ^{2 3}

Assess each organisation and processing activity. Having an EU business customer does not, by itself, settle whether a Swiss processor falls directly within GDPR. Examine the customer's obligations, the processor's activity and any connection to EU targeting or monitoring, plus the contractual requirements.

These hypothetical examples illustrate the questions to ask:

The biggest difference is how private-sector processing is justified. GDPR requires an Article 6 legal basis for each processing purpose. Consent is one option; other bases include contractual necessity and legitimate interests, subject to their conditions. Special-category data, such as health information, needs an additional Article 9 condition. ⁴

The Swiss FADP uses a different structure for private businesses. Processing must respect its principles and must not unlawfully infringe personality rights, including privacy. Where justification is needed, consent, an overriding private or public interest, or law may be relevant. Assess the particular use rather than simply copying a GDPR legal-basis label. ⁵

The notice, officer, incident and enforcement differences are detailed below. This is a selected comparison, not a complete list of obligations.

Swiss sensitive-data categories also include information about social assistance measures and administrative proceedings or sanctions. Check those categories when classifying data for a service used in Switzerland. ²

Both frameworks make the same delivery questions useful: what data is necessary, who can access it, how long it stays, and how a person can exercise their rights. Those answers should shape the service before launch.

Providers need a clear allocation of responsibility across the customer, implementation studio, hosting company and model provider. A controller decides the purposes and means of processing. A processor handles data on the controller's behalf. One provider can have different roles for different activities.

For example, a studio may process customer documents to deliver an assistant. If it separately reuses those documents to develop its own product, that additional purpose needs its own role and lawfulness assessment. A contract calling the studio a processor does not settle what it actually does. ⁶

Under FADP, outsourcing leaves the controller responsible for selecting, instructing and appropriately monitoring processors. Subprocessing requires the controller's prior consent; a general authorisation can involve notification and an opportunity to object to changes. ⁷

For the delivery team, this means the processing agreement should address instructions, security, subprocessors, incident escalation, assistance with rights, and deletion or return at the end of the engagement. Review the agreement alongside the system: a promise to delete data needs a working deletion process.

What should an AI privacy notice explain?

People should be able to understand who is responsible, why their data is processed and who receives it. Swiss notices also need the destination countries and relevant safeguards or exceptions for foreign disclosures. ⁸

For an AI service, explain the use in ordinary language. Is a person interacting with a machine? Are their messages used to answer a request, improve a model, or serve another purpose? The FDPIC explicitly addresses these transparency questions. ¹

Using personal data to answer a request does not automatically justify reusing it for model training. These operations can have different purposes, recipients and retention periods. Under GDPR, assess the legal basis for training separately; consent collected for one purpose does not automatically cover another. ⁹

Map the operations separately:

• Inference: a model processes an input to produce an answer.
• Retrieval, or RAG: the service finds documents and supplies relevant passages as context. Retrieval alone does not update model weights.
• Logging: the service or supplier stores a copy for operations, security or another stated purpose.
• Fine-tuning or training: data influences the model's parameters, creating different questions about reuse and individuals' rights.

A practical example is the OpenAI API. Its documentation says API data is not used for training unless the customer opts in. It also describes default abuse-monitoring logs retained for up to 30 days, subject to exceptions, and separate storage that depends on the feature. Zero Data Retention requires approval and has limitations. Verify these settings for the service you plan to use. ¹⁰

A “no training” setting still leaves storage and access questions to answer. Check the exact product, endpoint, account settings and agreement. Consumer tools and business APIs may have different arrangements.

Yes, subject to the applicable requirements. FADP does not impose a blanket rule that all personal data must stay in Switzerland. Foreign disclosures need an appropriate route, such as adequate protection, suitable guarantees or an applicable statutory exception. Sector rules, professional secrecy and customer contracts can impose additional constraints. ¹¹

Check where each operation happens: document storage, model inference, logs, backups and support access. A Swiss database can send a prompt to an overseas model. Remote access by a separate overseas recipient can also raise transfer issues. ¹²

Where contracts such as standard contractual clauses are used, review their suitability, Swiss adaptations and any necessary supplementary measures. EU GDPR has its own transfer requirements. Switzerland's EU adequacy status facilitates covered transfers to Switzerland; it does not certify an individual provider or settle its onward transfers. ^{11 13}

A data protection impact assessment (DPIA) evaluates proposed processing, risks to people and measures to address them. Under FADP, likely high risk is the trigger. Nature, scale, circumstances and purpose matter; examples include large-scale sensitive-data processing. GDPR has its own high-risk criteria and supervisory-authority lists. The AI label alone does not determine whether a DPIA is mandatory. ^{14 15}

High risks that remain after planned safeguards can require consultation with the supervisory authority. FADP allows a specific exception for private controllers consulting a suitably qualified data protection officer; appointing an officer does not remove the DPIA itself. ¹⁴

For illustration, an assistant summarising routine support tickets and a service evaluating applicants for rejection deserve different assessments. Employment, healthcare and finance also bring rules beyond this general overview.

Automated decisions need particular attention:

• FADP Article 21 covers solely automated decisions with a legal consequence or considerable adverse effect. Subject to exceptions, the controller must inform the person and, on request, allow them to express their position and obtain human review. ¹⁶
• GDPR Article 22 generally protects people from being subject to solely automated decisions with legal or similarly significant effects, with specified exceptions and safeguards. ¹⁷

Build human review into the workflow where required. The reviewer needs information, time and authority to reconsider the outcome. For an applicant challenging a rejection, that means a real opportunity for reconsideration.

Rights procedures need to reach every relevant copy of personal data. For an AI assistant, that may include source documents, retrieved passages, indexes, conversation histories, logs and supplier-held data.

An engineering approach is to trace those copies from the original record and define how requests reach each system. Deleting a source document does not necessarily remove its cached passages or conversation history. Define how to handle backups, retention exceptions and supplier-held copies too.

Model training creates further difficulty. CNIL distinguishes personal data in external retrieval databases from data that may be retained in model parameters; the measures needed depend on the system and applicable rights. ¹⁸

Do not assume an embedding or trained model is anonymous because information has been converted into numbers. The EDPB says model anonymity must be assessed case by case, including the likelihood of identifying people or extracting their personal data. ¹⁹

Under FADP, a controller must notify the FDPIC as soon as possible when a breach is likely to create a high risk to individuals' personality or fundamental rights. Informing affected individuals has a separate test: whether this is necessary for their protection or ordered by the FDPIC, subject to statutory exceptions. ²⁰

Under GDPR, a controller must notify the relevant authority unless the breach is unlikely to result in a risk to individuals. Notification must be without undue delay and, where feasible, within 72 hours of awareness. Likely high risk triggers communication to affected individuals, subject to exceptions. ²¹

Processors must escalate breaches promptly to controllers under both frameworks. Set contacts and escalation procedures before an incident. If both laws apply, assess both reporting obligations; the Swiss threshold does not replace GDPR's test.

Enforcement also differs. Certain intentional FADP offences primarily target individuals and carry a maximum criminal fine of CHF 250,000. This is not a cap on civil liability or all consequences of a breach. ²²

GDPR administrative fines can reach EUR 20 million or 4% of worldwide annual turnover, whichever is higher, for specified infringements. Authorities can also restrict or ban processing. ^{23 24}

The EU AI Act adds a separate assessment of the AI system, its use and the organisation's role. Meeting data protection obligations does not resolve all AI Act obligations. A Swiss provider should assess the Act's scope when entering the EU market. ²⁵

As of this article's update, the Commission's timeline states that transparency requirements for certain systems, including chatbots, apply from 2 August 2026. Rules for high-risk systems listed in Annex III apply from 2 December 2027, and those embedded in regulated products from 2 August 2028. Check the applicable provision and transition arrangements for the service. ²⁶

Switzerland's planned AI regulation is a separate development. Existing data protection obligations already apply while that work proceeds. ²⁷

Use this checklist to prepare a service for technical and legal review. It is a delivery aid, not a compliance certification.

1. Define the use and markets. State what the service does, whose data it handles and which jurisdictions may apply.
2. Map the data flow. Include prompts, retrieval, outputs, logs, training, backups and support access.
3. Assign roles by activity. Identify controllers, processors and any supplier using data for its own purposes.
4. Document processing justification. Assess GDPR bases and the Swiss requirements separately; review sensitive data and optional reuse.
5. Verify contracts and locations. Check instructions, subprocessors, transfer arrangements and actual retention settings.
6. Assess risk before launch. Determine DPIA and automated-decision requirements, then assign necessary review responsibilities.
7. Test controls and rights procedures. Check that retrieval respects user permissions and keeps customers' records separate. Test deletion and incident escalation too.
8. Keep documentation current. Reassess when a vendor, feature, market or processing purpose changes.

Start with one workflow: a customer request, the records it retrieves, the suppliers it reaches and the copies it leaves behind. That gives your delivery team and legal advisers something concrete to review before the service expands.

Does GDPR compliance also satisfy Switzerland's revised FADP?

It provides useful groundwork, but a Swiss assessment is still needed. Review destination-country information in notices, transfer arrangements, local breach duties and any representation requirements. The laws overlap without having identical obligations. ^{8 28}

What are the implications of Swiss data privacy for AI firms under GDPR?

An AI firm subject to both laws needs to document both assessments for its service. Shared controls can support security, minimisation and rights handling. Notices, legal reasoning and incident procedures still need checks against each law. The sections above show where those checks affect delivery.

Is consent always required to use personal data in an AI service?

No. The answer depends on the purpose and applicable rules. GDPR has several legal bases. Under FADP, when consent is required, it must be explicit for sensitive data and private high-risk profiling. Avoid treating one consent checkbox as permission for every AI use. ^{4 29}

Do AI service providers need a data protection officer or Swiss representative?

A data protection officer is generally voluntary for private businesses under FADP. GDPR can require one, including for certain core activities involving large-scale monitoring or sensitive-data processing. A foreign private controller needs a Swiss representative when all four Article 14 conditions are met: Swiss offering or monitoring, large-scale processing, regular processing and high risk. ^{30 31 28}

Does Swiss hosting make an AI service FADP compliant?

Hosting location answers only part of the assessment. Review overseas inference and support access, processing purposes, security, retention and individuals' rights. A Swiss hosting address does not establish compliance across the service. ⁷

Related reading: AI agents and Swiss data protection.

1. FDPIC. AI and data protection. ↑1 ↑2
2. FDPIC. Guide to technical and organisational data protection measures. Definitions: section 1.2; scope: section 1.1. ↑1 ↑2
3. European Data Protection Board. Guidelines 3/2018 on the territorial scope of GDPR. ↑1
4. European Data Protection Board. Process personal data lawfully. ↑1 ↑2
5. FDPIC. Guidance on cookies and similar technologies. Version 1.1, 6 October 2025. Section 3.5: principles and justification for private-sector processing. ↑1
6. European Data Protection Board. Coordinated enforcement: cloud-based services. ↑1
7. FDPIC. Outsourcing of data processing. ↑1 ↑2
8. FDPIC. Duty to provide information. ↑1 ↑2
9. CNIL. Ensuring lawfulness: legal basis for AI development. ↑1
10. OpenAI. API data controls. ↑1
11. FDPIC. Cross-border transfer of personal data. ↑1 ↑2
12. European Data Protection Board. Recommendations on supplementary transfer measures. Version 2.0, 18 June 2021. Paragraphs 8–13 and footnote 23: transfers and remote access. ↑1
13. FDPIC. Adequacy. ↑1
14. FDPIC. Data protection impact assessment. ↑1 ↑2
15. European Data Protection Board. Be compliant: data protection by design and DPIAs. ↑1
16. FDPIC. Knowing and asserting my rights. ↑1
17. European Data Protection Board. Respect individuals’ rights. ↑1
18. CNIL. Ensuring and facilitating rights in AI systems. ↑1
19. European Data Protection Board. Opinion on AI models and GDPR. ↑1
20. FDPIC. Guidelines on data breaches. ↑1
21. European Data Protection Board. Data breaches. ↑1
22. FDPIC. Criminal law. ↑1
23. European Data Protection Board. Guidelines 04/2022 on calculating administrative fines. ↑1
24. European Commission. Consequences of non-compliance with data protection rules. ↑1
25. European Commission. Navigating the AI Act: frequently asked questions. ↑1
26. European Commission. AI Act enforcement framework and timeline. Updated 6 October 2026. Transparency and high-risk application dates. ↑1
27. Federal Office of Communications. Artificial intelligence: Swiss regulation. ↑1
28. FDPIC. Representatives under Article 14 FADP. ↑1 ↑2
29. Swiss Confederation. Federal Act on Data Protection: enacted text. Article 6: consent; Articles 30–31: personality rights and justification. ↑1
30. FDPIC. Data protection officer. ↑1
31. European Data Protection Board. Coordinated enforcement: data protection officers. ↑1