How to Build One AI Privacy Program Without Missing the Swiss–EU Gaps

The EU General Data Protection Regulation and Switzerland’s revised Federal Act on Data Protection share enough principles to support a common AI privacy-governance foundation. They are not interchangeable, however. The most consequential differences concern the GDPR’s lawful-basis model, Switzerland’s infringement-and-justification structure, profiling, automated decisions, governance thresholds, representatives, breach reporting, and enforcement.

The practical answer is not to build two completely separate programs. Organizations can reuse controls for minimization, security, impact assessment, retention, vendor oversight, rights handling, and human escalation. They should then preserve distinct Swiss and GDPR analyses wherever the legal tests diverge.

Scope note: This is a high-level issue-spotting guide, not a comprehensive statement of Swiss or EU law or jurisdiction-specific legal advice. Some Swiss conclusions below rely on explanatory commentary rather than primary-law analysis. Before making consequential decisions, verify the current statutory text, regulator guidance, case law, and applicable public-sector, employment, healthcare, financial, secrecy, or other sector rules.

What the FADP and GDPR regulate when AI uses personal data

The GDPR and revised FADP are technology-neutral privacy laws, not standalone AI statutes. They become relevant when the development or operation of an AI system involves information relating to identified or identifiable natural persons.

The GDPR has applied since May 25, 2018. Switzerland’s revised FADP and its implementing ordinances entered into force on September 1, 2023, without a transition period. Unlike the former Swiss framework, the revised FADP protects personal data concerning natural persons rather than legal entities, according to the current overview of Swiss data-protection law.

Personal data can appear throughout an AI lifecycle, not just in a labeled training database. Depending on the system and surrounding information, it may include:

• Source and training datasets
• Names, account details, device identifiers, or other direct and indirect identifiers
• User prompts and uploaded documents
• Conversation histories and interaction logs
• Behavioral observations
• Inferred interests, health characteristics, performance indicators, or risk traits
• Validation, annotation, and feedback data
• Inputs used during inference
• Model outputs about or linkable to individuals
• Information retained in model parameters or representations
• Retrieval indexes and associated metadata

This does not mean every parameter, embedding, or output is personal data. The question is whether the information relates to an identifiable person in context, including through extraction, combination, or linkage. Nor does a model necessarily become anonymous when its original training files are deleted.

Treat each lifecycle stage as a potentially distinct processing activity. Collection, dataset creation, training, evaluation, deployment, inference, monitoring, profiling, reuse for improvement, and consequential automated decisions may have different purposes, affected populations, risks, and legal analyses. GDPR-oriented lifecycle guidance similarly treats collection, training, inference, profiling, and behavioral monitoring as potentially distinct activities when personal data is involved (GDPR AI lifecycle guidance).

Three boundaries are especially important:

1. Privacy law is not the same as AI product regulation. GDPR or FADP compliance does not by itself establish compliance with the EU AI Act or any future Swiss AI-specific regime.
2. Federal privacy law may not be the only Swiss rule. Public-sector, cantonal, employment, healthcare, financial, secrecy, and other regulated-market requirements may alter the analysis.
3. The regimes can overlap without using identical scope tests. An organization may face both based on its establishment, activities, affected individuals, offerings, monitoring, and other legally relevant connections.

The differences at a glance: a side-by-side AI privacy matrix

Both regimes support a substantial shared baseline. An AI program should normally define and limit purposes, provide appropriate transparency, apply privacy by design and default, secure personal data, assess qualifying high-risk processing, govern processors, handle individual rights, and control international transfers.

The following matrix is a high-level comparison, not an article-by-article account. Matters such as sensitive-data categories, processor-contract requirements, individual breach notices, model-parameter rights, and sector-specific duties require separate legal analysis.

Issue	GDPR	Swiss FADP	Practical AI implication
Applicability	May apply to organizations established in the EU and to qualifying activities by organizations outside it.	May also have extraterritorial effect, but its territorial tests are not identical.	Do not assume that hosting or processing in Switzerland removes an AI system from GDPR scope.
Legal basis or justification	Each personal-data processing activity generally requires an Article 6 legal basis.	Explanatory Swiss commentary describes private-sector processing as generally permissible unless it unlawfully infringes personality rights or otherwise requires justification (comparison of the revised FADP and GDPR).	Maintain separate GDPR lawful-basis and Swiss infringement-and-justification analyses.
Consent	When used, consent must meet GDPR conditions, including being specific, informed, unambiguous, affirmative, and withdrawable.	Consent is not necessarily required for every private-sector processing operation or profiling activity. If consent is required as the justification for high-risk profiling, it must be express.	Do not use a common consent screen as a substitute for deciding whether consent is appropriate under each regime.
Profiling	Profiling is personal-data processing and can affect lawful basis, transparency, rights, DPIAs, and automated-decision analysis.	The FADP distinguishes profiling from high-risk profiling. High-risk profiling does not automatically make consent necessary.	Classify the activity before deciding which notice, justification, or safeguard applies.
Automated decisions	Article 22 addresses qualifying decisions based solely on automated processing that produce legal or similarly significant effects.	Qualifying exclusively automated decisions with important effects trigger notice and an opportunity to request human intervention. These concepts are summarized in GDPR and AI lifecycle guidance.	Apply the tests independently rather than equating “solely,” “exclusively,” “important,” and “similarly significant.”
DPIAs	Required where processing is likely to result in high risk to individuals’ rights and freedoms.	Also required for qualifying high-risk processing, subject to the Swiss test and procedures.	AI is a risk indicator, not an automatic DPIA trigger.
Processing records	Recordkeeping duties apply subject to GDPR rules and exemptions.	Some organizations with fewer than 250 employees may qualify for an exemption where processing presents no significant privacy risk.	Headcount alone does not establish the Swiss exemption; risk-intensive AI may prevent reliance on it.
DPO or adviser	Appointment of a data protection officer can be mandatory in qualifying circumstances, including certain systematic monitoring or large-scale sensitive-data processing.	Appointment of a Swiss data-protection adviser is generally optional. The distinction, including the qualified records exemption, is explained in this Swiss-law comparison.	A Swiss-only staffing conclusion does not resolve whether the GDPR requires a DPO.
Breach reporting	Supervisory-authority notification is generally required within 72 hours after awareness when the GDPR threshold is met.	Qualifying breaches must be reported promptly under a different threshold. A statutory Swiss 72-hour deadline is not established by the cited comparison (GDPR–FADP breach overview).	Preserve the GDPR clock while conducting a separate Swiss assessment.
Representatives	A non-EU organization may separately need an EU representative when the GDPR test is met.	A foreign private controller may need a Swiss representative when the cumulative Swiss conditions are met, including the relevant Swiss connection, extensive and regular processing, and high risk.	Document the EU and Swiss appointment analyses independently.
International transfers	Transfers to jurisdictions without recognized adequate protection require an applicable transfer route and supporting assessment.	The FADP also regulates exports to countries without recognized adequate protection and may permit contractual safeguards.	Do not assume one adequacy finding or contractual package resolves both regimes.
Enforcement	Supervisory authorities can exercise investigative and corrective powers against regulated organizations.	The FDPIC has corrective powers, including the ability to issue orders, while criminal enforcement follows a different structure.	Escalation plans should account for both organizational and individual exposure.
Sanctions	Administrative fines primarily expose organizations and may be calculated by reference to worldwide annual turnover.	Swiss criminal sanctions are primarily directed at responsible individuals for intentional conduct, according to the current Swiss legal overview.	Train decision-makers as well as the organization; do not treat Swiss compliance as only a corporate-control exercise.

These distinctions are not adequately described as “strict versus light.” The more useful question is whether a shared control implements the correct legal test. A GDPR lawful-basis memorandum may demonstrate disciplined governance, for example, but it does not necessarily document whether Swiss processing infringes personality rights or requires justification.

Lawful basis, Swiss justification, and consent across the AI lifecycle

Under the GDPR, an organization generally needs a valid legal basis for each activity involving personal data. An AI initiative should therefore divide processing into meaningful stages rather than assign one basis to “the AI system” as a whole.

The six GDPR bases are:

1. Consent
2. Performance of a contract
3. Compliance with a legal obligation
4. Protection of vital interests
5. Performance of a task in the public interest or exercise of official authority
6. Legitimate interests

For private-sector AI development, consent and legitimate interests often receive the most attention, but neither should be chosen by default. Contract may apply only when processing is actually necessary for the contractual service, not merely because the activity is mentioned in contract terms. Each of the other grounds has its own conditions. CNIL’s current AI development recommendations identify the six bases and emphasize case-specific analysis.

Consent in an AI context

GDPR consent must be specific, informed, unambiguous, affirmatively given, and withdrawable. Those requirements can make it difficult to use consent for open-ended development, broad secondary uses, or datasets collected from third parties.

Withdrawal also needs an operational consequence. If a team cannot explain what withdrawal changes in source records, future training, deployed systems, logs, retrieval indexes, vendors, and outputs, it may not have designed a usable consent mechanism.

Before selecting consent, ask:

• Can the purpose be described with sufficient specificity?
• Does the person have a genuine choice?
• Can the person refuse without inappropriate detriment?
• Can the organization prove what the person agreed to?
• Can consent be withdrawn as easily as it was given?
• Can systems and vendors act on withdrawal?
• Is consent being used to avoid a harder necessity or fairness analysis?

Consent should not be treated as an all-purpose answer to uncertainty.

Legitimate interests in an AI context

A legitimate-interests assessment is case-specific. It generally asks whether the interest is legitimate, whether the personal-data processing is necessary for that interest, and whether individuals’ interests and fundamental rights override it.

For AI, necessity should include whether anonymous, non-personal, synthetic, smaller, or less intrusive data could achieve the purpose. Balancing should address the collection context, affected population, sensitivity, scale, reasonable expectations, model capabilities, foreseeable downstream uses, and safeguards.

Public accessibility does not by itself settle whether web data may be collected for AI training. GDPR analysis may need to consider the source, content, privacy settings, terms of use, technical restrictions, reasonable expectations, necessity, objection mechanisms, filtering, minimization, and memorization risks. CNIL’s guidance identifies these factors and recommends safeguards for web-sourced data.

Accordingly, “the information was public” is not a complete GDPR analysis for scraping. The team still needs a defined purpose, a suitable basis, necessity analysis, controls for irrelevant or sensitive material, and a way to address individual rights where applicable.

Do not import that EU analysis unchanged into Swiss law. The cited Swiss materials do not establish a public-web scraping rule or legitimate-interests test identical to the GDPR’s.

The Swiss private-sector structure

Swiss private-sector processing uses a different legal architecture. Commentary on the revised FADP describes processing as generally permissible unless it unlawfully infringes personality rights or falls into circumstances requiring justification. A GDPR-style Article 6 basis is therefore not necessarily required for every Swiss private-sector operation.

That does not make purpose, proportionality, transparency, security, sensitivity, disclosure, or individual effects irrelevant. It means the analysis must be expressed in Swiss terms. Where processing infringes personality rights, the organization should determine whether an applicable justification exists and whether the proposed safeguards adequately address the infringement.

Consider a company training a generative model on customer-support messages:

• Under the GDPR, it should identify the purpose of collecting the messages, the separate purpose of model training, the lawful basis for each activity, whether training is compatible with the original purpose, and whether the use is necessary and appropriately balanced.
• Under the FADP, it should separately assess the processing principles, possible personality-rights infringement, sensitivity, expectations, disclosure or reuse, and whether justification is required and available.
• Under both, it should address minimization, de-identification, retention, access restrictions, testing, vendor access, transparency, and rights handling.

A dual-regime assessment should record:

• Processing activity and lifecycle stage
• Defined purpose
• Data categories and sources
• Affected people
• GDPR lawful basis
• Swiss infringement-and-justification analysis where relevant
• Necessity and proportionality
• Compatibility of later uses
• Safeguards and residual risks
• Retention period
• Responsible owner
• Review date and change triggers

This structure lets teams reuse factual analysis without disguising the legal differences.

Profiling and consequential automated decisions are not interchangeable concepts

Profiling and automated decision-making are related but separate questions.

Profiling generally involves using personal data to evaluate or predict aspects of a person. An organization can profile customers without allowing the resulting score to make a final decision. Conversely, an automated system may apply rules or inputs without matching every informal use of the term “profiling.”

Under the revised FADP, profiling—including high-risk profiling—does not automatically require consent. The cited Swiss commentary supports the more qualified conclusion that, if consent is otherwise required or used as the applicable justification, consent for high-risk profiling must be express.

Qualifying exclusively automated decisions with important effects require notice and an opportunity for the affected person to request human intervention under the Swiss framework. GDPR Article 22, by contrast, addresses qualifying decisions based solely on automated processing that produce legal or similarly significant effects. The definitions, thresholds, safeguards, and exceptions should not be assumed to match element by element.

Use a common screening sequence, but answer each question under the applicable law:

1. Is personal data involved?
2. Is the system evaluating, predicting, ranking, or categorizing a person?
3. Does the activity meet the applicable definition of profiling?
4. Is the profiling high risk under the Swiss test?
5. Is the final decision exclusively or solely automated?
6. Does a reviewer have relevant information, sufficient time, authority, and a genuine ability to change the result?
7. Is the effect important, legal, or similarly significant under the applicable test?
8. What notice, contest process, explanation, or human intervention is required?
9. Is consent relevant, and if so, under which rule?

How the questions apply in practice

Customer segmentation: Grouping customers by predicted interests may constitute profiling even if no consequential decision follows. Assess the GDPR basis or Swiss justification, transparency, inferred traits, retention, and downstream use.

Fraud scoring: A score reviewed by a trained investigator differs from an automatically blocked transaction.

Employee performance scoring: Employment and local labor rules may add obligations not covered here.

Personalized pricing: Determine what traits drive the price, whether sensitive or proxy characteristics are inferred, whether the result materially affects the person, and whether the final price is automatically determined.

Automated hiring, credit, or eligibility: These applications warrant close review because they can materially affect access to work, finance, housing, insurance, benefits, or services. The GDPR significant-effect analysis and Swiss important-effect test still need to be performed separately.

A shared operational safeguard is a meaningful escalation procedure. It should route disputes to a qualified reviewer, provide relevant context, allow the person to submit additional information, prevent retaliation for contesting a result, and document whether the reviewer changed the outcome. That procedure improves governance, but identical implementation should not be presumed to satisfy both legal regimes.

DPIAs, privacy by design, records, and AI governance roles

Neither the GDPR nor the FADP makes a DPIA mandatory merely because software is called AI. The legal trigger is qualifying high-risk processing under the applicable framework.

Risk indicators can include:

• Sensitive-data processing or sensitive inferences
• Systematic monitoring
• Large-scale monitoring of publicly accessible areas
• Decisions with significant or important effects
• New technologies used in ways that create material uncertainty or impact
• Large, linked, or unexpectedly reused datasets
• Certain processing involving children or other vulnerable people
• Persistent scoring or behavioral prediction
• Limited ability to correct model-driven errors
• Memorization, extraction, or disclosure risk

These indicators do not replace the governing test. A low-risk drafting assistant configured not to retain prompts has a different profile from a system that continuously scores employees.

Where a DPIA is required, complete it early enough to influence system design, procurement, contracting, and launch. It should address the purpose, necessity, proportionality, data flows, affected people, potential harms, safeguards, residual risk, consultation requirements, and review triggers.

Shared lifecycle controls

Most organizations can use one control library for both regimes:

• Defined and limited purposes
• Data minimization
• Pseudonymization or separation where appropriate
• Privacy by design and default
• Processing inventories and records
• Retention and deletion rules
• Access controls, logging, and security testing
• Dataset and output quality checks
• Model evaluation and red-team testing
• Approval gates before launch or material change
• Rights-request procedures
• Human escalation for consequential outcomes
• Vendor and subprocessor governance
• Periodic reassessment after drift, fine-tuning, or new use

Under the GDPR, data protection by design applies when processing methods are determined and while processing occurs. Depending on the context and risk, appropriate measures may include minimization and pseudonymization. The design-stage obligation, legal-basis analysis, high-risk DPIA trigger, and EDPB model-anonymity position are discussed in this GDPR compliance-by-design analysis.

DPOs, Swiss advisers, and processing records

A GDPR data protection officer may be mandatory in qualifying circumstances, including certain forms of regular and systematic monitoring or large-scale sensitive-data processing. Appointment of a Swiss data-protection adviser is generally optional.

That distinction affects staffing but should not determine whether privacy expertise participates in AI governance. Even where no formal appointment is mandatory, a high-risk system benefits from an independent challenge function with access to technical records and decision-makers.

The Swiss processing-record exemption described in the cited commentary is qualified: some organizations with fewer than 250 employees may rely on it where processing presents no significant privacy risk. Headcount is not sufficient by itself. A smaller organization conducting systematic monitoring, sensitive inference, or consequential decision-making should not assume that it qualifies.

Determine roles from actual control

Controller, joint-controller, and processor roles depend on who actually determines purposes and means, not only on contractual labels.

Ask:

• Who decided why the system would be developed or used?
• Who selects or materially controls the training data?
• Who defines the capabilities and intended population?
• Who sets retention periods?
• Who decides whether prompts enter an improvement pipeline?
• Who controls output monitoring and secondary use?
• Can the vendor independently reuse data or commercialize resulting insights?

Suppose a customer hires a vendor to customize a model. The contract may call the vendor a processor, but the vendor might independently select broad training sources, define reusable capabilities, retain interaction data, and improve a general product. Those facts can complicate the contractual allocation. Conversely, a vendor following sufficiently detailed customer instructions without independent use may have a more processor-like role. CNIL emphasizes that roles turn on actual control over purposes and means rather than labels alone (CNIL AI role guidance).

Transparency, individual rights, and personal data inside AI models

Both regimes impose transparency and rights-related obligations, but one notice and one response script may not be sufficient for every jurisdiction or lifecycle stage.

An AI privacy notice should address, as applicable:

• Processing purposes
• Categories of personal data
• Direct and indirect data sources
• How AI is used
• Material profiling or automated-decision practices
• Recipients, model providers, and other vendors
• International hosting or access
• Retention periods or criteria
• How individuals can exercise applicable rights
• Relevant controller, adviser, DPO, or representative details

Swiss notices are described in the cited commentary as requiring less mandatory content in some respects than GDPR notices while requiring attention to destination countries and the applicable basis or safeguard for exported data. The precise disclosure needed for a particular transfer should be verified against current Swiss law and guidance.

Access, rectification, erasure, and portability can be supported through a shared intake process, but the rights, conditions, and exceptions are not identical. The organization should be able to locate information across source systems, prompts, logs, evaluation datasets, retrieval indexes, profiles, outputs, and vendor systems.

Is the model itself anonymous?

Removing the training files does not prove that a trained model is anonymous. A model not designed to reveal personal data may still permit information to be extracted from its parameters or elicited through carefully constructed queries.

Under the cited EDPB analysis, both the risk of identifying people and the risk of obtaining personal data through queries would need to be insignificant before a model could be treated as anonymous. That is a demanding, fact-specific, nonbinding regulatory analysis rather than a label that follows from the developer’s intention.

As a risk-management measure, test for:

• Memorization of rare or sensitive examples
• Extraction through adversarial prompts
• Linkage with external datasets
• Personal-data disclosure in outputs
• Retrieval of deleted or restricted records
• Reidentification of pseudonymized information
• Changes in disclosure risk after fine-tuning
• Leakage through logs, debugging tools, or monitoring systems

These tests are governance recommendations, not a claim that Switzerland applies the same model-anonymity standard. The cited materials do not conclusively resolve how Swiss access, correction, deletion, or suppression rights apply to personal data embedded in model parameters. Verify current Swiss law and FDPIC guidance, then document technically feasible response options rather than assuming either that full retraining is always required or that model parameters are categorically outside privacy law.

Cross-border scope, representatives, vendors, and international transfers

Both regimes can apply outside their home territories, but their territorial tests are not identical. Processing physically conducted in Switzerland is not automatically outside the GDPR. A Swiss developer, deployer, or service provider may still fall within GDPR scope because of its establishment, offerings, monitoring, or other covered activities.

A non-EU organization may separately need an EU representative when the GDPR conditions are met. Under the Swiss test described in the current legal overview, a foreign private controller may need a Swiss representative when all relevant conditions are satisfied, including:

• A connection to offering goods or services in Switzerland or monitoring behavior there
• Extensive and regular processing
• High risk to the personality of affected people

This is a cumulative, fact-specific test. It should not be converted into a categorical statement that the Swiss rule is always narrower than GDPR Article 27.

Transfers require separate analysis

Both frameworks regulate transfers to jurisdictions that lack recognized adequate protection and may permit contractual safeguards. One transfer arrangement should not automatically be assumed to satisfy both.

Perform separate EU and Swiss assessments for:

• Model hosting
• Cloud storage and backups
• Remote vendor support
• Security and performance telemetry
• Human review of prompts or outputs
• Fine-tuning and evaluation
• Centralized group-company access
• Model improvement
• Downstream subprocessors

An EU adequacy decision does not necessarily settle the Swiss analysis, and the reverse is also true. Processor agreements and vendor questionnaires should likewise reflect the applicable requirements rather than merely carrying a “GDPR compliant” label.

AI supply-chain checklist

For each supplier, document the role, data, purpose, locations, retention, security, independent uses, and subprocessor chain:

• Model provider: Does it retain prompts, use customer data for improvement, or allow personnel to access personal data?
• Cloud host: Where are primary systems, backups, administrators, and support personnel located?
• Fine-tuning vendor: Who selects data, filters records, evaluates outputs, and retains resulting artifacts?
• Application deployer: Who determines the user population, decision logic, and downstream use?
• Monitoring service: Does it receive full prompts, outputs, and identifiers, or only aggregated telemetry?
• Subprocessors: How are additions, location changes, security changes, and transfer implications communicated?

As a due-diligence baseline, contracts should address instructions, confidentiality, security, incident assistance, rights support, deletion or return, audit information, subprocessors, international access, and limits on independent model improvement. Whether particular terms are legally required or sufficient must be evaluated separately under the GDPR and FADP.

A dual-regime implementation plan for AI teams

A dual-regime program should use one operational backbone with explicit jurisdictional branches.

1. Inventory AI systems and personal data

Include internally developed models, purchased tools, embedded features, employee uses, pilots, and unsanctioned applications. Record personal data in training sets, prompts, logs, parameters, retrieval systems, outputs, and monitoring tools.

2. Map lifecycle activities and roles

Separate collection, training, validation, deployment, inference, monitoring, improvement, rights handling, and deletion. Determine who controls the purpose and essential means at each stage. Reassess roles if a vendor begins reusing data for its own product.

3. Define and limit purposes

Avoid purposes such as “use AI” or “improve services” without further detail. State the system type, intended users, intended decisions, feasible capabilities, and prohibited uses. Define what evidence and approval would be required before expanding the purpose.

4. Complete both legal analyses

For each activity:

• Record the GDPR lawful basis.
• Assess compatibility for later uses.
• Complete the Swiss infringement-and-justification analysis where applicable.
• Document necessity, proportionality, expectations, affected populations, and safeguards.
• Assign an owner, review date, and change triggers.

5. Screen for profiling and automated decisions

Determine whether the system evaluates or predicts personal characteristics, whether Swiss high-risk profiling may be involved, how the final decision is made, and whether human involvement is meaningful. Apply the GDPR and FADP consequence thresholds separately.

6. Assess DPIA triggers

Screen for sensitive data, monitoring, vulnerable people, large scale, consequential decisions, data linkage, unexpected inferences, new uses, and limited contestability. Do not require a DPIA solely because a tool is marketed as AI, but do not waive one merely because the algorithm is familiar.

7. Review transparency and rights workflows

Build notices from the data-flow map. Test whether the rights team can locate information across source systems, prompts, logs, retrieval indexes, outputs, models, and vendors. Create local modules for automated decisions, representatives, transfers, and jurisdiction-specific rights.

8. Validate vendors and transfers

Confirm roles, instructions, secondary uses, subprocessors, locations, security controls, incident assistance, rights support, retention, deletion, and transfer arrangements. Repeat the assessment if the provider changes how it uses customer interactions.

9. Establish retention and security controls

Set retention by data category and lifecycle stage. Restrict access to raw training data, prompts, evaluation records, and outputs. Test extraction, memorization, prompt injection, data leakage, unauthorized improvement, and excessive logging.

10. Prepare a two-track incident workflow

Use one response team but separate legal decision paths:

• Preserve the GDPR’s 72-hour assessment and reporting clock where applicable.
• Independently determine whether the Swiss reporting threshold is met.
• Report under the FADP promptly when required.
• Assess communications to affected individuals under each applicable framework.
• Document decisions, assumptions, and timing.
• Preserve evidence concerning model versions, prompts, outputs, logs, vendors, and transfers.

The GDPR’s 72-hour supervisory-authority deadline and the FADP’s prompt-notification approach are distinct. The cited comparison does not establish 72 hours as a Swiss statutory deadline (GDPR–FADP comparison).

Four-scenario mini-playbook

Scenario	Decision points
Public-web model training	What data categories are collected? What is the specific purpose? Who controls collection and model design? What is the GDPR basis? Does Swiss processing infringe personality rights or require justification? What expectations and collection restrictions apply? Can irrelevant or sensitive records be filtered? Where are training and support performed? How long are source data and artifacts retained?
Employee monitoring	Which activities, communications, locations, or performance indicators are observed? Are sensitive traits inferred? Is monitoring systematic? Who determines the score and its use? Is a DPIA required? Does profiling occur? Can the result affect discipline, promotion, scheduling, or dismissal? Is review genuinely human? Which employment rules also apply?
Customer profiling	What behavior and account data feed the profile? Is the purpose marketing, fraud prevention, personalization, or pricing? What basis or justification applies? Is profiling high risk? Are sensitive data or proxies used? Does the profile recommend an action or determine the result? What notice, objection, retention, and transfer controls apply?
Automated hiring or eligibility	What training and applicant data are used? Who defines the criteria? Is the decision solely or exclusively automated? What is the effect under each legal test? Can a qualified reviewer reverse it? What contest process exists? Is the system validated for the intended population? How are vendors, transfers, logs, and retention controlled?

What can be shared—and what should remain distinct

Shared controls:

• Data inventory and mapping
• Minimization and purpose controls
• Privacy-by-design reviews
• Security testing
• Retention management
• DPIA operations
• Vendor governance
• Rights intake
• Human escalation
• Incident coordination

Jurisdiction-specific records or modules may include:

• GDPR lawful-basis analysis
• Swiss infringement-and-justification analysis
• Profiling classification
• Automated-decision notices
• Representative appointments
• Privacy-notice language
• Processing-record exemptions
• Transfer assessments
• Breach thresholds and procedures
• Enforcement and escalation analysis

Before launch or material change, recheck current primary law, regulator guidance, sector-specific requirements, and developing AI regulation. GDPR compliance is a strong operational baseline, but it does not automatically establish FADP compliance. Neither privacy framework alone establishes EU AI Act compliance.

Does GDPR compliance automatically satisfy Switzerland’s FADP for an AI system?

No. GDPR compliance supplies reusable controls and evidence, but the FADP uses distinct rules and legal tests. A GDPR lawful-basis memorandum, DPO structure, representative appointment, incident procedure, or automated-decision analysis may not answer the corresponding Swiss question.

Use the GDPR program as an operational foundation, then add Swiss workstreams for infringement and justification, high-risk profiling, exclusively automated decisions, representatives, processing-record exemptions, prompt breach reporting, and enforcement exposure.

Does high-risk profiling under the FADP always require consent?

No. Swiss high-risk profiling does not automatically require consent merely because it meets that classification. If consent is otherwise required or used as the applicable justification, the cited Swiss commentary states that consent for high-risk profiling must be express.

First determine whether profiling occurs, whether it is high risk, whether the processing infringes personality rights, and whether a justification is necessary and available. Do not jump directly from “high-risk profiling” to “consent required.”

Does every AI project require a data protection impact assessment?

No. Under both regimes, the trigger is qualifying high-risk processing, not the use of AI alone.

Sensitive data, systematic monitoring, large-scale public monitoring, vulnerable populations, consequential automated decisions, and novel processing can indicate high risk. The organization must still evaluate the actual data, purpose, scale, population, consequences, and safeguards.

Even when a formal DPIA is not mandatory, a proportionate privacy and security assessment can document why the threshold was not met and identify controls needed before launch.

Is Switzerland’s personal-data-breach reporting deadline 72 hours?

Not as a statutory rule established by the cited materials. Under the GDPR, supervisory-authority notification is generally required within 72 hours after awareness when the reporting threshold is met. The FADP uses a prompt-notification standard and a different threshold.

A cross-border organization should preserve the GDPR clock while separately assessing Swiss notification. Using 72 hours as an internal target may support incident discipline, but it should not be described as the Swiss statutory deadline.

Can an AI model be treated as anonymous after its training data is removed?

Not automatically. Deleting the source dataset does not establish that information cannot be identified, extracted, linked, or elicited through queries. The assessment must address the trained model and its access conditions, not only the original files.

Under the cited EDPB view, identification risk and the risk of obtaining personal data through queries would both need to be insignificant for the model to be treated as anonymous (analysis of the EDPB AI-model position). Whether and how that nonbinding EU analysis translates to a particular Swiss-law question requires separate verification.

The durable implementation principle is straightforward: build one strong privacy-governance foundation across the AI lifecycle, but do not collapse the two legal analyses into one. Share minimization, security, impact assessment, transparency, retention, vendor oversight, rights handling, and human escalation. Maintain explicit Swiss and GDPR workstreams for legal basis or justification, profiling, automated decisions, representatives, breach reporting, and enforcement—and validate consequential conclusions against current primary law, regulator guidance, and applicable sector rules before launch or material change.