Feature 9 August 2026

What AI Teams Must Change When Moving From GDPR Compliance to Swiss Compliance

Priya Ellison

Legal review date: 10 August 2026. This vendor-neutral guide is informational only and is not legal, HR, or employment advice. Requirements vary by organization, use case, and jurisdiction; confirm the current position with qualified counsel before acting. See HRaizon’s terms and important notice.

FADP and GDPR at a glance: similar foundations, different compliance consequences

An AI service that follows the EU General Data Protection Regulation is not automatically compliant in Switzerland. A mature GDPR program supplies useful infrastructure—data inventories, privacy notices, security controls, vendor reviews, impact assessments, and incident procedures—but it still needs a Swiss scope and gap assessment.

Switzerland’s principal federal personal-data framework consists of the Federal Act on Data Protection, commonly called the FADP, and its implementing ordinances. The revised FADP took effect on 1 September 2023 and protects personal data relating to natural persons. The Federal Data Protection and Information Commissioner, or FDPIC, is the federal supervisory authority. The revision brought Swiss law closer to the GDPR partly to support European adequacy, but it retained material Swiss deviations in areas such as territorial reach, representatives, breach reporting, and sanctions, as summarized in this overview of Swiss data-protection law.

The FADP is technology-neutral rather than a comprehensive AI statute. It applies directly when AI-supported activity involves regulated processing of personal data. Depending on the system, that processing can occur during collection, model development, prompting, inference, monitoring, improvement, and output handling—not only in an original training dataset. The FDPIC expressly applies the technology-neutral framework to AI manufacturers, providers, and users in its guidance on AI and data protection.

The following table is a practical operational overview, not an exhaustive article-by-article comparison. In particular, it does not attempt to compare every lawful basis, justification, data-subject right, DPO rule, representative rule, or automated-decision provision under the two regimes.

Issues	Practical Swiss FADP position	GDPR comparison and operational consequence
Effective scope and foreign representatives	The FADP can reach circumstances initiated abroad that have effects in Switzerland. A foreign private controller’s representative duty is separate and depends on cumulative targeting or monitoring, regularity, scale, and risk conditions.	Do not substitute a GDPR territorial or representative analysis for the Swiss tests. Applicability does not itself establish a Swiss representative duty. These distinctions are outlined in a current Swiss jurisdiction and role overview.
Privacy by design and default; profiling; DPIAs	Safeguards must be considered during planning, and defaults must limit processing to what is required. Swiss law separately defines profiling and high-risk profiling. A DPIA is required where planned processing is likely to create a high risk to personality or fundamental rights.	Existing GDPR product reviews and impact assessments can be reused, but teams should check Swiss terminology, affected populations, risk framing, and conclusions. The FDPIC confirms that high-risk AI processing requires an impact assessment and appropriate safeguards.
Breach reporting and enforcement	Swiss breach reporting uses a likely-high-risk threshold and an “as soon as possible” standard. The FDPIC may impose corrective measures, while specified intentional violations can expose responsible individuals to criminal penalties.	Do not run a blended Swiss-EU incident test. Assess the applicable thresholds, clocks, authorities, and potential defendants separately.
Data-protection officers and governance	A private controller is not universally required to appoint a Swiss data-protection officer. That does not remove the need for competent ownership, advice, escalation, and records where applicable.	An existing privacy office or DPO function can support Swiss compliance, but its existence is not evidence that all Swiss duties have been addressed.
International transfers	Swiss law permits foreign disclosures through adequacy and recognized safeguards, subject to the applicable conditions.	GDPR transfer work may be reusable, but recipient status, access patterns, contractual language, onward transfers, and Swiss adaptations still require review. The governing Swiss provisions appear in the Federal Act on Data Protection.

The English Fedlex translation is informational and has no legal force; the authoritative official-language texts control.

The central takeaway is straightforward: treat GDPR compliance as reusable infrastructure, not as a Swiss compliance certificate.

When the Swiss FADP reaches an AI service outside Switzerland

The FADP can apply to circumstances having effects in Switzerland even when the relevant conduct begins abroad. That calls for a fact-specific effects analysis.

The Swiss and EU inquiries may overlap in commercial practice, but teams should not assume that their legal boundaries are identical or that one is categorically broader.

For an AI service, a practical Swiss scope assessment should examine:

Who is affected and whether those people are in Switzerland.
Whether Switzerland is an intended service market or merely an incidental source of traffic.
Whether the service observes, tracks, scores, or predicts behavior in Switzerland.
The purposes of the processing and the provider’s role in determining them.
Whether prompts, uploaded files, inferred attributes, or outputs contain personal data.
Whether processing is continuous, consequential, or connected with employment or another important interest.
What effects on people in Switzerland were reasonably foreseeable.
Which organization makes the relevant decisions and which acts only on documented instructions.

Consider a generative-AI provider with no Swiss office. A person in Geneva creates an account and uploads a document containing customer information. Access by that user should not be presented as the decisive legal test. The provider should instead assess its intended market, foreseeable effects, retention and reuse of prompts, profiling, disclosures, and whether it independently determines model-improvement purposes.

The analysis becomes more significant in AI hiring. A foreign vendor may rank applicants in Switzerland, predict work performance, infer reliability, analyze behavior, or monitor assessment activity. Those functions directly concern people in Switzerland and may materially shape access to employment. They do not automatically settle every scope or role question, but they warrant a documented assessment rather than a conclusion based only on the vendor’s place of incorporation.

Server location is also not a substitute for legal analysis. Conversely, infrastructure outside Switzerland does not by itself place processing beyond the FADP.

The federal/private-sector distinction matters. Private organizations generally work from the federal FADP framework, while cantonal and local public bodies may be governed by separate cantonal legislation. Employment, health, finance, professional secrecy, discrimination, public-sector, and other regulated uses may also face additional rules.

A Swiss provider serving people in the EU may separately need to assess the GDPR and, depending on the system and activity, the EU AI Act. This article does not establish the detailed obligations of those other regimes.

Map the AI data lifecycle and assign controller, processor, and subprocessor roles

Start by mapping the complete lifecycle:

Collection from applicants, employees, customers, public sources, or licensed datasets.
Dataset cleaning, labeling, enrichment, filtering, and preparation.
Initial model training or fine-tuning.
Prompt, file, image, audio, or API submission.
Inference and creation of scores, classifications, embeddings, or generated content.
Delivery and use of outputs.
Quality assurance, abuse detection, security monitoring, and human support access.
Reuse for evaluation, analytics, or model improvement.
Retraining or transfer into another model or dataset.
Retention in primary systems, logs, caches, and backups.
Export, correction, anonymization, and deletion.

A typical service may involve a foundation-model developer, an application provider, an employer or enterprise customer, a cloud infrastructure provider, support personnel, and several subprocessors. An application vendor might process candidate files on an employer’s instructions while independently determining how telemetry is used to improve its general service.

The FADP uses controller and processor concepts. Processor engagement must meet the statutory conditions, and a processor must obtain the controller’s prior approval before appointing a subprocessor. Those requirements appear in the FADP’s processor-governance provisions.

For procurement and contracting, document at least:

The processing purpose and permitted instructions.
Which party decides how training, inference, monitoring, and improvement occur.
The categories of inputs, outputs, logs, and inferred data.
Security responsibilities and access controls.
Approved subprocessors and the procedure for changes.
Retention, backup treatment, deletion, and return or export.
When vendor employees or contractors may view customer content.
Incident detection, investigation, and escalation responsibilities.
Hosting locations and international remote access.
Whether customer inputs or outputs may be reused for training, evaluation, or other customers.
Assistance with requests, impact assessments, audits, and regulatory inquiries.
Treatment of data and model artifacts when the service ends.

This is a combined role-governance and AI due-diligence checklist. It does not mean every term is expressly mandated in identical wording for every contract.

The available framework also does not conclusively resolve every joint-controller, downstream-liability, or model-supply-chain question. Where several parties determine purposes, reuse the same data, or assert incompatible roles, obtain qualified legal advice before launch.

Shared controls: lawfulness, transparency, proportionality, security, and privacy by design

Many GDPR controls can be adapted because the FADP uses familiar processing principles. The Swiss analysis should nevertheless be documented in its own terms.

Processing should be assessed for lawfulness, good faith, proportionality, and compatibility with a specified or apparent purpose. Teams should also address data accuracy and what happens when identifiable data is no longer needed for that purpose.

Privacy by design means building appropriate safeguards into planning and development rather than adding a notice after deployment. Privacy by default means configuring the service so that default processing is limited to what is required. Security should be appropriate to the relevant risks and should seek to prevent data-security breaches.

Translate those principles into concrete design questions:

What personal data is collected at each lifecycle stage?
Why is each field, uploaded document, metadata item, or inferred attribute needed?
Could the same objective be achieved with less data or a less intrusive method?
Are unrestricted free-text prompts necessary, or could structured inputs reduce exposure?
Who can access prompts, outputs, candidate files, and evaluation logs?
Are support staff prevented from browsing customer content without a defined need?
How long are prompts, outputs, embeddings, telemetry, and backups retained?
Does deletion propagate through production systems and downstream processors?
Can data be anonymized rather than kept in identifiable form?
How are inaccurate source data and unreliable inferences identified and corrected?
Do defaults enable optional training reuse, broad sharing, or extended retention?
Can the organization explain why the processing is proportionate to its purpose?

Consent should not be treated as a universal answer to AI processing. A hiring team should not add a broad “I consent to AI” checkbox and assume its work is complete. It should first identify the processing, purpose, roles, justification, consequences of refusal, and whether consent could genuinely be voluntary in the relationship.

Where consent is the applicable justification, teams should assess whether it is voluntary, specific, and informed. Express consent may be required in specified circumstances involving sensitive personal data or high-risk profiling when consent is the justification relied upon. That does not mean sensitive data can only ever be processed with consent; the full justification analysis depends on the facts and applicable law.

Architecture preferences should also be distinguished from legal mandates. Swiss hosting, zero retention, and avoiding U.S. infrastructure may be sensible controls for a particular project, but none is a universal FADP requirement. The proper question is whether the selected architecture supports lawful, proportionate, transparent, secure processing and valid transfer arrangements.

How Swiss rules apply to AI profiling, transparency, and automated decisions

Swiss profiling includes automated processing used to evaluate specified personal aspects or predict characteristics such as work performance, economic situation, health, preferences, interests, reliability, behavior, location, or movements.

High-risk profiling is narrower. It concerns profiling that poses a high risk to personality or fundamental rights by matching data in a way that permits assessment of essential aspects of a person’s personality.

Those definitions help prevent four common overstatements:

Not every AI function is profiling.
Not every profiling activity is high-risk profiling.
Not every high-risk AI use is high-risk profiling.
Not every score, draft, recommendation, or ranked list is an automated individual decision.

In recruitment, résumé ranking or candidate scoring may evaluate or predict work performance or reliability. Whether it also amounts to high-risk profiling depends on the data matching, depth of assessment, resulting risk, and consequences. Whether it constitutes or contributes to an automated individual decision is a separate, fact-specific question.

The supplied evidence does not support a complete statement of every statutory element governing automated individual decisions. Teams should therefore avoid treating any informal “human in the loop” formula as a conclusive legal test.

As practical governance, review is more credible when the reviewer:

Understands the nature and limitations of the output.
Can examine relevant source information.
Has authority to disagree with the system.
Actually considers the individual case.
Is not expected to approve the recommendation routinely.

These are operational safeguards, not a verbatim statutory threshold. An entirely automated rejection warrants a different analysis from a score that informs a genuinely independent, documented assessment.

Transparency should reflect the real system. Relevant disclosures may include:

That AI is used and where it enters the workflow.
The purposes for which personal data is processed.
The principal data sources and categories.
What the system does in terms understandable to the affected person.
Whether information is used for training, evaluation, or model improvement.
Whether profiling occurs and which characteristics are assessed.
The role of an output in a consequential decision.
Whether and how a person reviews the decision, where applicable.
Relevant retention, recipients, and international disclosures.

For interactive language models, users should be told that they are communicating with a machine and whether submitted information is used to improve a self-learning system or for another purpose. The FDPIC also links transparency with objection to automated processing and human review of automated individual decisions.

That does not establish a universal right to human review for every autocomplete suggestion, recommendation, risk flag, or generated draft. The legal characterization depends on the processing and on how the output is used.

Programs that manipulate identifiable people’s faces, images, or voices should clearly disclose the manipulation. Criminal or other laws may also apply depending on the conduct.

The FDPIC identifies comprehensive real-time facial recognition and comprehensive observation and evaluation of lifestyle—often described as social scoring—as examples incompatible with privacy and informational self-determination. That position should not be generalized into a claim that every facial-recognition or scoring application is automatically prohibited. Each use still requires analysis of its design, purpose, scale, context, and effect.

High-risk AI, DPIAs, records, and the Swiss representative test

A Swiss data protection impact assessment is required when planned processing is likely to create a high risk to personality or fundamental rights. AI use alone does not automatically meet that threshold. High-risk AI processing is permitted in principle when appropriate safeguards are adopted, although particular privacy-subverting practices may be impermissible.

Practical screening considerations include:

Sensitive, genetic, or uniquely identifying biometric data.
Possible high-risk profiling.
Extensive monitoring of applicants, workers, customers, or the public.
Consequential employment, health, financial, or access assessments.
Large-scale processing or combination of multiple datasets.
Predictions about work performance, health, reliability, behavior, or location.
Vulnerable people or a significant imbalance of power.
Novel processing whose consequences may be difficult to anticipate or reverse.

Some of those considerations reflect prudent risk governance rather than a verbatim statutory trigger list. Teams should record why each factor does or does not create high risk in the actual project.

An operational DPIA can cover:

The intended purpose and end-to-end data flow.
The organizations and roles involved.
Necessity and proportionality.
Risks to affected people, not only risks to the organization.
Accuracy, discrimination, misuse, disclosure, and security scenarios.
Safeguards, including data reduction and access limitations.
Human oversight and challenge procedures.
Retention, anonymization, and deletion.
International access and transfer safeguards.
Residual risk, approval, ownership, and review triggers.

This is practical operating guidance, not a verbatim statutory checklist. A pre-existing GDPR DPIA can often be adapted, but it should expressly address affected people in Switzerland, Swiss legal concepts, the actual AI lifecycle, and residual Swiss risks.

Controllers and processors maintain records of processing activities, subject to exceptions that may apply to certain organizations with fewer than 250 employees where processing presents negligible risk. Private controllers are not universally required to appoint a Swiss data-protection officer.

The representative question must be separated from territorial scope. A foreign organization can be subject to the FADP without being required to appoint a representative.

For a foreign private controller, assess whether the relevant processing:

Concerns people in Switzerland.
Relates to offering goods or services in Switzerland or monitoring behavior there.
Occurs regularly.
Occurs on a large scale.
Poses a high risk to personality or fundamental rights.

These conditions are cumulative. The representative serves as a Swiss point of contact, but appointment is neither universal nor something that should be dismissed categorically as rare.

A compact decision tree is:

Are there relevant effects in Switzerland? If not, document the conclusion and monitor changes.
Is the foreign organization a controller for the processing? If it acts only as a processor, assess its other duties without automatically applying the foreign-controller representative rule.
Does the processing concern people in Switzerland?
Does it relate to offering goods or services there or monitoring behavior there?
Is it regular?
Is it large scale?
Does it pose high risk?
If every condition is met, assess appointment, publication, responsibilities, and supporting records with counsel.

“Regular,” “large scale,” and “high risk” require a fact-specific assessment. Borderline conclusions—including uncertainty about how safeguards affect the risk analysis—should be recorded and reviewed by qualified Swiss counsel.

International transfers, security incidents, and enforcement differ in important ways

International-transfer analysis should follow the data, not only the server. Remote support access, cloud hosting, subprocessors, security monitoring, content moderation, and model-improvement pipelines can all result in personal data being disclosed abroad.

Swiss personal data may be disclosed abroad on the basis of adequacy or recognized safeguards, including appropriately adapted standard contractual clauses and approved binding corporate rules. The Swiss-U.S. Data Privacy Framework can support transfers to certified U.S. recipients, but the organization should verify current certification and whether the actual recipient and relevant use are covered, as outlined in this Swiss transfer-framework summary.

For each AI service, map:

Primary and backup hosting.
Administrative and support-access locations.
Subprocessors and onward transfers.
Logging, abuse-detection, and telemetry destinations.
Training, fine-tuning, evaluation, and annotation pipelines.
Human review of prompts or outputs abroad.
Contractual safeguards and Swiss adaptations.
Encryption, access segregation, and other technical controls.

Incident response is an area where copying a GDPR procedure without modification can create errors. Under the Swiss rule, a controller notifies the FDPIC as soon as possible when a data-security breach is likely to create a high risk to personality or fundamental rights. The supplied comparative materials summarize the GDPR supervisory-notification rule as using a risk threshold and a 72-hour deadline, subject to the exception where the breach is unlikely to result in a risk.

A dual-jurisdiction workflow should:

Contain the incident and preserve evidence.
Identify affected systems, datasets, models, credentials, and vendors.
Identify affected Swiss, EU, and other populations.
Start the applicable GDPR assessment and clock immediately.
Assess and document the separate Swiss likely-high-risk threshold.
Notify the relevant authority where its legal test is met.
Assess whether communication to affected people is required or necessary for their protection.
Record decisions, uncertainties, mitigation, and later updates.
Review processor escalation and contractual notice obligations.
Reassess the incident as new facts emerge.

Swiss law does not impose the same fixed 72-hour period described for the GDPR. “As soon as possible” is not permission to delay unnecessarily.

Enforcement also changes the governance calculation. The FDPIC may order processing to be corrected, suspended, or stopped, or may order data to be deleted. Specified intentional Swiss violations can expose responsible natural persons to criminal fines of up to CHF 250,000. In the limited situation where identifying the responsible individual would require disproportionate investigative effort, an organization may instead face a lower fine.

By contrast, the supplied comparison describes GDPR administrative fines as principally directed at organizations and reaching EUR 20 million or 4% of worldwide annual turnover for specified infringements. These numeric and structural differences are summarized in an analysis of the revised FADP.

Organizations should not describe the Swiss maximum as a routine GDPR-style corporate administrative penalty. Appropriate governance includes named control owners, approval records, training, escalation routes, and documented responses to known risks.

A GDPR-to-FADP gap checklist for AI services and AI hiring tools

A GDPR certificate, vendor statement, or global privacy policy does not prove Swiss compliance. Before launching, procuring, or materially changing an AI service, use the following checklist as an operational review—not as a substitute for project-specific legal advice.

1. Scope and roles

Document actual and reasonably foreseeable effects in Switzerland.
Identify affected applicants, employees, customers, users, and non-users.
Record whether Switzerland is an intended market.
Assign controller and processor roles operation by operation.
Identify subprocessors, infrastructure providers, support teams, and model providers.
Test separately whether the GDPR applies.
Identify overlapping cantonal, employment, health, financial, public-sector, secrecy, or sector-specific rules.

2. Data inventory

Map each data asset separately:

Training and fine-tuning data.
Prompts and uploaded documents.
Applicant résumés and application-form answers.
Audio, video, images, and transcripts.
Voiceprints and other biometric templates.
Inferred characteristics and predicted attributes.
Candidate scores, rankings, and recommendations.
Model outputs and generated summaries.
Embeddings and vector-database records.
Usage, audit, security, and performance logs.
Support tickets and human-review access.
Backups, caches, and evaluation datasets.

Do not assume that public availability, encryption, pseudonymization, inference, or conversion into an embedding automatically places information inside or outside data-protection law. Analyze identifiability, purpose, access, and available means in context.

3. Purpose and proportionality

State each purpose clearly.
Link every input category to a documented need.
Distinguish service delivery from analytics and model improvement.
Determine whether less data or a less intrusive method could achieve the purpose.
Establish accuracy and quality controls.
Define retention by data category and system.
Explain how deletion or anonymization works.
Address derived data, logs, backups, and downstream copies.
Reassess the purpose before reusing information.

4. Transparency

Tell affected people, as applicable:

That they are interacting with or being evaluated by AI.
The processing purposes.
The system’s relevant functionality.
The principal data sources.
Whether their information supports training or model improvement.
Whether profiling occurs.
How scores or outputs affect a decision.
Whether meaningful human consideration takes place.
How to exercise applicable rights or challenge an automated individual decision.
Relevant recipients, retention, and international disclosures.

Avoid vague statements such as “we use AI to improve your experience” when the system ranks applicants, predicts behavior, or reuses submissions for training.

5. Risk governance

Screen for sensitive, genetic, and biometric data.
Decide whether processing may constitute profiling.
Conduct a separate high-risk-profiling analysis.
Assess the scale and intrusiveness of monitoring.
Identify consequential individual decisions.
Determine whether a Swiss DPIA is required.
Adapt any GDPR DPIA instead of assuming it is sufficient.
Record safeguards, residual risks, approvals, and review dates.
Reassess after changes to models, datasets, purposes, or subprocessors.

6. Human oversight

Identify who reviews consequential outputs.
Confirm that the reviewer understands the result and its limitations.
Give the reviewer access to relevant source information.
Give that person genuine authority to change the outcome.
Address automation bias through training, testing, and sampling.
Record departures from model recommendations where appropriate.
Provide a challenge and review route where the applicable automated-decision rules require one.
Do not describe nominal sign-off as human judgment if the outcome is effectively predetermined.

7. Vendor governance

Examine:

Whether inputs and outputs are reused for training.
Whether optional training is enabled by default.
Human access for support, moderation, or quality assurance.
Retention in production, logs, backups, and abuse-monitoring systems.
Security controls and available incident information.
Approved subprocessors and change notifications.
Hosting, remote administration, and onward transfers.
Incident-notification timing and content.
Export, correction, deletion, and termination support.
Assistance with DPIAs and affected-person requests.
Restrictions on combining customer data with other datasets.
Evidence supporting privacy and security representations.

Treat vendor statements as due-diligence inputs, not independently verified proof.

8. Swiss additions to the GDPR baseline

Record the effects-based scope analysis.
Test every cumulative representative condition.
Confirm whether processing-record duties or an exception apply.
Adapt transfer documents and clauses for Switzerland.
Verify recipients relying on adequacy or certification.
Add the Swiss likely-high-risk threshold to incident playbooks.
Establish escalation to the FDPIC.
Assign responsible individuals and document approvals.
Train relevant staff on potential personal criminal exposure.
Confirm when authoritative official-language text or Swiss legal advice is required.

Applying the checklist to an AI hiring tool

Suppose an employer uses a foreign vendor to rank applicants for roles in Zurich and Basel.

First, inventory the applicant’s résumé, application answers, assessment results, interview recordings, inferred skills, work-performance predictions, ranking, recruiter notes, and system logs. Determine whether the system collects or infers health, biometric, or other sensitive data.

Second, map roles by operation. The employer may determine the hiring purpose while the vendor processes applications and produces scores on its instructions. If the vendor reuses applicant information to improve a general model, that additional decision and purpose require separate analysis.

Third, explain the workflow to candidates. The notice should identify the use of automated evaluation, principal data sources, relevant functionality, and the role of the score. If the system makes or contributes to a potentially automated individual decision, assess the applicable notice, objection, and review requirements rather than assuming that every ranking triggers the same rule.

Fourth, test profiling and risk. Predicting work performance or reliability may amount to profiling. Combining several datasets to assess essential aspects of a candidate’s personality may raise the high-risk-profiling question. Consequential scoring, sensitive data, large-scale use, or extensive monitoring may make a DPIA more likely.

Fifth, make human oversight real. A recruiter should have enough information and authority to challenge the ranking—not merely click “approve.” Set documented retention limits for unsuccessful applications, logs, recordings, and derived scores.

Finally, map cross-border infrastructure and support access, verify subprocessors and transfer safeguards, test the Swiss representative conditions, and maintain separate Swiss and GDPR incident paths where both populations may be affected.

Escalate to qualified counsel where there is:

An unclear justification for collection, training, monitoring, or reuse.
Biometric identification or analysis.
Possible high-risk profiling.
A fully automated consequential decision.
Extensive applicant or employee monitoring.
Uncertainty about representative status.
Ambiguous controller or processor roles.
A simultaneous Swiss and EU security incident.
Interaction with employment, cantonal, regulated-sector, GDPR, or EU AI rules.

An AI service should treat GDPR compliance as a foundation, not a substitute for Swiss analysis. The practical next step is a documented gap review covering territorial effects, processing roles, AI transparency, profiling and DPIA risk, records, representatives, transfers, incidents, and potential personal enforcement exposure.

Frequently asked questions

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

No. GDPR controls for transparency, security, privacy by design, vendor management, records, and impact assessment may be reusable, but the regimes are not equivalent. Swiss territorial effects, representative conditions, profiling terminology, breach rules, transfer arrangements, record exceptions, and enforcement require a separate assessment, as reflected in the Swiss jurisdiction summary.

Does every foreign AI provider serving Swiss users need a representative in Switzerland?

No. FADP applicability and representative appointment are separate questions. The foreign-controller representative rule depends on cumulative conditions involving people in Switzerland, offering goods or services or monitoring behavior there, regularity, large scale, and high risk. Incidental access or one Swiss user does not by itself prove that all conditions are met. See the detailed Swiss territorial and representative analysis.

Is consent always required to process personal data with AI under Swiss law?

No. Consent is not universally required merely because AI or personal data is involved. Where consent is the applicable justification, it must be voluntary, specific, and informed. Express consent is required in specified sensitive-data and high-risk-profiling circumstances when consent is the justification relied upon; that does not make consent the only possible route for every sensitive-data use. A Swiss consent overview provides supplementary context, but project-specific analysis should be checked against the current official text.

When does a Swiss AI project require a data protection impact assessment?

A DPIA is required when planned processing is likely to create a high risk to personality or fundamental rights. Sensitive or biometric data, possible high-risk profiling, extensive monitoring, large-scale processing, and consequential assessments are important screening considerations, but AI use alone does not automatically trigger a DPIA. The revised framework’s conditional impact-assessment duties are summarized in this Swiss FADP legal guide.

How do Swiss and GDPR data-breach notification rules differ?

Under the Swiss framework, a controller must notify the FDPIC as soon as possible when a breach is likely to create a high risk to personality or fundamental rights. The supplied comparison summarizes the GDPR rule as generally requiring supervisory notification within 72 hours where a breach is likely to result in a risk, subject to the exception where risk is unlikely. An incident affecting both populations should therefore be assessed under separate thresholds and timing rules, as explained in the IAPP comparison of the revised FADP.