revDSG-konforme KI-Architektur: was wirklich zählt

Das revidierte Datenschutzgesetz (revDSG) verbietet den Einsatz von KI nicht. Es verlangt vier Dinge: eine rechtmässige und zweckgebundene Bearbeitung nach Art. 6 DSG, Transparenz über die Beschaffung nach Art. 19, Datensicherheit nach Art. 8 in Verbindung mit der Datenschutzverordnung (DSV), und bei automatisierten Einzelentscheidungen das Recht auf Überprüfung durch eine natürliche Person nach Art. 21.

Der Unterschied zur DSGVO, der die meisten Architekturentscheide prägt, steht nicht im Pflichtenkatalog. Er steht im Strafrecht: Die Busse bis CHF 250’000 trifft die natürliche Person, die vorsätzlich handelt, nicht das Unternehmen.

Die Rechtsabteilung fragt nach Konformität. Was man dazu findet, sind Gutachten: Sie sagen, was gilt, nicht, welche technische Massnahme das erfüllt. Hier steht die zweite Hälfte.

Welche vier Anforderungen stellt das revDSG an ein KI-System?

Das revDSG ist das totalrevidierte Bundesgesetz über den Datenschutz vom 25. September 2020 (SR 235.1), in Kraft seit dem 1. September 2023. Vier seiner Normen bestimmen, wie ein KI-System gebaut sein muss. Verbindlich ist der Gesetzestext auf Fedlex, keine Zusammenfassung.

Art. 6 DSG, Grundsätze. Personendaten dürfen nur zu einem bestimmten, erkennbaren Zweck beschafft werden und müssen weg, sobald sie dafür nicht mehr erforderlich sind. Der Zweck muss pro Verarbeitungsschritt festhaltbar sein, nicht pro Produkt.
Art. 19 DSG, Informationspflicht. Die betroffene Person erfährt Identität des Verantwortlichen, Zweck und Kategorien der Empfänger. Ein Inferenzanbieter ist ein Empfänger. Geht es ins Ausland, kommen nach Abs. 4 der Staat und die Garantien nach Art. 16 Abs. 2 dazu.
Art. 8 DSG, Datensicherheit. Die Mindestanforderungen stehen in der DSV. Art. 2 DSV nennt vier Ziele: Vertraulichkeit, Verfügbarkeit, Integrität, Nachvollziehbarkeit. Am vierten scheitern KI-Systeme.
Art. 21 DSG, automatisierte Einzelentscheidung. Beruht ein Entscheid ausschliesslich auf automatisierter Bearbeitung und hat er eine Rechtsfolge, gilt eine Informationspflicht. Die betroffene Person kann verlangen, dass ein Mensch den Entscheid überprüft.

Dazu kommt Art. 7 DSG: Die Bearbeitung ist ab der Planung technisch so auszugestalten, dass die Vorschriften eingehalten werden. Der Artikel, der die Rechtsfrage zur Architekturfrage macht.

Wer zahlt die Busse, wenn ein KI-System gegen das revDSG verstösst?

Die natürliche Person zahlt, nicht das Unternehmen. Art. 60 bis 62 DSG stellen private Personen mit Busse bis CHF 250’000 unter Strafe. Der Geschäftsbetrieb kommt nur subsidiär ins Spiel: Nach Art. 64 Abs. 2 DSG kann die Behörde ihn statt der handelnden Personen verurteilen, wenn eine Busse von höchstens CHF 50’000 in Betracht fällt.

Die für ein KI-Projekt einschlägige Norm ist meist nicht Art. 60, sondern Art. 61 DSG, Verletzung von Sorgfaltspflichten. Er trifft genau die drei Fehler, die eine Architektur macht:

Bekanntgabe ins Ausland entgegen Art. 16 und 17 (lit. a)
Übergabe an einen Auftragsbearbeiter entgegen Art. 9 (lit. b)
Mindestanforderungen an die Datensicherheit nach Art. 8 Abs. 3 nicht eingehalten (lit. c)

Der EDÖB verhängt diese Bussen nicht. Nach Art. 65 Abs. 1 DSG obliegen Verfolgung und Beurteilung den Kantonen, in der Regel den Staatsanwaltschaften. Er kann verfügen und Anzeige erstatten, wie er auf seiner Seite zu den Strafbestimmungen selbst festhält.

Punkt	revDSG	DSGVO
Sanktionsadressat	die handelnde natürliche Person (Art. 60 bis 62 DSG); der Geschäftsbetrieb nur subsidiär (Art. 64 Abs. 2)	der Verantwortliche oder Auftragsverarbeiter als Unternehmen (Art. 83)
Bussenhöhe	bis CHF 250’000; Unternehmensbusse bis CHF 50’000	bis EUR 20 Mio. oder 4 % des weltweiten Jahresumsatzes, je nachdem, was höher ist (Art. 83 Abs. 5)
Verschulden	nur Vorsatz; Art. 60 Abs. 1, 61 und 62 sind Antragsdelikte	auch Fahrlässigkeit wird sanktioniert (Art. 83 Abs. 2 lit. b)
Wer verfolgt	kantonale Strafverfolgungsbehörden (Art. 65 Abs. 1); der EDÖB verfügt, sanktioniert aber nicht	die Aufsichtsbehörde verhängt die Geldbusse selbst
Meldung einer Sicherheitsverletzung	„so rasch als möglich“ an den EDÖB, wenn voraussichtlich hohes Risiko (Art. 24 Abs. 1)	unverzüglich, möglichst binnen 72 Stunden (Art. 33 Abs. 1)
Automatisierte Einzelentscheidung	zulässig; Informationspflicht, auf Antrag Überprüfung durch einen Menschen (Art. 21)	grundsätzlich untersagt, zulässig nur in den Fällen von Art. 22 Abs. 2
Auftragsbearbeitung	Voraussetzungen in Art. 9; Unterauftrag nur mit vorgängiger Genehmigung (Art. 9 Abs. 3)	detaillierter Pflichtkatalog für den Vertrag (Art. 28)
Verjährung der Strafverfolgung	fünf Jahre (Art. 66)	in der DSGVO nicht geregelt, richtet sich nach nationalem Recht

Praktische Folge: Unter der DSGVO ist Compliance ein Bilanzrisiko und wird delegiert. Unter dem revDSG ist sie persönlich. Wer ein Agentensystem freigibt, unterschreibt mit seinem Namen.

Was ändert sich bei besonders schützenswerten Personendaten?

Bei besonders schützenswerten Personendaten verschärfen sich drei Pflichten. Art. 5 lit. c DSG zählt die Kategorien abschliessend auf, darunter Gesundheit und Intimsphäre, genetische und biometrische Daten, religiöse, politische oder gewerkschaftliche Ansichten sowie Daten über verwaltungs- und strafrechtliche Verfolgungen.

Die Einwilligung muss ausdrücklich sein (Art. 6 Abs. 7 lit. a DSG). Ein Hinweis in der Nutzungsordnung genügt nicht.
Datenschutz-Folgenabschätzung bei umfangreicher Bearbeitung (Art. 22 Abs. 2 lit. a DSG).
Protokollierung und Bearbeitungsreglement, wenn sie in grossem Umfang automatisiert bearbeitet werden und präventive Massnahmen den Schutz nicht gewährleisten (Art. 4 Abs. 1 und Art. 5 Abs. 1 DSV).

Der Haken für ein Agentensystem ist die Klassifikation zur Laufzeit. Ein Freitext-Prompt aus einem HR- oder Supportkanal enthält solche Daten, ohne dass ein Datenbankfeld sie markiert. Wer sie nicht erkennt, protokolliert zu wenig. Deshalb führt das Audit-Log unten ein Feld data_classes.

Wo landen Personendaten in einem Agentensystem tatsächlich?

Personendaten landen an sieben Stellen, und das Modell ist die harmloseste davon. Souveränität bricht fast nie beim Inferenzanbieter, sondern an der Peripherie, weil dort niemand hinschaut.

Prompt. Was die Nutzerin eintippt. Der einzige Ort, an dem die meisten Konzepte hinsehen.
Systemkontext. Retrieval-Ergebnisse, Few-Shot-Beispiele, Stammdaten aus dem CRM. Oft mehr Personendaten als im Prompt, und niemand hat sie bewusst dorthin gegeben.
Tool-Aufrufe. Der Agent ruft eine API mit Argumenten auf. Diese Argumente sind Personendaten und gehen an ein zweites System.
Vektordatenbank. Ein Vektorindex über Kundenkorrespondenz ist eine Personendatensammlung mit ungewohntem Dateiformat und braucht dieselben Löschpfade wie die Quelle.
Logs. Ein Stacktrace enthält den Payload, ein Debug-Log den ganzen Prompt.
Telemetrie. Die GenAI-Semantikkonventionen von OpenTelemetry definieren gen_ai.input.messages, gen_ai.output.messages und gen_ai.system_instructions als Span-Attribute. Sie stehen auch nach dem Umzug in ein eigenes Repository mit Release v1.42.0 vom 12.06.2026 im Status „Development“ (Attributregister) und transportieren den vollständigen Gesprächsinhalt.
Monitoring- und Eval-SaaS. Error-Tracking, Tracing, Prompt-Evaluation. Drei Dienste, die selten in einer Vertragsprüfung auftauchen und oft im Drittstaat laufen.

flowchart TB
  subgraph CH["Jurisdiktion Schweiz"]
    U["Mitarbeiterin<br/>Eingabe mit Personendaten"]
    APP["Agent-Runtime"]
    VDB[("Vektordatenbank<br/>Embeddings = Personendaten")]
    REV["Human-in-the-Loop<br/>Art. 21 Abs. 2 DSG"]
    LOG[("Audit-Log<br/>Art. 4 DSV, getrennt")]
    CRM[("Fachsystem / CRM")]
  end

  subgraph EU["Jurisdiktion EU"]
    INF["Inferenz-Endpunkt<br/>Anhang 1 DSV: angemessen"]
  end

  subgraph US["Jurisdiktion USA"]
    OBS["Monitoring-SaaS"]
    EVAL["Eval- und Tracing-Plattform"]
    ERR["Error-Tracking"]
  end

  U --> APP
  APP --> VDB
  APP --> CRM
  APP -->|"Prompt + Systemkontext"| INF
  INF --> APP
  APP --> REV
  REV --> LOG
  APP -.->|"Telemetrie"| OBS
  APP -.->|"Traces mit Prompt-Inhalt"| EVAL
  APP -.->|"Stacktrace mit Payload"| ERR

  classDef leak stroke-dasharray: 6 4;
  class OBS,EVAL,ERR leak;

Die gepunkteten Kanten sind Bekanntgaben ins Ausland, die in keinem Konzept stehen. Wer seinen Datenfluss so aufzeichnet, findet meist zwei oder drei. Welche es bei euch sind, gehen wir gemeinsam durch.

Was heisst „Hosting in der Schweiz“ technisch, und wo hört es auf?

„Hosting in der Schweiz“ beschreibt den Speicherort, nicht die Zugriffsmöglichkeit. Beides fällt auseinander, sobald der Anbieter eine Muttergesellschaft in einem Drittstaat hat, sein Support aus einer anderen Zeitzone eskaliert oder sein Control Plane anderswo läuft. Zugriff von aussen ist eine Bekanntgabe ins Ausland nach Art. 16 DSG.

Die Prüfung ist zweistufig: Steht der Empfängerstaat in Anhang 1 DSV? Falls nein, braucht es eine Garantie nach Art. 16 Abs. 2, etwa vom EDÖB anerkannte Standarddatenschutzklauseln.

Für die USA gilt eine Zwischenlage, die häufig falsch wiedergegeben wird. Seit dem 15.09.2024 gelten sie als Staat mit angemessenem Datenschutz, aber nur für Unternehmen mit Zertifizierung nach dem Swiss-U.S. Data Privacy Framework (EDÖB). Zertifiziert wird pro Unternehmen, nicht pro Land.

Daraus folgen drei technische Konsequenzen:

Egress wird erzwungen, nicht vereinbart. Eine Allowlist auf Netzwerkebene ist der einzige Nachweis, der eine Prüfung übersteht.
Der Inferenz-Endpunkt gehört hinter eine eigene Abstraktion. Wer gegen ein Anbieter-SDK programmiert, kann nicht wechseln, wenn die Zertifizierung fällt.
Jede ausgehende Verbindung braucht eine hinterlegte Jurisdiktion. Bei AIgent ist das Startbedingung: Ein Endpunkt ohne Jurisdiktionsangabe läuft nicht an.

Wie sitzt das Human-in-the-Loop-Gate im Agent-Graph?

Das Gate sitzt zwischen Entscheidung und Wirkung, nicht zwischen Modellantwort und Entscheidung. Art. 21 Abs. 2 DSG verlangt die Überprüfung durch eine natürliche Person, und überprüfbar ist ein Entscheid nur, solange er nicht vollzogen ist. Eine Freigabe nach dem Versand der Absage erfüllt die Norm nicht.

Entscheidend ist das Verhalten bei Zeitablauf: Ein Gate, das nach einem Timeout durchlässt, ist kein Gate.

package hitl

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

// Decision ist der Vorschlag des Agenten, bevor er wirksam wird.
type Decision struct {
	RunID       string
	SubjectRef  string   // Pseudonym der betroffenen Person, nie der Klarname
	Action      string   // z. B. "antrag.ablehnen"
	Rationale   string   // Begründung für die prüfende Person
	DataClasses []string // z. B. []string{"bonitaet", "beschaeftigung"}
}

// Review ist das Ergebnis der Prüfung durch eine natürliche 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: keine Freigabe innerhalb der Frist, Entscheid verworfen")
	ErrRejected = errors.New("hitl: durch prüfende Person abgelehnt")
)

// Gate hält eine automatisierte Einzelentscheidung nach Art. 21 DSG an, bis
// eine natürliche Person sie bestätigt hat. Läuft die Frist ab, gilt die
// Entscheidung als nicht getroffen. Es gibt keinen Pfad, auf dem ein Timeout
// zu einer stillen Freigabe führt.
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 {
		// Der Abbruchgrund gehört ins Log, auch wenn der Kontext bereits tot ist.
		_ = 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
}

Zwei Dinge sind bewusst gesetzt. Der Vorschlag wird protokolliert, bevor jemand ihn sieht; sonst lässt sich nicht belegen, dass eine Prüfung stattfand. Und Decision trägt ein Pseudonym statt eines Namens: Die prüfende Person löst die Identität über ihre eigene Berechtigung auf. Dieselbe Trennung, die wir in Architektur-Entscheidungen dokumentieren als Schnittstellenfrage behandeln, ist hier eine Datenschutzfrage.

Wie sieht ein Audit-Log aus, das eine Auskunftsanfrage übersteht?

Ein revDSG-taugliches Audit-Log beantwortet pro betroffener Person, welche Personendaten wann, von wem und wozu bearbeitet wurden. Art. 4 Abs. 4 DSV nennt die Pflichtfelder: Identität der bearbeitenden Person, Art, Datum und Uhrzeit, gegebenenfalls den Empfänger. Abs. 5 verlangt mindestens ein Jahr Aufbewahrung, getrennt vom System, in dem die Personendaten bearbeitet werden.

-- Eigene Datenbank, eigene Credentials, eigener Backup-Zyklus.
-- Art. 4 Abs. 5 DSV verlangt die Trennung vom bearbeitenden System.
CREATE TABLE agent_audit (
    id           bigserial PRIMARY KEY,
    occurred_at  timestamptz NOT NULL DEFAULT now(),  -- Art. 4 Abs. 4 DSV
    run_id       uuid        NOT NULL,
    actor        text        NOT NULL,  -- 'user:4711', 'agent:triage@2.3.1', 'reviewer:rp'
    operation    text        NOT NULL   -- die sechs Vorgänge aus Art. 4 Abs. 1 DSV
        CHECK (operation IN ('speichern','veraendern','lesen',
                             'bekanntgeben','loeschen','vernichten')),
    subject_ref  text        NOT NULL,  -- Pseudonym, auflösbar nur im Identitätsdienst
    data_classes text[]      NOT NULL,  -- welche Kategorien, nicht welche Inhalte
    recipient    text,                  -- 'llm:apertus@ch-inference', 'crm:abacus'
    jurisdiction char(2)     NOT NULL,  -- 'CH', 'EU', 'US'
    purpose      text        NOT NULL,  -- Art. 6 Abs. 3 DSG nachweisbar halten
    payload_sha  bytea       NOT NULL   -- Hash statt Inhalt
);

-- Auskunftsbegehren nach Art. 25 DSG in einer Abfrage beantwortbar machen.
CREATE INDEX ON agent_audit (subject_ref, occurred_at DESC);
CREATE INDEX ON agent_audit (run_id);

Die Zeile, die am häufigsten fehlt, ist payload_sha. Ein Audit-Log mit dem Prompt im Klartext ist eine zweite Kopie der Personendaten, die ein Jahr liegen bleiben muss. Der Trade-off: Der Hash belegt die Bearbeitung, aber niemand kann nachlesen, was drinstand.

Hier stossen zwei Normen aufeinander. Art. 6 Abs. 4 DSG verlangt Vernichtung, sobald die Daten nicht mehr erforderlich sind; Art. 4 Abs. 5 DSV verlangt ein Jahr Aufbewahrung des Protokolls. Das löst sich nur mit getrennten Lebenszyklen, wie im Formularservice für das BIT.

Wovon wir abraten

Vom Enterprise-Abo als Konformitätsnachweis. Ein Enterprise-Tarif regelt, ob der Anbieter eure Daten zum Training verwendet. Das ist die einzige der vier Anforderungen, die er für euch erfüllen kann. Zweckbindung, Informationspflicht, Nachvollziehbarkeit und Überprüfbarkeit nach Art. 21 entstehen in eurem System, nicht in seinem Vertrag.

Von Prompt-Inhalten in der allgemeinen Observability. Wer gen_ai.input.messages in dasselbe Trace-Backend schreibt wie seine HTTP-Spans, hat den Gesprächsinhalt in einem System, dessen Retention nach Kosten eingestellt ist. Prompts gehören ins Audit-Log, nicht in die Telemetrie.

Und der Trade-off, den wir offen benennen: Selbsthostung des Modells kostet Geschwindigkeit. Ihr betreibt GPU-Kapazität, hinkt bei Modellfähigkeiten hinterher und verlagert Aufwand von einer Rechnung in ein Team.

Ein Inferenzanbieter aus einem Staat in Anhang 1 DSV, kombiniert mit strenger Kontrolle der Peripherie, erfüllt dieselben vier Anforderungen mit weniger Betriebsaufwand. Selbsthostung ist die richtige Antwort bei besonders schützenswerten Personendaten, etwa Gesundheitsdaten, und wie das geht, steht in souveräne KI-Inferenz in der Schweiz. Für einen internen Wissensassistenten ist sie die falsche.

Wie in der KI-gestützten Entwicklung: Die Leitplanken stehen im Repository, nicht im Kopf.

Häufige Fragen

Brauche ich einen Auftragsbearbeitungsvertrag für einen KI-Anbieter?

Ja, sobald er Personendaten in eurem Auftrag bearbeitet, und das tut jeder gehostete Inferenzdienst. Art. 9 Abs. 1 DSG erlaubt die Übertragung nur, wenn die Daten so bearbeitet werden, wie ihr sie selbst bearbeiten dürftet. Regelmässig gerissen wird Abs. 3: Unteraufträge brauchen eure vorgängige Genehmigung. Prüfbar ist das über die versionierte Subprozessorenliste, nicht über den Vertragstext.

Darf ich Personendaten in ChatGPT eingeben?

Rechtlich möglich, technisch selten sauber. Nötig sind eine Rechtsgrundlage nach Art. 6 DSG, eine Auftragsbearbeitung nach Art. 9, die Information nach Art. 19 inklusive Empfängerstaat und, falls der Anbieter nicht Swiss-U.S.-DPF-zertifiziert ist, eine Garantie nach Art. 16. Fehlt eine davon, greift Art. 61 lit. a.

Reicht ein Enterprise-Abo für revDSG-Konformität?

Nein. Ein Enterprise-Abo regelt die Trainingsnutzung und meist die Datenresidenz. Es erzeugt weder das Protokoll nach Art. 4 DSV noch die Überprüfbarkeit nach Art. 21 DSG, und es sagt nichts über eure Vektordatenbank, eure Logs und euer Monitoring.

Brauchen wir eine Datenschutz-Folgenabschätzung für einen KI-Assistenten?

Wenn die Bearbeitung ein hohes Risiko für Persönlichkeit oder Grundrechte mit sich bringen kann, ja (Art. 22 Abs. 1 DSG). Abs. 2 nennt zwei Regelfälle: umfangreiche Bearbeitung besonders schützenswerter Personendaten und systematische Überwachung öffentlicher Bereiche. Bleibt trotz Massnahmen ein hohes Risiko, ist der EDÖB zu konsultieren (Art. 23).

Gilt der EU AI Act für unser Schweizer Unternehmen?

Er kann extraterritorial greifen. Art. 2 Abs. 1 lit. c der KI-Verordnung erfasst Anbieter und Betreiber aus Drittstaaten, wenn das Ergebnis des KI-Systems in der Union verwendet wird. Die Pflichten für Hochrisikosysteme nach Anhang III gelten seit der Verordnung (EU) 2026/1744 erst ab 02.12.2027, für eingebettete Systeme nach Anhang I ab 02.08.2028.

Nehmt euer Architekturdiagramm und zeichnet die Jurisdiktionsgrenzen ein. Tauchen Kanten auf, die ihr nicht erklären könnt, reden wir darüber.

30 Minuten mit einem Engineer über eure Agenten-Architektur, ohne Verkaufsgespräch: Termin buchen. Lieber schriftlich? Über Kontakt. Was wir bauen, steht unter Künstliche Intelligenz.

Alle Gesetzesangaben geprüft am 18.08.2026 an Fedlex und beim EDÖB. Dieser Beitrag ist Architekturberatung, keine Rechtsberatung.