Switzerland FADP AI Audit Evidence: Build the Record Before the Review

A Swiss FADP review starts with a processing activity and follows it into the deployed system. For an enterprise LLM, that path runs through the prompt payload, the identity that initiated it, the provider endpoint, the policy decision and the resulting output. The Federal Data Protection and Information Commissioner confirmed on 24 September 2025 that the Federal Act on Data Protection applies directly to AI-supported processing.

I would build the Switzerland FADP AI audit evidence as a chain of linked records. A binder full of policies says what the organization intended. A sampled request, tied to the applicable purpose and safeguards, shows what happened.

Start with the processing record

Article 12 of the Federal Act on Data Protection requires controllers and processors to maintain records of processing activities. The controller record covers purpose, categories of data subjects and personal data, recipient categories, retention, security measures and foreign disclosures. Smaller legal entities receive an exception only where they have fewer than 250 employees and their processing poses a negligible risk.

For each AI use case, the opening exhibit should identify the controller, processor, purpose, prompt data classes, provider, endpoint region and retention rule. Then attach observed traffic for the review period. A route inventory based on procurement records alone misses model endpoints introduced through SDK configuration, embedded features and agents. The useful artifact reconciles the Article 12 record against the destinations actually reached.

Select samples that test the controls

A random sample can show ordinary operation. It rarely tests the risky branches an FDPIC reviewer cares about. I would select three groups: permitted requests carrying ordinary personal data, requests containing sensitive personal data, and denied requests aimed at an unapproved provider or region.

Each sampled request needs a stable record ID, timestamp, initiating identity, role, declared purpose, data classification, destination, policy version and outcome. Keep the source payload under access controls, with a redacted rendering for the evidence package. On a review screen, the assessor should be able to click one record ID and see the policy version beside the destination country.

The sample design should also include one timeout and one unknown route. Those cases prove the control's failure posture rather than its behaviour during normal traffic.

Connect purpose, transparency and recipients

Article 6 limits collection to a specific purpose recognizable to the data subject and requires compatible further processing. Article 19 requires information about the controller, purpose and recipients, plus the destination state and safeguards where personal data goes abroad. The FDPIC's 24 September 2025 AI guidance adds a direct implementation expectation: purpose, functionality and data sources should be transparent.

The evidence package therefore needs a purpose code on each sampled request, linked to the approved use case and the notice shown to the affected person. It also needs a destination record linked to the recipient category in that notice. If a support assistant sends a ticket transcript to a new model endpoint, the package should expose the purpose, data classes and recipient together. That linkage gives compliance and security one shared fact pattern.

Prove foreign disclosure per route

Article 16 permits disclosure abroad where the Federal Council recognizes adequate protection or where an accepted safeguard applies. Article 12 also places the state and applicable guarantees in the processing record. For hosted AI, the operational event is the outbound HTTPS request to a model endpoint.

Evidence should pair the legal transfer assessment with route-level records. The legal file identifies the destination state, adequacy status or safeguard. Runtime records show which state and endpoint received each sampled request. A contract naming a Swiss region supports the intended design; DNS, base URL and provider-route evidence support actual operation.

This distinction matters because model routing can change through configuration. My view is blunt: a transfer assessment without observed destination evidence belongs in procurement, not in an audit conclusion about deployed AI.

Tie the DPIA to deployed safeguards

Article 22 requires a data protection impact assessment before processing likely to create a high risk to personality or fundamental rights, especially where new technologies are involved. The assessment must describe the planned processing, evaluate risks and describe protective measures. Article 23 requires prior consultation with the FDPIC where planned measures leave a high residual risk, subject to the statutory route involving a qualified data protection officer.

The audit file should link each DPIA safeguard to a test and a result. If the assessment promises destination restrictions, test an unapproved endpoint. A minimization promise calls for a payload containing an unnecessary personal field and a record of how it was handled. Role limits can be tested by replaying the same request under two approved test identities. The dated DPIA stays with privacy; the test records show that its safeguards reached production.

Reconstruct automated decisions and rights requests

Article 21 covers decisions based exclusively on automated processing that carry a legal consequence or a considerable adverse effect. It requires notice and, on request, an opportunity to state a view and seek review by a natural person, subject to listed exceptions. Article 25 gives data subjects access to processed data, purpose, retention, source, recipients and the logic behind an applicable automated individual decision.

For an AI-assisted decision, preserve the request ID, input provenance, model route, output, downstream use, human-review state and final decision reference. The record should identify where the model's output entered the business process. Legal and operations own the human-review workflow. Request evidence supports their answer by locating the relevant model interactions under a stable person reference.

Package incidents separately

Article 24 requires the controller to notify the FDPIC as quickly as possible when a data security breach is likely to create a high risk. The notification must describe the breach, consequences and measures taken or planned. The processor must alert the controller as quickly as possible.

An incident exhibit should contain the detection time, affected request IDs, identities, data classes, destinations, policy versions and containment changes. Add the notification decision and its legal rationale. The technical record supports the facts; privacy owns the threshold analysis and communication.

Keep this exhibit separate from routine samples. An assessor should see a clean incident timeline rather than hunt through a month of traffic records for six highlighted rows.

DeepInspect

DeepInspect supplies the request-path evidence in this package. It sits between authenticated users or agents and HTTP-based LLM endpoints, evaluates application-supplied identity, data class, route and policy on each call, and writes a signed, tamper-evident per-decision record outside the calling application's write path.

For Articles 6, 8, 12, 16, 19, 21, 24 and 25, those records support purpose testing, security-control tests, recipient reconciliation, destination evidence, decision reconstruction and incident scoping. DeepInspect leaves notices, transfer assessments, DPIAs, human review decisions and FDPIC communications with privacy, legal and operations. Book a technical deep dive at deepinspect.ai.