Switzerland FADP AI Controls Mapping: Duty, Owner, Test and Evidence

TL;DR

• Swiss FADP duties apply directly to AI processing, but only two of the mapped areas can be enforced fully at the request path: approved model routes under Article 16 and tested HTTP security controls under Article 8.
• Every other duty stays partial, because the gateway applies a legal decision it never makes.
• Purpose codes, endpoint allowlists and destination inventories give privacy and platform testable evidence.
• Notices, contracts, DPIAs, human reviews and FDPIC notification keep their named owners.

The Swiss FADP turns one enterprise LLM request into several control questions. Purpose falls under Article 6, security under Article 8, and the processing record under Article 12. Articles 16 and 19 address where the personal data went and what the person was told. The FDPIC's 24 September 2025 AI guidance makes the application explicit: the technology-neutral law governs AI-supported processing.

I use six fields for this Switzerland FADP AI controls mapping: duty, objective, owner, implementation, test and evidence. Coverage describes the HTTP AI boundary only. It says nothing about the quality of adjacent legal or governance work.

Purpose and minimization controls

Article 6 of the Federal Act on Data Protection requires lawful, good-faith and proportionate processing tied to a recognizable purpose. Article 7 requires protection by design, protection by default and processing limited to the minimum needed for the intended purpose.

Privacy owns the approved purpose and product owns the data design. Platform engineering can enforce their decisions by attaching a purpose code and permitted data classes to each model route. The test sends a payload containing an unnecessary personal field under a valid identity. Evidence includes the policy version, classification result and handling decision.

Coverage remains partial because the request point can enforce an approved purpose policy while privacy establishes the legal purpose and product redesigns excessive collection.

Processor control

Article 9 allows assignment to a processor under the controller's permitted processing and applicable confidentiality, with the controller verifying data security. Further assignment requires prior approval.

Procurement and legal own the contract, security owns provider assessment, and platform owns the permitted endpoint list. A quarterly test reconciles provider and subprocessor approvals against model destinations observed in production. The evidence set contains agreements, approval dates, assessment results and endpoint records.

Coverage remains partial because endpoint policy can refuse an unapproved provider, while contract terms, subprocessor approval and provider security review sit outside the gateway.

Processing-record control

Article 12 requires controller and processor records. The controller record must contain the identity of the controller, the purpose of processing, the categories of data subjects and of processed personal data, and the categories of recipients. Two further fields are qualified rather than absolute: the retention period, or the criteria for determining it, and a general description of the Article 8 data security measures are each required only if possible. The destination State and the guarantees under Article 16 paragraph 2 apply only where the data are disclosed abroad.

Privacy owns the Article 12 record and platform supplies a destination inventory built from observed AI traffic, with request classifications aggregated by use case. The test compares the recipient and country fields with the prior 30 days of runtime routes. Evidence is the signed reconciliation, discrepancy list and closure record.

Coverage is partial because runtime evidence supports selected fields. Retention schedules and the legal description of processing remain governance artifacts.

Foreign-disclosure control

Article 16 permits foreign disclosure under an adequacy decision or a listed guarantee, with exceptions under Article 17. Article 19 requires information about the destination state and applicable guarantee or exception.

Legal owns the transfer basis, while platform implements a country and endpoint allowlist per data class. The test changes a model base URL to an endpoint outside the approved state set and expects refusal before payload transmission. Evidence consists of the transfer assessment, route policy, attempted destination and decision record.

Coverage is full for enforcing the approved route on HTTP LLM traffic and partial for the broader legal duty. The control applies the legal decision; it never creates that decision.

Transparency control

Article 19 requires appropriate information at collection, including controller identity, purpose and recipients. The FDPIC's 24 September 2025 guidance calls for transparency around AI purpose, functionality, data sources, machine interaction and reuse of entered data.

Privacy drafts the notice and product presents it. The implementation links a notice version to the use case and records the version active at interaction time. The test samples an AI interaction and verifies that the correct notice appeared before collection. Evidence includes interface captures, notice history and interaction timestamps.

Coverage is outside the gateway for presentation. A request record can preserve the notice version supplied by the application, which gives supporting evidence rather than delivery proof.

Automated-decision control

Article 21 applies to exclusively automated decisions carrying legal consequences or considerable adverse effects. It provides for information, an opportunity to express a view and human review on request, subject to statutory exceptions. Article 25 adds access to the logic behind an applicable automated decision.

Legal classifies the decision before the business owner runs human review. Engineering links the model interaction to the downstream case and final outcome. A tabletop begins with one person reference and retrieves the notice, model records, reviewer and final decision. Evidence is the joined case file.

Coverage remains partial because request-path records reconstruct the model interaction, while people and workflow controls deliver the Article 21 review.

High-risk processing control

Article 22 requires a data protection impact assessment beforehand where processing is likely to create high risk, with new technology expressly relevant. Article 23 provides the consultation path where planned measures leave high residual risk.

Privacy owns the threshold decision and assessment. Security and platform own tests for the technical safeguards named in it. Each safeguard receives a control ID, test case, result and evidence link before launch. A failed destination test or role test keeps the associated control open.

Coverage remains partial because runtime controls implement and evidence technical safeguards, while DPIA reasoning, residual-risk approval and FDPIC consultation remain with privacy.

Security and incident controls

Article 8 requires security appropriate to risk and measures aimed at avoiding data security breaches. Article 24 requires notice to the FDPIC as quickly as possible for a breach likely to create high risk, including its nature, consequences and measures taken or planned.

Security owns request classification and fail-closed policy. Incident response and privacy own the notification decision. Tests cover a sensitive-data marker, unknown route and policy-service failure. Evidence includes signed decisions, affected request IDs, destination history and containment policy changes.

Coverage is full for the tested HTTP request controls and partial for Article 24. Notification analysis and communication stay outside the traffic path.

Consolidated mapping

FADP duty             Owner                 Control at AI use              Test                         Coverage
--------------------  --------------------  -----------------------------  ---------------------------  --------
Art. 6 purpose        Privacy + business    Purpose code per model route   Unrelated-purpose request    Partial
Art. 7 minimization   Product + platform    Data-class policy              Excess-field payload         Partial
Art. 8 security       Security              Classify, route, fail closed   Marker, unknown route, fault Full
Art. 9 processors     Legal + procurement   Approved endpoint inventory    Destination reconciliation   Partial
Art. 12 records       Privacy               Runtime recipient feed         30-day RoPA comparison        Partial
Art. 16 disclosure    Legal + platform      Country and endpoint policy    Unapproved foreign endpoint  Partial
Art. 19 information   Privacy + product     Versioned notice               Interaction-to-notice sample Outside
Art. 21 decisions     Legal + operations    Human-review workflow          Person-to-case tabletop      Partial
Art. 22 DPIA          Privacy               Control-linked assessment      Safeguard evidence review     Partial
Art. 24 breach        IR + privacy           Incident query and decision   Unapproved-route tabletop     Partial
Art. 25 access        Privacy operations    Search by stable person ref    30-day response exercise      Partial

The table has one Full row because the FADP is a governance regime with technical duties inside it. Turning the other rows green through product language would erase the accountable owner. My opinion is that a controls map earns trust through its grey cells.

The concrete review move is simple: place the table on one screen and open a sampled request on the other. Every Partial row should point to both artifacts, the gateway record and the legal or operational record that completes it. The Swiss FADP audit evidence guide explains that package; the implementation checklist turns it into completion tests.

DeepInspect

DeepInspect implements the request-path portions of this mapping for authenticated users or agents calling HTTP-based LLM endpoints. It evaluates identity context supplied by the application, data classification, destination and policy before the request reaches the model, then creates a signed, tamper-evident per-decision record on an independent write path.

That gives platform and security a testable enforcement point for purpose codes, data classes, approved model routes and fail-closed behaviour. It gives privacy evidence for recipient reconciliation, foreign-destination checks, automated-decision reconstruction, rights searches and incident scoping. Notices, contracts, DPIAs, human reviews and FDPIC communications retain their named owners. Book a technical deep dive at deepinspect.ai.