A revDSG-compliant AI architecture: what actually counts

Under the revised Swiss Data Protection Act, liability for a breach falls on the natural person who acted, with a fine of up to CHF 250,000 — not on the company. That is the difference from the GDPR that shapes most architecture decisions, and it appears not in the catalogue of duties but in the criminal provisions.

That does not make the use of AI prohibited. The revised DPA requires four things: purpose-bound processing under the principles of Art. 6 DPA, transparency about collection under Art. 19, data security under Art. 8 in conjunction with the Data Protection Ordinance (DPO), and, for automated individual decisions, the right to review by a natural person under Art. 21.

The legal department asks about compliance. What you find on the subject are opinions: they say what applies, not which technical measure satisfies it. The second half is here.

Which four requirements does the revised DPA place on an AI system?

The revised DPA is the fully revised Federal Act on Data Protection of 25 September 2020 (SR 235.1), in force since 1 September 2023. Four of its provisions determine how an AI system has to be built. What binds is the statutory text on Fedlex, not a summary.

1. Art. 6 DPA, principles. Personal data may only be collected for a specific purpose that is evident, and must go as soon as they are no longer required for it. The purpose has to be recordable per processing step, not per product.
2. Art. 19 DPA, duty to inform. The data subject learns the identity of the controller, the purpose, and the categories of recipients. An inference provider is a recipient. Where data goes abroad, para. 4 adds the state and the safeguards under Art. 16 para. 2.
3. Art. 8 DPA, data security. The minimum requirements are in the DPO. Art. 2 DPO names four goals: confidentiality, availability, integrity, traceability. AI systems fail on the fourth.
4. Art. 21 DPA, automated individual decision. Where a decision is based exclusively on automated processing and has legal consequences or significantly affects the data subject, a duty to inform applies. The data subject can demand that a human review the decision.

To that add Art. 7 DPA: processing must be technically designed from the planning stage so that the rules are met. The article that turns the legal question into an architecture question.

Who pays the fine when an AI system breaches the revised DPA?

The natural person pays, not the company. Arts. 60 to 62 DPA make private persons liable to a fine of up to CHF 250,000. The business comes into it only subsidiarily: under Art. 64 para. 2 DPA the authority may sentence it instead of the persons acting, where a fine of at most CHF 50,000 is in question.

The provision relevant to an AI project is usually not Art. 60 but Art. 61 DPA, breach of duties of care. It catches precisely the three mistakes an architecture makes:

• Disclosure abroad contrary to Art. 16 paras. 1 and 2, without the conditions of Art. 17 being met (lit. a)
• Handover to a processor contrary to Art. 9 paras. 1 and 2 (lit. b)
• Failure to meet the minimum data security requirements under Art. 8 para. 3 (lit. c)

The Federal Data Protection Commissioner does not impose these fines. Under Art. 65 para. 1 DPA, prosecution and adjudication fall to the cantons, generally to the public prosecutors. He can issue orders and file complaints, as he notes himself on his page on the criminal provisions.

The practical consequence: under the GDPR, compliance is a balance sheet risk and gets delegated. Under the revised DPA it is personal. Signing off an agent system means signing with your own name.

What changes with sensitive personal data?

With sensitive personal data three duties tighten. Art. 5 lit. c DPA lists the categories exhaustively: health, the intimate sphere and affiliation to a race or ethnicity, genetic data, biometric data uniquely identifying a person, religious, ideological, political or trade-union views, data on administrative and criminal proceedings, and data on social assistance measures.

• Consent must be explicit (Art. 6 para. 7 lit. a DPA). A note in the terms of use is not enough.
• Data protection impact assessment for large-scale processing (Art. 22 para. 2 lit. a DPA).
• Logging, where they are processed automatically on a large scale or high-risk profiling takes place, and preventive measures cannot ensure data protection (Art. 4 para. 1 DPO). Both conditions have to coincide.
• Processing regulations already where they are processed on a large scale or high-risk profiling takes place (Art. 5 para. 1 DPO). Without the restriction that applies to the logging duty.

The catch for an agent system is classification at runtime. A free-text prompt from an HR or support channel contains such data without any database field marking it. Failing to recognise them means logging too little. That is why the audit log below carries a data_classes field.

Where do personal data actually end up in an agent system?

Personal data end up in seven places, and the model is the most harmless of them. Sovereignty almost never breaks at the inference provider but at the periphery, because that is where nobody looks.

• Prompt. What the user types. The only place most concepts look at.
• System context. Retrieval results, few-shot examples, master data from the CRM. Often more personal data than in the prompt, and nobody put them there deliberately.
• Tool calls. The agent calls an API with arguments. Those arguments are personal data and go to a second system.
• Vector database. A vector index over customer correspondence is a collection of personal data in an unfamiliar file format, and it needs the same deletion paths as the source.
• Logs. A stack trace contains the payload; a debug log the entire prompt.
• Telemetry. OpenTelemetry’s GenAI semantic conventions define gen_ai.input.messages, gen_ai.output.messages and gen_ai.system_instructions as span attributes. Even after moving to their own repository with release v1.42.0 of 12 June 2026 they remain at status “Development” (attribute registry), and they carry the full content of the conversation.
• Monitoring and eval SaaS. Error tracking, tracing, prompt evaluation. Three services that rarely appear in a contract review and often run in a third country.

The dotted edges are disclosures abroad that appear in no concept document. Anyone who draws their data flow this way usually finds two or three.

Draw your own flow like this once. It takes an hour and is the cheapest data protection measure we know. If you want somebody at the whiteboard who already knows the periphery: half an hour, no preparation.

How the same data flow can be built at the infrastructure level, with a provider comparison and GPU costs in CHF, is in sovereign AI inference in Switzerland.

What does “hosted in Switzerland” mean technically, and where does it stop?

“Hosted in Switzerland” describes the storage location, not the possibility of access. The two come apart as soon as the provider has a parent company in a third country, its support escalates from another time zone, or its control plane runs elsewhere. Access from outside is a disclosure abroad under Art. 16 DPA.

The test has two stages: is the recipient state in Annex 1 DPO? If not, a safeguard under Art. 16 para. 2 is required, for instance standard data protection clauses recognised by the Commissioner.

For the USA an intermediate position applies that is frequently misreported. Since 15 September 2024 it counts as a state with adequate data protection, but only for companies certified under the Swiss-U.S. Data Privacy Framework (Commissioner). Certification is per company, not per country.

Three technical consequences follow:

• Egress is enforced, not agreed. A network-level allowlist is the only evidence that survives a review.
• The inference endpoint belongs behind an abstraction of your own. Programming against a provider SDK means you cannot switch when the certification falls.
• Every outbound connection needs a recorded jurisdiction. At AIgent that is a start-up condition: an endpoint without a jurisdiction entry does not come up.

Where does the human-in-the-loop gate sit in the agent graph?

The gate sits between decision and effect, not between model response and decision. Art. 21 para. 2 DPA requires review by a natural person, and a decision is only reviewable while it has not been carried out. An approval after the rejection letter has gone out does not satisfy the provision.

What decides it is the behaviour on timeout: a gate that lets things through after a timeout is not a gate.

package hitl

import (
	"context"
	"errors"
	"fmt"
	"time"
)

// Decision is the agent's proposal before it takes effect.
type Decision struct {
	RunID       string
	SubjectRef  string   // pseudonym of the data subject, never the real name
	Action      string   // e.g. "application.reject"
	Rationale   string   // reasoning for the reviewing person
	DataClasses []string // e.g. []string{"creditworthiness", "employment"}
}

// Review is the outcome of review by a natural person.
type Review struct {
	ReviewerID string
	Approved   bool
	Comment    string
	At         time.Time
}

type Auditor interface {
	Append(ctx context.Context, runID, event string, payload any) error
}

type ReviewQueue interface {
	Await(ctx context.Context, d Decision) (Review, error)
}

var (
	ErrExpired  = errors.New("hitl: no approval within the deadline, decision discarded")
	ErrRejected = errors.New("hitl: rejected by the reviewing person")
)

// Gate holds an automated individual decision under Art. 21 DPA until a
// natural person has confirmed it. If the deadline passes, the decision counts
// as not taken. There is no path on which a timeout leads to a silent
// approval.
func Gate(ctx context.Context, a Auditor, q ReviewQueue, d Decision, wait time.Duration) error {
	if err := a.Append(ctx, d.RunID, "decision.proposed", d); err != nil {
		return fmt.Errorf("audit: %w", err)
	}

	waitCtx, cancel := context.WithTimeout(ctx, wait)
	defer cancel()

	r, err := q.Await(waitCtx, d)
	if err != nil {
		// The reason for abandoning belongs in the log, even when the context is dead.
		_ = a.Append(context.WithoutCancel(ctx), d.RunID, "decision.expired", err.Error())
		return ErrExpired
	}

	event := "decision.rejected"
	if r.Approved {
		event = "decision.approved"
	}
	if err := a.Append(ctx, d.RunID, event, r); err != nil {
		return fmt.Errorf("audit: %w", err)
	}
	if !r.Approved {
		return fmt.Errorf("%w: %s", ErrRejected, r.ReviewerID)
	}
	return nil
}

Two things are set deliberately. The proposal is logged before anyone sees it; otherwise there is no way to evidence that a review took place. And Decision carries a pseudonym rather than a name: the reviewing person resolves the identity through their own authorisation. The same separation we treat as an interface question in documenting architecture decisions is a data protection question here.

What does an audit log that survives a subject access request look like?

An audit log fit for the revised DPA answers, per data subject, which personal data were processed when, by whom and for what purpose. Art. 4 para. 4 DPO names the mandatory fields: identity of the processing person, type, date and time, and where applicable the recipient. Para. 5 requires at least a year of retention, separated from the system in which the personal data are processed. Anyone supplying software into the EU needs a second, similarly built log from September 2026: the incident log for the CRA reporting obligation.

-- Its own database, its own credentials, its own backup cycle.
-- Art. 4 para. 5 DPO requires separation from the processing system.
CREATE TABLE agent_audit (
    id           bigserial PRIMARY KEY,
    occurred_at  timestamptz NOT NULL DEFAULT now(),  -- Art. 4 para. 4 DPO
    run_id       uuid        NOT NULL,
    actor        text        NOT NULL,  -- 'user:4711', 'agent:triage@2.3.1', 'reviewer:rp'
    operation    text        NOT NULL   -- the six operations from Art. 4 para. 1 DPO
        CHECK (operation IN ('store','modify','read',
                             'disclose','delete','destroy')),
    subject_ref  text        NOT NULL,  -- pseudonym, resolvable only in the identity service
    data_classes text[]      NOT NULL,  -- which categories, not which contents
    recipient    text,                  -- 'llm:apertus@ch-inference', 'crm:abacus'
    jurisdiction char(2)     NOT NULL,  -- 'CH', 'EU', 'US'
    purpose      text        NOT NULL,  -- keep Art. 6 para. 3 DPA demonstrable
    payload_sha  bytea       NOT NULL   -- hash instead of content
);

-- Make an access request under Art. 25 DPA answerable in one query.
CREATE INDEX ON agent_audit (subject_ref, occurred_at DESC);
CREATE INDEX ON agent_audit (run_id);

The line most often missing is payload_sha. An audit log with the prompt in cleartext is a second copy of the personal data that then has to sit there for a year. The trade-off: the hash evidences the processing, but nobody can read back what was in it.

Two provisions collide here. Art. 6 para. 4 DPA requires destruction as soon as the data are no longer required; Art. 4 para. 5 DPO requires a year of retention for the log. That only resolves with separate lifecycles, as in the form service for the Swiss FOITT.

What we advise against

An enterprise subscription as proof of compliance. An enterprise plan governs whether the provider uses your data for training. That is the only one of the four requirements it can meet for you. Purpose limitation, the duty to inform, traceability and reviewability under Art. 21 arise in your system, not in their contract.

Prompt contents in general observability. Writing gen_ai.input.messages into the same trace backend as your HTTP spans puts the conversation content in a system whose retention is tuned for cost. Prompts belong in the audit log, not in telemetry.

And the trade-off we will name openly: self-hosting the model costs speed. You operate GPU capacity, lag behind on model capabilities, and move effort from an invoice into a team.

An inference provider from a state in Annex 1 DPO, combined with strict control of the periphery, meets the same four requirements with less operational effort. Self-hosting is the right answer for sensitive personal data such as health data, and how to do it is in sovereign AI inference in Switzerland. For an internal knowledge assistant it is the wrong one.

As in who writes the architecture: the guardrails live in the repository, not in someone’s head.

Frequently asked

Do I need a processor agreement for an AI provider?

Yes, as soon as it processes personal data on your behalf, and every hosted inference service does. Art. 9 para. 1 DPA permits the transfer only where the data are processed as you would be permitted to process them yourself. What regularly gets broken is para. 3: sub-processing requires your prior authorisation. That is checkable through the versioned sub-processor list, not through the contract text.

May I put personal data into ChatGPT?

Legally possible, technically rarely clean. You need processing under the principles of Art. 6 DPA, a processor arrangement under Art. 9, the information under Art. 19 including the recipient state, and, where the provider is not Swiss-U.S. DPF certified, a safeguard under Art. 16.

Which criminal provision applies depends on what is missing: for the safeguard Art. 61 lit. a, for the processor arrangement Art. 61 lit. b, for the information Art. 60 para. 1 lit. b.

Is an enterprise subscription enough for revDSG compliance?

No. An enterprise subscription governs training use and usually data residency. It creates neither the log under Art. 4 DPO nor the reviewability under Art. 21 DPA, and it says nothing about your vector database, your logs and your monitoring.

Do we need a data protection impact assessment for an AI assistant?

Where the processing may entail a high risk to personality or fundamental rights, yes (Art. 22 para. 1 DPA). Para. 2 names two standard cases: large-scale processing of sensitive personal data, and systematic monitoring of extensive public areas. Where a high risk remains despite measures, the Commissioner must be consulted (Art. 23).

Does the EU AI Act apply to our Swiss company?

It can apply extraterritorially. Art. 2(1)(c) of the AI Regulation covers providers and deployers from third countries where the output of the AI system is used in the Union. The obligations for high-risk systems under Annex III apply, following Regulation (EU) 2026/1744, only from 2 December 2027, and for embedded systems under Annex I from 2 August 2028.

---

Take your architecture diagram and draw in the jurisdictional boundaries. If edges appear that you cannot explain, let’s talk about them.

Thirty minutes with an engineer about your agent architecture, no sales pitch: book a slot. Prefer writing? Through contact. What we build is under Artificial Intelligence & Machine Learning.

All legal references verified on 18 August 2026 against Fedlex and the Federal Data Protection Commissioner. This article is architecture advice, not legal advice.