When an AI Service Must Follow Swiss Law, the GDPR, or Both

The short answer: FADP, GDPR, or both?

An AI service may need to comply with Switzerland’s Federal Act on Data Protection (FADP), the EU General Data Protection Regulation (GDPR), or both. It may fall outside these particular privacy regimes if neither territorial test is met or the relevant activity does not involve personal data.

The answer does not depend solely on where the vendor is incorporated, what law governs its customer contract, or whether somebody in Switzerland or the EU can open its website. The relevant facts include:

• Which entities and establishments participate in the processing
• Whether the provider deliberately serves Swiss or EU markets
• Whether it monitors behavior in either market
• Whether foreign conduct has relevant effects in Switzerland
• Whether the activity processes information about identifiable people
• Which participants act as controllers, joint controllers, or processors

Switzerland’s revised FADP and supporting ordinances took effect on 1 September 2023, without a transition period. The revised law protects personal data relating to natural persons rather than legal entities and incorporates several GDPR-like governance measures while retaining Swiss-specific differences. It can also apply to circumstances initiated abroad that have effects in Switzerland, although the limits of that test are fact-dependent. DLA Piper’s Swiss data-protection guide summarizes the revised framework, commencement date, and territorial approach.

A practical first-pass classification is:

• FADP only: The processing has a sufficient Swiss connection or relevant effects in Switzerland, but no GDPR territorial trigger has been identified.
• GDPR only: The processing is within GDPR scope, but the available facts do not establish Swiss scope.
• Both: Separate Swiss and EU territorial tests are satisfied, and the relevant activity processes personal data.
• Neither: Neither territorial test is met, or no personal data is processed. Other AI, consumer, employment, intellectual-property, cybersecurity, or sector-specific laws may still apply.

A Swiss company is not automatically subject to the GDPR merely because one person in the EU uses its service. A Swiss provider may, however, enter GDPR scope when it deliberately offers goods or services to people in the EU or monitors their behavior there. Incidental accessibility and deliberate EU market activity should not be treated as equivalent. This GDPR-and-Switzerland overview describes the offering and behavioral-monitoring triggers for non-EU businesses.

A defensible decision sequence

Evaluate territorial and material scope before copying obligations into a compliance checklist:

1. Identify participating entities and establishments. Include the contracting vendor, parent and affiliate companies, deployment partners, cloud operators, support teams, and any Swiss or EU establishment involved in deciding or carrying out the processing.
2. Map intended markets. Record where the service is deliberately marketed, localized, priced, sold, delivered, or supported.
3. Identify behavioral monitoring. Examine persistent analytics, user profiles, employee monitoring, candidate scoring, personalization, fraud models, advertising technology, and cross-session tracking.
4. Assess effects in Switzerland. Ask what foreign processing does to people, employment processes, customer relationships, or other interests in Switzerland. Do not assume every technical interaction creates a legally sufficient effect.
5. Assign roles by purpose. Determine who decides why and how data is used and who processes data on another organization’s instructions. A provider may be a processor for customer-directed service delivery but a controller for its own security analytics or model improvement.
6. Inventory personal-data processing. Review accounts, prompts, files, outputs, identifiers, telemetry, support records, training and validation data, inferred attributes, and retained model-improvement datasets.

Territorial scope is only the first gate. It is distinct from transfer compliance, representative appointments, controller and processor duties, privacy notices, individual rights, and AI-specific regulation. For example, a transfer from the EEA to Switzerland may be permitted under an adequacy framework while the recipient still has separate obligations for its own GDPR-regulated processing.

Currentness and legal notice: Last editorial review: 8 August 2026. This is a high-level scoping and governance guide, not a definitive statement of current regulator practice or case law. The supporting evidence includes third-party legal commentary and an institutional study rather than a complete set of current statutory, regulatory, and judicial authorities. Privacy and AI rules continue to develop. Confirm consequential or fact-specific conclusions against current official materials with qualified counsel. This content is informational and is not legal, HR, or employment advice, consistent with HRaizon’s informational-content notice.

What each law regulates—and where the EU AI Act fits

Neither the FADP nor the GDPR comprehensively regulates AI as a technology category. Both principally regulate the processing of personal data. A spreadsheet, database, or manual review process can therefore fall within privacy law, while an AI system that uses no personal data requires a different privacy analysis.

Personal data can enter an AI service at several stages:

• Training and fine-tuning
• Validation and evaluation
• Account registration and authentication
• Prompts, uploaded documents, and support conversations
• Outputs concerning identifiable people
• Device identifiers, usage logs, and telemetry
• Behavioral profiles and inferred attributes
• Rankings, recommendations, flags, and decisions
• Feedback retained for product or model improvement

The same record may support several purposes. A prompt might initially be processed to generate a response, then logged for security, reviewed during customer support, and later selected for model evaluation. Those purposes should be documented separately rather than grouped under a broad label such as “operating the AI.”

The EU AI Act is a separate regulatory framework covering the development, provision, deployment, and use of AI systems and general-purpose AI models. Its scope does not depend exclusively on personal-data processing. It may therefore apply to an AI system that processes no personal data, while the GDPR may apply to personal-data processing that does not involve an in-scope AI system. This comparison explains the distinct subject matter and possible concurrent application of the GDPR and EU AI Act.

Does the activity process personal data?	Is there an in-scope AI system or model?	Likely regulatory track
Yes	Yes	FADP and/or GDPR analysis, plus a separate EU AI Act analysis
Yes	No	FADP and/or GDPR may apply; the AI Act may not apply to that activity
No	Yes	The AI Act may apply even though privacy law is not triggered by personal-data processing
No	No	The activity may fall outside these regimes, although other laws can apply

This is a triage matrix, not a legal conclusion. A claim that a dataset contains “no personal data” should rest on an identifiability assessment. Removing names does not necessarily make records anonymous when they retain stable identifiers, detailed behavior, or information that can reasonably be linked back to individuals.

Governance documents should maintain separate tracks:

• Privacy track: territorial scope, purposes, roles, GDPR lawful bases or Swiss justification, transparency, individual rights, security, retention, transfers, profiling, and automated decisions.
• AI Act track: whether the technology is an AI system or general-purpose AI model, the organization’s role, territorial reach, risk classification, and applicable provider or deployer duties.

Satisfying the AI Act does not replace a GDPR or FADP assessment. Likewise, a privacy-compliant data flow does not establish AI Act compliance. Current application dates, classifications, exceptions, and implementation guidance should be checked against official EU materials rather than inferred from a general comparison.

Territorial scope: test the provider, users, market, monitoring, and local effects

Territorial analysis should focus on the entity and processing operation in question—not just the vendor’s headquarters.

The FADP can apply to circumstances initiated abroad that have effects in Switzerland. That principle should not be reduced to a rule that every Swiss visit, account, or data record creates jurisdiction. The available evidence does not establish a definitive test for every online AI service, so the nature and legal significance of the Swiss connection may require current official guidance or legal advice.

A Swiss provider may enter GDPR scope when it deliberately offers goods or services to people in the EU or monitors their behavior there. Relevant evidence can include EU-directed advertising, localized offers, supported EU delivery, EU-focused campaigns, and persistent observation of behavior in the EU. Mere accessibility, an isolated EU visitor, or the fact that a record concerns an EU citizen should not automatically be treated as sufficient.

The following scenarios illustrate the factual inquiry without announcing definitive outcomes.

Scenario 1: A Swiss-only chatbot

A company in Lausanne offers a chatbot to Swiss business customers. Its contracts, marketing, currency, support, and deployments are directed to Switzerland.

Questions include:

• Does an EU establishment participate in deciding the chatbot’s purposes or means?
• Is the service advertised or offered to people in the EU despite its “Swiss-only” label?
• Does the provider monitor behavior occurring in the EU?
• Do customer employees or end users enter personal data in prompts?
• Does the provider follow customer instructions, or does it reuse prompts for independent purposes?
• Where do hosting, support, safety review, and model processing occur?

The FADP is an obvious starting point, but the territorial conclusion should follow actual sales, organizational, and data-flow evidence.

Scenario 2: A Zurich SaaS provider advertising to EU users

A Zurich provider runs EU-targeted campaigns, accepts EU customers, and profiles in-product behavior to personalize recommendations.

Questions include:

• Which EU countries and customer groups are targeted?
• What evidence demonstrates an offering of services rather than incidental access?
• Which tracking, profiling, or personalization functions observe behavior in the EU?
• Does an EU affiliate participate in the processing?
• Is the provider a controller for behavioral analytics even if it acts as a processor for customer content?
• Does a possible EU representative requirement need to be assessed?

These facts can point toward simultaneous GDPR and FADP work, but each entity and processing purpose still requires separate classification.

Scenario 3: An EU vendor processing Swiss users’ activity

An EU-established fraud-detection vendor receives transaction or account activity relating to Swiss users.

Questions include:

• Is the information processed in the context of an EU establishment’s activities?
• Is the Swiss customer the controller and the vendor its processor?
• Does the vendor select independent fraud-intelligence or model-training purposes?
• Was the service deliberately offered in Switzerland?
• How extensive and regular is the processing?
• What effects can alerts or scores produce in Switzerland?
• Are onward transfers made outside Switzerland or the EEA?

The GDPR may apply through the EU establishment. A separate Swiss analysis may also be needed where the foreign processing has relevant effects in Switzerland.

Scenario 4: A non-European provider serving both markets

A provider outside Europe sells subscriptions in Switzerland and several EU countries, monitors usage, and reuses customer interactions to improve its models.

Questions include:

• How are the Swiss and EU markets targeted?
• Where are the monitored individuals located?
• Which entities determine the purposes of service delivery, telemetry, security, and training?
• Are prompts and outputs retained by default?
• Are sensitive or consequential use cases involved?
• Could the Swiss representative conditions be met?
• Does GDPR scope create a separate EU representative issue?
• Which transfers occur among customers, cloud hosts, support teams, and model vendors?

This provider may require parallel compliance programs, but that result cannot be inferred solely from having Swiss and EU customers.

Across all four scenarios, keep two questions distinct:

1. Establishment, offering, monitoring, and Swiss effects determine territorial reach.
2. Controller or processor status influences which obligations attach to each participant.

Roles can change by purpose. An enterprise AI vendor may act as a processor when generating text under documented customer instructions but as a controller when independently retaining prompts for misuse detection, analytics, or general model improvement. Contract labels are relevant, but the actual decisions and data uses remain central.

The central difference: GDPR lawful bases versus the Swiss private-sector model

One of the most important differences between the GDPR and Swiss private-sector law is the legal structure used to assess processing.

Under the GDPR, each personal-data processing purpose generally requires a documented lawful basis. The available categories include consent, performance of a contract, compliance with a legal obligation, protection of vital interests, performance of a task in the public interest, and legitimate interests. GDPR consent must be freely given, specific, informed, unambiguous, distinguishable, and withdrawable. This GDPR overview summarizes the lawful bases and consent conditions.

Consent is not always necessary or preferable. It may be unsuitable where processing is not genuinely optional, where withdrawal cannot realistically stop the activity, or where an imbalance limits freedom of choice. A provider should not choose consent merely because its interface can display an “accept” button.

Swiss private-sector law uses a different structure. Processing is generally permissible unless it unlawfully infringes personality rights or another condition requires justification. Swiss law should therefore not be presented as requiring a GDPR-style lawful basis for every processing purpose. Swiss consent is also structured differently; the need for consent and its legal consequences remain dependent on the purpose, data, risk, and justification being relied upon. This comparison explains the Swiss private-sector justification model and its distinction from the GDPR.

A mature program should record two analyses instead of using one combined “GDPR/FADP basis” field:

• GDPR analysis: Which lawful basis applies to the particular purpose? Are additional conditions relevant to sensitive data?
• Swiss analysis: Does the activity comply with Swiss processing principles and avoid an unlawful personality-right infringement? If justification is required, what justification applies?

AI data-purpose worksheet

Do not assess “the AI service” as one undifferentiated activity. Complete a row for each material purpose.

Purpose	Questions to document
Collection and account setup	Which contact details, identifiers, authentication records, and device data are collected, and from whom?
Service delivery	Which data must enter the application or model to provide the requested function?
Training and fine-tuning	Is personal data included intentionally or incidentally? Who selected the data and purpose?
Validation and evaluation	Are identifiable records used to test accuracy, bias, safety, or performance?
Prompt and file processing	Are prompts transient, logged, manually inspected, or sent to another provider?
Inference and profiling	Which preferences, risks, attributes, or predictions are derived?
Personalization	Is behavior used within one session or linked across accounts, devices, and services?
Fraud and abuse detection	Which indicators are generated, and can they restrict access or trigger investigation?
Telemetry and analytics	Are events aggregated, pseudonymized, account-linked, or combined with other datasets?
Model improvement	Is customer data reused beyond delivering the contracted service? Is participation optional?
Retention	How long is each copy kept in logs, backups, evaluation sets, and support tools?
Deletion	Which systems, recipients, derived records, and downstream copies are covered?

For every purpose, document:

1. Data categories and sensitivity
2. Affected people
3. Controller, joint-controller, or processor role
4. GDPR lawful basis, where applicable
5. Swiss personality-right and justification analysis
6. Collection source and recipients
7. Retention and deletion rules
8. Geographic data route and onward transfers
9. Privacy, security, fairness, and human-review controls
10. Accountable business and legal owners

Do not assign a lawful basis solely from a generic use-case label. “Model improvement,” “fraud prevention,” and “personalization” can describe materially different activities. The analysis depends on necessity, expectations, sensitivity, contractual context, available choices, potential consequences, and the provider’s role.

Profiling, AI-generated decisions, and individual rights

AI systems may use personal data both to learn general correlations and to make inferences or decisions about identifiable people. That distinction matters because a general model can become an individual profiling tool when applied to a person’s résumé, transactions, medical history, location, or workplace behavior.

Not every score, ranking, rejection, recommendation, or risk flag is automatically a qualifying automated individual decision. Relevant questions include:

• Is the outcome produced exclusively through automated processing?
• Does a person conduct a genuine review before the outcome?
• Does the reviewer have sufficient information and authority to depart from the model?
• Does the outcome have legal or similarly significant effects?
• Is the output advisory, or does it effectively determine what happens?
• Do downstream systems implement the output automatically?

Under the revised FADP, qualifying automated individual decisions must be disclosed, and affected individuals may request human intervention subject to the applicable statutory conditions. Profiling does not inherently require consent under the FADP. High-risk profiling changes the analysis, but express consent is relevant where consent is the justification being relied upon. The Swiss comparison discusses automated-decision disclosure, human intervention, profiling, and consent.

The precise line between ordinary and high-risk profiling is fact-sensitive and should be checked against current authoritative materials.

The GDPR can provide rights to information, access, correction, erasure, restriction, portability, and objection, as well as protections concerning profiling and automated decisions. Application of those rights depends on the data, purpose, role, and statutory conditions. An institutional study prepared for the European Parliament identifies continuing AI-related uncertainty involving profiling, explanations, purpose limitation, minimization, and automated decision-making. The EPRS study examines these GDPR and AI tensions in depth.

Example: AI in hiring

Consider a recruiting system that generates a candidate score.

A score used to organize applications for an independent recruiter review may require a different analysis from a workflow that automatically rejects every candidate below a threshold. Labels such as “recommendation only” and “human in the loop” do not determine the answer.

Teams should document:

• Which data and inferred attributes the model uses
• Whether the system ranks, recommends, advances, or rejects candidates
• What the reviewer sees in addition to the score
• Whether the reviewer understands the system’s limitations
• Whether the reviewer can override the recommendation
• Whether review occurs before the candidate is rejected
• How often reviewers actually depart from recommendations
• Whether workload or performance targets make review nominal
• How candidates receive applicable information and exercise rights

The supplied evidence does not establish a universal legal test for meaningful human involvement. As a practical risk-management measure, organizations should preserve evidence of reviewer authority, timing, information, training, and actual conduct rather than relying on the product’s marketing description.

Design rights workflows around where data persists

An AI service may distribute personal data across:

• Training and validation records
• Prompt and conversation logs
• Account and telemetry systems
• Safety-review queues
• Generated outputs
• Profiles and inferred attributes
• Embeddings and retrieval indexes
• Fine-tuning datasets
• Downstream customer systems
• Model parameters

The evidence does not establish a universal rule for locating, correcting, or deleting personal data in embeddings or model parameters. Providers should identify which artifacts remain reasonably linkable to individuals, determine their role for each copy, document technically available actions, and obtain stronger authority for unresolved cases.

Escalation is particularly important where a service uses sensitive data, affects vulnerable people, or contributes to consequential decisions.

Operational duties: privacy by design, records, DPIAs, notices, security, and breaches

The FADP and GDPR support a substantial shared operational baseline:

• Transparent descriptions of processing
• Privacy by design and by default
• Security appropriate to risk
• Accountable roles and decisions
• Processing records where required
• Workflows for individual requests
• Data protection impact assessments for qualifying high-risk processing
• Processor oversight
• Retention and deletion controls
• Incident detection and escalation

The revised FADP introduced or expanded information duties, processing records, impact assessments, security-breach reporting, and data portability. These measures bring Swiss governance closer to the GDPR, but the triggers, exemptions, thresholds, and procedures are not identical.

AI can make familiar privacy principles more difficult to implement. Large reusable datasets may create tension with purpose limitation and minimization. Inferred attributes can raise accuracy and fairness concerns. Training corpora may include sensitive data the provider did not intend to collect. Persistent logging may conflict with limited retention. Automated recommendations may reproduce discrimination or materially incorrect assumptions.

Pseudonymization and reduced linkability can be useful safeguards, but they should not be treated as automatic anonymization. A coded record may remain personal data if it can reasonably be reconnected to an individual. Data volume, detail, accessibility, linkage opportunities, and the processing purpose still matter.

DPIA screening questions

Screen an AI activity before launch and when a material change occurs. Indicators that may justify deeper DPIA analysis include:

• Sensitive or highly intimate data
• Extensive profiling or inference
• Systematic monitoring of workers, candidates, customers, or public spaces
• Large-scale or long-term processing
• Automated outcomes with legal or similarly significant effects
• Children, employees, patients, applicants, or other vulnerable groups
• Novel combinations of datasets
• New technology used in a consequential setting
• Material re-identification risk
• Discrimination or exclusion risk
• Limited ability to understand, contest, or avoid the processing
• Dependence on opaque vendors or complex onward data flows

A DPIA should not be treated merely as a launch form. As a governance practice, it should describe necessity and proportionality, identify risks to people, specify safeguards, assign owners, and track residual risk. Reassessment may be appropriate when the model, dataset, use case, population, threshold, vendor, or deployment environment changes.

Operational evidence to retain

Useful compliance evidence can include:

• A personal-data inventory
• A purpose and legal-analysis register
• Model architecture and data-flow diagrams
• Dataset provenance and selection records
• Retention schedules and deletion-test results
• Access-control matrices
• Security testing and remediation records
• Processor instructions and subprocessor decisions
• Risk assessments and accepted residual-risk decisions
• Human-review procedures and reviewer training
• Model limitation and escalation guidance
• Incident response and notification decision trees
• Rights-request search and response workflows
• Change-management records
• Named accountable owners

These are practical governance recommendations; whether a particular document is legally required depends on the applicable regime, role, risk, and statutory conditions.

AI-specific security reviews may need to consider prompt leakage, unauthorized model access, extraction of sensitive records, insecure integrations, cross-tenant exposure, poisoned datasets, excessive logging, and support access to customer content.

Breach procedures require separate legal paths

Swiss and GDPR breach rules have different thresholds and procedures. The GDPR’s supervisory-notification timing rule should not be described as a universal deadline for notifying affected individuals, and it should not be copied into a Swiss playbook without separate analysis.

Maintain a common operational process for detection, containment, evidence preservation, risk assessment, and escalation. Then create jurisdiction-specific decision paths addressing:

• Which authority may need notification
• The applicable risk threshold
• When a notification period begins
• What information must be supplied
• Whether affected individuals must be contacted
• Who approves the decision
• How the reasoning is recorded

The exact threshold, recipient, content, and timing rules should be checked against current authoritative materials for the incident in question.

Representatives, DPOs, processors, and cross-border transfers

Four privacy functions are frequently confused:

1. GDPR data protection officer: An independent oversight role required only in specified circumstances.
2. Swiss data protection adviser: A Swiss governance role that organizations generally are not required to appoint.
3. EU representative: A point of contact that some non-EU organizations within GDPR territorial scope may need.
4. Swiss representative: A role required for certain foreign private controllers when cumulative Swiss conditions are met.

A GDPR DPO may be required for public authorities and in specified circumstances involving qualifying large-scale, regular and systematic monitoring or qualifying large-scale processing of special-category or criminal-offense data. The analysis depends on core activities, scale, regularity, and data—not simply on whether an organization uses AI. This GDPR overview summarizes the conditional DPO triggers and accountability framework.

Swiss law generally does not require an organization to appoint a data protection adviser. A company may still designate privacy leadership voluntarily, but that governance role is not interchangeable with a statutory representative.

Swiss representative test

A foreign private controller must appoint a Swiss representative only if all relevant conditions are satisfied. The cited framework identifies:

• A connection to offering goods or services in Switzerland or monitoring behavior there
• Extensive and regular processing
• High risk to data subjects’ personality

This is a cumulative test, not an automatic consequence of having one Swiss user. The Swiss data-protection guide summarizes the cumulative representative conditions.

A Swiss provider within GDPR territorial scope may separately need an EU representative. Exceptions may apply, but the supplied evidence does not support a complete exceptions analysis. A Swiss representative should not be assumed to perform the statutory function of an EU representative, or vice versa.

Adequacy solves only the transfer question

The available comparison reports that Switzerland’s EU adequacy status generally permits covered transfers from the EEA to Switzerland without additional transfer safeguards for that route. Adequacy concerns international transfer restrictions; it does not certify the recipient’s entire service as GDPR compliant. This overview explains the reported effect of Switzerland’s adequacy status on EEA-to-Switzerland transfers.

Adequacy does not remove the need to assess:

• The lawful basis for processing
• Transparency and privacy notices
• Controller and processor responsibilities
• Security measures
• Purpose limitation and retention
• Individual rights
• Profiling and automated decisions
• Subsequent transfers outside Switzerland
• Separate GDPR territorial scope

Before relying on adequacy for an important transfer, verify the current status and scope against current European Commission materials.

Map the full data route

Do not stop a transfer map at “customer to Swiss provider.” Trace:

• Customer systems
• Integration and identity providers
• Swiss or EEA application infrastructure
• Cloud hosting regions
• Foundation-model and API vendors
• Content-moderation services
• Analytics and logging platforms
• Support and engineering access
• Backup and disaster-recovery locations
• Subprocessors
• Onward transfers outside Switzerland or the EEA

For each leg, record the asserted transfer mechanism, contractual restrictions, security measures, access locations, and onward-transfer rules. Do not assume that adequacy makes every transfer lawful or that one set of contractual clauses resolves every onward-transfer scenario.

A GDPR baseline plus Swiss add-ons: the practical compliance plan

A mature GDPR program provides reusable documentation, controls, and organizational habits. It is a baseline—not proof of FADP compliance.

1. Confirm territorial scope

Document participating establishments, intended markets, monitoring, and possible Swiss effects. Keep GDPR and FADP conclusions separate and identify assumptions requiring legal confirmation.

2. Inventory AI data and purposes

Map training data, validation records, prompts, outputs, telemetry, inferred attributes, support content, safety logs, and model-improvement reuse. Separate customer-directed service delivery from the provider’s independent purposes.

3. Assign controller and processor roles

Allocate roles by purpose rather than by product. Record where a customer gives instructions, where the vendor makes independent decisions, and whether affiliates or deployment partners may share control.

4. Perform both legal analyses

For each purpose, document the GDPR lawful basis where applicable. Separately assess Swiss processing principles, personality-right implications, and any required justification. Do not translate a GDPR lawful-basis field mechanically into Swiss terminology.

5. Screen for profiling, automated decisions, and DPIAs

Examine the degree of automation, significance of outcomes, actual reviewer authority, scale, sensitivity, monitoring, vulnerable groups, and discrimination risk. Test real workflows rather than relying on feature names.

6. Update privacy notices

Describe data categories, purposes, recipients, retention, rights, and automated processing as applicable. Review Swiss-specific notice and export requirements against current authority instead of assuming a GDPR notice necessarily covers them.

7. Review processors and subprocessors

As a risk-management exercise, examine documented instructions, confidentiality, security, deletion and return processes, assistance with rights and incidents, approval controls, audit evidence, and onward data use. Pay particular attention to model providers that reserve rights to reuse prompts or outputs.

The exact contractual requirements should be confirmed under the applicable law rather than inferred from this general checklist.

8. Map transfers

Trace hosting, support, logging, model-processing, and backup locations. Distinguish EEA-to-Switzerland adequacy from onward transfers and remote access from other countries.

9. Test representative and DPO triggers

Assess the GDPR DPO, EU representative, Swiss data protection adviser, and Swiss representative independently. Record the rationale for each appointment or non-appointment.

10. Align rights and incident workflows

Build common intake and investigation processes, then add jurisdiction-specific decision paths. Test whether teams can locate personal data across prompts, logs, profiles, outputs, evaluation datasets, and downstream platforms.

11. Assign accountable owners

Name the people who approve new purposes, accept residual risk, authorize subprocessors, decide breach escalation, oversee human review, and sign off on consequential deployments.

Swiss overlays to review explicitly

A GDPR-ready provider should separately examine:

• Swiss notice and personal-data export disclosures
• Conditions for appointing a Swiss representative
• Profiling and high-risk profiling
• Disclosure and intervention rights for qualifying automated individual decisions
• Swiss breach thresholds and reporting procedures
• Exemptions affecting processing-record duties
• The Swiss private-sector justification structure
• Individual criminal-liability exposure

The enforcement models differ without either regime being universally “stricter.” GDPR penalties can reach EUR 20 million or 4% of worldwide annual turnover, while the cited Swiss framework describes intentional-violation fines of up to CHF 250,000, directed primarily at responsible individuals.

Swiss commentary also describes a separate enforcement path under which the Federal Data Protection and Information Commissioner may issue corrective orders, including orders restricting or stopping processing, but does not directly impose the cited criminal fines.

Individual exposure makes decision ownership a governance concern. Organizations should define approval authority, escalation routes, training requirements, and evidence of who reviewed material privacy decisions—particularly where product, engineering, procurement, or HR teams can enable new data uses.

Preliminary compliance and verification checklist

Baseline operational controls

• [ ] The data inventory covers the full AI lifecycle
• [ ] Purposes are separated and documented
• [ ] Controller and processor roles are assigned by purpose
• [ ] Privacy-by-design review is incorporated into change management
• [ ] Access, security, retention, and deletion controls are tested
• [ ] Rights-request and incident workflows have accountable owners
• [ ] Processor and subprocessor data uses are understood
• [ ] International data routes are mapped
• [ ] Notices reflect actual processing
• [ ] Risk decisions and approvals are retained

Conditional legal triggers

• [ ] GDPR lawful basis identified for each in-scope purpose
• [ ] Additional sensitive-data conditions assessed
• [ ] DPIA requirement screened
• [ ] Profiling and automated-decision rules assessed
• [ ] GDPR DPO trigger tested
• [ ] EU representative trigger and exceptions reviewed
• [ ] Swiss representative conditions tested cumulatively
• [ ] Processing-record exemptions checked rather than assumed

Swiss-specific verification

• [ ] Personality-right and justification analysis documented
• [ ] Swiss notice and export disclosures checked against current authority
• [ ] Swiss profiling classification examined
• [ ] Automated-decision disclosure and intervention procedures tested
• [ ] Swiss breach threshold and reporting path documented
• [ ] Corrective-order exposure considered
• [ ] Individual criminal-liability risk reflected in governance and training

Questions requiring current official sources or counsel

• [ ] Does the foreign processing create legally sufficient effects in Switzerland?
• [ ] Is the particular profiling activity high risk under the FADP?
• [ ] Is human review legally meaningful in the actual workflow?
• [ ] How do rights apply to personal data in logs, embeddings, datasets, or model parameters?
• [ ] Are purportedly anonymous or synthetic datasets genuinely outside personal-data scope?
• [ ] What current EU AI Act duties and application dates govern the service?
• [ ] Do employment, finance, healthcare, insurance, biometrics, government, or other sectoral rules apply?

Frequently asked questions

Does the GDPR apply to every Swiss AI company with an EU user?

No. A Swiss company is not automatically subject to the GDPR merely because one person in the EU accesses or uses its service.

Relevant questions include whether an EU establishment participates in the processing, whether the provider deliberately offers goods or services to people in the EU, and whether it monitors their behavior there. Incidental access and deliberate market activity are not equivalent.

Does Switzerland’s EU adequacy status mean a Swiss AI provider is GDPR compliant?

No. Adequacy addresses a covered transfer route. It does not certify the provider’s broader processing or eliminate other GDPR requirements.

The provider may still need to assess territorial scope, lawful basis, notices, individual rights, security, processor governance, profiling, automated decisions, and onward transfers. Current adequacy status and scope should be confirmed against official European Commission materials before reliance.

Is consent always required to train or improve an AI service with personal data?

No. The GDPR recognizes several lawful bases, and the appropriate basis depends on the specific purpose and facts. Swiss private-sector law does not impose a GDPR-style lawful-basis requirement on every activity.

Training and improvement should be separated from service delivery and assessed for necessity, reasonable expectations, sensitivity, role allocation, retention, safeguards, and available choices. The interaction between AI and purpose limitation, minimization, lawful bases, and individual rights remains context-dependent. The EPRS study examines these issues without prescribing one basis for every AI use.

Does adding a human reviewer prevent an AI outcome from being treated as an automated decision?

Not necessarily. The reviewer’s involvement must be assessed in practice.

Relevant facts include what information the reviewer receives, whether they can challenge and depart from the output, whether review occurs before the outcome, and whether workload or internal policy makes approval effectively automatic. Document the reviewer’s authority, evidence, timing, training, and actual conduct.

Which is stricter for AI services: the Swiss FADP or the GDPR?

Neither can be labeled universally stricter.

The GDPR generally requires a lawful basis for each processing purpose and provides for substantial turnover-based penalties. Swiss private-sector law uses a different justification model but has its own rules concerning notices, profiling, representatives, breaches, automated decisions, corrective orders, and individual liability.

The useful question is not which law is stricter in the abstract. It is which obligations attach to the provider’s entities, data, purposes, markets, monitoring, roles, risks, and automated outcomes.

Conclusion: facts before labels

Dual compliance begins with facts: where participating entities are established, which markets they deliberately serve, whether behavior is monitored, what effects occur in Switzerland, what personal data enters each AI lifecycle stage, and who controls each purpose.

Use GDPR documentation and controls as an operational foundation, then complete a documented Swiss overlay covering scope, notices, representatives, profiling, automated decisions, breach response, transfers, and individual accountability. Run the EU AI Act analysis separately.

Consequential, unresolved, or high-risk deployments should be reviewed against current official materials with qualified counsel. Additional employment, finance, healthcare, insurance, biometric, public-sector, and other sector-specific rules may also apply.