Die sieben Säulen einer DSG-konformen AI-Architektur
Säule 1: Datenminimierung — nur die Personendaten verarbeiten, die für den deklarierten Zweck notwendig sind. Säule 2: Verarbeitungs-Region — wo werden Daten verarbeitet, wo gespeichert, wer hat Zugriff? Säule 3: Audit-Trail — jede Verarbeitung und Entscheidung ist nachvollziehbar protokolliert. Säule 4: Zugriffskontrolle — wer in Ihrem Team darf welche KI-Funktion benutzen, RBAC-System. Säule 5: Verschlüsselung — Transit (TLS 1.3) und at-rest (AES-256). Säule 6: Aufbewahrung — definierte Löschfristen pro Datenkategorie. Säule 7: Human-Override — bei wesentlichen Entscheidungen muss eine Person eingreifen können. Diese sieben gelten zusammen — eine fehlende Säule reisst die Architektur ein.
Pattern 1: Edge-Gateway
Das Edge-Gateway-Pattern setzt einen Vor-Filter zwischen Ihre Anwendung und den Modell-Anbieter. Beim Eingang werden Personendaten erkannt (PII-Detection), pseudonymisiert oder anonymisiert, dann an das Modell weitergegeben. Beim Ausgang werden die Pseudonyme wieder durch echte Werte ersetzt — falls notwendig. Beispiel: Eine Mail mit Mandanten-Namen kommt rein, der Name wird durch [KUNDE_001] ersetzt, Claude bearbeitet die Mail, das Ergebnis kommt zurück mit Tag [KUNDE_001], wird beim Versand wieder rückübersetzt. Vorteil: das Modell sieht keine echten Personendaten. Nachteil: Komplexität, Risiko von Re-Identifikation in Sonderfällen.
Pattern 2: CH-Strict
Beim CH-Strict-Pattern fliessen alle Personendaten ausschliesslich über Schweizer Anbieter. Apertus 70B via Swisscom, Hosting bei einem Schweizer Cloud-Provider (Exoscale, Infomaniak, Swiss Backup), keine US-Anbieter im Pfad. Geeignet für: FINMA-regulierte Daten, BGFA-Mandanten-Daten, Gesundheitsdaten in spezifischen Settings, politisch sensitive Anwendungen. Vorteile: maximale Souveränität, vereinfachte Dokumentation. Nachteile: oft Kapazitäts-Limits, weniger Modell-Auswahl, höhere Kosten als US-Anbieter. Für viele KMU-Anwendungen unnötig streng — aber für bestimmte Branchen-Strecken die einzig vertretbare Option.
Pattern 3: Hybrid-Routing
Hybrid-Routing kombiniert die Stärken: ein Klassifikator prüft eingehende Anfragen auf Sensitivität, sensitive Strecken laufen über CH-Strict, nicht-sensitive über das stärkere US-Modell. Konkret: eine Mail kommt rein, ein leichter Klassifikator (Apertus 8B lokal) entscheidet 'enthält PII/sensitive Daten ja/nein'. Nein-Pfad: Claude Opus 4.7 mit DPF-konformer Verarbeitung. Ja-Pfad: Apertus 70B via Swisscom mit voll konformer Verarbeitung. Vorteil: Kosten-Effizienz und Qualität wo möglich, Strenge wo nötig. Nachteil: zwei Pfade pflegen, Klassifikator muss verlässlich sein.
Audit-Trail in der Praxis
Ein robuster Audit-Trail enthält pro KI-Verarbeitung: Zeitstempel, User-ID (wer hat angefragt), Input-Hash (was wurde verarbeitet, ohne dass Personendaten roh gespeichert sind), gewähltes Modell, Tool-Calls (welche Aktionen wurden ausgelöst), Output-Snippet (Zusammenfassung des Ergebnisses), Eskalationen, Bearbeitungs-Dauer, Cost. Speicherung: Postgres-Tabelle mit klarer Retention-Policy (typisch 18 Monate, dann gelöscht; bei FINMA-Daten 10 Jahre, gemäss Vorgabe). Für Branchen mit strikter Aufsicht (FINMA, BGFA) ist der Audit-Trail nicht nice-to-have sondern Pflicht-Bestandteil — und sollte als Erstes gebaut werden, nicht zuletzt.
Zugriffskontrolle und Rollen
RBAC (Role-Based Access Control) ist 2026 Standard. Typische Rollen in einer KMU-KI-Anwendung: User (kann Anfragen stellen, sieht eigene Historie), Reviewer (sieht Eskalationen, kann freigeben), Admin (Konfiguration, Logs, Cost), Auditor (read-only auf Audit-Trail, keine Verarbeitung). Wichtig: Service-Accounts (Maschine-zu-Maschine-Calls) bekommen eigene Tokens mit eingeschränkten Scopes, niemals User-Tokens für System-Calls verwenden. Two-Factor-Authentication für Admin-Rollen ist non-negotiable. Im Audit-Log ist klar nachvollziehbar, welche Rolle welche Aktion ausgelöst hat.
Aufbewahrungs- und Löschstrategie
Eine durchdachte Retention-Policy unterscheidet drei Datentypen. (1) Verarbeitungs-Inputs (Mails, PDFs, Texte): typisch 30–90 Tage, danach gelöscht — ausser regulatorische Aufbewahrungspflicht greift (z.B. 10 Jahre bei steuerrelevanten Belegen nach OR 958f). (2) Modell-Outputs und Bearbeitungs-Resultate: oft länger als Inputs, weil sie Teil der operativen Daten sind. Hier folgt die Frist der Geschäftslogik. (3) Audit-Logs: 12–24 Monate Standard, bis 10 Jahre bei regulatorischen Anforderungen. Wichtig: automatische Löschung implementieren, nicht manuell. Ein Cron-Job, der täglich abgelaufene Datensätze entfernt — und das Löschen selbst ins Audit-Log einträgt.
TOM — die zehn häufigsten technischen Massnahmen
Technische und organisatorische Massnahmen, die wir in TYTOS-Projekten standardmässig umsetzen. (1) TLS 1.3 für alle Verbindungen. (2) AES-256-Verschlüsselung at-rest. (3) Sealed-Secrets-Management (Vault, AWS Secrets Manager, kein .env in Git). (4) Schlüssel-Rotation alle 90 Tage. (5) Network-Isolation (private VPCs, keine öffentlichen DB-Endpoints). (6) Rate-Limiting auf API-Endpoints. (7) Anomalie-Erkennung im Audit-Log (ungewöhnliche Volumen, ungewöhnliche Zeiten). (8) Regelmässige Dependency-Scans (Snyk, Dependabot). (9) Backup-Strategie mit verschlüsselter Off-Site-Kopie. (10) Incident-Response-Plan dokumentiert. Diese zehn sind Mindeststandard, nicht Premium.