Feature

One AI Privacy Program, Two Legal Overlays: A Practical Swiss–EU Framework

By Priya Ellison · 4 August 2026

Switzerland’s Federal Act on Data Protection (FADP) and the EU General Data Protection Regulation (GDPR) overlap enough for an AI company to build a substantial shared compliance program. They are not interchangeable, however. A GDPR policy, audit, vendor contract, or certification does not by itself establish Swiss compliance.

The practical approach is core plus overlays:

Determine jurisdiction for each processing operation.
Inventory personal data across the AI lifecycle.
Separate model development from deployment.
Apply shared controls for purpose, proportionality or minimization, transparency, security, retention, accountability, vendors, and individual requests.
Add the Swiss or EU analysis required for representatives, legal grounds, profiling, automated decisions, transfers, assessments, rights, and enforcement.

This is an operational starting framework, not a comprehensive article-by-article comparison. Questions involving lawful grounds, exceptions, automated decisions, impact-assessment procedures, representatives, transfers, and individual remedies require verification against the complete current rules for the relevant jurisdiction.

That operation-level approach matters because the same model might support a Swiss-only chatbot, an EU-facing recruiting product, and an internal evaluation environment hosted by foreign cloud providers. Each operation can involve different people, purposes, participants, locations, retention rules, and legal regimes.

Start With Jurisdiction: FADP, GDPR, or Both?

Switzerland is outside both the EU and the European Economic Area. A company does not become subject to the GDPR merely because it is incorporated or established in Switzerland.

The territorial analysis begins with each regime’s own rules. The FADP applies to personal-data processing by private persons and federal bodies and can reach circumstances initiated abroad that have effects in Switzerland. The GDPR can apply to a Swiss or other non-EU company when it offers goods or services to people in the EU or monitors their behavior there. The supplied English FADP text is an informational translation and expressly states that it has no legal force, so consequential Swiss conclusions should be checked against the applicable official-language text (Swiss FADP text).

Applicability should be assessed per processing operation, not once for the model, product, legal entity, or corporate group. User location is important, but it does not alone determine the answer.

The following matrix is a triage tool, not a final jurisdictional opinion:

Question	Provisionally Swiss-only	Provisionally EU-only	Potentially dual-regime
Illustrative facts	Swiss chatbot serving only Swiss users, with relevant Swiss processing or effects and no identified EU establishment, targeting, or monitoring	Non-Swiss entity serving people only in the EU, with no relevant Swiss establishment, processing, targeting, monitoring, or effects	Swiss AI service marketed to people in the EU
Initial legal focus	FADP and applicable Swiss sector rules	GDPR and applicable EU or national rules	Both FADP and GDPR
Facts still to verify	Establishments, Swiss effects, users, monitoring, vendors, hosting, and foreign access	EU establishment or targeting, behavior monitoring, controller or processor role, and absence of relevant Swiss connections	All Swiss and EU connections, including separate product channels and vendor routes
Representative analysis	Swiss representative test if the controller is foreign	Separate EU representative analysis if the organization lacks an EU establishment	Separate Swiss and EU representative analyses
Transfer focus	Disclosures from Switzerland and onward routes	Transfers governed by the GDPR	Both transfer frameworks and every onward route
Operational treatment	Common privacy core plus Swiss fields and decisions	Common core plus EU fields and decisions	One core record with both overlays

A Swiss chatbot serving only Swiss users may be a Swiss-only operation. The company should still map account data, prompts, outputs, safety logs, support access, hosting, and foreign disclosures. An EU establishment, deliberate EU targeting, monitoring of people in the EU, or another EU-related processing connection could change the classification.

A Swiss AI service advertised and sold to people in the EU may face both regimes. Available secondary guidance describes GDPR territorial scope as reaching some organizations outside the EU when they offer goods or services to people there or monitor their behavior. Because the supplied source is a third-party guide with historically dated material, the conclusion for a particular service should be verified against current primary EU law and guidance (overview of GDPR applicability to Swiss companies).

The reverse scenario also matters. A foreign model provider may fall within the FADP where its conduct has relevant effects in Switzerland. Regular monitoring or profiling of people there is a fact pattern to investigate, but territorial coverage and the narrower duty to appoint a Swiss representative are separate questions.

For each operation, record at least:

The responsible legal entity and relevant establishments
Where affected people are located
Where the organization offers or markets the product
Whether behavior is monitored in Switzerland or the EU
Where data is collected, stored, accessed, backed up, and returned
Which vendors and subprocessors receive it
Whether the operation concerns development, evaluation, deployment, or monitoring
Which employment, healthcare, financial, public-sector, or other specialist rules may also apply
Whether the initial classification remains provisional pending legal review

Jurisdiction is therefore an input to the processing inventory—not a corporate status selected once and reused everywhere.

What the Two Regimes Regulate When AI Uses Personal Data

The supplied FADP provisions establish general data-protection requirements rather than a standalone Swiss privacy code specifically for AI. The comparable operational premise under the GDPR is that privacy obligations arise when an operation processes personal data, not merely because a product is described as artificial intelligence.

The relevant threshold is information relating to an identified or identifiable natural person. The revised FADP protects natural persons rather than legal persons. Whether a particular AI artifact is personal data depends on its content, context, linkability, accessible auxiliary information, and realistic means of identification.

Potential personal data can appear throughout the AI lifecycle:

Source, licensed, customer-supplied, or web-collected datasets
Training, fine-tuning, reinforcement, and annotation data
Evaluation and benchmark sets
User and administrator account information
Prompts and uploaded documents, images, audio, or video
Generated outputs and recommendations
Inferred traits, classifications, risk scores, or profiles
Embeddings and vector-database entries
Device, location, usage, and performance telemetry
Safety, fraud, and misuse-monitoring records
Human-review notes
Interaction logs, caches, and support tickets
Records selected for later retraining

This list identifies locations to inspect. It does not mean that every prompt, output, embedding, dataset, or model necessarily contains personal data. A generic recipe prompt may not relate to anyone identifiable. A prompt containing a candidate’s résumé, patient history, employee number, or other identifying context presents a different question.

Separate development from deployment

AI development and deployment should ordinarily be documented separately because they may involve different:

Purposes and reuse questions
Data sources and affected populations
Controllers, processors, and other participants
GDPR lawful bases or Swiss lawfulness and justification analyses
Retention periods
Access patterns
Risks and safeguards
Request-handling consequences

For example, a developer might use historical applicant records to train or validate a matching model. An employer might then deploy that model to rank current applicants. Development concerns historical data, model design, validation, and training. Deployment concerns new applications, generated scores, recruiter actions, monitoring, and possible effects on candidates. Describing both operations as “improving recruitment” conceals material differences.

Deletion and pseudonymization do not prove model anonymity

Removing names, pseudonymizing a dataset, or deleting the original training table can reduce exposure. None of those actions alone proves that a resulting model is anonymous.

A responsible assessment considers whether someone can still be identified, whether training information can be extracted, what auxiliary information is available, how the model is released, and what technology, cost, and time an attacker would need.

A December 2024 European Data Protection Board opinion, as summarized in legal analysis, treats model anonymity as a contextual assessment involving whether identification and training-data extraction risks are insignificant. The cited analysis also reports the position that a model designed to provide personal data from its training data should not be considered anonymous. This is a nonbinding regulator position rather than settled judicial law (analysis of the EDPB position on AI models).

Keep four categories distinct:

Statutory duties: binding requirements under applicable law
Regulator interpretations: influential positions that may remain contestable
Judicial rulings: binding or persuasive decisions within their proper scope
Prudent controls: technical or organizational measures adopted to reduce risk

Extraction testing, access restrictions, and output filtering may be sensible without being universally mandated. Conversely, calling a model anonymous in a contract does not establish that it is anonymous in fact or law.

The Shared Compliance Core—and Why Swiss Add-Ons Still Matter

The revised FADP and its ordinances took effect on September 1, 2023, without a transition period. The revision sought stronger protection and closer alignment with the GDPR while preserving Swiss deviations. It also introduced or emphasized privacy by design and default, transparency, accountability, impact assessment, processing records, and data portability (overview of the revised Swiss framework).

That alignment makes operational reuse practical. It does not make the regimes equivalent.

Operational theme	Shared operational core	Swiss overlay	EU overlay
Purpose	Define each operation and control secondary use	Apply the relevant Swiss purpose, proportionality, and lawfulness analysis	Apply GDPR purpose limitation and any compatibility analysis
Data scope	Avoid indiscriminate collection or reuse	Document proportionality	Document minimization against each stated purpose
Accuracy	Test source quality, labels, inferences, and output limitations	Apply applicable Swiss accuracy requirements	Apply GDPR accuracy requirements and rights procedures
Retention	Set store-specific periods and disposal methods	Record the Swiss rationale and applicable exceptions	Record the GDPR storage-limitation rationale
Transparency	Explain data, purposes, responsible parties, recipients, and retention	Include relevant collection and foreign-disclosure information	Provide the information required under applicable GDPR notice rules
Security	Use measures proportionate to the operation’s risk	Apply FADP security requirements	Apply GDPR risk-based security requirements
Design and default	Restrict unnecessary collection, access, and reuse	Record Swiss design and default decisions	Record GDPR data-protection-by-design decisions
Accountability	Assign owners and preserve evidence	Reflect Swiss duties and possible individual exposure	Maintain evidence demonstrating controller compliance
Processing records	Maintain an operation-level inventory	Apply Swiss thresholds and exceptions	Apply relevant GDPR recordkeeping rules
Processor oversight	Control instructions, access, deletion, and subprocessors	Capture Swiss approval and transfer requirements	Capture relevant GDPR processor and transfer terms
Impact assessment	Screen risk before launch	Apply the Swiss trigger and procedure	Apply the GDPR DPIA trigger and procedure

The table identifies common operational themes, not identical legal tests. Each overlay must be verified against the complete current rules.

Build one core, not two disconnected programs

The shared program can include:

One data and processing taxonomy
One inventory platform or structured register
One vendor-governance workflow
One retention-management process
One request-intake channel
One security and incident-management framework
One impact-assessment method

The organization can then add jurisdiction-specific:

Applicability fields
Legal analyses
Notice language
Approval gates
Transfer mechanisms
Representative decisions
Automated-decision assessments
Rights, remedies, and exception rules
Escalation paths

Do not label the shared core “GDPR compliant” and assume Switzerland is covered. An audit may test only a defined scope. A certification may address selected security or management controls rather than every legal duty. Contract templates cannot establish what a deployed system actually does.

The revised FADP protects personal data relating to natural persons. Comparisons stating that current Swiss law protects data about legal persons are descriptions of the former regime and should not be reused.

The FADP may also be only one part of the analysis. Employment, healthcare, finance, insurance, biometrics, public-sector processing, regulated markets, and professional-secrecy settings can introduce additional requirements.

An evidence register helps prevent overstatement. Classify each requirement or control as:

Binding statutory or regulatory duty
Conditional legal duty
Regulator interpretation
Judicial judgment
Contractual commitment
Internal policy
Recommended engineering or governance control
Open legal question

That classification prevents a voluntary practice from being represented as universal law—and prevents a binding requirement from being dismissed as optional guidance.

Turn the AI Lifecycle Into a Defensible Processing Inventory

Do not document “the recommendation model” or “our generative AI platform” as one activity. Create a separate record whenever an operation has a distinct purpose, dataset, participant, location, risk, or retention rule.

Appropriate entries may include:

Data sourcing and collection
Dataset cleaning and labeling
Initial training
Fine-tuning
Evaluation and red-team testing
Account administration
Production prompt processing
Retrieval from vector databases
Output generation
Safety and abuse monitoring
Product analytics
Human review or escalation
Customer support
Retraining from production interactions
Dataset, log, model, and account deletion

For every operation, record:

Field	What to document
Owner	Business and technical owners
Entity	Legal entity determining or performing the processing
Role	Controller, joint controller, processor, or another supportable classification
Jurisdiction	FADP, GDPR, both, another regime, or provisional pending review
Lifecycle stage	Sourcing, training, evaluation, deployment, monitoring, retraining, or deletion
Purpose	Specific objective—not “AI improvement” alone
People	Users, applicants, employees, customers, patients, visitors, or others
Data	Identifiers, content, sensitive data, inferences, and telemetry
Source	Individual, customer, public source, vendor, employer, or generated record
Recipients	Internal teams, customers, model providers, hosts, and reviewers
Locations	Collection, hosting, support, backup, and processing regions
Transfers	Destination, mechanism, safeguard, exception, and onward route
Security	Access restrictions, encryption, monitoring, testing, and segregation
Retention	Period or objective trigger linked to purpose
Deletion	Method, responsible system, vendor confirmation, and evidence
Risk	Initial risk, mitigations, residual risk, and approval status

Recordkeeping exceptions require an actual assessment

Swiss processing-record duties are conditional. The supplied FADP material describes exceptions for some organizations with fewer than 250 employees where the relevant processing presents only negligible risk. Headcount should therefore not be treated as an automatic exemption. Data-intensive processing, sensitive data, consequential profiling, or systematic monitoring can make an unsupported size-only assumption particularly weak (informational English translation of the FADP).

Record the exemption analysis, evidence, decision-maker, and review date. Even where a formal record is not legally required, an operation-level inventory may remain a prudent governance control.

Document the applicable legal analysis

Use precise terminology:

GDPR lawful basis refers to the relevant GDPR legal-basis analysis.
Swiss lawfulness or justification analysis refers to the applicable FADP assessment and should not be treated as a copied GDPR form.
Legal assessment is the neutral umbrella term used in shared workflows.

For GDPR planning, ask:

Do the inputs, intermediate records, or outputs contain personal data?
What specified purpose supports the operation?
Which valid GDPR lawful basis applies?
Is each data field necessary for that purpose?
Is a DPIA required?
Does the answer differ between development and deployment?

Consent is not the universal basis for AI. Depending on the operation, other grounds may need to be assessed. The supplied evidence does not establish a complete one-to-one mapping between FADP and GDPR grounds, so a Swiss analysis should not be reduced to a GDPR Article 6 checklist.

Where legitimate interests are considered under the GDPR, document:

The interest being pursued
Why the processing is necessary
Effects on affected people
Their reasonable expectations
Safeguards reducing adverse effects
The result of the balancing assessment

Perform this analysis separately for development and deployment. A conclusion supporting production fraud detection does not automatically support using resulting records to train a general-purpose model.

Under the supplied FADP extract, explicit consent is required where consent is the applicable basis for processing sensitive personal data, high-risk profiling by a private person, or profiling by a federal body. That is a narrow statement; it does not mean every private-sector AI operation requires consent.

GDPR planning materials likewise treat legal-basis selection, necessity, purpose definition, minimization, and impact-assessment screening as operation-specific questions rather than one-time model approvals (GDPR planning analysis for the AI lifecycle).

Risk Assessments, Profiling, and Consequential Automated Decisions

An AI label does not automatically trigger a formal impact assessment. The trigger is the risk created by the processing under the applicable legal test.

Potential risk indicators include:

Sensitive personal data
Large-scale processing
New or unfamiliar technology
Systematic or large-scale monitoring
Extensive or high-risk profiling
Decisions producing legal or comparably significant effects
Certain processing involving children
Processing that may contribute to physical harm
Unexpected combination of data sources
Limited ability to avoid or contest the processing

Under the FADP, qualifying high-risk processing may require a data-protection impact assessment. Under the GDPR, a DPIA is required before processing likely to result in high risk to individuals’ rights and freedoms. The exact triggers, required contents, exceptions, consultation rules, and procedural consequences must be checked under the complete current rules.

A predeployment assessment workflow

A practical workflow should cover:

Define the purpose. State what the system should do and its prohibited uses.
Identify affected people. Include non-users whose data may enter datasets, prompts, or outputs.
Test necessity and proportionality. Ask whether less data or a less intrusive design could achieve the purpose.
Validate data sources. Record provenance, permissions, collection context, and known gaps.
Assess accuracy. Evaluate labels, stale data, error patterns, inference quality, and output limitations.
Examine bias and privacy risks. Consider disparate effects, proxy variables, extraction, memorization, reidentification, and misuse.
Review security. Test access, tenant separation, secrets, prompt injection, exfiltration, logging, and incident detection.
Map vendors and transfers. Include model providers, hosts, support teams, and subprocessors.
Set retention. Define periods for prompts, outputs, logs, reviews, and retraining copies.
Design human review. Specify reviewer authority, competence, information, time, and reversal power.
Test request handling. Verify search, access, correction, deletion, objection, and escalation procedures as applicable.
Select mitigations. Change the dataset, purpose, interface, permissions, automation, or deployment population.
Assess residual risk. Identify the approver and whether launch must be delayed, narrowed, or rejected.

This workflow combines conditional legal screening with recommended controls. It should not be represented as the mandatory statutory contents of every assessment.

Automated decisions need a precise test

GDPR Article 22 concerns certain decisions based solely on automated processing, including profiling, that produce legal or similarly significant effects.

Do not collapse all associated protections into a general “right to an explanation.” Where the relevant Article 22 provisions apply, the statutory safeguards described in the supplied materials include obtaining human intervention, expressing a point of view, and contesting the decision.

“Solely automated” and “similarly significant” are legal tests, not slogans. Conversely, not every automated score, rank, or recommendation necessarily falls within Article 22.

Hiring illustrates the distinction. A résumé-ranking tool might affect review order without itself making the final employment decision. That does not make it harmless: the operation may still warrant transparency, accuracy testing, bias controls, risk assessment, and meaningful oversight. But it should not automatically be described as a solely automated legally significant decision without examining the workflow.

Do not assume that Swiss automated-decision rules are identical to GDPR Article 22. Maintain separate fields for:

Swiss high-risk profiling
Swiss automated individual decisions
GDPR profiling
GDPR Article 22 applicability
Transparency duties under each regime
Human-review design under each applicable rule

The precise Swiss–EU comparison should be verified using complete current legislation, ordinances, regulator materials, and relevant judgments.

Transparency, Rights, Retention, and Model-Related Requests

A useful AI privacy notice should explain, in clear language:

What personal data is processed
Where the data comes from
Which entity is responsible
What each operation is intended to achieve
Whether data is used for development, deployment, monitoring, or retraining
Which significant recipients or vendor categories receive it
Whether data is disclosed abroad
How long it is retained or how the period is determined
Whether consequential automated processing is involved
Which request and complaint routes are available

Avoid describing every secondary use as “product improvement.” That phrase can conceal materially different operations, including evaluation, behavioral analytics, safety review, annotation, and retraining.

For Swiss processing, the supplied practical material says transparency documentation may need to address collection and disclosures abroad. It also refers to access, rectification, deletion, and portability, but those concepts should not be presented as identical to GDPR rights because their legal basis, terminology, procedure, remedies, and exceptions may differ (practical FADP overview of transparency and individual requests).

Under the GDPR, rights potentially relevant to AI include:

Information
Access
Rectification
Erasure under applicable conditions
Restriction of processing
Data portability
Objection

Applicability and exceptions must be evaluated for the specific request and processing operation.

Build a system-level search workflow

A request involving an AI service should not be routed only to the customer-account database. Search locations may include:

Source and licensed datasets
Labeling and annotation systems
Training and fine-tuning stores
Evaluation and benchmark sets
Vector databases and embeddings
Prompt and output logs
Safety-monitoring records
Caches and backups
Support tickets
Human-review notes
Inferred profiles and scores
Product analytics
Customer-controlled workspaces
Downstream exports
Vendor and subprocessor systems
Retraining or feedback datasets

The workflow should identify which entity controls each location, which identifiers can be used to search it, whether the information remains personal data, and whether correction or deletion propagates downstream.

Treat database deletion and model remediation separately

Deleting a record from an operational database is different from determining whether related information remains recoverable from a trained model. The model question can require investigation into memorization, extraction, architecture, release context, auxiliary information, and the practical ability to isolate one person’s contribution.

Do not promise that any single intervention will always satisfy a request. Depending on the facts, teams might evaluate:

Dataset deletion
Suppression from retrieval indexes
Log deletion
Fine-tuning changes
Output filters
Access restrictions
Model-unlearning techniques
Retraining
Model replacement or retirement

These are possible responses, not automatic legal safe harbors. The appropriate action depends on the applicable right or remedy, available exceptions, technical evidence, proportionality, and whether the relevant information remains personal data.

Retention should be tied to the documented purpose of each store. “Kept while useful” is not an operational rule. Define a period or objective trigger, owner, deletion method, exceptions, and evidence. Vendor deletion should produce confirmation or auditable records rather than ending with an email request.

Vendors, Subprocessors, Security, and International Data Flows

AI vendor governance must examine actual architecture and behavior. A data-processing agreement or security certification can be valuable evidence, but neither proves what happens to prompts, outputs, logs, embeddings, or support records.

A provider described as a processor may require a different analysis if it independently reuses customer data for its own purposes.

AI vendor questionnaire

Ask each model provider, cloud host, labeling service, monitoring provider, and subprocessor:

What data will you process, and under whose instructions?
May prompts, outputs, files, telemetry, or feedback be used for training?
Where is data stored, backed up, and remotely accessed?
Which subprocessors receive it?
How are subprocessor changes communicated and approved?
Which personnel can access content, and why?
Which access controls and encryption measures apply?
How are tenants and environments separated?
What logs are created, and how long are they retained?
How can customers request deletion?
Does deletion cover backups and subprocessor systems?
How are incidents detected, investigated, and communicated?
What audit evidence or testing rights are available?
Which transfer mechanism supports each international route?
How does the service support human review and automated-decision controls?
What happens to customer data when the contract ends?

The supplied FADP extract states that a processor may use a third-party processor only with the controller’s prior approval. It also describes Swiss foreign disclosure through an adequacy basis, an approved or recognized safeguard, or an applicable statutory exception.

Map every route through which the following may travel:

Training and fine-tuning records
User prompts and uploaded files
Generated outputs
Embeddings and retrieval content
Telemetry and diagnostic data
Safety logs
Support records
Backups and disaster-recovery copies

The architecture diagram should show model APIs, cloud regions, support teams, security services, subprocessors, and onward transfers.

For Swiss operations, foreign disclosures may need to appear not only in the transfer register but also in transparency documentation, vendor records, and the processing inventory.

Vendor review should test claims in practice where proportionate. Useful exercises include:

A sample access request
A sample deletion request
Review of administrative access
Verification of regional routing
Confirmation of training-use settings
Review of subprocessor changes
An incident-notification exercise
Extraction or memorization testing for high-risk models

Commercial GDPR guidance similarly emphasizes that vendor contracts and certifications do not remove the deploying organization’s need to examine data locations, subprocessors, retention, deletion, security, and transfer arrangements (AI vendor compliance checklist).

Pseudonymization, synthetic data, federated learning, differential privacy, encryption, restricted access, and related techniques may reduce risk. Their effectiveness depends on implementation and context. None automatically makes a dataset or model anonymous, validates a transfer, or eliminates legal analysis.

Representatives, Enforcement Exposure, and a 90-Day Implementation Plan

A foreign private controller does not automatically need a Swiss representative merely because people in Switzerland can access its AI service.

The Swiss test described in the supplied material is conjunctive. The relevant processing must be connected to offering goods or services in Switzerland or monitoring behavior there, occur regularly and extensively, present high risk, and satisfy the remaining applicable statutory conditions. Territorial FADP coverage does not itself prove that a representative is required.

An EU representative assessment under the GDPR is separate. Do not copy the Swiss conclusion into the EU field or infer the complete EU test and its exceptions from Swiss law.

Enforcement should influence governance, not produce a fine-only comparison

The enforcement structures differ. The revised FADP gives the Federal Data Protection and Information Commissioner administrative powers and includes criminal sanctions directed primarily at responsible individuals. The GDPR can expose organizations to turnover-based administrative fines. A comparison based only on maximum headline amounts is incomplete and can also be misleading when it relies on material describing former Swiss law (Swiss legal guide on representatives and enforcement).

For Swiss operations, possible individual exposure makes clear ownership especially important. Assign named owners, approval authority, training duties, and escalation paths for compliance-critical decisions. For GDPR operations, preserve evidence showing that the organization designed, implemented, and tested the controls it claims to operate.

Days 1–30: Map scope and architecture

During the first month:

List legal entities, establishments, and business units
Identify every AI product, feature, model, and internal tool
Map Swiss and EU users, customers, employees, and applicants
Document territorial marketing and service availability
Identify behavioral monitoring and profiling
Separate development, testing, deployment, and retraining
Determine preliminary controller and processor roles
Map model providers, cloud hosts, and subprocessors
Record hosting, support, backup, and access regions
Classify operations provisionally as Swiss-only, EU-only, or dual-regime
Flag Swiss and EU representative questions
Escalate sector-specific and public-sector uses

The deliverable is a jurisdiction-and-data-flow map, not merely a vendor list.

Days 31–60: Build controls and documentation

During the second month:

Convert architecture maps into operation-level processing records
Document GDPR lawful-basis and Swiss legal assessments separately
Update notices to distinguish development, deployment, monitoring, and retraining
Add foreign-disclosure information where applicable
Establish GDPR DPIA and Swiss impact-assessment screening
Review processor and subprocessor terms
Document transfer routes and safeguards
Set retention periods and deletion methods
Create system-level request-search procedures
Define automated-decision and profiling review gates
Assign control owners and approval authority
Record open legal questions rather than masking them as completed controls

The deliverable is a working control set linked to each operation.

Days 61–90: Test whether the program works

During the final month:

Run a sample access request across datasets, logs, vectors, and vendors
Run a sample deletion request and retain evidence
Review privileged and support access
Validate that regional routing matches documentation
Test whether human reviewers can understand and reverse recommendations
Verify that reviewers do not merely rubber-stamp outputs
Conduct an incident exercise involving an AI vendor
Test escalation for sensitive data appearing in prompts
Train employees with compliance-critical responsibilities
Review subprocessor approvals and change notices
Assemble evidence packages for high-risk operations
Obtain legal review for unresolved jurisdiction-specific questions

Evidence package for each high-risk use case

Maintain a compact package containing:

Defined purpose and prohibited uses
Applicable jurisdictions
Entity and role allocation
Data and system-flow diagram
GDPR lawful-basis or Swiss legal assessment
Impact assessment
Data-source and quality analysis
Known model limitations
Profiling and automated-decision analysis
Human-review design
Vendor and subprocessor controls
Security measures and test results
Retention and deletion rules
International-transfer analysis
Notice language
Request-handling test results
Residual risks and launch approval

The core-plus checklist is straightforward:

Determine jurisdiction for every processing operation.
Inventory personal data across the AI lifecycle.
Separate development from deployment.
Document purposes, roles, applicable legal analyses, retention, and risk.
Assess high-risk uses before launch.
Govern vendors, subprocessors, and international transfers.
Prepare request, deletion, and incident workflows.
Add the Swiss or EU overlay that applies.

Substantial alignment makes reuse possible. Neither a GDPR policy nor a vendor certification substitutes for a current, use-case-specific FADP and GDPR analysis.

Frequently Asked Questions

Does GDPR compliance automatically make an AI company compliant with Switzerland’s FADP?

No. A mature GDPR program can provide a strong operational foundation because the regimes address recurring themes such as transparency, security, privacy by design, processing records, vendor oversight, retention, and risk assessment.

Swiss-specific requirements still need to be identified and added. Depending on the operation, those additions may concern territorial scope, representatives, foreign disclosures, consent, profiling, processing records, enforcement, remedies, or sector rules.

When does a Swiss AI company also have to comply with the GDPR?

A Swiss company may come within the GDPR when it offers goods or services to people in the EU or monitors their behavior there. An EU establishment can also affect the analysis.

The assessment should concern the particular processing operation rather than incorporation alone. A Swiss-facing product and an EU-facing product built on the same underlying model may therefore produce different jurisdictional conclusions.

Does every foreign AI company serving Swiss users need a Swiss representative?

No. The representative requirement is conditional. The supplied Swiss material describes a conjunctive test involving processing connected to offering goods or services in Switzerland or monitoring behavior there, regular and extensive processing, high risk, and the remaining statutory conditions.

A foreign provider may fall within the FADP without satisfying the narrower representative test. Document the two conclusions separately.

Does every AI project require a data-protection impact assessment?

No. The trigger is risk, not the AI label itself.

A formal assessment may be required where processing is likely to create high risk. Indicators can include sensitive data, large-scale or systematic monitoring, extensive profiling, consequential automated decisions, certain processing involving children, and possible physical-harm risks. Even where no formal assessment is required, a documented risk review can remain a prudent control.

Is an AI model anonymous after its original training records are deleted or pseudonymized?

Not necessarily. Deleting source records or removing direct identifiers may reduce risk, but it does not prove that information cannot be linked to an individual or extracted from the model.

The assessment should consider memorization, extraction methods, auxiliary information, release context, available technology, cost, and time. Model anonymity is a factual and technical conclusion requiring evidence—not a status created by a contract label or a single de-identification step.

This article is informational only and is not legal, HR, or employment advice. Privacy and AI requirements change and vary by jurisdiction, sector, role, and system design. As reflected in the website’s terms and important notice, confirm current, use-case-specific requirements with qualified counsel before acting.