Feature 6 August 2026

When AI Services Cross the Swiss–EU Privacy Border

Priya Ellison

The short answer: aligned privacy regimes, not interchangeable rulebooks

Compliance with the EU General Data Protection Regulation does not automatically make an AI service compliant with Swiss data-protection law. GDPR readiness is a strong operational starting point, but Switzerland has an independent statute, regulator, territorial rule, terminology, representation test, transfer framework, and enforcement structure.

Switzerland’s principal federal personal-data law is the revised Federal Act on Data Protection, commonly called the FADP or revFADP. It and its implementing ordinances took effect on 1 September 2023. The revision substantially aligned Swiss protections with the GDPR while retaining Swiss-specific differences. It also limited the law’s protection to personal data relating to natural persons, unlike the former law, which also covered legal persons. DLA Piper summarizes the revision, effective date, scope change, and relationship with the GDPR.

The two regimes share important operational foundations, including transparency, purpose controls, proportionate or minimized processing, security, retention discipline, privacy by design and default, documentation, and mechanisms for individual rights. An AI provider with a mature GDPR program can therefore reuse much of its control environment. The European Parliamentary Research Service identifies purpose limitation, data minimisation, transparency, individual rights, privacy by design, and accountable risk management as central GDPR considerations for AI systems. Its study examines how those requirements interact with AI development and use.

Substantial alignment is not legal equivalence. Providers should separate at least four questions:

Territorial scope: Does the FADP, GDPR, or both apply?
Local representation: Must an overseas controller appoint a representative in Switzerland, the EU, or both?
International transfers: Is personal data being disclosed abroad, and what supports that disclosure?
Substantive compliance: Do the service’s collection, training, inference, profiling, retention, security, and rights practices comply with every applicable regime?

A “yes” to one question does not answer the others. The FADP may apply to a foreign provider even when the narrower conditions for mandatory Swiss representation are not met. Similarly, Switzerland’s EU adequacy status can facilitate an EEA-to-Switzerland transfer without deciding whether the GDPR applies to the provider or whether the processing itself is lawful.

Neither the FADP nor the GDPR is exclusively an AI law. Each becomes relevant when an AI activity processes personal data within its material and territorial scope. A system using only genuinely non-personal industrial information may fall outside both privacy regimes. A system trained on identifiable support transcripts, used to rank applicants, or configured to retain user prompts may fall within one or both.

The practical method is to:

determine which jurisdictions connect to the service;
map personal data through the complete AI lifecycle;
classify sensitive data, profiling, monitoring, and consequential uses;
assign controller, processor, and subprocessor roles;
analyze each international disclosure; and
document a Swiss delta against the existing GDPR program.

That is more reliable than asking whether Swiss law is simply “lighter” or “stricter” than the GDPR.

Which law applies? A territorial-scope decision tree

Territorial analysis should begin with facts rather than the provider’s incorporation label. Record:

where the provider and relevant customers are established;
where affected people are located;
which markets the provider deliberately serves;
how the product is marketed, priced, distributed, and supported;
whether behavior is monitored;
where personal data is collected and processed; and
whether overseas processing produces effects in Switzerland.

Step 1: Does the activity process personal data?

Personal data is information relating to an identified or identifiable natural person. In an AI service, that can include names and account details, but also applicant histories, prompts, recordings, device information, persistent identifiers, inferred preferences, scores, and model-generated assessments.

If the activity processes no personal data, the FADP and GDPR may not apply to it. That does not make the system unregulated. Product-safety, discrimination, employment, consumer, intellectual-property, confidentiality, cybersecurity, sector-specific, and AI-specific rules may still matter.

A system can also process personal data without either regime applying if neither law’s territorial requirements are met. Material scope and territorial scope are separate inquiries.

Step 2: Does the processing have effects in Switzerland?

The FADP follows an effects principle: circumstances initiated abroad can fall within the Act when they have effects in Switzerland. Server location and corporate domicile are therefore relevant but not conclusive. The FADP’s scope, definitions, principles, and effects rule appear in the Fedlex text.

The linked English Fedlex version is an unofficial translation provided for information only and has no legal force. Determinative wording should be checked against a current official-language version and, where appropriate, regulator guidance.

Relevant facts may include Swiss-directed marketing, contracts with Swiss customers or employers, Swiss onboarding, supported Swiss locations, regular processing concerning people in Switzerland, and product functions designed for the Swiss market. Incidental contact should not automatically be treated as equivalent to deliberate market activity.

FADP applicability does not itself create a duty to appoint a Swiss representative. Representation is governed by a separate cumulative test discussed below.

Step 3: Is the provider connected to the EU?

Switzerland is outside the EU and EEA, so a company is not subject to the GDPR merely because it is Swiss. A Swiss or other non-EU provider may nevertheless enter GDPR scope when it offers goods or services to people in the EU or monitors their behavior there. A provider may also require a separate establishment-based analysis where processing is connected to an EU establishment. This GDPR-and-Switzerland overview summarizes the offering and monitoring triggers for Swiss providers.

Evidence of an EU-directed offer can include:

EU-focused advertising or sales campaigns;
EU countries in a supported-market selector;
country-specific landing pages;
languages used in a market-facing context;
EU currencies or payment arrangements;
EU customer contracts or sales personnel;
onboarding or implementation in EU countries; and
EU-focused distribution partnerships.

Mere technical accessibility from an EU country should not be treated as conclusive evidence of targeting. The assessment should consider the provider’s apparent intention and commercial conduct as a whole.

The four practical outcomes

FADP only. The activity processes personal data in circumstances producing Swiss effects, but no supported GDPR territorial connection is present.

GDPR only. The activity is connected to the EU under the GDPR but does not produce a relevant Swiss effect.

Both regimes. The processing produces effects in Switzerland and also has a supported EU connection, such as an EU-directed offering or behavioral monitoring there.

Neither regime. The activity may use no personal data, or it may process personal data without meeting either regime’s territorial requirements. Other laws can still apply.

Consider a U.S. applicant-ranking provider deliberately marketed to employers in Switzerland and several EU countries. Processing involving Swiss applicants may produce effects in Switzerland and engage the FADP. The deliberate offer to people in EU markets, or relevant monitoring there, may also engage the GDPR. The provider should document separate scope conclusions rather than treating the result as undifferentiated “European privacy compliance.”

FADP versus GDPR: the comparison the evidence supports

The defensible comparison is bounded. The regimes are sufficiently aligned for many operational controls to be reused, but their statutory tests and terminology are not interchangeable. The revised FADP introduced or strengthened privacy by design and default, information duties, conditional impact assessments, processing records, breach duties, and data portability, while maintaining Swiss-specific deviations. A current high-level Swiss legal guide describes those areas of alignment and divergence.

The table below is a scoping aid, not a provision-by-provision legal crosswalk.

Topic	Revised Swiss FADP	Supported GDPR comparison	Practical implication for AI services
Protected data	Protects personal data relating to natural persons.	The supplied GDPR-focused evidence also treats personal data about individuals as the relevant subject matter.	Check whether datasets, prompts, outputs, logs, and inferences relate to identifiable people. Do not rely on descriptions of the former Swiss law protecting legal-person data.
Territorial reach	Can apply to circumstances initiated abroad that have effects in Switzerland.	A non-EU provider may be covered where supported EU offering or monitoring triggers are met; the territorial tests are not identical.	Run separate Swiss and EU analyses.
Core principles	Requires lawful, good-faith, proportionate, purpose-specific, accurate, and retention-limited processing.	GDPR-oriented AI analysis emphasizes purpose limitation, minimisation, transparency, rights, security, and accountability.	Reuse controls where possible, but document the applicable legal rationale and terminology.
Privacy by design and default	Requires technical and organizational protections to be considered during design, with defaults limited to necessary processing.	GDPR-focused evidence treats privacy by design and default as central to responsible AI processing.	Connect privacy controls to architecture, feature selection, access, retention, and release gates.
Transparency	The revised framework includes broader information duties under Swiss law.	The GDPR has its own information requirements, including in AI contexts involving profiling and automated processing.	Maintain operationally consistent notices, but review them separately under each regime.
Processing records	Controllers and processors generally keep processing records. A possible exemption may apply to entities with fewer than 250 employees where processing poses negligible risk.	The supplied evidence does not support a detailed comparison with the GDPR exemption structure.	Do not import a GDPR recordkeeping conclusion into the Swiss analysis.
Risk assessment	Higher-risk processing can require enhanced assessment, including consideration of a Swiss DPIA under the applicable provisions.	GDPR-oriented AI analysis also uses preventive, risk-based assessment, but the exact triggers require separate verification.	Screen the same project under both regimes without assuming that one assessment automatically resolves both tests.
Profiling	Expressly defines profiling and high-risk profiling.	GDPR analysis also addresses profiling, but under its own definitions and safeguards.	Classify the actual activity under each law rather than applying a generic “AI profiling” label.
Representatives	Certain foreign private controllers must appoint a Swiss representative only when cumulative statutory conditions are met.	EU representation is a separate question that requires its own current GDPR analysis.	A provider may need a Swiss representative, an EU representative, both, or neither.
International disclosures	Require adequate protection, recognized safeguards, or an applicable statutory exception.	The GDPR has a distinct international-transfer framework.	Analyze each transfer leg under the law governing the exporting activity.
Regulation and enforcement	The federal regulator is the Federal Data Protection and Information Commissioner. Secondary legal summaries describe Swiss sanctions as focusing substantially on responsible individuals.	The GDPR uses a different supervisory and enforcement structure.	Maintain distinct escalation and regulatory-response procedures; do not reduce the comparison to maximum fines.

The Swiss principles, definitions, design duties, recordkeeping rule, processor conditions, representative threshold, and foreign-disclosure framework are set out in the FADP. The same source also confirms that the English version is informational rather than legally controlling. See the current Fedlex text for the supported statutory framework.

These differences do not prove that either regime is categorically stricter or more lenient. One rule may be narrower while another is structured differently. The practical burden depends on the provider’s role, data, purposes, scale, users, architecture, contractual position, and risk.

Before making definitive comparisons, obtain current primary-law or regulator support for:

exact security-breach thresholds and timing;
safeguards for automated individual decisions;
Swiss and GDPR DPIA triggers;
detailed lawful-processing and justification models;
employee, applicant, health, and biometric uses;
sanctions and allocation of responsibility; and
sector-specific duties layered over general privacy law.

Map privacy obligations across the AI lifecycle

AI privacy reviews often begin too late. Teams inspect the output screen while overlooking collection, training, retrieval, logging, vendor access, and human review. A defensible assessment follows personal data through every technical layer.

Collection and ingestion

Document each source, including customer uploads, applicant forms, connected business systems, licensed datasets, public material, support conversations, telemetry, recordings, and third-party enrichment.

For each source, record:

the personal-data categories;
the affected people;
the collection purpose;
who supplied the information;
whether the collection was expected;
whether sensitive data may appear; and
whether the provider proposes a new use.

Training and fine-tuning

Document the proposed reuse, its purpose, the people affected, the necessity of identifiable information, and less intrusive alternatives.

Purpose limitation and minimisation should not be reduced to dataset size. Review whether identity is necessary, whether less granular features would work, whether sensitive proxies are present, who can access the data, how long it remains useful, and whether a less intrusive process can achieve the same objective.

Retrieval, embeddings, and vector stores

Retrieval-augmented systems may transform source documents into embeddings, indexes, caches, or vector databases.

Ask whether a record can be linked to a person through account identifiers, document references, metadata, search results, surrounding records, or access to the source text. Map deletion dependencies across the source system, index, cache, generated output, and backup environment.

Prompts, inference, and outputs

Prompts may contain employee concerns, health details, financial information, complaints, names, or confidential narratives. Review not only the visible prompt field but also attachments, system prompts, tool calls, API payloads, conversation memory, temporary caches, and abuse-monitoring records.

High-consequence outputs need processes for accuracy review, correction, provenance, challenge, and meaningful human oversight. Confidence of expression is not evidence of reliability.

Logging, monitoring, and human review

Operational logs can preserve prompts, outputs, user identifiers, IP information, timestamps, feedback, error traces, and moderation results. Security and debugging can justify useful records without justifying indefinite retention or unrestricted access.

Define:

which logs are necessary;
which fields can be omitted or masked;
which uses are security-related rather than analytical;
who can access the records; and
when deletion or backup expiration occurs.

Reviewers may work for another company, use an annotation platform, export records, or operate from another country. Record their location, access boundaries, confidentiality terms, instructions, escalation paths, and whether reviewed content later enters training data.

Retention, deletion, and model updates

Use retention rules by data layer rather than one broad period for the entire service. Source files, fine-tuning records, prompt histories, embeddings, outputs, evaluation datasets, support tickets, security logs, and backups may follow different paths.

Do not promise that deleting a source record will “unlearn” all model influence unless the architecture and process support that statement. Distinguish among:

deletion from active databases;
removal from retrieval indexes;
exclusion from future training;
expiration from backups;
deletion of prompts and outputs; and
technically feasible model-level remediation.

Do not accept labels at face value

“Anonymous,” “synthetic,” “aggregated,” and “pseudonymized” describe different conditions, not automatic exemptions.

Practical transparency

A useful AI privacy notice should explain:

the service’s purpose;
the main categories and sources of personal data;
significant uses, including material training uses;
relevant profiling or evaluation;
recipient and service-provider categories;
the retention approach;
important limitations; and
how people can exercise applicable rights.

It should allow a reasonable person to understand what happens to their information and what the system is intended to do.

In hiring, one workflow may ingest resumes, infer work-history characteristics, produce suitability scores, log candidate interactions, and retain recruiter decisions. Treating only the final score as personal data misses most of the regulated flow.

Profiling, sensitive data, consent, and higher-risk AI uses

An AI system does not perform profiling simply because it uses machine learning. Under the FADP, profiling is automated processing of personal data used to evaluate, analyze, or predict personal aspects such as work performance, health, preferences, reliability, behavior, location, or movements. High-risk profiling is narrower: it involves profiling that poses a high risk to personality or fundamental rights through data matching that permits assessment of essential aspects of personality.

That creates three practical categories:

Personal-data processing without profiling. A transcription service might convert a named person’s speech into text without evaluating a personal aspect.
Profiling that is not necessarily high-risk profiling. A recommendation feature might infer preferences without crossing the higher statutory threshold.
Potential high-risk profiling. Extensive matching of datasets to assess essential aspects of work suitability, health, reliability, or behavior requires closer analysis.

Classification depends on what the system does, not how it is marketed.

Sensitive personal data

Supported FADP categories include information concerning:

religious, ideological, political, or trade-union beliefs or activities;
health;
private life;
race or ethnicity;
genetic data;
biometric data uniquely identifying a person;
administrative or criminal proceedings and sanctions; and
social-assistance measures.

AI systems may receive these categories directly or infer them from other inputs.

Consent is not the default answer

The FADP does not require consent for every processing operation. The analysis instead considers the statutory processing principles, any infringement of personality, and available justification where one is needed.

When consent is used, it must be voluntary, informed, and specific. The cited Swiss framework requires express consent in specified circumstances involving sensitive personal data and high-risk profiling by a private person. UC Berkeley’s institutional overview summarizes the supported consent conditions and cautions that consent is not universally required.

A checkbox does not resolve necessity, proportionality, security, transparency, discrimination, or employment-law concerns.

Risk signals requiring enhanced review

More intensive screening is appropriate where a service involves:

extensive or persistent monitoring;
sensitive-data processing;
matching information from multiple sources;
potential high-risk profiling;
biometric identification or analysis;
health or behavioral inference;
location tracking;
scoring that materially affects opportunities;
employees, applicants, patients, or vulnerable groups;
training on records collected for another purpose; or
limited ability to understand or challenge an output.

These factors may indicate the need for a DPIA or another enhanced assessment, but none should be treated as automatic proof that a statutory threshold has been crossed. The applicable FADP and GDPR tests require current, fact-specific review.

In hiring, resume ranking may be profiling when it evaluates or predicts work performance or suitability. Adding health indicators, uniquely identifying biometrics, behavioral signals, or location history can increase sensitivity and risk.

The precise Swiss safeguards for automated individual decisions, and their comparison with GDPR Article 22, cannot be established conclusively from the supplied evidence. Teams should distinguish scoring, recommendations, human-in-the-loop workflows, and decisions made solely through automated processing.

Representatives, processors, and the AI vendor chain

A foreign AI provider does not need a Swiss representative merely because one person in Switzerland opens an account. The statutory test is cumulative.

A private controller outside Switzerland must assess whether its processing:

concerns people in Switzerland;
relates to offering goods or services in Switzerland or monitoring behavior there;
occurs regularly;
occurs on a large scale; and
poses a high risk to the personality or fundamental rights of affected people.

All conditions matter. A foreign provider can fall within the FADP’s effects-based scope without meeting the narrower representation threshold.

A Swiss representative functions as a contact point for affected people and the Federal Data Protection and Information Commissioner and supports availability of the controller’s processing record when requested. Swiss and EU representation are separate: a provider covered by both regimes may require different appointments if each regime’s conditions are satisfied. This representation overview describes the cumulative Swiss test and the representative’s supported functions.

Map the chain before assigning roles

An AI service may involve:

the employer or other customer;
the AI application provider;
a foundation-model or API provider;
a cloud host;
an analytics or observability provider;
an annotation or human-review vendor;
identity, moderation, or security vendors;
customer-support personnel; and
affiliates with remote access.

Do not label every vendor a processor by default.

An application provider might process applicant records on an employer’s instructions while separately determining how it handles account administration, security, or model improvement. Contracts and notices should not hide those different purposes inside one generic description.

Under the FADP, a processor may perform only processing the controller could lawfully perform, must maintain appropriate security, and requires the controller’s prior approval before appointing a subprocessor. A practical approval process should provide enough information about the subprocessor’s function, location, access, and transfer implications for the controller to evaluate the change.

AI vendor-review checklist

Before deployment, ask:

What purposes and instructions govern the service?
Which data can enter prompts, files, logs, and outputs?
How long are prompts and outputs retained?
Can customer information be used for training, fine-tuning, evaluation, or product improvement?
Is secondary training disabled by default or configurable?
Which security measures apply?
Which subprocessors are used, and how are changes approved?
Where do inference, storage, logging, backups, and support occur?
Can overseas personnel access production data?
How does the vendor support access, correction, deletion, export, and objection requests?
What happens to embeddings, caches, logs, and backups after source deletion?
How quickly must the vendor escalate a suspected incident?
What assessment, audit, or assurance evidence is available?
What happens to personal data at termination?

Contract language must match technical reality. A statement that data is “not stored” is misleading if abuse logs, observability systems, backups, or support tools retain it elsewhere.

International transfers, adequacy, and the data-localization myth

The FADP does not impose a universal requirement that personal data, model training, or inference remain in Switzerland. Foreign disclosures require adequate protection, recognized safeguards, or an applicable statutory exception.

That is not blanket permission to use any region or provider. Sectoral secrecy, national-security requirements, regulated-industry rules, customer contracts, and risk-based restrictions may still limit data location or overseas access. A Swiss compliance overview describes the absence of a general localization rule and the possible effect of sectoral and contractual restrictions.

What EU adequacy for Switzerland does

The EU recognizes Switzerland as providing adequate data protection. This reduces transfer friction for personal data moving from the EEA to Switzerland because the Swiss destination is not treated like a destination lacking adequacy.

What adequacy does not do

Adequacy does not:

decide whether the GDPR applies;
establish that collection, profiling, retention, or training is lawful;
replace transparency or security duties;
assign controller and processor roles;
satisfy rights-handling requirements;
authorize unrelated onward transfers; or
prove complete compliance with either regime.

Adequacy is a transfer pathway, not a general compliance certificate.

Identified mechanisms for other Swiss transfers include appropriately adapted EU standard contractual clauses and, for eligible certified U.S. recipients, the Swiss-U.S. Data Privacy Framework. These mechanisms have conditions and are not universal solutions. DataGuidance summarizes EU adequacy, adapted contractual clauses, and the Swiss-U.S. framework as distinct Swiss transfer routes.

Build an AI-specific data-flow diagram

The diagram should identify:

collection and upload locations;
training and fine-tuning environments;
inference regions;
vector stores and retrieval indexes;
prompt and output logs;
analytics and observability systems;
human-review locations;
backups and disaster-recovery regions;
remote support access;
every processor and subprocessor; and
onward disclosures among vendors.

Do not stop at the customer-facing region selector. A product advertised as hosted in Switzerland or the EEA may still send prompts to a model API elsewhere, copy logs into a global monitoring service, or permit support access from another country.

Consider a Swiss hiring platform using an EEA cloud provider and a model vendor in a country without a Swiss adequacy finding:

applicant information enters the Swiss platform;
platform records are processed by the EEA cloud provider; and
selected resume text or prompts are sent to the model vendor.

Each leg needs its own purpose, role, security, and transfer analysis. The EEA cloud arrangement does not legitimize the later model-vendor disclosure. A contractual transfer mechanism also does not answer whether sending applicant data for that purpose is proportionate and transparent.

Before deployment, verify the current Swiss adequacy list, recognized safeguards, contractual adaptations, recipient status, onward transfers, and sector-specific restrictions.

A practical Swiss delta checklist for GDPR-based AI programs

A mature GDPR program should be reused rather than discarded. The objective is a Swiss delta register showing what carries over, what requires different terminology or legal analysis, and what must be added.

1. Create a jurisdiction file

Record evidence concerning:

Swiss effects;
user and customer locations;
corporate establishments;
Swiss- and EU-directed marketing;
supported countries and currencies;
sales and distribution channels;
onboarding restrictions;
behavioral monitoring;
processing locations; and
locations where outputs are used.

State separate conclusions for FADP scope, GDPR scope, Swiss representation, EU representation, and international transfers.

2. Inventory personal data by technical layer

Cover source and evaluation datasets, fine-tuning data, prompts, uploads, model inputs and outputs, embeddings, retrieval indexes, telemetry, moderation records, security logs, human-review platforms, support systems, backups, and vendor environments.

Maintain lineage sufficient to identify where a person’s information has propagated.

3. Classify each use case

Classify activities as:

ordinary personal-data processing;
sensitive-data processing;
profiling;
potential high-risk profiling;
behavioral monitoring;
potentially consequential automated processing; or
genuinely non-personal processing.

A single product can contain several categories. Authentication, model inference, fraud scoring, and applicant ranking should not receive one blanket label.

4. Build the Swiss delta register

Translate existing controls into review fields for:

FADP terminology;
effects-based territorial scope;
lawfulness, good faith, and proportionality;
purpose specification;
sensitive personal data;
profiling and potential high-risk profiling;
Swiss transparency requirements;
processing records and any claimed exemption;
Swiss representative analysis;
processor and subprocessor approval;
Swiss transfer mechanisms;
regulator response; and
accountability under the Swiss enforcement structure.

Assign an owner, evidence, remediation, open question, and review date to every row.

5. Document privacy by design and default

Record architectural and product choices such as:

restricting collection to relevant fields;
using less granular features;
avoiding identity where unnecessary;
applying pseudonymization where useful;
setting short default retention;
limiting access by role;
separating production and training environments;
disabling secondary training unless justified;
preventing sensitive fields from entering prompts;
providing human review for consequential outputs; and
testing deletion across source records, indexes, logs, and backups.

6. Establish risk screening and escalation

Escalate appropriate matters to privacy specialists and qualified counsel, including:

sensitive or biometric data;
employee or applicant monitoring;
extensive behavioral tracking;
potential high-risk profiling;
health, reliability, or work-performance inference;
new training uses;
matching across datasets;
consequential scoring;
uncertain automated-decision safeguards;
possible DPIA triggers; and
regulated-sector deployments.

One screening process can collect facts for both Swiss and GDPR reviews, but it should not assume their legal tests are identical.

7. Review contracts and vendor operations

Verify instructions, purpose boundaries, security, prompt and output retention, training settings, subprocessor approval, foreign access, deletion assistance, rights support, audit evidence, and incident escalation.

Repeat the review when a vendor changes its model, hosting region, retention terms, training policy, or subprocessor list.

8. Operationalize individual rights

Create intake, identity-verification, search, response, and escalation workflows for applicable requests involving access, correction, deletion, portability, objection, complaints, and review of relevant outcomes.

The workflow should distinguish business databases from prompts, logs, vector stores, fine-tuning sets, outputs, and backups. Avoid unsupported promises that deletion will produce complete model unlearning.

9. Keep AI Act and privacy assessments connected but separate

The EU AI Act is not another name for the GDPR. Privacy law addresses personal-data processing; the AI Act governs covered AI systems and general-purpose AI models under its own scope and risk structure. A service may face both layers, only privacy law, or AI Act duties without processing personal data. A law-firm comparison explains the distinct material and territorial approaches of the GDPR and EU AI Act.

Use one system inventory and data-flow map, but make separate determinations for:

FADP applicability;
GDPR applicability;
EU AI Act applicability;
system or model classification;
provider, deployer, importer, and other roles;
privacy risk; and
broader safety and fundamental-rights risk.

10. Maintain evidence and refresh it

Keep dated evidence supporting scope, design, notices, vendor decisions, risk screening, transfer mechanisms, representative conclusions, and rights testing. Revisit the file when the service enters a new market, adds a dataset, changes model providers, enables monitoring, introduces secondary training, or produces more consequential recommendations.

The useful question is not whether Swiss law is generally stricter or lighter than the GDPR. It is whether the provider can show where the service has legal effects, how personal data moves, which forms of profiling and sensitivity are present, who can access the information, and what Swiss additions were made to the GDPR baseline.

This checklist is general information, not legal, HR, or employment advice. Laws, guidance, adequacy decisions, and product facts change. Organizations should confirm current requirements with qualified counsel, especially for DPIAs, automated decisions, breach response, employee or applicant data, regulated sectors, and international transfers.

Frequently asked questions

Does GDPR compliance automatically satisfy Switzerland’s revised FADP?

No. GDPR readiness supplies a useful control baseline, but the FADP is an independent Swiss statute. Providers still need a Swiss review covering territorial effects, proportionality, profiling, records, representation, processor arrangements, transfers, notices, and regulatory response.

Does every foreign AI provider with Swiss users need a Swiss representative?

No. FADP applicability and representation are separate questions. The representative test is cumulative and concerns processing connected with Swiss offerings or monitoring that is regular, large scale, and high risk. A service can produce effects in Switzerland without meeting every representation condition.

Is consent always required when an AI service processes personal data in Switzerland?

No. Swiss law does not make consent universally necessary. When consent is used as the relevant justification, it must be voluntary, informed, and specific; express consent is required in specified circumstances involving sensitive personal data and high-risk profiling by a private person.

Does Switzerland require AI training and inference data to stay inside the country?

Not as a general rule. Foreign disclosures can be supported by adequate protection, recognized safeguards, or an applicable exception. Sectoral secrecy, regulated-industry requirements, contracts, national-security restrictions, and risk decisions may nevertheless limit overseas processing or access.

Can the FADP, GDPR, and EU AI Act all apply to the same AI service?

Yes. The FADP may apply because personal-data processing has effects in Switzerland. The GDPR may apply through a supported EU territorial connection. The EU AI Act may apply under its separate rules for the system, model, market, actors, classification, or use of outputs. The assessments should share an inventory but remain legally distinct.