Feature 8 August 2026

What AI Companies Must Change When Operating Under Swiss and EU Privacy Rules

Priya Ellison

The short answer: FADP and GDPR overlap, but neither replaces the other

Switzerland’s revised Federal Act on Data Protection (FADP) is the country’s principal federal law governing personal-data processing. It and its accompanying ordinances entered into force on 1 September 2023 without a transition period. The revision strengthened Swiss protections and moved the framework closer to the EU General Data Protection Regulation (GDPR), but meaningful differences remain and can require Swiss-specific additions to a GDPR program. DLA Piper summarizes the revised framework, effective date, and need for “Swiss add-ons.”

The FADP is technology-neutral, not a dedicated AI statute. It becomes relevant when developing, testing, buying, or operating an AI system involves personal data. Personal data means information relating to an identified or identifiable natural person. Unlike the former Swiss framework, the revised FADP protects natural persons rather than legal persons.

The practical question is therefore not simply whether a product uses AI. It is whether information processed during sourcing, labeling, training, validation, deployment, logging, monitoring, or retraining relates—or can reasonably be linked—to a person. Relevant information may appear in training examples, user accounts, prompts, interaction logs, inferred attributes, generated outputs, evaluation data, or security records.

Genuinely anonymous information falls outside the ordinary personal-data analysis, but teams should not treat the removal of names as conclusive. Equally, the available evidence does not establish that every prompt, embedding, model parameter, inference, or generated output is necessarily personal data. Those questions require analysis of the particular artifact, system, available means, and context.

A company with a mature GDPR program can usually reuse substantial operational infrastructure: inventories, notices, security controls, processor reviews, rights workflows, retention rules, impact-assessment methods, and privacy-by-design processes. That reuse can reduce duplication, but GDPR compliance is not an automatic FADP safe harbor. The laws differ in territorial structure, processing frameworks, representative tests, breach reporting, recordkeeping exceptions, governance roles, and enforcement.

Privacy compliance must also be separated from AI-product regulation. A recruitment platform may therefore require parallel reviews covering privacy, employment, discrimination, and AI governance.

This guide is a high-level operational comparison based on the materials identified here, not a complete article-by-article legal opinion. It is informational, not legal, HR, or employment advice, consistent with HRaizon’s editorial terms. Before making material decisions, check the complete current statutes, ordinances, official regulator guidance, applicable sector rules, and authoritative official-language Swiss text. Fedlex states that its English FADP translation is informational and has no legal force.

Scope decision tree: when FADP, GDPR, or both may apply

Start with establishments, entities, markets, and processing activities—not the citizenship or nationality of the people represented in a dataset.

Use this sequence for every AI product, internal system, and material data flow:

Identify the entities and establishments involved. Which entity decides why and how the data is processed? Which entity develops, operates, sells, or supports the system? Is a Swiss or EU establishment connected to the relevant processing?
Map the processing. Record where information is collected, labeled, hosted, accessed, analyzed, logged, retrained, transferred, and deleted.
Identify markets and conduct. Is the company offering a service in Switzerland or the EU? Is it monitoring behavior in either market?
Test each regime separately. Do not assume that one law displaces the other.
Apply obligation-specific tests. General territorial scope, representative appointments, DPIAs, processing records, and breach notification do not necessarily share the same trigger.

The FADP applies to processing by private persons and federal bodies and to circumstances having effects in Switzerland, including circumstances initiated abroad. That effects-based rule can require investigation by foreign AI providers, but it should not be converted into a claim that any contact with information about someone in Switzerland automatically triggers every Swiss obligation. The FADP’s purpose, scope, definitions, processing principles, and effects rule appear in the current Fedlex text.

At a high level, the available comparison evidence indicates that GDPR scope can arise through processing connected with an EU establishment. It can also reach certain organizations outside the EU when relevant processing concerns offering goods or services to people in the EU or monitoring their behavior there. Any operational conclusion should be verified against the current official text of GDPR Article 3 and applicable official guidance. This 2026 comparison describes the establishment, offering, and monitoring questions at a high level.

Four screening scenarios

1. A Swiss AI company serving only Switzerland

The FADP requires investigation because a Swiss entity is processing personal data. The GDPR does not apply merely because some records concern EU nationals. The answer may change if an EU establishment is connected to the processing or if the company offers relevant services to, or monitors the behavior of, people in the EU.

2. A Swiss company offering an AI service in the EU

Both regimes require investigation. The FADP remains relevant to the Swiss company’s processing, while the GDPR may apply through an EU establishment or an applicable offering or monitoring test. The company must separately determine whether any GDPR requirement for an EU representative or DPO is triggered.

3. An EU company serving Switzerland

The GDPR will ordinarily remain relevant to processing connected with the company’s EU operations. The FADP also requires investigation where the company’s conduct has effects in Switzerland. That does not automatically mean the company must appoint a Swiss representative because the representative duty has narrower cumulative conditions.

4. A non-European model provider serving users in both markets

Both laws may require investigation even if the provider has no Swiss or EU headquarters. General scope questions include the markets targeted, behavior monitored, entities involved, and relationship between each processing activity and the relevant market.

Scale, regularity, and high risk should then be considered separately when testing the narrower Swiss-representative requirement. They should not be presented as prerequisites for every possible application of the FADP.

Scope is not the same as representation

A foreign private controller’s Swiss-representative duty is narrower than the FADP’s general effects-based scope. The available statutory and secondary evidence describes cumulative conditions involving processing connected with offering goods or services to people in Switzerland or monitoring them, together with large-scale processing, regularity, and high risk. A Swiss representative should therefore be assessed under its specific statutory test, not inferred from general territorial scope.

The GDPR’s EU-representative rule is a different role with its own trigger and exceptions. Each appointment must be assessed and documented separately.

FADP versus GDPR: the comparison matrix AI teams need

The matrix is a high-level screening tool, not a substitute for checking the controlling provisions. Its status labels mean:

Confirmed: supported at a general level by the supplied statutory text or consistently reported evidence.
Conditional: applies only if a statutory threshold, role, or factual condition is met.
Fact-specific: cannot safely be converted into a universal rule.
Verify in primary law: the available evidence supports only a high-level comparison, so the complete controlling text and current official guidance must be checked.

Issue	Swiss FADP	EU GDPR	Status and AI implication
Territorial scope	Covers relevant Swiss processing and circumstances having effects in Switzerland, including some conduct initiated abroad.	Available evidence describes scope through qualifying EU establishments and certain offering or behavioral-monitoring activities.	Fact-specific: test each entity, activity, establishment, and market.
Protected data	Protects information relating to an identified or identifiable natural person, not a legal person.	Protects personal data relating to natural persons.	Confirmed at a high level: assess identifiability throughout the AI lifecycle.
Processing framework	Structured around processing principles, possible personality infringements, consent where required or relied upon, and possible justifications.	Generally requires a lawful basis for each processing activity.	Confirmed at a high level: do not mechanically document Swiss processing through GDPR Article 6 labels.
Consent	Must meet Swiss requirements when relied upon or legally required; the need for consent depends on context.	One potential lawful basis, subject to GDPR validity requirements.	Fact-specific: sensitive data or profiling does not support an unqualified statement that consent is always mandatory.
Sensitive data	Includes specified health, genetic, uniquely identifying biometric, racial or ethnic, political, trade-union-related, religious or philosophical, criminal-proceeding, sanctions, and social-assistance information.	Contains special-category and criminal-offense rules whose categories and structure are not identical.	Conditional: classification can change the applicable analysis and risk controls.
Profiling	Defines profiling and separately recognizes high-risk profiling.	Regulates profiling and addresses certain automated decisions.	Fact-specific: not every score or recommendation is high-risk profiling.
Privacy by design and default	Requires protection from the planning stage and defaults that limit processing to what the purpose requires.	Also contains express design-and-default requirements.	Confirmed at a high level: integrate controls into architecture and procurement.
Transparency	Imposes information duties subject to statutory detail and exceptions.	Contains detailed transparency duties commonly associated with Articles 13 and 14.	Conditional: one notice can be used operationally only if it satisfies both regimes.
Data-subject rights	Includes access and other Swiss rights subject to Swiss scope and exceptions.	Includes a broader set of named rights, each subject to conditions and exceptions.	Verify in primary law: use a common intake channel but maintain regime-specific decision rules.
Processing records	Required subject to conditions and possible exceptions, including reported relief for some smaller organizations whose processing presents negligible risk.	Article 30 contains recordkeeping duties and a limited derogation.	Conditional: do not infer an exemption from headcount alone.
DPIAs	Required where planned processing is likely to create a high risk to personality or fundamental rights.	Required where processing is likely to result in a high risk to rights and freedoms.	Conditional: AI is not itself the trigger.
Security	Requires technical and organizational measures appropriate to risk.	Uses a risk-based security framework.	Confirmed at a high level: controls should follow actual data, systems, and threats.
Breach reporting	The controller must notify the FDPIC as soon as possible when a data-security breach is likely to create a high risk.	Supervisory notification is generally required without undue delay and, where feasible, within 72 hours after awareness when the reportability threshold is met.	Conditional: evaluate both thresholds independently.
Privacy leadership	A private controller may generally appoint a Swiss data-protection adviser; the role is not universally mandatory.	A DPO is mandatory only when Article 37 criteria are met.	Conditional: similar expertise does not make the roles interchangeable.
Foreign representatives	Certain foreign private controllers must appoint a Swiss representative when cumulative offering or monitoring, scale, regularity, and high-risk conditions are met.	Certain non-EU controllers or processors must appoint an EU representative, subject to separate conditions and exceptions.	Conditional: conduct and document two separate tests.
International transfers	Foreign disclosure may rely on recognized adequacy, appropriate safeguards, or an applicable statutory exception.	GDPR Chapter V provides its own transfer mechanisms and derogations.	Fact-specific: map storage, remote access, onward transfers, and subprocessors.
Enforcement	Includes supervisory measures and criminal sanctions for specified conduct, with fines primarily focused on responsible individuals.	Supervisory authorities may impose corrective measures and administrative fines generally directed at organizations.	Confirmed at a high level: governance and attribution of decisions matter.
Maximum penalties	Secondary sources report a maximum of CHF 250,000 for specified willful violations.	Secondary sources report an upper tier of EUR 20 million or 4% of worldwide annual turnover, whichever is higher.	Conditional: these are statutory maximums, not automatic outcomes.

The broad similarities are real: both regimes address transparency, security, individual rights, impact assessment for high-risk processing, processor governance, retention, privacy engineering, and international transfers. A combined operational program is therefore sensible. PwC’s Swiss overview likewise describes the revised law as similar to EU data-protection law while retaining differences. Its glossary covers consent, rights, DPIAs, transfers, breaches, sanctions, and the Swiss adviser role.

The central structural distinction is the processing framework. The GDPR generally asks which lawful basis supports each processing activity. Swiss documentation should not simply rename a GDPR Article 6 basis as a “Swiss lawful basis.” Instead, it should address applicable processing principles, whether processing may infringe personality, whether consent is required or relied upon, and whether a justification is available.

Consent illustrates the risk of overstatement. Where Swiss consent is required, the supplied FADP text indicates that it must be voluntary, appropriately informed, and specific, with explicit consent relevant in specified circumstances. That does not prove that every use of sensitive data or every high-risk profile invariably requires consent regardless of the surrounding provisions and any available justification.

Processing records and DPIAs are also conditional. A company should not treat “uses AI,” “has fewer than 250 employees,” or “already completed a GDPR DPIA” as a complete Swiss test. The exact recordkeeping exception should be verified against the complete FADP and ordinance, while the DPIA inquiry should focus on whether the planned processing is likely to create high risk. Termly’s comparison reports the Swiss high-risk DPIA threshold and conditional recordkeeping treatment.

Breach reporting and sanctions differ in ways that affect operations. Secondary comparisons report a generally applicable GDPR supervisory-notification period of 72 hours for reportable breaches, while Swiss law uses an as-soon-as-possible standard when the breach is likely to create a high risk. They also report different maximum-penalty structures: organizational, turnover-based exposure under the GDPR and individual-focused criminal fines for specified willful FADP violations. These high-level differences are summarized in Usercentrics’ FADP–GDPR comparison.

Map the rules across the AI data lifecycle

Treat an AI system as a chain of processing activities rather than a single object. At each stage, ask:

What information is present?
Does it relate, or remain reasonably linkable, to a natural person?
Why is it being processed?
Which entity makes the relevant decisions?
Where is the information stored or accessed?
Who can receive or reuse it?
How long is it required?
What happens when the purpose ends?

Dataset sourcing and collection

Document where data came from, who collected it, the original purpose, applicable notices, contractual restrictions, and whether sensitive information is present.

Collection decisions should be tested against lawful and good-faith processing, proportionality, purpose specificity, and transparency. “We may use data to improve AI” is usually too vague for an internal specification because it does not identify which fields are necessary, what improvement is intended, how long data is required, or who may receive it.

A dataset record should, where feasible, identify:

Source and acquisition date
Original and proposed purposes
Data categories
Geographic and contractual restrictions
Sensitive-data indicators
Expected affected groups
Retention period
Permitted users and systems
Known quality or provenance limitations

Labeling and enrichment

Record what labelers can see, whether identifiers can be masked, how access is authenticated, how work is monitored, and whether the provider may use information for its own purposes.

Enrichment may also create consequential inferences. A tool that extracts document language presents different questions from a system that infers health status, personality, likely job performance, political views, or retention risk. The output must be assessed, not just the source fields.

Training and validation

Training teams should document provenance, filtering, minimization, duplicate handling, data quality, validation sets, access, intended reuse, and retention.

Do not assume that removing names always anonymizes a dataset. Indirect identifiers, unusual characteristics, free text, and linkages may preserve identifiability. At the same time, do not claim that every model weight is necessarily personal data. The available evidence does not establish a universal rule for model parameters, memorization, extraction, or the legal consequences of those technical properties.

The prudent approach is to record the open question, available technical evidence, safeguards, decision owner, and reassessment trigger.

Deployment and interaction logging

Before launch, confirm that default settings limit processing to what the service actually needs. Optional logging, long retention, secondary training, broad employee access, or unnecessary integration data should not be enabled merely because a provider offers them.

For a customer-service generative AI system, distinguish:

The customer’s original message
Retrieved account data
Prompt construction and system instructions
Information sent to the model provider
The generated response
Quality-review and safety logs
Any information selected for later training

Those components may have different purposes, recipients, risks, and retention periods.

Monitoring and retraining

Production monitoring may support security, quality, or misuse detection, but it can also expand behavioral observation. Define the monitored events, sampling rules, access permissions, escalation criteria, and retention period.

If production interactions are later selected for evaluation or retraining, record that secondary use. Do not treat it as an invisible continuation of customer support or system administration.

Retention, deletion, and anonymization

Personal data should not be retained indefinitely because it might someday improve a model. Swiss processing principles include destruction or anonymization when information is no longer required for the purpose. Create schedules for raw records, labels, prompts, outputs, logs, backups, evaluation datasets, and vendor-held copies.

The supplied evidence does not establish a universal legal or technical method for removing an individual’s information from a trained model. Teams should document:

What can be deleted directly
Which copies, logs, or backups are affected
What cannot currently be isolated
Which mitigations reduce residual risk
Whether future retraining or retirement could address the issue
What is communicated to affected people without overpromising

Bounded examples for product review

Recruitment scoring: Ask whether the system profiles applicants, uses or infers sensitive attributes, affects significant opportunities, creates high risk, and requires additional human review or escalation. Do not infer a categorical legal result merely from the label “recruitment AI.”
Employee copilot: Restrict unnecessary employee, client, health, biometric, or confidential information in prompts. Determine whether interaction logs are used for support, monitoring, evaluation, or training.
Customer-service generative AI: Separate account retrieval from model processing and decide whether prompts and outputs belong in customer records, operational logs, or training datasets.
Third-party model API: Identify provider access, retention, secondary training, subprocessors, support access, storage locations, remote-access locations, and deletion options.

These are prompts for analysis, not categorical legal conclusions.

Practical controls include provenance records, approved-input rules, minimization, retention schedules, role-based access, staff training, vendor restrictions, and documented risk reviews. Privacy by design means addressing such controls during planning, architecture, and procurement. Privacy by default means configuring the service so that only processing required for the stated purpose occurs without additional user action. CASUS identifies privacy by design and default, DPIAs, breach escalation, transfer controls, vendor review, and staff rules as central AI-related Swiss workstreams.

Questions concerning prompts, embeddings, inferred attributes, model weights, generated outputs, public-web collection, and deletion from trained models remain context-dependent. None should be labeled always personal data or never personal data on the supplied evidence.

Profiling, sensitive data, DPIAs, and processing records

Under the FADP, profiling is automated processing of personal data used to evaluate, analyze, or predict aspects relating to a natural person. High-risk profiling is narrower: it concerns profiling that poses a high risk to personality or fundamental rights by matching data that permits an assessment of essential aspects of a person’s personality.

An automated score is therefore not automatically high-risk profiling. Relevant questions include:

What data is combined?
What characteristics are inferred?
How comprehensively is the person evaluated?
What consequences follow?
Can the result be corrected or challenged?
What safeguards and human controls exist?

The FADP’s sensitive-data categories relevant to AI include:

Health data
Genetic data
Biometric data that uniquely identifies a person
Racial or ethnic data
Political views or activities
Trade-union-related views or activities
Religious or philosophical views or activities
Data concerning administrative or criminal proceedings and sanctions
Data concerning social-assistance measures

The complete category wording should be checked against the authoritative official-language statute before it is used in a binding policy or legal classification.

Activities deserving heightened review include behavioral scoring, face or voice analysis, employee and applicant assessment, health-related prediction, fraud classification, and other consequential categorization. Heightened review does not predetermine that processing is unlawful; it means routine controls may not be enough.

A Swiss DPIA is required where planned processing is likely to create a high risk to personality or fundamental rights. AI is not an automatic trigger. The assessment should consider the purpose, categories and volume of information, affected people, scale, profiling, vulnerability, potential consequences, security threats, safeguards, and residual risk.

A practical AI DPIA should cover:

Purpose and system boundaries: Intended uses, prohibited uses, users, integrations, and decision points.
Data and data flows: Sources, fields, inferred data, outputs, logs, storage, access locations, and recipients.
Affected people: Customers, employees, applicants, patients, children, contractors, or people represented in third-party datasets.
Necessity and proportionality: Why each processing step and field is needed and whether a less intrusive design is available.
Threat and harm analysis: Unauthorized access, leakage, re-identification, inaccurate classification, exclusion, manipulation, or loss of opportunity.
Vendor dependencies: Model providers, cloud hosts, annotators, analytics services, and subprocessors.
Safeguards: Minimization, filtering, testing, access controls, encryption, human review, correction channels, retention, and monitoring.
Residual risk and approval: Remaining exposure, accountable approvers, launch conditions, and escalation.
Review triggers: New data, new purposes, model changes, geographic expansion, incidents, performance drift, or vendor changes.

Processing records are also conditional. Available evidence indicates that exceptions may exist for some legal entities with fewer than 250 employees where processing presents negligible risk. The exact exception and any limitations must be verified against the complete FADP and ordinance. A small AI company handling biometric data, conducting consequential employee profiling, or monitoring users at scale should not assume that headcount alone creates an exemption. The reported employee threshold, risk qualification, DPIA rule, and profiling distinctions are summarized here.

Detailed obligations concerning automated-decision notices, explanations, human intervention, or contestation require review of provisions beyond the incomplete primary-law excerpt supplied for this article, together with any applicable GDPR Article 22 analysis. No universal right or product design rule should be inferred solely from the definition of profiling.

AI vendors, subprocessors, and international data transfers

An AI data chain may include:

The customer or deployer
The AI application developer
A foundation-model or model API provider
A cloud infrastructure host
An analytics or observability provider
A human-review or labeling service
Each organization’s subprocessors

Map the chain based on documented conduct, contractual permissions, and technical configuration. A contractual label is important but should not replace examination of who selects purposes, who controls relevant means, who may reuse inputs or outputs, and who acts only on documented instructions. Where the legal allocation is uncertain, record it as an issue requiring qualified review rather than presenting an unsupported conclusion.

Controllers and processors must implement technical and organizational security measures appropriate to risk. Under the supplied FADP provision, a processor may engage a subprocessor only with the controller’s prior approval. Subprocessor governance is therefore not merely a procurement preference.

Before sending personal data to a model or cloud provider, document:

What data is transferred, including metadata
Why it is transferred
Storage and remote-access locations
Retention periods and backup treatment
Whether prompts, files, or outputs may be used for secondary training
Whether provider personnel or contractors can access content
Security and encryption arrangements
Participating subprocessors
Onward-transfer routes
Available rights-request support
Deletion capabilities and limitations
Incident notification and investigation support

Foreign disclosure may rely on recognized adequacy, appropriate safeguards, or an applicable statutory exception. Transfer compliance should not be reduced to adequacy or consent alone. The selected mechanism, destination, contractual protections, technical controls, onward transfers, and practical access conditions must be considered. This FADP overview identifies adequacy decisions, contractual safeguards, and binding corporate rules among the available transfer concepts.

The supplied evidence reports that the EU renewed Switzerland’s adequacy status in January 2024, but it does not include the official decision. A date-specific adequacy statement should therefore be confirmed against the official European Commission material before it is used in a legal memorandum or transfer assessment. Adequacy between jurisdictions would not, in any event, answer every question about a provider chain extending to other destinations.

Contracts should address:

Purpose restrictions
Permitted use of prompts and outputs
Confidentiality
Security standards
Subprocessor approval and change notices
Incident cooperation
Rights-request support
Retention and deletion
Audit information
Service termination
Data return or export

Procurement should also test whether the contractual commitments match the actual product configuration. A contract promising limited retention is of little operational value if the purchased service tier uses different defaults.

None independently proves FADP compliance because purpose, transparency, security, rights, processor roles, and other duties remain relevant.

Maintain separate Swiss and GDPR transfer maps. The same provider chain may require analysis under both regimes, and a mechanism documented for one legal relationship does not automatically complete the other. A high-level international comparison likewise cautions that both regimes regulate transfers and recognize more than a single route.

Breach response, governance roles, and personal exposure

The GDPR and FADP use different notification formulations. For a reportable breach, GDPR supervisory notification is generally due without undue delay and, where feasible, within 72 hours after awareness. Under the FADP, the controller must notify the FDPIC as soon as possible when a data-security breach is likely to create a high risk.

Not every security event is reportable under either regime. A failed login, a contained configuration error, and exposure of a sensitive dataset require different assessments. Teams must test the Swiss and GDPR thresholds independently instead of treating the shorter-looking timetable as the only rule.

Use a dual-regime incident workflow:

Detect and contain. Stop ongoing access, preserve systems, and avoid destroying evidence.
Preserve facts. Record discovery time, suspected start time, affected systems, logs, actors, and containment measures.
Map impact. Identify the data, systems, people, countries, entities, vendors, and possible consequences.
Assess the GDPR threshold. Begin the reportability and 72-hour analysis immediately.
Assess the Swiss threshold. Determine whether the breach is likely to create a high risk and whether FDPIC notification is required as soon as possible.
Determine communications. Analyze regulator, individual, customer, contractual, insurer, and sector-specific duties separately.
Document the decision. Preserve the facts, reasoning, uncertainty, approvers, and timing.
Remediate and review. Correct the issue, test the fix, address root causes, and update controls.

Do not wait for the Swiss assessment to finish before beginning the GDPR analysis. An incomplete initial picture should trigger accelerated fact gathering and documented decisions, not paralysis. The Swiss high-risk standard and lack of a fixed FADP notification period are summarized in this AI-focused Swiss review.

Four governance roles are often confused:

Swiss data-protection adviser: An internal or external advisory role that is generally optional for private controllers.
GDPR DPO: An independent oversight role required only when Article 37 criteria are met.
Swiss representative: A local contact role for certain foreign private controllers meeting the cumulative Swiss conditions.
EU representative: A role for certain non-EU controllers or processors, subject to separate GDPR conditions and exceptions.

Swiss enforcement creates a distinctive governance concern. Secondary sources report that specified willful FADP violations can result in fines directed primarily at responsible natural persons, up to CHF 250,000. They report GDPR upper-tier administrative fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. Aiara summarizes the contrast between individual-focused Swiss fines and organization-focused GDPR penalties.

These are maximum exposures, not automatic penalties. Not every FADP error creates personal liability. The practical governance response is to establish named ownership, written approval paths, executive escalation, staff training, procurement gates, and records showing who made material decisions and on what information. Documentation should support accountable reasoning, not shift blame to junior employees.

A practical GDPR-to-FADP gap checklist for AI companies

A mature GDPR program can provide the operational foundation. Reuse:

Data and AI-system inventories
Processing records
Privacy notices
Rights-request intake and verification
Security and access controls
Vendor and processor reviews
DPIA methods
Retention schedules
Incident-response procedures
Privacy-by-design reviews

Then add or validate Swiss-specific treatment:

Effects-based scope: Identify conduct initiated abroad that may have effects in Switzerland.
Processing framework: Document Swiss processing principles, potential personality infringement, consent where required or relied upon, and possible justification rather than copying Article 6 labels.
High-risk profiling: Apply the Swiss definition separately.
Swiss representation: Test all cumulative conditions.
Recordkeeping exceptions: Verify any small-entity relief against the complete FADP and ordinance.
FDPIC escalation: Use the as-soon-as-possible, high-risk breach test.
Foreign disclosure: Document Swiss transfer mechanisms and onward transfers.
Enforcement: Reflect possible exposure for responsible natural persons.

Control labels

Use consistent labels in the compliance register:

Mandatory: The requirement clearly applies to the documented facts.
Conditionally mandatory: It applies if a threshold, role, or risk condition is met.
Recommended: A risk-management control not presented as a universal statutory command.
Disputed: Authorities, courts, or credible interpretations are not settled.
Emerging: Legislation, regulator interpretation, or technical practice is developing.

These labels help prevent recommended controls from being mistaken for universal legal duties and stop uncertain interpretations from becoming undocumented product assumptions.

A 30-day implementation sequence

Days 1–5: Map systems and scope

Inventory production AI, pilots, public tools, internal copilots, and shadow AI.
Map information from sourcing through deletion.
Identify entities, establishments, controllers, processors, users, and markets.
Screen separately for FADP, GDPR, and sector-law relevance.

Days 6–10: Classify risk

Identify sensitive data, vulnerable groups, profiling, monitoring, and consequential uses.
Test whether profiling may meet the Swiss high-risk definition.
Triage systems for Swiss and GDPR DPIAs.
Open an issues register for unresolved classifications.

Days 11–15: Review vendors and transfers

Map providers and subprocessors.
Verify retention, human access, secondary training, hosting, remote access, security, rights support, and deletion.
Confirm subprocessor approval mechanisms.
Document Swiss and GDPR transfer analyses separately.

Days 16–20: Update rules and notices

Revise privacy notices and internal processing records.
Implement an approved-input policy.
Define retention and deletion rules.
Add procurement and architecture review gates.

Days 21–25: Revise incident response

Add separate GDPR and Swiss threshold assessments.
Define the GDPR 72-hour escalation path and the FADP as-soon-as-possible path.
Pre-assign legal, security, product, communications, and executive roles.
Run a tabletop exercise involving a model or cloud provider.

Days 26–30: Assign and train

Complete the DPO, adviser, and representative analyses.
Name an accountable owner for each AI system.
Train engineering, product, HR, support, security, and procurement teams.
Set review dates and change triggers.

Approved-input policy for public AI tools

The default policy should restrict unnecessary entry of:

Customer or prospect records
Applicant or employee information
Health, genetic, or biometric data
Identity documents or financial details
Authentication credentials
Confidential business information
Legal advice or privileged material
Third-party datasets without approved provenance
Information subject to contractual or sector-specific restrictions

Exceptions should require an approved business purpose, an authorized tool, configured safeguards, minimization, and a documented owner.

Procurement questions

Before approving an AI provider, ask:

Does the provider retain prompts, files, outputs, or metadata?
Can employees, contractors, or reviewers access content?
May customer information be used for training or product improvement?
Which subprocessors participate, and how are changes approved?
Where is information stored, remotely accessed, and supported?
What security controls and incident commitments apply?
Can the provider support access, correction, restriction, or deletion requests?
What happens to information at termination?
What evidence supports deletion?
Which model artifacts, backups, or logs may remain?

Maintain an issues register for unsettled questions such as public-web training, inferred data, embeddings, memorization, model artifacts, generated outputs, automated decisions, and deletion from trained models. Record the current position, supporting evidence, responsible owner, safeguards, and next review trigger.

A combined program is operationally efficient, but it should preserve separate legal decision records. General Swiss data-protection resources identify many of the same foundational workstreams—rights, DPIAs, transfers, breach handling, and governance—while recognizing that the Swiss and EU frameworks are not identical. PwC’s Swiss data-protection overview provides a high-level map of those shared subjects.

Frequently asked questions

Does GDPR compliance automatically mean an AI company complies with the Swiss FADP?

No. GDPR controls can cover much of the operational work, including inventories, notices, rights handling, security, DPIAs, retention, and vendor reviews. The Swiss framework still requires a separate analysis of territorial effects, processing structure, high-risk profiling, representative conditions, breach escalation, recordkeeping exceptions, transfers, and enforcement. The revised FADP was aligned more closely with the GDPR but retained differences requiring Swiss-specific additions.

Does an AI company without a Swiss office need a representative in Switzerland?

Possibly, but not merely because it handles data connected with someone in Switzerland. A foreign private controller must assess the narrower cumulative test involving relevant offering or monitoring, large-scale processing, regularity, and high risk. General FADP scope and the representative duty are separate questions. The conditional nature of the representative requirement is described in this FADP overview.

Does every AI system require a data protection impact assessment under Swiss law?

No. A Swiss DPIA is required when planned processing is likely to create a high risk to personality or fundamental rights. Relevant factors include purpose, data categories, scale, affected people, profiling, consequences, safeguards, and residual risk. AI may contribute to risk, but it is not an automatic trigger.

How do Swiss and GDPR breach-notification deadlines differ?

For a reportable breach, the GDPR generally requires supervisory notification without undue delay and, where feasible, within 72 hours after awareness. The FADP has no equivalent fixed 72-hour period; it requires notification to the FDPIC as soon as possible when the breach is likely to create a high risk. Not every event is reportable, and the thresholds must be assessed independently. Usercentrics compares the two notification formulations at a high level.

Who can be fined under the FADP compared with the GDPR?

GDPR administrative fines generally target organizations and can reach the applicable turnover-based or fixed statutory maximum. Under the FADP, specified willful violations may expose responsible natural persons to criminal fines reported at up to CHF 250,000. These are maximum exposures, not automatic penalties, and not every Swiss violation creates personal liability.

Last reviewed: 9 August 2026. This date records the article’s editorial review, not a representation that every 2026 authority or development has been exhaustively examined. Before relying on the checklist, verify the complete current FADP, its ordinance, authoritative official-language text, official FDPIC materials, applicable GDPR provisions and guidance, transfer decisions, and sector-specific rules with qualified counsel.

Dual compliance is not a choice between interchangeable rulebooks. Reuse mature GDPR controls, then document a distinct Swiss analysis for scope, profiling, DPIAs, representatives, incidents, transfers, records, and accountable decision-making.