Feature

How Swiss and EU Privacy Rules Change the Way You Build and Use AI

By Priya Ellison · 4 August 2026

The short answer: FADP and GDPR are aligned, not identical

Switzerland’s closest equivalent to the EU General Data Protection Regulation is the revised Federal Act on Data Protection, usually abbreviated as the FADP. It is Switzerland’s principal federal law governing personal-data processing and has applied since 1 September 2023. The revision strengthened transparency, accountability, data-subject rights, impact assessments, recordkeeping, breach response, supervisory powers, and sanctions while retaining important Swiss departures from the GDPR. DLA Piper summarizes the revision, its effective date, and the need for Swiss-specific additions to GDPR programs.

The FADP is technology-neutral. It does not apply merely because a product is marketed as “AI”; it applies when AI-supported activity processes personal data. The Federal Data Protection and Information Commissioner, or FDPIC, has expressly confirmed that the FADP applies directly to AI-supported processing. The FDPIC explains this technology-neutral application to AI.

At a practical level, personal data is information relating to an identified or identifiable natural person. It can include names and email addresses, but also application records, account identifiers, device data, behavioral observations, inferred preferences, interview evaluations, location histories, and other information that can be connected to a person.

The FADP protects natural persons and establishes principles relevant throughout an AI system’s lifecycle. Processing must be lawful, in good faith, proportionate, connected to a recognizable purpose, and limited in duration. Data should be accurate, and appropriate technical and organizational safeguards should be built into processing and reflected in default settings. Security must be appropriate to risk. These principles, along with the definitions of personal data, profiling, high-risk profiling, and sensitive personal data, appear in the Federal Act on Data Protection published by Fedlex. The available English text is an informational translation and has no legal force.

These features will be familiar to organizations with mature GDPR programs. Both regimes support transparency, security, privacy by design and default, processor oversight, processing records, data-subject procedures, breach response, and impact assessments for qualifying high-risk processing.

The overlap does not make the laws interchangeable. A GDPR lawful-basis assessment cannot simply be relabeled as a Swiss analysis. The two regimes differ in areas such as private-sector processing justification, representatives, profiling, automated decisions, breach thresholds and timing, international transfers, and sanctions.

EU recognition of Switzerland as providing adequate protection is also narrower than substantive equivalence. Adequacy facilitates transfers from the EU to Switzerland; it does not prove that every Swiss obligation matches the GDPR or remove other duties concerning transparency, processors, security, purposes, retention, or regulated data.

Privacy law must also be separated from AI-system regulation. The FADP is not a comprehensive Swiss AI code governing every system regardless of whether it processes personal data. In the EU, the GDPR remains a privacy framework, while the EU AI Act adds a separate risk-based regulatory layer. An organization may therefore need to assess the FADP, GDPR, EU AI Act, and applicable sector rules independently. KPMG describes the GDPR and EU AI Act as complementary parts of EU AI governance.

For an AI service operating across Switzerland and the EU, the comparison should cover:

Territorial scope and the people or markets affected
The legal justification for processing
Controller, processor, representative, advisor, and DPO roles
Ordinary processing, profiling, and high-risk profiling
Important decisions made exclusively by automated means
Transparency to users and other affected individuals
Data protection impact assessments, or DPIAs
Security incidents and jurisdiction-specific notification procedures
International transfers and AI supply chains
Supervisory powers, criminal exposure, and administrative fines

The practical task is not to declare one regime “stricter” in the abstract. It is to determine which rules govern each data flow and then add jurisdiction-specific legal procedures to a shared privacy-control foundation.

When the FADP, GDPR, or both apply to an AI service

Territorial analysis should happen before a pilot—not after a contract has been signed or personal data has entered a model. A provider’s place of incorporation, server label, or website address does not answer the question by itself.

A useful starting point is a three-path decision tree.

Path 1: The service has Swiss effects but no relevant EU-facing activity

Ask whether processing initiated inside or outside Switzerland produces effects in Switzerland. Relevant facts can include whom the service targets, where affected people are located, what the processing does, and whether it monitors behavior connected to Switzerland.

A Swiss employer using an AI assistant only for employees and candidates in Switzerland is a straightforward example. A non-Swiss provider deliberately marketing a personalized service to Swiss users may also create Swiss effects. By contrast, the mere fact that a globally accessible website can be opened from Switzerland should not be treated as an automatic answer to every scope or compliance question.

The FADP’s effects test and its Swiss-representative requirement are related but distinct. A foreign private controller may be within the law’s territorial scope without necessarily having to appoint a Swiss representative.

Path 2: The service has relevant EU-facing processing but no Swiss effects

At a high level, the GDPR may apply to a Swiss or other non-EU provider when it offers goods or services to people in the EU or monitors their behavior there. Relevant facts can include intentional market targeting, supported markets, customer geography, tracking practices, behavioral personalization, and the purposes for which observations are made.

For example, a Swiss provider offering behavior-based personalization to people in several EU countries should conduct a GDPR territorial analysis even if its engineering team and infrastructure remain in Switzerland. Adnovum’s comparison outlines the circumstances in which Swiss businesses may face GDPR obligations.

This is a high-level comparison rather than a complete statement of GDPR territorial rules. Establishment, customer relationships, affected individuals, and actual processing operations all require case-specific review.

Path 3: The service has both Swiss effects and EU-facing activities

Both regimes may apply to the same product, organization, or processing operation.

Consider a Swiss recruitment-scoring provider that serves Swiss employers and also offers its service to employers processing applicants in the EU. Candidate profiles, assessment results, inferred suitability scores, and recruiter activity could fall within the FADP, GDPR, or both, depending on the affected person, service arrangement, relevant establishment, and processing purpose.

The provider and employer must also determine their organizational roles. One party might process prompts solely to produce an output on a customer’s instructions while separately reusing some information for its own evaluation or development purposes. Role allocation remains fact-dependent: contract language, actual purposes, decision authority, technical behavior, settings, and applicable guidance must be assessed together.

When is a Swiss representative required?

A foreign private controller does not need a Swiss representative merely because someone in Switzerland can access its service. The statutory conditions are cumulative. The processing must:

Concern offering goods or services to people in Switzerland or monitoring their behavior there;
Be regular;
Be large-scale; and
Present a high risk to the personality or fundamental rights of affected people.

A representative is a local contact and compliance role. It is not the same as a GDPR data protection officer, a voluntarily appointed Swiss data-protection advisor, or an internal privacy lead. The representative question must be assessed independently from whether those other roles are required or useful. The IAPP discusses the effects test and the cumulative conditions for foreign controllers.

Worked example: A non-Swiss chatbot marketed to Switzerland

Suppose a company outside Switzerland promotes an AI chatbot to Swiss consumers.

First, assess Swiss effects. Examine Swiss-directed advertising, local pricing or language, contractual availability, user numbers, and the location of people whose data the chatbot processes.

Second, identify the processing. Does the chatbot answer isolated questions, or does it build persistent profiles, analyze sensitive conversations, infer health or financial characteristics, or monitor behavior across sessions?

Third, assess regularity and scale. A limited test involving a small user group differs from continuous processing across a substantial customer base. A “pilot” label, however, is not a general exemption from the FADP.

Fourth, assess risk. Relevant questions include:

How sensitive are the prompts and uploaded files?
What could happen if an inference is wrong?
Who can access conversation histories?
Does the system contribute to consequential decisions?
Are customer inputs reused for training, evaluation, or improvement?
Which security and retention controls apply?

Only after completing those steps should the company determine whether the cumulative representative conditions are met. Other FADP obligations may apply even when a representative is not required.

Document the analysis by market and use case, including:

Relevant establishments
User and affected-person locations
Target markets
Processing purposes
Monitoring or behavioral analysis
Data volume and frequency
Sensitive-data involvement
Potential consequences for individuals
Controller and processor roles
Swiss effects and possible GDPR territorial triggers
Representative, advisor, and DPO conclusions

Revisit territorial scope when the provider enters a new market, adds tracking, changes a service purpose, begins independently reusing customer data, or moves from decision support toward automated decision-making.

Side-by-side comparison: the differences that change AI compliance

The FADP and GDPR share enough structure to support a common control environment. The legal analysis underneath those controls, however, cannot always be consolidated.

Issue	FADP position	GDPR position	Practical implication for an AI service
Processing justification	Swiss private-sector processing does not use the same universal lawful-basis structure as the GDPR. Processing must satisfy statutory principles, and justification may be required where processing unlawfully infringes personality rights.	GDPR processing generally requires an applicable lawful basis.	Preserve the GDPR lawful-basis assessment, but add a Swiss review of processing principles, personality-rights effects, and any required justification.
Data-protection leadership	The FADP does not impose a general obligation on every organization to appoint a Swiss data-protection advisor.	A GDPR DPO is not universally required; the applicable triggering conditions must be assessed.	Do not treat either role as automatically mandatory. Determine what is legally required and whether voluntary appointment would improve governance.
Foreign representatives	A foreign private controller may need a Swiss representative when the cumulative targeting or monitoring, regularity, scale, and high-risk conditions are satisfied.	The GDPR has a separate representative framework for certain non-EU organizations.	Conduct separate representative assessments. A DPO is not a substitute for a representative.
Processing records	Controllers and processors generally maintain records, subject to possible exceptions established for legal entities with fewer than 250 employees whose processing presents negligible risk.	The GDPR has its own recordkeeping requirements and exceptions.	A GDPR inventory is a strong baseline, but Swiss coverage and any exception must be confirmed.
Processor governance	A processor may act only within what the controller may permit, must be capable of guaranteeing appropriate security, and needs prior controller approval before assigning processing to a third party.	GDPR processor arrangements are subject to their own requirements.	Reuse vendor-review and contract workflows, but do not assume a clause-by-clause match.
Transparency	Individuals must receive appropriate information about relevant processing.	Transparency is also central to the GDPR, subject to its own notice requirements.	Use a common notice framework with jurisdiction-specific fields instead of assuming one template is complete everywhere.
Sensitive data	Swiss categories include health, genetic and uniquely identifying biometric data, data about administrative or criminal proceedings and sanctions, and social-assistance measures.	GDPR special-category and criminal-offence rules have their own categories and structure.	Data classification must recognize Swiss-specific categories rather than relying solely on a GDPR taxonomy.
Profiling	The FADP distinguishes profiling from high-risk profiling and contains express-consent requirements in specified circumstances.	GDPR profiling requires its own assessment under applicable GDPR rules.	Do not treat every score as legally equivalent or assume all profiling requires consent.
Automated decisions	An important individual decision made exclusively through automated processing can trigger notice and human-review consequences.	The GDPR has a distinct framework for certain solely automated decisions.	Record whether the system recommends, ranks, gates, or determines the outcome, and evaluate whether human involvement is substantive.
Breach response	Notification to the FDPIC uses a high-risk threshold and an “as soon as possible” standard.	A qualifying GDPR supervisory notification uses a different risk test and is generally subject to a 72-hour period.	Maintain separate decision paths and clocks.
Sanctions	Certain intentional violations can expose responsible individuals to criminal fines.	GDPR administrative fines can be imposed on organizations.	Preserve decision records and clear approval authority; do not collapse the enforcement models into one risk score.

The Swiss positions on processing principles, sensitive-data categories, profiling, processor approval, records, and representatives are grounded in the FADP itself. Fedlex provides the statutory definitions and requirements summarized in the table.

Processing justification deserves particular attention. A GDPR team may be accustomed to asking first whether consent, contract, legitimate interests, legal obligation, or another lawful basis applies. Swiss private-sector analysis starts from a different structure. That does not mean processing is unrestricted: statutory principles, transparency, sensitive-data rules, personality protections, and any necessary justification still matter. GDPR Register provides a bounded comparison of the Swiss private-sector structure and GDPR lawful-basis approach.

Governance titles are another frequent source of confusion:

A controller determines the purposes and means of relevant processing.
A processor processes data on a controller’s behalf within the permitted arrangement.
A Swiss representative is a local role required for certain foreign controllers.
A Swiss data-protection advisor is not universally mandatory.
A GDPR representative and GDPR DPO have separate functions and triggering tests.

AI supply chains complicate role allocation because one provider can perform several activities for different purposes. Processing a prompt to generate a customer-requested answer may support one role analysis, while independently using information for general product development creates another purpose and requires separate scrutiny. The contract, product settings, technical behavior, actual reuse, and decision authority should be assessed together.

An existing GDPR program is therefore valuable, but it needs Swiss additions. Copying a privacy notice, processing record, or vendor contract without reviewing Swiss categories and legal tests can create apparent consistency while leaving substantive gaps.

AI profiling, automated decisions, transparency, and human review

Not every use of an algorithm is profiling, and not every AI-supported score is an exclusively automated decision. A useful analysis separates four categories.

1. Ordinary data processing

Ordinary processing can include collection, organization, retrieval, summarization, or generation that does not evaluate or predict personal aspects. An assistant that reformats a candidate’s submitted work history still processes personal data, but that function is not necessarily profiling.

Such processing remains subject to applicable principles, transparency, security, retention, and role-allocation duties.

2. Profiling

Profiling involves automated processing used to evaluate or predict personal aspects. Examples can include predicting interests, assessing work performance, estimating reliability, segmenting customers by behavior, or scoring an applicant’s likely fit.

The vendor’s label is not decisive. A feature called “matching,” “recommendation,” “personalization,” or “insight generation” may still perform profiling if it evaluates or predicts characteristics of a person.

3. High-risk profiling

Under the FADP, high-risk profiling involves a high risk to personality or fundamental rights through matching data in a way that permits an assessment of essential aspects of a person’s personality.

A practical assessment can consider the breadth and sensitivity of the information, persistence of the profile, combination of multiple sources, confidence attributed to inferences, and possible consequences. These are risk-assessment considerations, not an exhaustive statutory checklist.

Profiling does not automatically require consent under Swiss law. Express consent becomes relevant in specified circumstances, including where consent is the applicable justification for sensitive personal data or high-risk profiling by a private person.

4. An important individual decision made exclusively through automated processing

This category focuses on decision authority and effect, not merely the presence of AI somewhere in a workflow. An important individual decision made exclusively through automated processing may require notice and an opportunity to request human intervention or reconsideration.

A recommendation, ranking, or draft does not automatically meet that test. Ask:

Does the system determine the outcome or inform a person?
Can the reviewer understand and depart from the recommendation?
Does the reviewer have enough time, authority, and information?
Is review routine and substantive, or merely nominal?
How important is the decision for the affected person?

These Swiss distinctions and the associated consent and automated-decision consequences are summarized in comparative legal guidance. GDPR Register discusses profiling, high-risk profiling, consent, and human reconsideration under the FADP.

AI hiring example

Consider two configurations of the same recruitment model.

In the first, the model ranks applicants and gives a recruiter enough information to review every application, correct input errors, consider additional evidence, and depart from the score. This may operate as decision support, although profiling, transparency, accuracy, and high-risk questions remain.

In the second, the model automatically rejects every applicant below a threshold without meaningful recruiter review. If rejection is an important individual decision and the result is determined exclusively through automated processing, the Swiss automated-decision provisions may apply.

The phrase “human in the loop” is not enough.

What AI transparency should answer

The FDPIC expects manufacturers, providers, and users to make the purpose, functionality, and data sources of AI-supported processing transparent. For interactive language models, users should know that they are communicating with a machine and whether submitted information is being used to improve a self-learning system or for another purpose. The FDPIC explains these AI-transparency expectations and their connection to human review.

A useful notice or in-product explanation should answer concrete questions:

Are prompts and uploaded files retained?
Are outputs stored or connected to an account?
Are feedback, logs, embeddings, or metadata retained?
Is customer content used for general training, fine-tuning, evaluation, safety testing, or abuse monitoring?
Is reuse enabled by default, optional, or contractually prohibited?
Can administrators, provider personnel, affiliates, or subprocessors access the content?
How long does each relevant data category remain?
Which applicable rights and review channels are available?
What happens when an output contributes to a consequential decision?

Transparency should match actual behavior.

DPIAs and privacy controls across the AI data flow

Under the FADP, a DPIA is required when planned processing is likely to create a high risk to a person’s personality or fundamental rights. A DPIA is not a declaration that the system is unlawful.

Features that warrant careful high-risk screening can include:

Systematic monitoring
Sensitive personal data
Biometric or genetic processing
Extensive profiling or data matching
Persistent inference of intimate or essential characteristics
Important automated decisions
Large-scale processing
Uses in contexts where errors could materially affect individuals

These features should prompt assessment rather than an automatic conclusion. Context, scale, safeguards, decision effect, and plausible consequences all matter.

High-risk AI-supported processing is not automatically prohibited under the FADP. It may proceed in principle where the law is satisfied and appropriate measures protect affected people. The DPIA should therefore inform design decisions rather than being completed after the product is fixed.

Map the full AI data flow

A practical assessment should follow data from collection through retirement.

Collection: Where does the data originate? Is it collected directly, supplied by a customer, purchased, inferred, generated, or obtained from another source?
Prompt or file submission: What can users enter, and what controls discourage inappropriate submissions?
Retrieval: Does the system search internal documents, candidate records, vector stores, or external sources?
Inference: Which model and provider process the information, and what outputs or inferences are created?
Logging: Which prompts, files, outputs, security events, and metadata are retained?
Model improvement: Is information reused for training, fine-tuning, evaluation, feedback analysis, or safety testing?
Human review: Who sees inputs and outputs, and what authority does that person have?
Sharing: Which teams, customers, providers, affiliates, and subprocessors receive data?
Retention and deletion: How long does each relevant copy or derived dataset remain under the service’s documented architecture?
Retirement: What happens to integrations, indexes, credentials, retained data, and derived artifacts when the use case ends?

For every stage, document:

The processing purpose
Personal and sensitive-data categories
Affected groups
Controller and processor roles
Access permissions
Security controls
Retention periods
Subprocessors
Transfer destinations and remote-access locations
Training, fine-tuning, or evaluation reuse
Foreseeable effects on individuals
Applicable Swiss and EU rules

Questions about deletion from backups, caches, indexes, evaluation datasets, or model-related artifacts should be resolved against the provider’s actual technical design and contract. Do not promise complete removal from every artifact unless that capability has been verified.

Privacy by design and default

Privacy by design means incorporating suitable technical and organizational measures during planning. Privacy by default means configuring the service so that processing is limited to what is required for its intended purpose.

For an AI service, these principles can influence whether conversation history is enabled, provider training is disabled, retrieval is restricted to approved documents, exports require permission, logs have defined retention periods, and the model receives full records or minimized extracts.

Practical risk-management measures can include:

Approved and prohibited use-case categories
Data minimization and redaction
Role-based access
Separation of testing and production environments
Logging and periodic access review
Retention and deletion settings
Provider security and contract review
Human-review procedures
Accuracy testing and error escalation
A DPIA escalation path
Reassessment after model or provider changes

These measures are implementation practices, not universal statutory specifications for every deployment. They should be selected according to the data, purpose, architecture, and risk.

Control shadow AI

Employees may enter candidate records, customer messages, source code, medical details, or confidential documents into unapproved tools because those tools are convenient. A policy that says only “use AI responsibly” is unlikely to guide real decisions.

A more useful program includes:

An approved-tool list
Clear restrictions on entering sensitive, confidential, or regulated data into unapproved services
Examples tailored to actual teams
A review path for new tools and use cases
Escalation for profiling, monitoring, or consequential decisions
Proportionate technical controls
Training on provider reuse, retention, and account settings

Hosting location should be one field in this assessment, not its conclusion. Swiss hosting, EU hosting, or on-premises deployment does not by itself resolve access, security, transfer, or purpose questions. Contracting entities, remote support, permissions, subprocessors, training practices, and actual data flows remain relevant. NeuraTech similarly treats AI privacy as an architecture and governance question rather than a hosting label.

Breach reporting and sanctions: two different risk models

Organizations subject to both regimes should not adopt one blended global deadline. They need a coordinated incident process with separate Swiss and GDPR decision paths.

A parallel incident-response workflow

1. Contain the event and preserve evidence. Restrict unauthorized access, preserve relevant logs, identify affected systems, and avoid destroying information needed for the investigation.

2. Establish awareness and chronology. Record when the organization learned of the event, what was known at each stage, and which controllers, processors, and subprocessors were involved.

3. Identify affected data and people. Determine the categories, approximate scope, sensitivity, safeguards, affected jurisdictions, and plausible consequences.

4. Run the Swiss test. Under the FADP, the controller must notify the FDPIC as soon as possible when a data-security breach is likely to result in a high risk to the affected person’s personality or fundamental rights. Affected individuals must be informed when notice is necessary for their protection.

5. Run the GDPR test separately. At a high level, supervisory notification is generally required for a qualifying personal-data breach unless it is unlikely to result in risk. When notification is required, the period is generally 72 hours after awareness.

6. Address processor escalation. Contracts and operational procedures should require processors and subprocessors to provide controllers with the information needed to assess applicable duties.

7. Document the outcome. Preserve the facts, risk reasoning, notifications made or not made, responsible decision-makers, remedial actions, and follow-up commitments.

The central contrast is threshold and timing. The Swiss framework uses a high-risk threshold and an “as soon as possible” standard. The GDPR uses a different risk threshold and a fixed 72-hour period where supervisory notification is required. Dual-regime organizations should open both analyses immediately rather than completing one before starting the other. The IAPP comparison sets out the differing Swiss and GDPR notification approaches.

Different enforcement exposure

The sanctions models also differ. Certain intentional FADP violations can expose responsible individuals to criminal fines of up to CHF 250,000. The FDPIC has supervisory powers and may issue orders, but it does not itself impose those criminal fines. Under the GDPR, administrative fines against organizations can reach EUR 20 million or 4% of worldwide annual turnover, depending on the infringement tier and applicable conditions. Adnovum summarizes the contrasting Swiss and GDPR sanctions structures.

Those differences do not support predictions about which executive, employee, or privacy professional would be prosecuted in a particular case. They do justify clear governance.

Organizations should document:

Who approves high-risk AI processing
Who can accept vendor exceptions
Who signs off on DPIAs
Who determines whether an incident is reportable
Who communicates with regulators and affected people
Who can suspend processing
Which facts and advice informed each decision

Documentation does not eliminate liability. It can reduce ambiguity, improve escalation, and demonstrate how the organization addressed risk.

International transfers and AI vendor due diligence

Sending personal data to an overseas model, cloud platform, support team, affiliate, or subprocessor requires more than checking the country shown in a hosting menu.

Under the FADP, personal data may be disclosed abroad through routes including a Swiss adequacy decision, recognized safeguards such as standard contractual clauses or binding corporate rules, and specified statutory exceptions. The appropriate route depends on the destination, recipient, relationship, data, and processing.

The EU continues to recognize Switzerland as providing adequate protection for personal-data transfers. Consequently, an EU-to-Switzerland transfer generally does not require standard contractual clauses solely because Switzerland is the destination. PwC summarizes the European Commission’s continued recognition of Swiss adequacy and its transfer consequence.

Adequacy is a transfer mechanism, not a universal compliance certificate. It does not establish that the FADP and GDPR are identical or replace processor terms, purpose analysis, transparency, retention limits, access controls, security review, or sector-specific obligations.

Reviewing a US AI provider

For a US recipient, a Swiss organization should verify through current official materials whether the relevant legal entity participates in an applicable Swiss–US Data Privacy Framework arrangement and whether the certification covers the intended data and processing. If it does not, the organization should assess an appropriate alternative, such as recognized contractual safeguards, together with any supporting analysis and measures.

Available practitioner guidance identifies certification and contractual safeguards as potential paths, but this is a legally dynamic area. Entity identity, certification scope, onward transfers, and current framework status should be independently verified before data is sent. This practitioner overview discusses Swiss transfer routes for US AI providers.

Do not assume that an EU contracting entity or European server prevents access from the US or another country. Remote support, affiliate access, globally operated security systems, subprocessors, disaster recovery, and onward transfers can affect the analysis. The same caution applies to a Swiss server or an on-premises installation.

AI vendor-review checklist

Review at least:

Contracting entity: Which legal entity provides the service?
Roles: For which activities is each party a controller, processor, or potentially an independent controller?
Purpose: What processing is necessary to provide the service?
Training and evaluation: Are prompts, files, outputs, feedback, or metadata reused?
Data-center region: Where do primary processing and storage occur?
Remote access: From which countries can support, security, or engineering personnel gain access?
Subprocessors: Which entities participate, and how are changes communicated?
Onward transfers: Where can information move after the first recipient?
Security: Which access, isolation, logging, testing, incident, and other safeguards apply?
Retention and deletion: Can the customer configure retention and obtain verifiable deletion consistent with the architecture?
Incident terms: How quickly must the provider notify the customer, and what information must it supply?
Audit evidence: What reports, certifications, testing results, or audit rights are available?
Exit support: What happens to data and integrations when the contract ends?

Under the FADP, a processor needs the controller’s prior approval before assigning processing to a third party. Because AI providers can change subprocessor lists frequently, approval must work operationally rather than exist only as contractual wording. Customers need notification, review, escalation, and objection procedures that can function when the list changes.

Worked scenario: A Swiss organization evaluating a US generative-AI service

A defensible sequence is:

Classify the data. Determine whether the use case includes personal data, sensitive personal data, confidential information, or regulated records.
Map roles and flows. Identify the Swiss organization, US provider, relevant affiliates, hosting operators, support locations, and subprocessors.
Choose a transfer path. Confirm applicable adequacy or certification status or implement recognized safeguards.
Review training and retention. Determine whether customer content is reused, what settings control reuse, and how long each data category remains.
Assess high risk. Consider scale, sensitivity, profiling, monitoring, affected people, and decision consequences.
Apply controls. Restrict permitted uses, minimize inputs, configure access and retention, prepare accurate notices, and establish incident and subprocessor procedures.
Reassess changes. Repeat the analysis if the provider, model, region, purpose, architecture, or data changes.

Professional secrets, banking information, healthcare data, employment records, public-sector processing, and other regulated information require additional analysis. General FADP transfer compliance does not resolve those separate requirements.

How to extend a GDPR program to cover Switzerland

Organizations do not need two disconnected privacy programs. They need a shared operational foundation with jurisdiction-specific legal fields, decisions, and response procedures.

Controls usually reusable as a baseline	Areas requiring Swiss-specific review
Data inventory and data-flow mapping	Effects-based territorial scope
Processing records	Swiss-representative conditions
Privacy by design and default	Private-sector processing justification
Risk-appropriate security	Swiss sensitive-data categories
Vendor and processor governance	Profiling and high-risk profiling
Retention and deletion controls	Exclusively automated important decisions
Data-subject request operations	Swiss transparency and notice details
DPIA methodology	FDPIC breach threshold and timing
Incident detection and investigation	Swiss transfer mechanisms
Training and accountability	Personal criminal-sanctions exposure

Use one AI inventory rather than separate undocumented spreadsheets maintained by legal, security, procurement, HR, and product teams. Give each use case jurisdiction-specific fields so that the same factual record can support different legal analyses.

At minimum, the inventory should identify:

Use case and business owner
Affected people
Personal and sensitive-data categories
Model and provider
Processing purpose
Customer-data training or reuse
Controller and processor roles
Subprocessors
Hosting, remote-access, and transfer locations
Retention and deletion behavior
Profiling activity
Automated-decision effect
Human-review process
Risk rating
DPIA status
Applicable jurisdictions
Representative, advisor, and DPO conclusions
Last review date and change triggers

Pre-pilot checklist

Before allowing personal data into an AI service:

Map the data and every material recipient.
Define a specific purpose.
Determine whether the FADP, GDPR, or both may apply.
Classify personal, sensitive, confidential, and regulated information.
Screen for profiling, monitoring, and important automated decisions.
Assess whether a DPIA is required.
Allocate controller and processor roles.
Review provider terms, security, subprocessors, access, and deletion.
Restrict provider training and evaluation reuse where appropriate.
Select and document international-transfer mechanisms.
Prepare accurate notices and user disclosures.
Test whether human review is meaningful.
Maintain separate Swiss and GDPR incident tests and clocks.
Obtain necessary business, privacy, security, and legal approvals.

HR and recruitment AI deserves a dedicated checkpoint. Candidate and employee records can combine identity information, work histories, assessments, monitoring data, inferred traits, sensitive information, and decisions affecting employment opportunities. Teams should determine whether a system merely organizes applications, profiles candidates, recommends outcomes, or makes an important rejection decision without meaningful human involvement.

Refresh the assessment whenever the organization changes:

The model or provider
A material subprocessor
Data sources or categories
The processing purpose
Training or evaluation practices
Retention settings
Target markets
User groups
Decision authority
Human-review arrangements
Hosting or remote-access locations

Frequently asked questions

Does GDPR compliance automatically satisfy Switzerland’s FADP?

No. A mature GDPR program provides a strong baseline because both regimes use controls such as transparency, security, privacy by design and default, processor oversight, processing records, impact assessments, and data-subject procedures.

A Swiss gap analysis is still necessary. It should address territorial effects, private-sector processing justification, representative conditions, Swiss sensitive-data categories, profiling, exclusively automated important decisions, breach thresholds and timing, transfers, and sanctions. The need for these Swiss-specific additions is recognized in comparative guidance on the revised law. DLA Piper describes the FADP’s alignment with the GDPR and its continuing Swiss deviations.

Does every foreign AI provider need a representative in Switzerland?

No. A foreign private controller must appoint a Swiss representative only when the cumulative statutory conditions are satisfied. The processing must concern offering goods or services to people in Switzerland or monitoring their behavior, and it must be regular, large-scale, and high-risk.

A foreign service can remain subject to other FADP obligations even if it does not meet the representative threshold. The representative is also distinct from a DPO, Swiss data-protection advisor, or internal privacy manager.

Does the FADP require consent for every use of AI profiling?

No. Profiling does not automatically require consent under the FADP.

Express consent becomes relevant in specified circumstances, including where consent is the applicable justification for processing sensitive personal data or for high-risk profiling by a private person. Organizations should first determine whether the activity is profiling, whether it is high-risk profiling, what principles and justification apply, and whether the system also makes an important decision exclusively through automated processing.

Is hosting an AI service in Switzerland or the EU enough to make it compliant?

No. Hosting location is relevant to data-flow and transfer analysis, but it does not resolve every compliance question.

The review should also cover the contracting entity, organizational roles, remote support, provider access, subprocessors, onward transfers, security, retention, deletion, transparency, purposes, and customer-content reuse. A Swiss or EU server does not necessarily prevent access from another jurisdiction.

Does the FADP impose the GDPR’s 72-hour breach deadline?

No. The FADP does not use the GDPR’s 72-hour supervisory-notification deadline.

Under the Swiss framework, a controller must notify the FDPIC as soon as possible when a data-security breach is likely to result in a high risk to the affected person’s personality or fundamental rights. The GDPR uses a different risk threshold, and a qualifying supervisory notification is generally due within 72 hours after awareness.

Organizations subject to both regimes should run the tests and clocks in parallel, preserve their reasoning, and avoid delaying one notification while waiting for the other assessment to finish.

The practical answer is to reuse what genuinely transfers: inventories, security controls, privacy-by-design work, vendor reviews, retention processes, incident-detection capabilities, and DPIA methods. Then add the Swiss legal fields and procedures that do not map directly onto the GDPR.

Map the AI service’s actual data flows. Determine whether Swiss effects and EU territorial triggers may apply. Distinguish ordinary processing from profiling, high-risk profiling, and exclusively automated important decisions. Assess high risk, transfers, provider access, customer-data reuse, and meaningful human review. Maintain separate Swiss and GDPR incident paths even when the same team administers them.

Privacy compliance alone does not establish compliance with the EU AI Act or with employment, banking, healthcare, professional-secrecy, public-sector, or other sector-specific rules. This article is informational and is not legal, HR, or employment advice. Current jurisdiction-specific requirements should be confirmed with qualified counsel, as explained in HRaizon’s Terms & Conditions.