Which controllers does Swiss data protection actually reach?
Settle this before the engineering question, because group functions get it wrong in both directions. The revised Federal Act on Data Protection (revFADP; DSG in German, LPD in French, SR/RS 235.1) is not limited to Swiss-established controllers. Art. 3 states that the Act applies to circumstances that have an effect in Switzerland, even if they were initiated abroad. A model served from Dublin or Virginia, operated by a London team, deciding about people in Switzerland, is within scope.
Two consequences follow for a multinational. First, which entity is caught is not settled by the org chart: the controller is whoever determines the purposes and means of the processing, frequently a group function rather than the Swiss subsidiary in the local registry. Second, art. 14 requires a private controller established abroad to designate a representative in Switzerland where it processes data of people in Switzerland in connection with offering goods or services or monitoring behaviour, on a large scale, regularly and with a high risk to them. For a vendor selling AI-driven decisioning into Switzerland without a Swiss entity, that is the provision to read first.
The supervisory position is settled: the Federal Data Protection and Information Commissioner (FDPIC) — EDÖB in German, PFPDT in French — stated on 8 May 2025 that the revFADP is drafted to apply to all types of technology and is therefore directly applicable to AI-supported processing. There is no gap to wait out.
Does Swiss law require you to log an AI agent?
Not in those terms. A data protection officer searching the revFADP for an article enumerating the fields of a log will not find one for private controllers. The tempting conclusion — that nothing is required — is the most expensive error in the file, because the requirement exists without being written as a list.
There is one express logging rule, worth stating precisely so that it is not oversold. Art. 4 of the Ordinance on Data Protection (FADPO; DSV in German, OPDo in French, SR/RS 235.11) requires private controllers to log the storage, alteration, reading, disclosure, deletion and destruction of the data — but only where they process sensitive personal data on a large scale or carry out high-risk profiling, and the log must be kept for at least a year, separate from the system in which the data are processed. Note what it is: a record of data operations, not of decisions. It will tell you that a record was read; it will never tell you why an agent acted on it, on which model version, or on whose approval. Even where art. 4 bites, it does not answer the question art. 21 asks.
The real requirement comes from three sources at once:
- Art. 21 para. 2 revFADP — the review by a natural person. This sets the standard: whatever that person needs in order to form a view has to exist somewhere.
- Art. 8 para. 3 revFADP — the minimum data security requirements the Federal Council issues, given content by the FADPO. Wilful disregard of them is an offence under art. 61.
- The FINMA reproducibility expectation, for supervised institutions. FINMA guidance 08/2024 of 18 December 2024 records that results often cannot be understood, explained or reproduced and therefore cannot be critically assessed, and expects documentation of material applications down to assumptions, limitations, testing and fallback solutions.
Elsewhere the law does name the fields — the Danish supervisory authority prescribes logging every use of personal data, from reading to deletion. That has no force in Switzerland; it only measures the distance between a regime that lists the fields and one that leaves you to derive them.
Why does re-running the decision prove nothing?
With a deterministic process the review is trivial: same rules, same inputs, same result, and re-execution is the explanation. With an agentic system that equivalence collapses. The output is not reproducible, and the model behind the interface may have been replaced by the provider without a parameter changing on your side. Re-running manufactures a second event and compares it against a result whose origin nobody knows.
Whether the review under art. 21 para. 2 revFADP is feasible at all depends on this. Without a record, the reviewing person can only take the decision again on their own account and present the outcome as a confirmation — not a review, but a second decision wearing the same name. It becomes concrete precisely where the exception in art. 21 para. 3 let. a does not apply: that exception operates only where the data subject's request is granted, so on a refusal it covers nothing — and a refusal is exactly the decision people ask to have reviewed. See automated individual decisions and, in general terms, human in the loop.
Which fields does a deterministic process not need?
Most logs were designed for deterministic sequences. They record that something happened and leave the why to the code, which is assumed unchanged. Applied to an agent they leave precise holes.
| Field | Required by | Why a deterministic process can omit it |
|---|---|---|
| Trigger of the operation | Art. 8 para. 3 revFADP; ISA art. 74a et seq. | The trigger is the schedule: known by construction |
| Input data the decision rested on | Art. 21 para. 2 revFADP | Reconstructable from the data state; the rule is known |
| Model and configuration version at the time of the operation | Art. 21 para. 2 revFADP; FINMA expectation | Follows from the released version; code does not change by itself |
| Policy version applied and approval threshold in force | FINMA guidance 08/2024; art. 8 para. 3 revFADP | The rule is the code: no separate policy to date |
| Approval: who approved, and what was displayed to them | Art. 21 para. 2 revFADP | No human appraisal step to document |
| Attempts that failed, were aborted or were refused | ISA art. 74a et seq.; art. 8 para. 3 revFADP | A deterministic failure leaves no ambiguity |
The version field is almost always absent. Without it an atypical decision cannot be interpreted: was it an error, or correct behaviour under the configuration then active? The two are indistinguishable after the event. A version inferred from a deployment log settles nothing — it evidences what was rolled out, not what the operation ran on.
On the input data the symmetrical risk is excess: a log that copies the entire context becomes a processing operation in its own right — sometimes of sensitive personal data — with its own retention and access questions. That perimeter is fixed during the data protection impact assessment that art. 22 revFADP requires where processing is likely to result in a high risk, in particular from the use of new technologies.
How does this differ from GDPR Article 22?
This is the comparison an English-speaking reader arrives with, and the architectures differ. Article 22 GDPR is framed as a right not to be subject to a decision based solely on automated processing, subject to exceptions — a prohibition in structure. Art. 21 revFADP is framed the other way round: an obligation on the controller to inform the data subject of the decision, plus a right for that person to state their position and to request review by a natural person.
For traceability the consequence is the opposite of what the softer framing suggests. A prohibition model lets an organisation argue itself out of the regime through consent or contractual necessity; the Swiss model leaves a review right that has to be honoured, and honouring it requires evidence about a past decision. The same asymmetry applies to breach timing: Article 33 GDPR gives 72 hours, Swiss law gives no hours at all and requires notification to the FDPIC as soon as possible — the most common error in English-language coverage, covered under Swiss cyber-incident reporting.
Where does the market cite this wrongly?
Four claims recur; a budget justified by a false citation loses the first challenge.
| What is said | What Swiss law establishes |
|---|---|
| AI system logging is mandatory in Switzerland. | No express rule for private controllers. The requirement is derived from art. 21 para. 2 and art. 8 para. 3 revFADP; art. 4 FADPO covers data operations in a narrow set of cases only. |
| You have 72 hours to notify. | No 72-hour deadline exists in Swiss law. Notification to the FDPIC is made as soon as possible. The 24-hour clock belongs to the ISA and to the NCSC, for critical infrastructure only. |
| A gap in the log exposes the company to CHF 250,000. | Art. 60 to 63 revFADP target natural persons. The undertaking is liable only subsidiarily, up to CHF 50,000 (art. 64 para. 2). The FDPIC does not pronounce these fines: it issues rulings. |
| Our platform can replay the decision. | Replaying produces a new decision, not an explanation of the old one. That is not the review contemplated by art. 21 para. 2 revFADP. |
When does a logging failure become punishable?
Art. 60 to 63 revFADP are criminal fines against natural persons, of up to CHF 250,000 — not administrative sanctions against undertakings. Under art. 64 para. 2 the undertaking can be ordered to pay only where a fine of no more than CHF 50,000 is in contemplation and identifying the individual would require disproportionate measures. The fines are pronounced by cantonal criminal prosecution authorities, not by the FDPIC, which issues rulings.
Three failures commonly thought serious are not punishable as such: the absence of a register of processing activities under art. 12 revFADP (with the exemption in art. 24 FADPO for private organisations with fewer than 250 employees, unless sensitive personal data are processed on a large scale or high-risk profiling is carried out), an omitted data protection impact assessment, and an unnotified data security breach. They become relevant to sanctions only indirectly, through an FDPIC ruling and art. 63.
For logging the route runs elsewhere: art. 61 covers wilful disregard of the minimum data security requirements under art. 8 para. 3. Logging badly is therefore not itself an offence; what is punished is knowingly falling below the minimum requirements. And the exposure is personal — an individual liability, not a corporate risk line.
Why is the 24-hour ISA clock the real driver?
For operators of critical infrastructure — and for them alone — a hard operational constraint sits on top of all this. Under art. 74a et seq. of the Information Security Act (ISA; ISG / LSI, SR/RS 128) a cyberattack must be reported to the National Cyber Security Centre within 24 hours of discovery, with an incomplete initial report completed within 14 days; the duty has applied since 1 April 2025 and its sanctions, fines to CHF 100,000, since 1 October 2025.
Twenty-four hours is not enough to establish what happened when autonomous processes have executed a series of actions in the meantime, so the incident becomes a chain rather than an event and the first day's question is which links were authorised. Reconstruction speed determines the quality of the initial report. One point of delimitation for group readers: NIS2 has no direct effect in Switzerland, which belongs to neither the EU nor the EEA — it reaches Swiss suppliers contractually, through the supply-chain obligations of EU customers, not by force of law.
How do you test whether your logging holds?
Half an hour, no preparation. Take an operation at random from at least three months ago and reconstruct it: trigger, input data, model and policy version, approval — including what was displayed to the approver — and outcome. The condition: no application logs, no engineering help.
- Under five minutes, from a single source — the record is evidence.
- Possible, but only with engineering — there is no evidence, only a few individuals' reconstruction ability: not transferable, not available on a Sunday.
- Trigger and outcome reconstructable, earlier failed attempts untraceable — the most frequent result. What succeeded was recorded; what was attempted first was not, and in an incident that is the more interesting question.
Then fix the three things that matter more than the volume logged:
- Write the record before execution, not after the response. Otherwise precisely what went wrong is missing: aborted runs, timeouts, refused calls.
- Capture the model and configuration version with the operation rather than inferring it from a deployment log, and record what was shown to the approver.
- Separate write rights from modification rights and remove the agent's access to the record, or the system audits itself. Align retention with the compliance periods in which someone can demand the evidence, not with log rotation.
In practice
BarzelVault applies policy and approval thresholds ahead of execution and issues signed audit receipts, recording the trigger, the parameters, the policy version and the approver before the action leaves the system — nine tools, in a layer independent of the agent. Approval checkpoints do the equivalent for cross-system processes in governed workflow automation.
Frequently asked questions
Does Swiss law require AI agents to be logged?
Not expressly. The requirement is derived from art. 21 para. 2 and art. 8 para. 3 revFADP and, for supervised institutions, from the FINMA reproducibility expectation. Art. 4 FADPO is the only express logging rule for private controllers, and it records data operations in a narrow set of cases rather than decisions.
Why is re-running the decision not enough?
Because it produces a new decision, not an explanation of the old one. The same input can yield a different result, and the model may have been replaced in the meantime.
Which fields are typically missing?
The input data the decision rested on, and the model and configuration version at the moment of the operation. A deterministic process needs neither.
Who pays a Swiss data-protection fine?
A natural person, up to CHF 250,000, in criminal proceedings before cantonal authorities. The undertaking is liable only subsidiarily and only up to CHF 50,000 under art. 64 para. 2. The FDPIC issues rulings; it does not levy fines.
Is a data protection impact assessment needed before an agent goes live?
Art. 22 revFADP requires one where the processing is likely to result in a high risk, a risk arising in particular from the use of new technologies. It is the moment to fix in writing which fields will be logged.
Will a Swiss AI act mandate logging?
Nothing indicates it. On 12 February 2025 the Federal Council settled on a sector-specific approach and expressly not a horizontal act. A consultation draft has been announced for the end of 2026; as at 3 September 2026 none has been opened.
Related reading
- Swiss cyber-incident reporting: 24 hours to the NCSC
- Automated individual decisions under art. 21 revFADP
- Data protection impact assessments for AI under art. 22 revFADP
- FINMA guidance 08/2024 on AI governance
- AI agent audit trails
- AI agent governance — the library index
- Glossary and the running corrections list
In practice
Permission before the action. Evidence after it.
The duties on this page attach to the moment an automated system acts: who permitted it, on which data, under which policy version, and what a person saw before approving. Barzel enforces that decision before execution and writes the record an auditor, a regulator or a data subject can be shown.
In forceRevised FADP in force since 1 September 2023
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
Barzel Central Gateway
The AI governance control plane: one inventory and one policy layer across every MCP server and agent.
- Registers and synchronises every tool; enforces identity, policy, region, cost and health per tool.
- Identity mapping through OIDC, Entra ID, Okta, SAML and SPIFFE, with credential brokerage.
- Trace and SIEM export (W3C trace context, OTLP) for the security team and the regulator.
Free tier: 1,000 calls a monthPaid plans from $10 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Sources
- Federal Act on Data Protection (FADP), SR 235.1, art. 3, 8, 12, 14, 21, 22, 60–64 — fedlex.admin.ch English translation; binding texts: DSG (German) and LPD (French).
- Ordinance on Data Protection, SR 235.11, art. 4 (logging) and art. 24 (exemption from the register of processing activities) — fedlex.admin.ch; binding texts: DSV and OPDo.
- FDPIC, Update: current data protection legislation is directly applicable to AI, 8 May 2025.
- FINMA, Guidance 08/2024 on governance and risk management when using artificial intelligence, 18 December 2024.
- Informationssicherheitsgesetz (ISG), SR 128, art. 74a et seq.; NCSC, Information on the reporting obligation, in force since 1 April 2025, sanctions since 1 October 2025.
- Federal Council, AI regulation: Federal Council to ratify Council of Europe Convention, media release of 12 February 2025.
- Regulation (EU) 2016/679 (GDPR), art. 22 and art. 33 — cited for comparison; not applicable in Switzerland.
- Datatilsynet (Denmark), requirements on logging — cited as a comparator only; not applicable in Switzerland.
This article is for information and does not constitute legal advice. The German and French texts of the instruments cited are the binding ones. Position as at 3 September 2026.