Warum Schweizer Banken bei KI nicht «ja oder nein» entscheiden sollten, und was kleinere Unternehmen daraus lernen können.
In vielen Schweizer Banken läuft im Moment dasselbe Gespräch. Jemand möchte ChatGPT oder Claude auf den SharePoint loslassen: Verträge zusammenfassen, Dossiers durchsuchen, Sitzungsprotokolle erstellen. Und aus der Compliance kommt ein reflexartiges Nein. Für die einen ist das Fortschrittsverweigerung, für die anderen schlicht gesunder Menschenverstand. Beide Lager liegen daneben. Weil sie über die falsche Frage streiten.
Die Skepsis ist rational, nur nicht aus dem Grund, den alle vermuten
Der verbreitete Widerstand gegen einen direkten Zugriff externer KI-Dienste auf interne Daten ist nicht Technikangst. Er ist regulatorisch gut erklärbar. Der Punkt ist allerdings nicht, dass SharePoint oder Microsoft 365 «risikolos» wären. Der Punkt ist, dass diese Plattformen in den meisten Häusern längst als etabliertes System of Record laufen, mit ausgebauten Rollenmodellen, Data Loss Prevention, Audit-Trails, Datenresidenz-Optionen und über Jahre verhandelten Vertragswerken.
Ein zusätzlicher KI-Anbieter schafft demgegenüber eine neue Verarbeiter-, Transfer- und Protokollierungskette, die separat beherrscht werden muss – rechtlich, technisch und organisatorisch. SharePoint ist primär eine Ablage- und Kollaborationsschicht. Ein Sprachmodell ist eine Inferenz- und Transformationsschicht: Es speichert oder indexiert Inhalte nicht nur, sondern verarbeitet sie über Prompts, Retrieval, Tool-Aufrufe und Safety-Prüfungen aktiv. Genau dort entstehen die zusätzlichen Pfade, die ein Finanzinstitut nervös machen.
«Kein Training» heisst nicht «keine Speicherung»
Das häufigste Missverständnis in diesen Diskussionen lautet: «Das Modell lernt mit unseren Daten.» Für die geschäftlichen Produkte ist das so pauschal falsch. Bei OpenAI werden in ChatGPT Business, Enterprise und über die API standardmässig keine Kundendaten zum Training genutzt; bei Anthropic gilt dasselbe für die kommerziellen Produkte und die API. Wer hier mit der Consumer-Variante argumentiert, vergleicht das Falsche – und kommt zu falschen Entscheidungen.
Die eigentliche Risikofläche liegt subtiler. Auch ohne Trainingsnutzung können Prompts, Outputs und abgeleitete Metadaten in Missbrauchs-, Audit- oder Qualitätslogs landen; API-seitig sind solche Logs typischerweise bis zu 30 Tage vorgesehen. Einzelne API-Funktionen halten Anwendungszustand bis zur Löschung. In RAG-Szenarien wird Prompt-Injection zum Thema, sobald manipulierte Dokumente oder E-Mails ins Spiel kommen. Dazu kommen Insiderzugriffe bei Support- und Safety-Vorfällen sowie zusätzliche Drittlandtransfers. «Kein Training» ist beruhigend, aber es ist eben nicht «keine Speicherung», und schon gar nicht «keine Jurisdiktion».
Für Banken ist es nicht nur Datenschutz
Die FINMA schaut nicht primär durch eine «KI-Brille», sondern durch die Brille von Auslagerung, operationeller Resilienz und kritischen Daten. Das Rundschreiben 2018/3 verlangt ein laufend aktuelles Inventar ausgelagerter Funktionen samt Subunternehmern, Weisungs-, Kontroll- und Auditrechte und die Durchsetzbarkeit dieser Rechte auch im Ausland. Das Rundschreiben 2023/1 verlangt, kritische Daten systematisch zu identifizieren, nach Kritikalität zu kategorisieren und den Zugriff nach Need-to-Know zu steuern. Parallel verlangen das revidierte DSG und die DSGVO Auftragsbearbeitung, ein risikoangemessenes Sicherheitsniveau, bei hohem Risiko eine Datenschutz-Folgenabschätzung und belastbare Transfermechanismen.
Entscheidend ist die Erkenntnis, dass kritische Daten weit mehr umfassen als «Kundendaten». Dazu zählen auch KYC-Merkmale, Zahlungsinstruktionen, interne Risikoberichte, Compliance-Fallakten, Kreditanalysen und Prüfungsdokumentation. Und bei börsennahen Häusern kommt eine eigene Dimension dazu: Sobald unveröffentlichte Zahlen, Entwürfe für Ad-hoc-Mitteilungen oder M&A-Szenarien in ein externes Inferenzsystem fliessen, geht es nicht mehr nur um Datenschutz, sondern um Insiderinformation, Marktmissbrauch und Governance, also um FinfraG und die Ad-hoc-Publizität der SIX. Wer das übersieht, unterschätzt das Research-Umfeld am stärksten, weil dort öffentliche und hochsensible Inhalte im selben Werkzeug zusammenlaufen.
Die richtige Frage ist abgestuft, nicht binär
Der Prüfstein ist deshalb nicht «Microsoft gegen OpenAI oder Anthropic». Die relevante Frage lautet: Welcher zusätzliche Verarbeitungspfad wird konkret eröffnet, mit welcher Persistenz und in welcher Jurisdiktion? Daraus ergibt sich eine natürliche Rangfolge der Sensitivität: öffentliche Inhalte, dann interne, aber nicht personen- oder marktmissbrauchsrelevante Inhalte, dann personenbezogene Kundendaten, dann Bankkundengeheimnis, KYC und Compliance-Dossiers, schliesslich insider-nahe oder ad-hoc-relevante Information.
Je weiter rechts ein Datentyp in dieser Reihe liegt, desto stärker verschiebt sich die sachgerechte Zielarchitektur: weg von «Enterprise-SaaS mit guter Konfiguration», hin zu privater, regionalisierter, schweiznaher oder on-prem kontrollierter KI. Für generische FAQ ist ein eng konfigurierter Enterprise-Dienst meist vertretbar. Für rohe KYC-Dossiers oder Board-Materials ist ein direkter Zugriff eines externen Modells regulatorisch und reputativ kaum zu rechtfertigen.
Der Grundsatz heisst «no direct broad access»
In der Praxis folgt daraus ein einziger, robuster Leitsatz: Kein externer KI-Dienst erhält je pauschalen Vollzugriff auf SharePoint oder M365. Zugriff sollte use-case-bezogen, rollenbasiert und dokumentbezogen sein, idealerweise vermittelt über einen bankseitigen Layer. Der Unterschied ist derselbe wie zwischen einem Generalschlüssel und einem zeitlich begrenzten, protokollierten Zutritt zu einem einzelnen Raum. Beides ist «Zugang», nur eines ist beherrschbar.
Mittelfristig läuft das auf eine Art Control Plane für KI hinaus: ein zentrales Gateway oder einen LLM-Proxy, über den alle produktiven Aufrufe laufen und an dem Prompt- und File-Policies, Redaction, DLP-Vorprüfung, Modell-Allowlisting und Protokollierung technisch erzwungen werden. Für RAG gilt das Prinzip der minimalen Retrieval-Menge statt globaler Suchzugriffe. Und für die wirklich heiklen Zonen – KYC, Compliance, interne Untersuchungen, Emissionsvorbereitung – gehört ein schweiz-gehosteter oder on-prem betriebener Stack ernsthaft geprüft.
Die eigentliche Lektion gilt weit über die Banken hinaus
Das Bankenbeispiel ist der Extremfall, und genau das macht es nützlich. Denn der Denkfehler, den es offenlegt, ist universell. Die Entscheidung lautet nie «KI ja oder nein». Sie lautet: Welche Daten, in welcher Architektur, mit welchen Verträgen, in welcher Jurisdiktion und mit welchen Kontrollen?
Auch ein Zwanzig-Personen-Betrieb hat Inhalte, die nichts in einem Consumer-Chatbot verloren haben, und Inhalte, bei denen genau das völlig unproblematisch ist. Die Arbeit besteht darin, diese Linie bewusst und einmal sauber zu ziehen und sie dann durchzusetzen. Das ist anstrengender als ein reflexartiges Ja und mutiger als ein reflexartiges Nein. Aber es ist die einzige Antwort, die in zwei Jahren noch trägt.
