BGFA Art. 13 und KI-Tools: Welche Anforderungen Anwaltssoftware in der Schweiz erfüllen muss

Das Anwaltsgeheimnis als technische Anforderung

BGFA Art. 13 ist eindeutig: Anwältinnen und Anwälte unterstehen zeitlich unbegrenzt und gegenüber jedermann dem Berufsgeheimnis. “Jedermann” schliesst US-Cloud-Anbieter, Tool-Hersteller und KI-Modell-Provider explizit mit ein. Wer als Anwalt eine KI-gestützte Software einsetzt, muss daher sicherstellen, dass Mandantendaten zu keinem Zeitpunkt an Stellen gelangen, die nicht selbst der Schweigepflicht unterstehen oder durch geeignete vertragliche und technische Mittel daran gebunden sind.

Diese Anforderung führt in der Praxis zu vier konkreten technischen Konsequenzen:

1. Datenresidenz und Provider-Auswahl

Mandantendaten dürfen die Schweiz und den EWR-Raum nicht ohne explizite, informierte Einwilligung des Mandanten verlassen. Das schliesst aus:

US-Cloud-Speicher als Default-Backend (z. B. AWS US-East, Google Cloud US-Central, Azure US-Regionen)
LLM-API-Calls an US-Endpoints, auch wenn die Daten “nur zur Inferenz” verarbeitet werden
Telemetrie-Pipelines in US-Logging-Dienste

Was funktioniert: EU-Region-pinned API-Calls (Anthropic mit Anthropic-Region: eu Header), Hosting bei EU-Anbietern wie Hetzner oder Infomaniak, vertraglich abgesicherte Subprozessoren mit revDSG-Art.-9-konformer Auftragsbearbeitungsvereinbarung.

2. End-to-End-Verschlüsselung mit Mandanten-Schlüsseln

Mandantendaten müssen at rest und in transit verschlüsselt sein — das ist Standard. Die nicht-triviale Anforderung ist die Schlüsselverwaltung: Wer hält die Master-Keys?

Eine Architektur, in der der Software-Anbieter die Schlüssel kennt, ist unter BGFA Art. 13 problematisch. Besser sind Modelle, in denen:

Lokale Schlüssel auf dem Anwalts-Device (iOS Keychain mit FaceID-Gate, WHEN_UNLOCKED_THIS_DEVICE_ONLY) liegen
Shamir-Secret-Sharing für Master-Recovery (z. B. 5-of-3-Splits in einem Vault wie OpenBao oder HashiCorp Vault)
AAD-Binding sicherstellt, dass Daten ausserhalb des Mandanten-Kontexts nicht entschlüsselbar sind, auch wenn ein Schlüssel kompromittiert wird

3. PII-Redaction vor jedem externen Call

Selbst mit EU-Region-Routing bleibt jeder externe LLM-Call ein Datentransfer an einen Auftragsbearbeiter im Sinne von revDSG Art. 9. Die Auftragsbearbeitungsvereinbarung deckt diesen Transfer ab — aber gute Praxis geht weiter und entfernt PII (Personally Identifiable Information) vor dem Versand.

Für den Schweizer Kontext heissen die kritischen Kategorien:

AHV-Nummer (756-Format)
IBAN (CH/LI mit Prüfsummen-Validation)
Schweizer Mobilnummer / Festnetz
Geburtsdaten
Strassen-/Postleitzahl-Kombinationen
Namen von Mandanten und Drittpersonen

Eine robuste PII-Redaction-Pipeline ersetzt diese Patterns vor dem Prompt-Build durch typisierte Platzhalter (<AHV_1>, <NAME_2>, <IBAN_3>), so dass das LLM den semantischen Kontext versteht, ohne die Identitäten zu kennen.

4. Audit-Trail mit Hash-Chain

Im Streitfall — sei es eine standesrechtliche Beschwerde, ein Disziplinarverfahren oder ein Schadenersatzprozess — muss nachweisbar sein, wer wann was mit den Mandantendaten gemacht hat. Eine fortlaufende, kryptographisch verkettete Hash-Chain pro Mandant ist heute das Mittel der Wahl:

Jeder Audit-Eintrag wird mit SHA-256 gehashed
Der Hash des Vorgängers wird in den nächsten Eintrag eingefügt
Eine Manipulation an einer Stelle macht die gesamte Kette ab dort invalid

Diese Architektur erlaubt eine forensisch beweissichere Protokollierung, ohne dass ein Drittanbieter den Inhalt der Einträge kennen muss.

Bonus: EU AI Act und Schweizer Anwälte

Ab August 2026 greift der EU AI Act in vollem Umfang. KI-Systeme, die “die Rechtspflege und demokratische Prozesse” unterstützen (Anhang III Ziff. 8), sind Hochrisiko-KI-Systeme. Schweizer Anwaltssoftware fällt unter den AI Act, sobald sie:

Auf dem EU-Markt angeboten wird (z. B. Beta-Slots an deutsche oder österreichische Kanzleien)
Outputs erzeugt, die in EU-Mitgliedstaaten verwendet werden

Für Schweizer Anbieter heisst das konkret: Risk-Management-System, Datenqualitäts-Anforderungen, Logging, technische Dokumentation, menschliche Aufsicht und Cybersicherheit sind nachzuweisen — und zwar bevor das Produkt einer EU-Kanzlei zur Verfügung gestellt wird.

Checkliste: BGFA-Compliance für KI-Tools

Bei der Evaluation einer KI-gestützten Anwaltssoftware sollten Sie folgende Fragen stellen können:

Wo liegen die Mandantendaten — physisch und vertraglich?
Wer hat Zugriff auf die unverschlüsselten Daten? (Antwort soll “niemand ausserhalb des Anwalts-Devices” sein)
Welche externen Subprozessoren werden eingebunden? Existiert eine AVV nach revDSG Art. 9?
Wird PII vor externen Calls automatisch redacted?
Existiert ein revDSG-Art.-22-konformer DSFA-Bericht?
Wie ist die Audit-Log-Integrität nachweisbar?
Wie lassen sich Mandantendaten vollständig löschen (Recht auf Vergessenwerden, revDSG Art. 32)?
Falls EU-Markt: Existiert eine AI-Act-Konformitätserklärung?

Wie Court Companion diese Anforderungen umsetzt

Court Companion wurde von der ersten Code-Zeile an um diese Anforderungen herum entworfen:

EU-Hosting ausschliesslich (Hetzner Nürnberg), kein US-Subprocessor in der kritischen Pipeline
Lokale Schlüssel in iOS Keychain, Master-Vault mit Shamir 5-of-3
PII-Redaction für 6 Schweizer Kategorien vor jedem LLM-Call
SHA-256-Hash-Chain pro Mandanten-Audit-Log, CLI-verifizierbar
revDSG-Art.-22-DSFA-Initial-Version vom 25.05.2026, jährlicher Refresh-Zyklus
AI-Act-Konformitäts-Pfad für EU-Marketing in Vorbereitung (Phase 2)

Wer eine vergleichbare Anwaltssoftware evaluiert, sollte die acht Fragen oben verbindlich beantworten lassen — schriftlich, am besten als Teil der Auftragsbearbeitungsvereinbarung.

Weiterführend

BGFA Art. 13 — Berufsgeheimnis
revDSG (ganzes Gesetz) — Schweizer Datenschutzgesetz, in Kraft seit 1.9.2023
EU AI Act — Verordnung (EU) 2024/1689
SAV-Wegleitung KI in der Anwaltschaft — externe Empfehlung des Schweizerischen Anwaltsverbandes

Letzte Aktualisierung: 26. Mai 2026. Dieser Artikel ersetzt keine juristische Beratung im Einzelfall.