Switzerland FADP AI Compliance Checklist: 11 Tests for a Live Deployment
The Swiss FADP has governed AI-supported personal-data processing since 1 September 2023. This eleven-item checklist follows implementation dependencies: inventory, purpose, processor terms, records, foreign disclosure, transparency, automated decisions, DPIA, security, rights and incidents. Every item names an owner, evidence and a completion test.
The Swiss Federal Act on Data Protection has applied since 1 September 2023, and the FDPIC confirmed on 24 September 2025 that it reaches AI-supported processing. A working checklist has to follow the dependency chain inside the deployment. The record of processing activities depends on a real inventory; the impact assessment depends on known data flows; incident decisions depend on retrievable request facts.
This Switzerland FADP AI compliance checklist uses eleven completion tests. Each one names the owner and artifact so a reviewer outside the implementation team can grade it.
1. Inventory every AI route carrying personal data
Article 5 of the Federal Act on Data Protection defines personal data around an identified or identifiable natural person. Prompts, retrieved context, attachments and outputs can each contain it.
Owner: AI platform and privacy.
Evidence: use-case register, endpoint inventory and a reconciliation against observed HTTP model traffic.
Done when: every endpoint observed during the prior 30 days maps to an approved use case, controller, processor and data classification, with discrepancies assigned for remediation.
2. Assign a recognizable purpose to each route
Article 6 requires lawful, proportionate processing for a specific purpose recognizable to the data subject, followed by compatible further processing.
Owner: privacy and the business process owner.
Evidence: purpose register and route-to-purpose mapping.
Done when: every approved model route carries a purpose code linked to the use-case record, and a test request under an unrelated purpose is refused or sent for approved exception handling.
3. Bind processors to the controller's instructions
Article 9 allows processing by a processor where the controller could perform the same processing and confidentiality permits the assignment. The controller must satisfy itself that the processor can guarantee data security; further assignment requires prior approval.
Owner: procurement, legal and privacy.
Evidence: processor agreement, security assessment, subprocessor approval record and retention terms.
Done when: each provider in item 1 has a current agreement and assessment covering actual prompt use, output handling, provider retention and subprocessor approval.
4. Reconcile the Article 12 processing record
Article 12 requires controller and processor records covering purpose, data categories, recipients, retention, security measures and foreign disclosures. Its small-entity exception depends on fewer than 250 employees plus negligible processing risk.
Owner: The privacy team owns this item.
Evidence: processing record linked to the route inventory.
Done when: recipient, country and data-category fields reconcile against observed traffic, and every difference has a dated explanation or remediation ticket.
5. Control foreign disclosure at the endpoint
Article 16 uses adequacy decisions and listed safeguards for foreign disclosures. Articles 12 and 19 require the state and relevant guarantee to appear in records and information supplied to data subjects.
Owner: legal for the transfer basis; platform for routing.
Evidence: transfer assessment, approved-country matrix and per-request destination record.
Done when: a test call to a provider endpoint outside the approved country set is refused, while the decision record identifies the attempted endpoint, identity and policy version.
6. Make AI processing transparent
Article 19 requires information about the controller, purpose and recipients. The FDPIC's 24 September 2025 guidance says AI manufacturers, providers and users should make purpose, functionality and data sources transparent, including machine interaction and reuse of entered data for model improvement.
Owner: The privacy and product teams own this item.
Evidence: notice text, interface capture and notice-version log.
Done when: the person sees the applicable notice before collection, and a sampled interaction links to the notice version in force on that date.
7. Create the automated-decision review path
Article 21 covers exclusively automated decisions with a legal consequence or considerable adverse effect. It requires information and, on request, an opportunity to express a view and obtain review by a natural person, subject to stated exceptions.
Owner: legal and the business process owner.
Evidence: decision classification, notice, review procedure and case log.
Done when: a tabletop produces the model interaction, reviewer assignment, human outcome and response to the person under one case reference.
8. Complete the DPIA before high-risk processing
Article 22 requires a data protection impact assessment beforehand where processing is likely to create a high risk to personality or fundamental rights. The assessment describes planned processing, risks and protective measures. Article 23 sends unresolved high residual risk to prior FDPIC consultation through the applicable statutory route.
Owner: privacy, with security and engineering input.
Evidence: dated threshold decision, DPIA, residual-risk approval and consultation record where required.
Done when: every use case has a documented threshold decision dated before launch, and each safeguard promised in a required DPIA maps to a test result.
9. Test data security on the request
Article 8 requires technical and organizational measures appropriate to risk. Article 7 adds protection by design, protection by default and processing limited to the minimum required for the intended purpose.
Owner: security and AI platform.
Evidence: request classification rules, destination policy, fail-closed test and minimization test.
Done when: a prompt containing a controlled sensitive-data marker reaches the expected policy branch, an unknown route is refused, and both results carry signed decision records.
10. Make Article 25 answers reproducible
Article 25 entitles a person to information including processed data, purpose, retention, source, recipients and, where applicable, the logic behind an automated individual decision. The general response period is 30 days.
Owner: The privacy operations team owns this item.
Evidence: rights procedure, stable person reference, search results and response approval.
Done when: a tabletop retrieves relevant AI interactions across the approved review period, connects them to business-system records and produces a reviewed answer within the internal service target.
11. Build the Article 24 incident packet
Article 24 requires notification to the FDPIC as quickly as possible where a data security breach is likely to create a high risk. The notice describes the breach, consequences and measures taken or planned; processors alert controllers as quickly as possible.
Owner: incident response and privacy.
Evidence: incident timeline, affected request IDs, data classes, destinations, containment action and notification decision.
Done when: a tabletop involving an unapproved model route produces the affected identities, payload classes and destination evidence during the first response shift.
Coverage boundary
Items 2, 3, 6, 7, 8, 10 and the legal decision in item 11 require privacy, legal, procurement or business-process work. Request-path controls contribute facts and enforcement to items 1, 2, 4, 5, 8, 9, 10 and 11. The ownership split is deliberate.
My view is that item 4 exposes the health of the whole program. Put the processing record on a whiteboard beside one week of observed endpoints. Any provider name appearing on only one side is a concrete compliance gap, and the mismatch gives the owner a precise place to start.
For an artifact-by-artifact review, see the Swiss FADP audit evidence guide. The obligation and control-owner view sits in the Swiss FADP controls mapping.
DeepInspect
DeepInspect supplies the HTTP request control point used in items 1, 2, 4, 5, 8, 9, 10 and 11. It evaluates application-supplied identity, data class, model route and policy for authenticated users or agents, then creates a signed, tamper-evident per-decision record outside the calling application's write path.
That record supports route inventory, purpose enforcement, recipient reconciliation, destination testing, safeguard evidence, rights searches and incident scoping. Contracts, notices, DPIAs, transfer mechanisms, human reviews and FDPIC notifications remain with their named owners. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does the FADP apply to a foreign company using AI?
Article 14 can require a Swiss representative where a foreign private controller processes personal data of people in Switzerland in connection with offering goods or services or monitoring behaviour, at scale, regularly and with high risk. Applicability should be documented per use case.
- Does every company need an Article 12 processing record?
Article 12 requires controller and processor records. The Federal Council may provide exceptions for legal entities with fewer than 250 employees whose processing presents negligible risk. Both parts of that exception require support.
- Is every AI output an automated individual decision?
Article 21 applies where a decision is based exclusively on automated processing and carries a legal consequence or a considerable adverse effect. The role of human review and the effect on the person determine the classification.
- Which date matters for a DPIA?
Article 22 requires the assessment beforehand. The approval date, deployment date and first processing date should therefore appear together in the evidence package.
- What should the first technical test cover?
Use an unapproved destination and a controlled sensitive-data marker. The pair tests routing policy, request classification, failure posture and decision-record retrieval under Article 8.