Feature 7 August 2026

What AI Providers Need to Change When Operating Across Switzerland and the EU

Priya Ellison

The short answer: similar privacy frameworks, different compliance tests

Switzerland’s revised Federal Act on Data Protection is broadly aligned with the EU General Data Protection Regulation, but the two regimes are not interchangeable. A mature GDPR program gives an AI provider a strong operational foundation. It does not, by itself, establish compliance with Swiss law.

The revised FADP and its implementing ordinances took effect on 1 September 2023 without a transition period. The framework protects personal data concerning natural persons, expressly incorporates privacy by design and privacy by default, and includes duties involving transparency, processing records, impact assessments, breach reporting and individual rights. It nevertheless retains Swiss-specific differences that may require additional controls or decisions, according to this overview of Switzerland’s data-protection framework.

For AI services, the threshold question is not whether a product is marketed as “AI,” “machine learning” or “automation.” It is whether the system processes personal data. The Federal Data Protection and Information Commissioner, or FDPIC, states that the technology-neutral FADP applies directly to AI-supported personal-data processing and addresses manufacturers, providers and users—not only the organization that originally developed the model. The same guidance calls for transparency about the purposes, functionality and data sources involved in AI processing (FDPIC guidance).

Several abbreviations refer to the Swiss federal framework:

FADP is the common English abbreviation for the Federal Act on Data Protection.
DSG reflects the German name, Datenschutzgesetz.
nDSG is often used to distinguish the revised or “new” statute from its predecessor.
revFADP is another English label for the revised law.

This guide uses FADP unless a particular source or context uses a different abbreviation.

Legal status as of 8 August 2026

On the evidence reviewed for this guide, Switzerland continues to regulate AI through technology-neutral laws such as the FADP, official guidance and rules applying to particular sectors or activities. Current legal commentary reports that Switzerland has not enacted a comprehensive horizontal AI statute equivalent to the EU AI Act and is instead pursuing targeted legislative amendments and sector-specific measures (2026 Swiss AI regulatory overview).

This is a time-sensitive status statement. Announced policy, consultation activity and proposed legislation should not be described as enacted law.

The EU AI Act is separate from both the GDPR and the FADP. A Swiss provider exposed to the EU market may therefore need three distinct assessments: FADP, GDPR and EU AI Act.

That separation matters. The FADP and GDPR regulate personal-data processing. Compliance with one regime does not determine whether either of the others applies.

This guide identifies potential gap-assessment areas rather than every change an organization must make. Obligations depend on service architecture, processing roles, data, affected people, contractual allocations and relevant jurisdictions. It is informational rather than legal advice; readers should confirm current, jurisdiction-specific requirements with qualified counsel, consistent with the publication’s terms and legal-information notice.

When the FADP, GDPR, or both can apply

Cross-border AI systems rarely have one meaningful location. A developer may be in the United States, an enterprise customer in Switzerland, an infrastructure provider in Germany and affected employees across Europe. Territorial scope must therefore be assessed separately for each regime and each relevant processing activity.

The FADP’s effects-in-Switzerland approach

The FADP can apply to circumstances initiated abroad when they have effects in Switzerland. Deliberately offering an AI service to people in Switzerland or monitoring behavior there are important examples, but the analysis remains contextual. Systematic tracking or profiling may indicate monitoring.

The provider should document what activity has an effect in Switzerland, which people are affected and how substantial or intentional the connection is. The effects-based approach and the relevance of targeting or monitoring are discussed in practitioner analysis of the revised law (IAPP analysis).

Some secondary commentary has suggested that storing personal data on Swiss servers can itself bring processing within the FADP. The evidence available here does not establish server location as a conclusive territorial rule. Hosting remains relevant to data-flow mapping, security, transfers and contractual diligence, but it should not replace analysis of the processing and its effects.

The GDPR’s reach beyond the EU

At a high level, the GDPR can apply to an organization outside the EU when it offers goods or services to people in the EU or monitors their behavior there. Switzerland is not an EU or EEA member, so a Swiss establishment does not automatically amount to an EU establishment. Switzerland’s non-membership also does not shield a Swiss provider that satisfies the GDPR’s extraterritorial tests. This distinction is summarized in a guide to GDPR application involving Swiss businesses.

The analysis should focus on the relevant activity and affected individuals—not only the provider’s incorporation, headquarters or cloud region. Because the evidence pack does not include the GDPR text or current territorial-scope guidance from EU authorities, providers should verify detailed Article 3 conclusions against current primary EU materials before relying on them.

Scenario matrix

Scenario	Likely starting point	Questions to resolve
Swiss-only AI service	FADP is the principal privacy assessment.	Does the service process personal data? Are cantonal or sector-specific rules relevant? Does any EU activity independently trigger the GDPR or EU AI Act?
Swiss provider serving EU users	FADP and GDPR may both apply.	Is the provider offering services to or monitoring people in the EU? Is an EU representative required? Are EEA-to-Switzerland or onward transfers involved?
Non-Swiss provider serving or monitoring Swiss users	FADP may apply through effects in Switzerland.	Is the Swiss market deliberately targeted? Is behavior monitored? Are the cumulative Swiss-representative conditions met?
One service serving Swiss and EU users	Both frameworks may govern the platform or different processing stages.	Can controls be coordinated while scope, notices, representatives, DPIAs, incidents and transfers remain legally separate?

A service can therefore be governed by both frameworks. Failure to satisfy one regime’s territorial test does not answer whether the other applies.

Territorial application must also be distinguished from three related questions:

Representative appointment: A law may apply even when its threshold for appointing a local representative is not met.
International transfers: Transfer analysis concerns where personal data is disclosed or made accessible, not merely which law governs the controller.
Sector regulation: Employment, healthcare, financial, secrecy, telecommunications, critical-infrastructure or public-sector rules may apply regardless of the general territorial conclusion.

For complex AI services, map scope by processing stage: collection, training, fine-tuning, prompt handling, inference, output review, monitoring, retention and deletion. The relevant actor, purpose, role or jurisdiction may change between stages.

Swiss and EU representative requirements are not identical

A foreign provider does not automatically need a Swiss representative merely because the FADP applies. The Swiss representative requirement uses a narrower, cumulative test.

A foreign private controller must assess whether all the following conditions are present:

It processes personal data of people in Switzerland in connection with offering goods or services there or monitoring their behavior.
The processing is extensive.
The processing is regular.
The processing creates a high risk to the personality or fundamental rights of the people concerned.

Concepts such as “extensive” and “high risk” can require legal judgment. Commentary also identifies unresolved interpretive questions, including whether risk should be evaluated before or after safeguards. The cumulative conditions and effects-based jurisdiction are summarized in this Swiss data-protection legal guide.

Where appointment is required, the representative must be a company established in Switzerland or an individual residing there. The representative acts as a contact for data subjects and the FDPIC. Practitioner commentary further states that the representative maintains the foreign controller’s processing record so that it can be produced on request.

The role should not be confused with:

a private-sector Swiss data protection adviser;
the controller’s internal privacy lead;
a GDPR data protection officer;
an EU representative;
a processor; or
a local reseller.

The GDPR has its own EU-representative framework, with separate triggers, exceptions and role requirements. One appointment should not be assumed to satisfy the other.

A practical representative decision sequence

Determine whether the FADP applies. Document the relevant Swiss effects, activities, people and processing stages.
Test each Swiss condition. Address offering or monitoring, extent, regularity and high risk individually.
Determine whether the GDPR applies. Analyze establishment, offering and monitoring separately.
Assess EU representation. Apply the GDPR’s own appointment test and exceptions.
Document the outcome. Record material facts, assumptions, owners, legal advice and the review date.
Reassess after material changes. New markets, larger datasets, sensitive attributes or a move from decision support to automated rejection may alter the result.

Consider a US provider offering continuous AI-based applicant evaluation to large Swiss employers. If the service regularly processes extensive candidate histories and sensitive or inferred attributes to recommend consequential employment outcomes, a Swiss-representative analysis is warranted. Appointment is not automatic: the provider must still assess every condition and its own role.

The same provider may serve EU employers. Depending on the facts and any applicable exceptions, it could need a Swiss representative, an EU representative, both or neither.

The core FADP–GDPR comparison for AI operations

The two frameworks share enough concepts to support a coordinated privacy program. They differ enough that the program needs jurisdiction-specific decision points.

Topic	Swiss FADP	EU GDPR	Operational consequence for AI services
Protected persons	Protects personal data concerning natural persons.	Protects personal data concerning natural persons.	Company information may still be personal data when it identifies employees, candidates, customers or professionals.
Territorial approach	Can apply to circumstances initiated abroad that have effects in Switzerland.	Can apply through EU establishment and, in specified cases, offering or monitoring involving people in the EU.	Run separate scope tests rather than relying only on headquarters or hosting location.
Privacy by design and default	Expressly required.	Expressly required.	Build minimization, access controls, retention settings and user choices into architecture and procurement.
Processing records	Controllers and processors generally maintain records in applicable circumstances, subject to a limited exemption described in secondary commentary.	Records are required subject to the GDPR’s conditions and exceptions.	Keep a system-level inventory, but verify the precise legal scope and any exemption under each regime.
DPIAs	Required before processing likely to create high risk to personality or fundamental rights.	Required where processing is likely to create high risk to individuals’ rights and freedoms.	Coordinate evidence gathering while documenting each regime’s trigger and escalation route.
Adviser or DPO	A private-sector Swiss data protection adviser is generally optional.	A DPO is mandatory only in circumstances specified by the GDPR.	Do not assume a GDPR DPO resolves Swiss governance questions or that every AI provider needs either role.
Breach reporting	Notify the FDPIC as soon as possible when a breach is likely to create high risk.	Notify the competent authority within 72 hours unless the breach is unlikely to result in risk.	Start both analyses immediately and track different thresholds and timing rules.
Representatives	Appointment depends on cumulative conditions, including extensive, regular and high-risk processing.	Separate rules apply to certain non-EU controllers and processors.	A provider may need both representatives, one or neither.
International transfers	Requires adequate protection or another applicable safeguard.	Restricts transfers outside the EEA unless an approved route or exception applies.	Map remote access and onward transfers, not only the primary hosting region.
Sanctions	Qualifying intentional violations can expose responsible natural persons to criminal fines.	Administrative fines generally target organizations and may be tied to worldwide annual turnover.	Add named responsibility, documentation and executive escalation to governance.

Secondary professional commentary states that controllers and processors generally maintain processing records under the FADP and describes a limited exemption involving businesses with fewer than 250 employees and low-risk processing. Because the supplied evidence does not establish the full ordinance-level test or all exclusions, organizations should not treat headcount and a general “low-risk” label as sufficient. The same commentary describes a private-sector Swiss adviser as generally optional and notes that a sufficiently independent adviser may have procedural value following a DPIA (EY analysis).

The shared operational baseline

A provider operating across Switzerland and the EU should ordinarily build a common control layer covering:

clear, accurate and context-specific transparency;
defined purposes and controls over incompatible reuse;
privacy by design and privacy by default;
appropriate technical and organizational security;
processing records where required;
documented controller, processor and subprocessor roles;
processor diligence and contractual controls;
risk assessments and DPIAs when triggered;
procedures for individual rights and automated decisions;
international-transfer safeguards;
incident detection, assessment and escalation; and
retention and deletion across the AI lifecycle.

Some of these controls are direct legal obligations in applicable circumstances. Others—such as maintaining a particularly detailed model-level inventory—may be recommended ways to implement or demonstrate compliance. Records should identify which regime and legal requirement support each mandatory control.

Do not overstate the lawful-basis comparison

The available evidence does not support saying that Swiss private-sector processing follows exactly the GDPR rule requiring a lawful basis for every operation. It also does not establish universal answers for:

collecting public information for model training;
fine-tuning on customer material;
retaining prompts for service improvement;
generating sensitive inferences;
using employee or applicant data to train a ranking model; or
combining datasets collected for different purposes.

These questions require fact-specific analysis of purpose, fairness, proportionality, transparency, contractual roles, individual expectations, applicable justification and sector rules.

Identifiability may depend on which party holds the relevant means and whether re-identification is reasonably possible.

Finally, distinguish binding requirements from recommended governance. Periodic DPIA reviews, inference logs, model cards, explanation traces and dedicated AI-governance committees may be prudent, but the evidence does not establish them as categorical FADP requirements for every service.

How the FADP applies to AI transparency, profiling, and automated decisions

The FDPIC expects AI manufacturers, providers and users to make the purposes, functionality and data sources of AI-supported processing transparent. It also states that people interacting directly with a language model should know that they are communicating with a machine and whether their submissions are used to improve a self-learning system or for another purpose (FDPIC AI guidance).

Transparency should be tailored to the processing rather than hidden behind a generic statement that “AI may be used.” Depending on the context, a Swiss-facing notice may need to identify:

the controller and its contact details;
the purposes of processing;
relevant categories of personal data;
recipients or categories of recipients;
whether prompts, files or outputs are retained;
whether submitted material is used for training or service improvement;
relevant destination countries or international bodies; and
applicable transfer safeguards or exceptions.

Commercial compliance guidance describes controller identity, purposes, recipients, relevant data categories and foreign-transfer information as important elements of a Swiss privacy notice (FADP notice overview). The exact content depends on the collection method, processing role and applicable statutory exceptions.

Product interfaces and contractual materials may need to supplement the general privacy notice. A user uploading an employment file, for example, should not have to infer from a broad policy whether the file will be reviewed by provider personnel or reused for model improvement.

Profiling is not the same as an automated decision

Profiling generally involves automated processing used to evaluate personal aspects of a natural person. An AI system might profile someone by estimating job fit, performance risk, purchasing behavior, creditworthiness or likely preferences.

Not all profiling is automatically high risk. Relevant factors may include scale, sensitivity, intrusiveness, consequences, the vulnerability of affected people, dataset combinations and the practical ability to contest an output.

An automated individual decision is a separate concept. Swiss law provides transparency and human-review safeguards for certain decisions made exclusively through automated processing, particularly those producing legal or similarly significant effects. Statutory conditions and exceptions must be assessed in the specific decision context.

The service should determine:

whether a decision—not merely an analytical score—is being made;
whether the decision is exclusively automated;
whether any human review is genuine and capable of changing the outcome; and
whether the consequences meet the relevant significance threshold.

A human name appearing in a workflow is not enough.

Hiring example: ranking versus rejection

An AI system that ranks applicants for a recruiter, who then reviews the applications and can disregard the ranking, differs from a system that automatically rejects everyone below a threshold.

The first system may still involve profiling, substantial privacy risks and potentially discriminatory effects. It is not necessarily an exclusively automated decision if the recruiter conducts genuine review.

The second is more likely to require analysis under the safeguards for exclusively automated decisions. The employer and provider should document the decision workflow, notice, intervention route, review authority and evidence available to the reviewer. For broader context on the operational difference between ranking and automated filtering, see this explanation of how AI-assisted resume screening works.

Sensitive, genetic and biometric data

Genetic and biometric data receive special treatment under the revised Swiss framework. AI services may process them directly—for example, through identity verification—or generate potentially sensitive inferences from apparently ordinary inputs.

Do not assume that explicit consent is universally required for every use of sensitive data under Swiss law. The appropriate justification and any consent requirement depend on the facts. Equally, do not assume an inferred attribute is harmless because the user did not submit it directly.

When an AI service needs a data protection impact assessment

No. AI use alone does not automatically require a DPIA.

Under the FADP, a controller must conduct a DPIA before processing that is likely to create a high risk to a person’s personality or fundamental rights. The assessment should be performed early enough to influence procurement, architecture and deployment rather than after material design choices have become difficult to reverse.

Risk indicators may include:

extensive or systematic profiling;
sensitive, genetic or biometric data;
large-scale processing;
decisions with legal or similarly significant effects;
vulnerable people, including employees, applicants or patients;
unexpected combination or reuse of datasets;
novel or difficult-to-predict processing;
pervasive monitoring;
limited ability to correct model outputs; and
consequences that are difficult to reverse.

These are indicators, not automatic rules. A limited biometric access-control system and a population-scale identification service do not present the same risk. Nor should a low-impact personalization tool and an automated employment-rejection system receive identical assessments.

High-risk AI processing is not necessarily prohibited. The FDPIC’s position is that such processing is permitted in principle where appropriate measures protect affected people. A DPIA is one part of demonstrating that the risks have been identified and addressed.

A practical AI DPIA workflow

1. Map actors and data flows. Identify the developer, model host, integrator, enterprise customer, users, affected non-users, subprocessors and human reviewers. Record data sources, processing locations, remote access and onward disclosures.

2. Define purposes and reuse. Separate the customer’s operational purpose from provider purposes such as fraud prevention, evaluation, debugging, training or general service improvement. Do not collapse every purpose into “service delivery.”

3. Classify the data. Cover prompts, uploaded files, account information, logs, outputs, labels, embeddings, inferred attributes and feedback. Note sensitive, biometric, genetic or secrecy-protected material.

4. Assess necessity and proportionality. Ask whether each data element, retention period and model function is needed for the stated purpose. Consider less intrusive alternatives and whether affected people reasonably expect the processing.

5. Evaluate risks to people. Consider unauthorized access, memorization, inaccurate inferences, discrimination, manipulation, loss of confidentiality, inability to exercise rights and overreliance by human decision-makers.

6. Document safeguards. Possible measures include access restrictions, encryption, minimization, purpose separation, retention limits, deletion processes, output testing, meaningful human review and subprocessor controls. Their suitability depends on the risk.

7. Assess residual risk. Determine what risk remains after safeguards, who accepted it and whether further consultation is required.

8. Establish monitoring and incident procedures. Define complaint routes, change-management triggers, breach escalation and reassessment after material changes to models, data sources, purposes or jurisdictions.

Where high residual risk remains, consultation with the FDPIC may be required. Secondary Swiss compliance commentary links this consultation question to the FADP’s DPIA framework and notes that an applicable exception involving a sufficiently independent Swiss data protection adviser may alter the procedure (Swiss AI compliance guide). The current statutory and ordinance-level conditions should be verified before relying on that exception.

A dual-regime organization can use one coordinated assessment process and evidence set. The final record should separately identify Swiss and GDPR triggers, safeguards, residual-risk conclusions, consultation questions and approvals.

Breach reporting, enforcement, and personal exposure

Swiss and EU incident rules differ in threshold and timing.

Under the FADP, a controller must notify the FDPIC as soon as possible when a personal-data breach is likely to create a high risk to a person’s personality or fundamental rights. Affected people must be informed where notification is necessary for their protection.

Under the GDPR, supervisory-authority notification is generally due within 72 hours after awareness unless the breach is unlikely to result in a risk to individuals’ rights and freedoms.

The central contrast is:

FADP: high-risk threshold; notification as soon as possible; no fixed 72-hour deadline.
GDPR: notification unless risk is unlikely; specified 72-hour deadline.

It is inaccurate to say that the GDPR requires regulator notification for every breach. It is also inaccurate to describe the Swiss threshold as lower based on the evidence reviewed. The different thresholds, timing rules and affected-person protection requirement are summarized in practitioner analysis of the revised FADP (breach and representative comparison).

Different enforcement models

The FADP can impose criminal fines of up to CHF 250,000, primarily on responsible natural persons for qualifying intentional violations. GDPR administrative fines generally target organizations and, for the upper tier, can be calculated by reference to worldwide annual turnover. Swiss legal commentary contrasts these enforcement models and cautions that they are structurally different rather than directly comparable (Swiss legal guide).

The lower numerical ceiling under Swiss law should not be read as low personal or organizational risk. Conversely, individual exposure does not mean that an executive, privacy officer or engineer will automatically be personally liable after an incident.

A proportionate governance response should:

identify accountable owners;
define who receives incident alerts;
establish escalation thresholds;
preserve investigation and decision records;
ensure decision-makers receive material risk information;
provide rapid access to legal, security and operational expertise; and
report unresolved issues to appropriate executives.

These are governance controls intended to support compliance and defensible decisions; they do not predetermine legal liability.

Dual-regime incident workflow

Contain the incident and preserve evidence. Secure systems while retaining logs needed to investigate.
Determine whether personal data is involved. Include prompts, uploaded documents, outputs, account records and telemetry.
Identify jurisdictions and roles. Establish which entities are controllers or processors and which regulators may be relevant.
Start both risk tests immediately. Do not wait for the Swiss and GDPR conclusions to converge.
Track the GDPR clock. Record when each relevant entity became aware and when material facts changed.
Evaluate the Swiss high-risk threshold. Consider sensitivity, scale, consequences, identifiability and protective measures.
Assess notification to affected people. Apply each framework’s requirements independently.
Coordinate processor notices. Contractual processes should support rapid fact sharing without requiring complete certainty first.
Document the decision. Record what was known, why notification was or was not made and who approved the outcome.
Remediate and review. Update controls, DPIAs, vendor terms and model processes where necessary.

The same event can produce different notification conclusions under the two regimes.

A GDPR-to-FADP gap checklist for AI providers and buyers

An organization with a functioning GDPR program should not rebuild everything for Switzerland. It should perform a documented gap assessment and add Swiss-specific decisions where needed.

Priority 1: Confirm scope, roles and ownership

[ ] Identify processing activities with effects in Switzerland.
[ ] Record whether Swiss users are deliberately targeted or monitored.
[ ] Separate provider, host, integrator, customer and end-user activities.
[ ] Assess controller, joint-controller and processor roles by processing stage.
[ ] Document why the FADP, GDPR or both may apply.
[ ] Assign an owner and review date to each conclusion.

Role documentation is a recommended governance measure unless a specific legal duty requires a particular record in the circumstances. It should reflect the actual allocation of purposes and decision-making rather than contractual labels alone.

Priority 2: Assess representatives separately

[ ] Test all Swiss representative conditions individually.
[ ] Record the extent, regularity and risk of Swiss processing.
[ ] Separately assess GDPR scope and EU representation.
[ ] Confirm that any representative has the required location, mandate and access to relevant records.
[ ] Revisit the analysis after material changes to markets, data or decision consequences.

Priority 3: Adapt Swiss-facing transparency

[ ] Identify the controller, purposes, data categories and recipients.
[ ] Explain where submitted data originates and how it is used.
[ ] State whether prompts, documents, outputs or feedback are retained.
[ ] Disclose whether customer material is used for training, evaluation or service improvement.
[ ] Explain relevant human access.
[ ] Describe destination countries and applicable safeguards or exceptions where required.
[ ] Tell users when they are interacting with a machine where relevant.
[ ] Provide appropriate notice for profiling and qualifying automated decisions.

Priority 4: Complete processing records

[ ] Map data flows across collection, training, fine-tuning, inference, monitoring and deletion.
[ ] List model providers, infrastructure providers and subprocessors.
[ ] Document processing and access locations.
[ ] Identify retention periods and deletion procedures.
[ ] Record security controls and access groups.
[ ] Identify rights-request and incident channels.
[ ] Verify the complete legal test before relying on any small-business or low-risk exemption.

A lifecycle-level inventory may exceed the minimum legal record in some circumstances, but it is a useful method for making AI data flows visible and supporting notices, DPIAs, vendor oversight and incident response.

Priority 5: Test automated-decision procedures

[ ] Identify outputs that determine or materially influence legal or similarly significant outcomes.
[ ] Distinguish recommendations from decisions.
[ ] Test whether human review is genuine and capable of changing an outcome.
[ ] Train reviewers to challenge the model rather than rubber-stamp it.
[ ] Provide a workable human-review route where required.
[ ] Retain enough relevant information to investigate disputed outcomes, subject to necessity and retention limits.
[ ] Assess statutory conditions and exceptions for the specific decision context.

Priority 6: Apply Swiss DPIA and escalation rules

[ ] Screen for high-risk processing before procurement or deployment.
[ ] Consider sensitive data, extensive profiling, scale, novelty and consequential decisions.
[ ] Document safeguards and residual risk.
[ ] Record Swiss and GDPR trigger analyses separately.
[ ] Assess whether FDPIC consultation is required.
[ ] Verify the role and independence of any Swiss data protection adviser.
[ ] Reassess after material changes rather than assuming the original analysis remains valid.

Priority 7: Prepare Swiss breach escalation

[ ] Add the FADP high-risk test to the incident playbook.
[ ] Route AI incidents to privacy, security and operational owners promptly.
[ ] Track the GDPR deadline independently.
[ ] Include prompt leakage, exposed model logs and unauthorized training reuse in incident exercises.
[ ] Define how the organization assesses whether affected people need information for their protection.
[ ] Preserve decisions and material executive escalations.
[ ] Ensure processors can provide relevant facts without avoidable delay.

Priority 8: Control international transfers

Swiss transfers require an adequate level of protection or another applicable safeguard, such as approved contractual clauses, depending on the destination and circumstances. Secondary analysis of the revised FADP identifies adequacy and contractual safeguards as important transfer routes (EY transfer overview). Organizations should verify current destination status, safeguard requirements and exceptions against current official Swiss materials.

Map more than storage. Relevant flows may include:

support and administrative access;
model inference in another country;
telemetry and diagnostics;
evaluation datasets;
subprocessors;
disaster recovery and backups; and
onward disclosures.

The evidence reviewed reports that EU adequacy for Switzerland facilitates EEA-to-Switzerland transfers. That does not eliminate processor-contract requirements, security duties, transparency, role allocation, purpose controls, retention controls, subprocessor diligence or analysis of onward transfers from Switzerland to another country (current Swiss AI and adequacy commentary).

For example, an EU customer may transfer data to a Swiss service under the applicable adequacy framework. If the Swiss provider then gives an overseas model or support provider access, that onward flow requires a separate assessment. The appropriate route depends on the destination, recipient, access model and current legal framework; no hosting configuration or contract clause guarantees compliance.

AI vendor questionnaire

Procurement teams should ask vendors to answer the following questions in writing.

Data use

Are prompts, uploaded files, outputs or feedback retained?
Are they used to train, fine-tune, evaluate or improve any model?
Is customer data used only for the customer’s service or also for provider purposes?
Can training or improvement uses be disabled?
Does a change in model provider alter how customer information is used?

Human and organizational access

Can provider personnel review prompts, files or outputs?
For which purposes and under which access controls?
Can subcontractors or support teams access the information?
Are privileged, confidential, health or employment records handled differently?
Are access events logged and reviewed?

Locations and subprocessors

Where is data stored and otherwise processed?
From which countries can personnel access it?
Which subprocessors participate in hosting, support, monitoring or model operation?
How are customers notified of subprocessor changes?
Which transfer safeguard supports each relevant flow?
Can customers object to or terminate following material changes?

Retention and deletion

What are the retention periods for prompts, files, logs, backups and outputs?
Can customers configure shorter periods?
How are deletion requests implemented and verified?
What remains in backups, evaluation datasets or trained parameters?
What happens to customer data when the agreement ends?

Security and incidents

Which technical and organizational controls protect the service?
How are customer environments and datasets separated?
What testing addresses model-specific leakage or extraction risks?
How quickly will the vendor notify the customer of an incident?
Which contact channel operates outside normal business hours?
What evidence will be provided for risk and notification decisions?
How will the vendor preserve relevant logs during an investigation?

These questions are recommended due-diligence controls, not a claim that every item is a categorical statutory requirement.

A contract should not merely declare the vendor “FADP and GDPR compliant.” Depending on the parties’ roles and the processing, it should address instructions, permitted purposes, training reuse, confidentiality, security, subprocessors, transfers, assistance with rights, incident notification, return and deletion. The precise mandatory clauses must be determined under the applicable law and architecture.

Four worked examples

1. Swiss-only customer-support chatbot

A Swiss company deploys a chatbot for ordinary customer questions, without deliberately serving the EU or monitoring behavior there. The FADP is the primary privacy framework. The company should define purposes, minimize inputs, disclose machine interaction where relevant, control retention and training reuse, govern the provider and establish incident procedures.

A DPIA is not automatic. Its necessity depends on the data, scale, functions and potential effects on people.

2. Swiss recruitment platform serving EU employers

A Swiss vendor markets applicant-ranking software to employers in France and Germany. The service may be subject to both the FADP and GDPR, with a separate EU AI Act assessment.

The provider should examine EU representation, applicant transparency, profiling, meaningful human review, DPIA triggers, employment-law overlays and the division of responsibility between vendor and employer. A ranking tool reviewed by recruiters should not be treated as equivalent to an automatic rejection system without examining how the workflow actually operates.

3. US model provider processing high-risk Swiss data

A US provider regularly processes extensive Swiss patient information or consequential applicant profiles. Its activities may have effects in Switzerland.

It should assess every Swiss representative condition, transfer safeguards, DPIA issues, deletion, human access, subprocessors and Swiss incident escalation. Neither foreign incorporation nor US hosting determines the outcome by itself.

4. EU customer using Swiss hosting and an overseas subprocessor

An EU professional-services firm sends client information to a Swiss-hosted AI service. Switzerland’s adequacy status may facilitate the EEA-to-Switzerland leg.

If an overseas model or support provider can access the information, the parties must separately assess the onward transfer, professional-secrecy obligations, processor terms, security, notices and incident channels. Swiss hosting alone does not resolve those questions.

Check the sector overlay

The federal FADP is not always the whole picture. Separate analysis may be required for:

employment and workplace monitoring;
healthcare, medical devices and patient confidentiality;
banking, insurance, credit and financial supervision;
legal, medical or other professional secrecy;
telecommunications and online tracking;
critical infrastructure and information-security obligations;
federal authorities; and
cantonal or communal public-sector bodies.

Switzerland has federal and cantonal data-protection regimes. The FADP governs private entities and federal bodies, while cantonal and communal authorities generally fall under cantonal law. Related federal and sector-specific rules also operate in areas such as telecommunications, medicine, finance and critical infrastructure (comparative Swiss legislation guide).

Label the status of each control

A useful gap register separates four categories:

Binding law: Statutory or regulatory duties applying to the service.
Official FDPIC expectations: Regulator interpretations informing how the FADP applies to AI.
Recommended risk controls: Measures such as periodic DPIA review, model documentation or enhanced logging.
Unresolved interpretations: Issues requiring current legal advice, including role allocation, inferred sensitive attributes, model training, pseudonymization and meaningful human review.

This classification should appear in working records, not only policy documents. It helps prevent a prudent control from being presented as a universal legal mandate—or a regulator expectation from being dismissed as optional operational advice.

Frequently asked questions

Does GDPR compliance automatically satisfy Switzerland’s FADP?

No. The frameworks share many operational concepts, so GDPR compliance can substantially reduce the implementation work. The FADP nevertheless has its own territorial, representative, automated-decision, breach, governance and enforcement rules.

An organization should document a Swiss-specific gap assessment rather than treating GDPR status as proof of FADP compliance. The revised law was designed partly to align Swiss protection with the GDPR while retaining deviations requiring Swiss additions.

Can the FADP apply to an AI company with no office in Switzerland?

Yes. The FADP can apply to circumstances initiated abroad when they have effects in Switzerland.

Deliberately offering an AI service to people in Switzerland or monitoring their behavior there are relevant examples. An incidental Swiss user or a particular server location should not be treated as a conclusive test without examining the processing, affected people and overall Swiss effects.

When must a foreign AI provider appoint a representative in Switzerland?

A foreign private controller must appoint a Swiss representative only when the cumulative conditions are satisfied: the processing concerns people in Switzerland in connection with offering goods or services or monitoring behavior, is extensive and regular, and creates high risk.

FADP applicability alone does not make appointment automatic. Where appointment is required, the representative must be established or resident in Switzerland and acts as a contact for data subjects and the FDPIC. The provider must separately assess EU representation.

Does every AI service or profiling system require a DPIA?

No. The Swiss trigger is planned processing likely to create a high risk to personality or fundamental rights.

Extensive profiling, sensitive or biometric information, large-scale processing, significant automated decisions and novel or unpredictable processing can be risk indicators, but they should not be applied as automatic rules without context.

Where high risk is likely, the DPIA should address purposes, actors, data flows, necessity, proportionality, risks, safeguards and residual risk before deployment.

Does Switzerland have an AI Act comparable to the EU AI Act?

On the evidence reviewed as of 8 August 2026, Switzerland does not have a comprehensive horizontal AI statute equivalent to the EU AI Act. It instead relies on technology-neutral laws such as the FADP, official guidance and sector-specific regulation. Announced implementation plans or consultations should not be described as enacted legislation.

The EU AI Act is a separate regime. A Swiss provider may need to assess it independently when offering an AI system in the EU, serving EU customers or otherwise falling within its scope.

The final takeaway has two parts. First, GDPR readiness gives an AI provider a substantial operational foundation, but expansion into Switzerland still requires a documented FADP gap assessment. Second, services operating across Switzerland and the EU should build one coordinated privacy program while preserving separate decisions for territorial scope, representatives, DPIAs, automated decisions, incidents, transfers and enforcement exposure.

High-risk, cross-border and sector-regulated deployments require current, fact-specific legal advice. A checklist can improve consistency; it cannot guarantee compliance.