SystemebeneAI ENGINEERING · SOFTWARE SYSTEMS · INFRASTRUCTURE

KI-Compliance im Schweizer Banking: Was die FINMA erwartet, woran es hakt und was technisch hilft

Die Schweiz hat kein KI-Gesetz, aber verbindliche Erwartungen an Governance und Risikomanagement. Was die Aufsichtsmitteilung 08/2024 verlangt und welche technischen Muster tragen.

23 Min. Lesezeit

Die Schweiz hat kein KI-Gesetz. Das ist der erste Satz, den man in jeder Präsentation zum Thema hört, und er ist richtig. Er wird nur meistens so verwendet, als folge daraus, dass es auch keine Anforderungen gäbe. Das Gegenteil ist der Fall: Weil es keine KI-spezifische Norm gibt, greifen die bestehenden, prinzipienbasierten Anforderungen an Governance, Risikomanagement und Auslagerung unverändert weiter, nur muss man selbst herleiten, was sie für ein RAG-System oder einen Agenten bedeuten. Diese Herleitung ist die eigentliche Arbeit, und sie ist zu einem grossen Teil Engineering-Arbeit, nicht Rechtsarbeit.

Die FINMA hat das in der Aufsichtsmitteilung 08/2024 explizit gemacht: „Bislang existiert in der Schweiz keine KI-spezifische Gesetzgebung. Im Finanzmarktrecht erfassen die technologieneutralen, prinzipienbasierten aufsichtsrechtlichen Anforderungen an eine wirksame Governance und ein wirksames Risikomanagement die Risiken aus dem Einsatz von KI.” (FINMA AM 08/2024) Der Leitsatz dazu lautet: Same business, same risks, same rules. (FINMA)

Im Folgenden geht es darum, was tatsächlich gilt, woran die Umsetzung scheitert und welche technischen Muster tragen. Zum Schluss steht der Stand bei einzelnen Banken, soweit er öffentlich belegt ist.

Was tatsächlich gilt

Die Aufsichtsmitteilung 08/2024 als Referenzdokument

Die AM 08/2024 vom 18. Dezember 2024 ist kein Rundschreiben und damit formal nicht verbindlich. Praktisch ist sie das wichtigste Dokument, weil sie beschreibt, was die FINMA in Aufsichtsgesprächen und Vor-Ort-Kontrollen tatsächlich geprüft hat. Sie gliedert sich in sieben Bereiche: Governance, Inventar und Risikoklassifizierung, Datenqualität, Tests und laufende Überwachung, Dokumentation, Erklärbarkeit sowie unabhängige Überprüfung. (FINMA AM 08/2024)

Der für die Praxis wertvollste Teil steht in einer Fussnote. Die FINMA listet dort Faktoren auf, die die Wesentlichkeit einer Anwendung beeinflussen: Bedeutung für die Einhaltung der Finanzmarktgesetzgebung, finanzielle Auswirkungen, Rechts- und Reputationsrisiken, Relevanz des Produkts, Anzahl und Typ betroffener Kunden, Konsequenzen bei Fehlern oder Ausfall. Und separat Faktoren für die Eintrittswahrscheinlichkeit: Komplexität, Art und Menge der verwendeten Daten, ungeeignete Entwicklungs- oder Überwachungsprozesse, Grad der Autonomie und Prozesseinbindung, Dynamik, Vernetzung mehrerer Modelle, Potenzial für Angriffe oder Ausfälle. (FINMA AM 08/2024)

Das ist im Grunde eine fertige Klassifizierungsmatrix. Wer ein Modellinventar aufbaut, kann diese beiden Achsen direkt als Schema übernehmen, statt eine eigene Taxonomie zu erfinden, die dann in der Prüfung erklärt werden muss.

Bemerkenswert ist auch die Definitionsfrage. Die FINMA verlangt ausdrücklich eine breite Definition von KI und verweist auf den OECD-Ansatz, weil „auch klassische Anwendungen ähnliche Risiken aufweisen können und gleiche Risiken gleich zu adressieren sind”. Sie hat beobachtet, dass Institute KI teilweise eng definierten, „um sich auf vermeintlich grössere oder neue Risiken zu fokussieren”. (FINMA AM 08/2024) Wer also sein Inventar auf LLM-Anwendungen beschränkt und das seit Jahren laufende Scoring-Modell im Kreditprozess aussen vor lässt, hat die Erwartung verfehlt, und zwar in die Richtung, die aufsichtsrechtlich unangenehmer ist.

Was seitdem dazugekommen ist

Im April 2025 veröffentlichte die FINMA die Ergebnisse einer Umfrage bei rund 400 bewilligten Instituten, durchgeführt von Ende November 2024 bis Mitte Januar 2025. Rund 50 Prozent setzen KI ein oder haben erste Anwendungen in Entwicklung, weitere 25 Prozent planen den Einsatz in den nächsten drei Jahren. Im Schnitt sind fünf Anwendungen im Einsatz und neun in Entwicklung. 91 Prozent derjenigen, die KI einsetzen, nutzen auch generative KI. Nur etwa die Hälfte hat eine explizite KI-Strategie. Von den 187 Bewilligten mit KI im Einsatz waren 100 Banken und Wertpapierhäuser. (FINMA-Umfrage)

Die praktisch wichtigste Aussage der Medienmitteilung steht ganz am Schluss: Die FINMA empfiehlt, „frühzeitig den Kontakt mit der FINMA aufzunehmen, falls KI bei kritischen Prozessen oder der Berechnung regulatorisch vorgegebener Grössen eingesetzt werden soll”. (FINMA-Umfrage) Das ist die Schwelle, ab der ein Projekt aufhört, eine interne Angelegenheit zu sein.

Interessant ist, was im Risikomonitor 2025 vom 17. November 2025 nicht steht. Die FINMA identifiziert neun als hoch eingestufte Hauptrisiken: Immobilien und Hypotheken, übrige Kredite, Credit-Spread, Liquidität und Refinanzierung, Geldwäschereibekämpfung, Sanktionen, Outsourcing, Cyberangriffe, IKT-Risiken. KI ist keines davon. (FINMA Risikomonitor 2025) Das ist konsequent technologieneutral gedacht: KI-Risiken materialisieren sich in den bestehenden Kategorien, vor allem in Outsourcing und IKT. Für die Aufsichtspraxis heisst das, dass eine KI-Anwendung nicht in einem Sonderregime geprüft wird, sondern im normalen operationellen Risikorahmen, inklusive der Erwartung, dass Systeme auch bei Ausfall einzelner Komponenten weiterlaufen.

Im April 2026 kam die Aufsichtsmitteilung 02/2026 „Digitale Betrugsrisiken bei Banken und Personen nach Art. 1b BankG” dazu, gestützt auf eine Umfrage bei 19 Banken verschiedener Aufsichtskategorien Ende 2025. Sie ist für dieses Thema aus zwei Gründen relevant. Erstens verweist die FINMA explizit auf den Trend zu KI-Werkzeugen und zur Automatisierung der Kontoadministration und Zahlungsabwicklung und verlangt einen angemessenen Rahmen unter anderem nach FINMA-RS 2023/1 zu operationellen Risiken und Resilienz. Zweitens erwartet sie den Einsatz technischer Mittel zur Erkennung von Deepfakes und manipulierten Videos. Die FINMA stellte ausserdem fest, dass Schwellenwerte für auffällige Transaktionen bei Privatkunden mit tiefem oder normalem Risiko häufig bei 100’000 bis 200’000 Franken liegen, also starre Schwellen statt analytischer Szenarien. (CMS zu FINMA Guidance 02/2026, FINMA)

Damit steht KI auf beiden Seiten derselben Aufsichtsmitteilung: als Werkzeug der Angreifer und als erwartetes Gegenmittel.

Der Rahmen ausserhalb der FINMA

Vier weitere Stränge sind relevant, und keiner davon ist neu:

Bankkundengeheimnis. Art. 47 BankG verbietet die Bearbeitung von Bankkundendaten im Ausland nicht per se. Die Bankiervereinigung hat das in ihrem Cloud-Leitfaden auf Basis eines Rechtsgutachtens ausformuliert: Entscheidend ist, dass das Institut das Zugriffsrisiko durch technische, organisatorische und vertragliche Massnahmen angemessen begrenzt. Wenn pseudonymisiert wird, soll die Zuordnungsregel unter Kontrolle der Bank in der Schweiz bleiben. (SBVg Cloud-Leitfaden, LAUX Rechtsgutachten) Für LLM-Architekturen heisst das: Der Ort, an dem De-Pseudonymisierung stattfindet, ist ein Compliance-Artefakt und keine Implementierungsdetailfrage.

Outsourcing. FINMA-RS 2018/3 greift, sobald ein Dienstleister eine wesentliche Funktion übernimmt. Bei Machine-Learning-Diensten mit Zugriff auf eine bedeutende Menge Kundendaten ist die Anwendbarkeit zu prüfen. (SBVg Cloud-Leitfaden) Die AM 08/2024 ergänzt, dass bei Outsourcing zusätzliche Tests, Kontrollen und Vertragsklauseln zu Verantwortlichkeiten und Haftung erwartet werden und dass die Fähigkeiten des Dienstleisters zu prüfen sind. (FINMA AM 08/2024)

Datenschutz. Art. 21 DSG gibt Betroffenen bei ausschliesslich automatisierten Einzelentscheiden mit Rechtsfolge oder erheblicher Beeinträchtigung ein Recht auf Stellungnahme und auf Überprüfung durch eine natürliche Person. Das ist die harte Grenze für vollautomatisierte Kreditentscheide. Ein Human-in-the-Loop, der nur formal abnickt, löst das Problem nicht. Die Prüfung muss substanziell sein.

EU AI Act. Die Verordnung wirkt extraterritorial: Sie greift, wenn ein KI-System in der EU in Verkehr gebracht oder betrieben wird oder wenn der Output in der EU verwendet wird. Eine Schweizer Bank mit EU-Kunden ist für diese Tätigkeiten im Anwendungsbereich. Kreditwürdigkeitsprüfung ist eine Hochrisiko-Kategorie nach Anhang III. Mit der Digital-Omnibus-Einigung vom Mai 2026 wurden die Fristen für Hochrisiko-Systeme allerdings deutlich verschoben: Anhang III auf den 2. Dezember 2027, Anhang I auf den 2. August 2028. (Zusammenfassungen der Omnibus-Einigung) Diese Verschiebung stützt sich auf Sekundärquellen; wer darauf plant, sollte den finalen Verordnungstext prüfen.

Was noch kommt. Der Bundesrat hat im Februar 2025 entschieden, die KI-Konvention des Europarats zu ratifizieren und dafür bestehendes Recht anzupassen statt ein EU-artiges KI-Gesetz zu schaffen. Das EJPD erarbeitet bis Ende 2026 eine Vernehmlassungsvorlage. Parallel analysiert das SIF sämtliche Finanzmarktregulierungen auf Lücken und Hürden für KI-Anwendungen; die Publikation war für das zweite Quartal 2026 angekündigt. Die FINMA betreibt seit 2022 einen dedizierten „AI Desk”. (SIF)

Wer heute eine KI-Architektur baut, baut also in einen Rahmen hinein, der in den nächsten zwei Jahren konkreter wird, aber in seiner Grundlogik feststeht: technologieneutral, proportional, risikobasiert.

Woran es in der Praxis hakt

Die FINMA benennt die Schwachstellen in der AM 08/2024 ungewöhnlich direkt. Vier davon halte ich für die substanziellen.

Der Fokus liegt auf Datenschutz, nicht auf Modellrisiko. Die FINMA beobachtete, dass sich Beaufsichtigte „in erster Linie auf Datenschutzrisiken, weniger aber auf Modellrisiken wie mangelnde Robustheit und Korrektheit, Bias, mangelnde Stabilität und Erklärbarkeit fokussieren”. (FINMA AM 08/2024) Das deckt sich mit dem EY Bankenbarometer 2026: Bei den Herausforderungen im Kunden- und Anlagebereich nennen 63 Prozent Datenschutz und Sicherheit, 48 Prozent Zweifel an Korrektheit und Genauigkeit. (EY Bankenbarometer 2026 via Netzwoche)

Das ist nachvollziehbar, weil Datenschutz eine etablierte Abteilung mit etablierten Prozessen hat. Modellrisiko hat das in vielen Instituten nicht, jedenfalls nicht ausserhalb des Marktrisikobereichs, wo Modellvalidierung seit Jahrzehnten Standard ist. Der Reflex, ein LLM-Projekt beim Datenschutzbeauftragten abzugeben und damit für erledigt zu halten, adressiert genau die Risiken nicht, die die FINMA an erster Stelle nennt.

Die Vollständigkeit des Inventars ist das eigentliche Problem. Die FINMA hält fest, dass Vollständigkeit eine Herausforderung darstellt, „da häufig KI-Entwicklung und -Anwendung im Unternehmen breit gestreut und seit dem Aufkommen generativer KI Anwendungen für jedermann zugänglich sind”. Bei eingekauften Anwendungen hatten Institute „teilweise Schwierigkeiten zu eruieren, ob KI enthalten ist”. (FINMA AM 08/2024)

Das ist die unangenehmste Feststellung im ganzen Dokument, weil sie sich nicht durch eine Richtlinie lösen lässt. Ein Inventar, das auf freiwilliger Selbstdeklaration beruht, ist in einer Organisation mit dezentraler Entwicklung strukturell unvollständig. Und die zweite Hälfte, KI in eingekauften Produkten, ist noch schwieriger, weil jeder SaaS-Anbieter inzwischen irgendwo ein Modell eingebaut hat, oft ohne das im Vertrag sauber auszuweisen.

Datenqualität schlägt Modellwahl. Die FINMA formuliert das explizit: „Die Datenqualität ist daher häufig wichtiger als die Auswahl des konkreten Modells.” (FINMA AM 08/2024) Eine Studie von Dun & Bradstreet unter Fach- und Führungskräften in fünf Märkten kommt zum Ergebnis, dass 61 Prozent der KI-Projekte bei Banken an einer mangelhaften Datenbasis scheitern; 56 Prozent der Banken vertrauen ihren eigenen Daten nur eingeschränkt, und nur 35 Prozent geben an, auf Basis der eigenen Datenbasis entscheiden zu können. (Dun & Bradstreet via Netzwoche)

Man sollte diese Zahlen mit der üblichen Vorsicht gegenüber Anbieterstudien lesen: Dun & Bradstreet verkauft Datenqualität. Die Richtung deckt sich aber mit dem, was die FINMA aus der Aufsicht berichtet, und mit dem, was man in jedem Datenprojekt sieht.

Unabhängige Überprüfung existiert kaum. Die FINMA beobachtete „nicht in allen Fällen eine klare Abgrenzung zwischen der Entwicklung von KI-Anwendungen und der unabhängigen Überprüfung” und dass „nur wenige Beaufsichtigte eine unabhängige Prüfung des gesamten Modellentwicklungsprozesses durch dafür qualifiziertes Personal durchführen”. (FINMA AM 08/2024)

Das ist der Punkt, an dem KI-Governance an den Fachkräftemangel stösst. Eine unabhängige Prüfung eines RAG-Systems verlangt jemanden, der Retrieval-Qualität, Prompt-Injection und Evaluationsdesign beurteilen kann, und der nicht derselbe ist, der das System gebaut hat. In einer Bank mit zwanzig Leuten in der IT gibt es diese Person nicht zweimal.

Dazu kommt ein Befund, den ich für unterschätzt halte: Das EY Bankenbarometer 2026 zeigt, dass der KI-Einsatz im Risikomanagement von 27 Prozent im Vorjahr auf 8 Prozent gefallen ist. EY erklärt das mit Herausforderungen bei Datenqualität und -verfügbarkeit, regulatorischen Anforderungen und geringer Fehlertoleranz. (EY Bankenbarometer 2026 via Netzwoche) Banken ziehen sich also aus genau dem Bereich zurück, in dem KI aufsichtsrechtlich am heikelsten wäre, und konzentrieren sich auf Prozessautomatisierung, die 80 Prozent nennen. Das ist rational, verschiebt das Problem aber nur.

Was technisch hilft

Die folgenden Muster leiten sich direkt aus den Erwartungen der AM 08/2024 ab. Sie sind keine Bankenlösung von der Stange, sondern Bausteine, die man in unterschiedlicher Tiefe kombinieren kann.

Das Inventar erzwingen statt erfragen

Ein Inventar, das nur aus einer Excel-Liste besteht, veraltet ab dem Tag der Erstellung. Der belastbarere Ansatz ist, den Zugang zu Modellen technisch zu bündeln und die Inventarisierung zur Voraussetzung für den Zugang zu machen.

Konkret: Alle Modellaufrufe laufen über ein internes Gateway. Direkter Egress zu Modellanbietern wird auf Netzwerkebene blockiert. Das Gateway akzeptiert nur Requests mit einem gültigen Anwendungs-Token, das an einen Inventareintrag gebunden ist. Wer keinen Eintrag hat, bekommt keinen Zugriff. Damit ist die Vollständigkeit für selbst gebaute Anwendungen keine Frage der Disziplin mehr, sondern eine Eigenschaft der Infrastruktur.

Der Inventareintrag lässt sich als versioniertes Artefakt im Repository führen, mit den Klassifizierungsachsen aus der AM 08/2024:

# inventory/apps/kb-assistant.yaml
id: kb-assistant
owner: retail-ops
purpose: >
  Beantwortung interner Fragen zu Weisungen und Reglementen.
  Kein Kundenkontakt, keine Entscheidungsunterstützung im Kreditprozess.

wesentlichkeit:
  finanzmarktrechtlich_relevant: false
  betroffene_kunden: 0
  konsequenz_bei_fehler: mittel   # falsche Weisungsauskunft an Mitarbeitende
  reputationsrisiko: niedrig

eintrittswahrscheinlichkeit:
  autonomiegrad: assistiv          # assistiv | teilautonom | autonom
  prozesseinbindung: keine
  personendaten: nein
  modellverkettung: nein
  kalibrierungszyklus: quartalsweise

risikoklasse: mittel               # abgeleitet, siehe classify.py
outsourcing_relevant: true
provider: <anbieter>
modellversion: <modell-id>@2026-05
datenresidenz: CH
fallback: verweis_auf_fachstelle
eval_suite: evals/kb-assistant/
letzte_unabhaengige_pruefung: 2026-04-18

Die Risikoklasse sollte nicht von Hand gesetzt, sondern aus den beiden Achsen abgeleitet werden. Sonst wandern Anwendungen erfahrungsgemäss nach unten. Ein CI-Schritt, der die Ableitung nachrechnet und bei Abweichung fehlschlägt, kostet wenig und verhindert genau die Inkonsistenz, die die FINMA als „nicht konsistente Kriterien” beschreibt.

Für eingekaufte Software hilft das alles nicht. Dort bleibt nur, KI-Nutzung im Beschaffungsprozess abzufragen, und zwar mit einer Frage, die sich nicht mit „nein” beantworten lässt, ohne zu lügen. Bewährt hat sich, statt „Enthält Ihr Produkt KI?” zu fragen: „Listen Sie alle Modelle Dritter auf, an die Ihr Produkt Daten unserer Nutzer sendet, mit Anbieter, Modellversion und Verarbeitungsort.” Das ist überprüfbar und lässt sich vertraglich mit einer Meldepflicht bei Änderungen kombinieren.

Ein Gateway als Kontrollpunkt

Das Gateway ist der Ort, an dem sich mehrere Anforderungen der AM 08/2024 gleichzeitig erfüllen lassen, ohne dass jedes Team sie einzeln implementiert:

  • Nachvollziehbarkeit: Persistieren von Prompt, Kontext, Modellversion, Parametern und Antwort, mit Korrelations-ID zur Geschäftstransaktion. Das ist die Grundlage für jede spätere Rekonstruktion einer Entscheidung.
  • Datenklassifikation: Prüfung vor dem Versand, ob der Payload zur deklarierten Datenklasse der Anwendung passt.
  • Modellversionierung: Anbieterseitige Modellwechsel sind ein Änderungsereignis im Sinne des Risikomanagements. Wer gegen einen gleitenden Alias arbeitet, hat kein reproduzierbares System.
  • Kostentransparenz und Rate Limits pro Anwendung, was in der Praxis oft der erste Grund ist, warum ein Gateway überhaupt gebaut wird.

Der Aufwand ist nicht trivial, aber er fällt einmal an. Die Alternative, dass jedes Team Logging und Klassifikation selbst implementiert, führt zu genau der Fragmentierung, die die FINMA als „dezentrale Entwicklung” und „verstreute Zuständigkeiten” kritisiert.

Ein Detail, das oft vergessen geht: Die Retention der Gateway-Logs muss zum Datenschutz passen. Vollständige Prompts können Personendaten enthalten, die man nicht sieben Jahre aufbewahren will. Ein gangbarer Kompromiss ist, Metadaten und Hashes langfristig zu behalten und Klartext-Payloads nach kurzer Frist zu löschen, ausser bei Anwendungen mit expliziter Aufbewahrungspflicht.

Anonymisierung vor dem Modellaufruf

Die Migros Bank hat ein Muster öffentlich beschrieben, das ich für den derzeit saubersten dokumentierten Ansatz einer Schweizer Retailbank halte. Kundenanfragen durchlaufen mehrere Schritte: Analyse und Anonymisierung der Eingabe, Suche in einer internen Wissensdatenbank, Antwortgenerierung, Faktenprüfung. Kundenidentifizierende Informationen werden vor dem Versand in die Schweizer Cloud durch Platzhalter ersetzt und erst on-premises wieder eingesetzt. (IFZ Retail Banking Blog)

Der entscheidende Punkt ist die Lage der Zuordnungsregel. Sie bleibt im Haus, was der Anforderung aus dem SBVg-Cloud-Leitfaden entspricht, dass die Zuordnungsregel unter Kontrolle der Bank in der Schweiz stehen soll. (SBVg Cloud-Leitfaden)

Man sollte die Grenzen davon kennen. Entity-Erkennung ist nicht perfekt, und bei Freitexteingaben von Kunden ist die Trefferquote schlechter als bei strukturierten Feldern. Ausserdem ist Anonymisierung kein Schutz gegen Reidentifikation über Kontext: Eine Anfrage mit Betrag, Datum und Filiale kann eindeutig sein, auch ohne Namen. Das Muster reduziert Risiko, es eliminiert es nicht, und genau so sollte es auch dokumentiert werden.

Evaluation als Gate, nicht als Bericht

Die FINMA erwartet „vorab festgelegte Performance-Indikatoren”, „Schwellenwerte oder andere Validierungsmethoden” und Tests auf „Genauigkeit, Robustheit und Stabilität sowie ggfs. Bias”. Sie nennt in einer Fussnote explizit Backtesting, Out-of-Sample-Testing, Sensitivitätsanalysen, Stress-Testing, Adversarial Testing mit falschen Inputdaten und Benchmarking gegen einfachere Modelle. (FINMA AM 08/2024)

Das ist praktisch eine Spezifikation für eine Eval-Suite. Sie in CI zu betreiben ist der Unterschied zwischen „wir haben getestet” und „wir testen”.

# evals/kb_assistant/test_regression.py
import pytest, yaml
from app.pipeline import answer

GOLDEN = yaml.safe_load(open("evals/kb_assistant/golden.yaml"))
THRESHOLDS = {"exact_ref": 0.95, "no_answer_recall": 0.98, "hallucination": 0.02}

@pytest.mark.parametrize("case", GOLDEN["cases"], ids=lambda c: c["id"])
def test_case(case, results):
    out = answer(case["question"], seed=0)
    results.record(
        case_id=case["id"],
        # Wird die korrekte Weisung als Quelle zitiert?
        exact_ref=case["expected_ref"] in out.citations,
        # Wird bei Fragen ausserhalb des Scope korrekt abgelehnt?
        refused=out.refused,
        # Enthält die Antwort Aussagen ohne Beleg im Kontext?
        unsupported=count_unsupported_claims(out.text, out.context),
    )

def test_thresholds(results):
    m = results.aggregate()
    assert m["exact_ref"] >= THRESHOLDS["exact_ref"]
    assert m["no_answer_recall"] >= THRESHOLDS["no_answer_recall"]
    assert m["hallucination"] <= THRESHOLDS["hallucination"]

Drei Dinge daran sind wichtiger als der Code selbst.

Erstens: Das Golden Set muss von Fachleuten stammen, nicht vom Entwicklungsteam. Die FINMA formuliert das als Erwartung, dass „Fachpersonen des jeweiligen Anwendungsbereiches hierzu Fragestellungen und vordefinierte Erwartungen” liefern. (FINMA AM 08/2024) Wer die Testfälle selbst schreibt, testet gegen das eigene mentale Modell des Systems.

Zweitens: Ablehnungsverhalten gehört genauso getestet wie Antwortqualität. Die Migros Bank hat entschieden, dass der Assistent nur Fragen zur Bank und ihren Dienstleistungen beantwortet und keine Beratung im engeren Sinn gibt. Auf die Frage nach dem optimalen Konto verweist er auf einen Berater. (IFZ Retail Banking Blog) Diese Grenze ist nur dann eine Kontrolle, wenn sie messbar ist.

Drittens: Reproduzierbarkeit ist bei LLM-Pipelines schwierig, und man sollte das nicht wegdefinieren. Ein fixer Seed und Temperatur null helfen, garantieren aber bei gehosteten Modellen keine Bit-Gleichheit. Batching und Infrastrukturänderungen beim Anbieter reichen für Abweichungen. Was reproduzierbar sein muss, ist nicht die exakte Antwort, sondern der Zustand: Prompt-Version, Kontextdokumente mit Hash, Modellversion, Parameter. Damit lässt sich eine Antwort nachträglich erklären, auch wenn sie sich nicht identisch erzeugen lässt. Das ist meiner Einschätzung nach die realistische Auslegung der Erwartung, Ergebnisse müssten „nachvollzogen, erklärt oder reproduziert” werden können.

Erklärbarkeit pragmatisch auslegen

Die AM 08/2024 verlangt, dass „die Plausibilität und Robustheit der Ergebnisse” beurteilt werden können und dass „die Treiber der Anwendungen oder das Verhalten unter verschiedenen Bedingungen” verstanden werden. (FINMA AM 08/2024) Diese Formulierung bleibt hinter einer Forderung nach mechanistischer Interpretierbarkeit zurück, und das ist gut so: Letztere ist für ein Modell mit hunderten Milliarden Parametern schlicht nicht lieferbar.

Was lieferbar ist:

  • Quellenbindung. Jede Aussage lässt sich auf ein Dokument zurückführen. UBS zeigt in ihrem internen Assistenten „Red” die Quelle direkt im Tool mit Link zum Originaldokument. (IFZ Retail Banking Blog) Das ist keine Erklärbarkeit im XAI-Sinn, aber es macht die Antwort für den Nutzer prüfbar, und das ist der Zweck.
  • Verhaltensdokumentation über Testfälle. Wenn eine Eval-Suite abdeckt, wie sich das System bei Grenzfällen, fehlenden Informationen und widersprüchlichen Quellen verhält, ist das eine belastbarere Aussage über Verhalten als jede Attributionsheatmap.
  • Ablationen. Was ändert sich, wenn ein Dokument aus dem Kontext entfernt wird? Das ist billig zu messen und beantwortet die Frage nach den Treibern für den konkreten Fall.

Bei klassischen Modellen wie Scoring, Segmentierung und Transaktionsmonitoring sieht das anders aus. Dort sind SHAP-Werte, Partial-Dependence-Plots und Benchmarking gegen ein einfaches, interpretierbares Referenzmodell weiterhin der Standard, und die FINMA nennt Benchmarking gegen einfachere Modelle ausdrücklich. Es lohnt sich, diese beiden Welten in der Dokumentation getrennt zu halten, statt einen einheitlichen Erklärbarkeitsbegriff über beide zu stülpen.

Drift und Override-Rate als Frühwarnsignale

Ein Detail der AM 08/2024 wird selten aufgegriffen, obwohl es das billigste verfügbare Signal ist: „Zur Überwachung gehört auch die Analyse von Fällen, in denen die Ausgabe von den Anwendern ignoriert oder verändert wurde, da solche manuellen Korrekturen Rückschluss auf Schwachstellen geben können.” (FINMA AM 08/2024)

Die Override-Rate ist bei jedem Human-in-the-Loop-System ohnehin vorhanden, man muss sie nur erfassen. Bei einem E-Mail-Assistenten, wie ihn die Migros Bank direkt in Outlook integriert hat, ist die Frage, wie stark der Vorschlag vor dem Versand verändert wurde, ein direkter Qualitätsindikator. (IFZ Retail Banking Blog) Eine steigende Override-Rate in einem einzelnen Themencluster zeigt eine Wissenslücke oder eine Regeländerung, die noch nicht im System angekommen ist. Das ist Monitoring, das ohne zusätzliche Modellierung auskommt.

Datendrift bei Eingaben ist der zweite Baustein, ebenfalls explizit gefordert. Bei LLM-Anwendungen ist die relevante Drift meist nicht in der Feature-Verteilung, sondern im Themenmix der Anfragen und in der Aktualität der Wissensbasis. Die Migros Bank behandelt schlecht bewertete Antworten systematisch als Hinweis auf Lücken in der Wissensdatenbank und schliesst diese. (IFZ Retail Banking Blog) Das ist ein geschlossener Regelkreis und deutlich wirksamer als ein Quartalsreport.

Deployment: die ehrliche Abwägung

Vier Optionen stehen realistisch zur Verfügung, und keine ist eindeutig überlegen.

Hyperscaler mit EU- oder US-Verarbeitung. Beste Modellqualität, tiefster Betriebsaufwand, höchste Drittparteiabhängigkeit. Die FINMA nennt die steigende Abhängigkeit von Anbietern von Hardware, Modellen und Cloud-Diensten „in einem zunehmend konzentrierten Markt” ausdrücklich als Risiko (FINMA AM 08/2024); der Risikomonitor 2025 verschärft das mit dem Befund, dass fast die Hälfte aller gemeldeten Cybervorfälle Drittparteien betraf (FINMA Risikomonitor 2025).

Schweizer Hosting durch Anbieter mit Modellzugang. Der Mittelweg, den mehrere Institute gewählt haben. UBS hostet den Bereich mit externen Informationen in ihrem Assistenten in der Schweiz; der Zugriff auf das öffentliche ChatGPT ist für Mitarbeitende blockiert. (IFZ Retail Banking Blog) Die Migros Bank nutzt LLM-Modelle in der Schweizer Cloud in Kombination mit vorgelagerter Anonymisierung. (IFZ Retail Banking Blog) Datenresidenz ist damit gelöst, die Modellabhängigkeit nicht.

Eigene Infrastruktur. Swissquote baut nach eigenen Angaben eine souveräne KI-Infrastruktur auf, investiert bis 2028 rund 30 Millionen Franken und nutzt bereits ein Rechenzentrum mit 140 Petaflops. CEO Marc Bürki begründet das damit, zentrale Technologien selbst kontrollieren und die Abhängigkeit von externen Plattformen reduzieren zu wollen. (Netzwoche) Das ist eine Grössenordnung, die für die meisten Institute nicht in Frage kommt.

Offene Modelle im eigenen Betrieb. Apertus, das im Rahmen der Swiss AI Initiative entwickelte, vollständig quelloffene Schweizer LLM, ist die interessanteste Option für Fälle, in denen Daten die Schweizer Jurisdiktion nicht verlassen dürfen; Version 1.5 wurde für Sommer 2026 angekündigt. (Swisscom zur Swiss AI Initiative) Die Einschränkung sollte man nicht kleinreden: Bei Aufgaben an der Leistungsgrenze aktueller Frontier-Modelle ist der Abstand real. Für gut abgegrenzte Aufgaben mit sauberem Retrieval, etwa Weisungsauskunft, Klassifikation oder Extraktion, ist er oft irrelevant.

Meine Einschätzung: Die Deploymentfrage wird zu früh gestellt. Sinnvoller ist, zuerst die Datenklassen sauber zu trennen und dann pro Klasse zu entscheiden. Ein Wissensassistent auf öffentlichen Produktinformationen und einer mit Zugriff auf Kundendossiers sind unterschiedliche Systeme mit unterschiedlichen Anforderungen, auch wenn sie dieselbe Oberfläche haben.

Agenten: die nächste Stufe

Die AM 08/2024 nennt den „Grad der Autonomie und Prozesseinbindung” sowie die „Vernetzung mehrerer Modelle” als Faktoren für die Eintrittswahrscheinlichkeit. (FINMA AM 08/2024) Genau dort bewegt sich die Entwicklung gerade.

Sygnum hat im Mai 2026 nach eigenen Angaben als erste Schweizer Bank einen KI-Agenten für Live-Transaktionen mit digitalen Vermögenswerten getestet. Der Agent wandelt Textanweisungen in mehrstufige Blockchain-Transaktionen um, plant die Schritte, prüft Smart Contracts und weist auf Transaktionsrisiken hin, bevor er dem Kunden die Transaktion zur Freigabe vorlegt. Die Signatur erfolgt über die selbstverwahrte Wallet des Kunden auf dessen Gerät. Die Architektur basiert auf dem Model Context Protocol; im Test kam Claude zum Einsatz. Für Kunden ist der Agent noch nicht verfügbar, ein Einsatz unterliege umfassenden regulatorischen Prüfungen. (Netzwoche)

Das Muster ist unabhängig von der Assetklasse übertragbar: Der Agent plant und begründet, der Mensch autorisiert, und die kritische Berechtigung, hier der private Schlüssel, verlässt die Kontrolle des Berechtigten nie. Diese Trennung sollte man als Architekturprinzip behandeln und nicht als Zwischenlösung, die man später wegoptimiert. Die Autorisierungsgrenze ist der Ort, an dem sich Verantwortlichkeit zuordnen lässt, und genau deren Zuordnung benennt die FINMA bei „autonomem und schwer erklärbarem Handeln” als Herausforderung.

Wo Schweizer Banken tatsächlich stehen

Die Zahlenlage ist besser als bei den meisten Technologiethemen, weil es drei unabhängige Erhebungen gibt.

Die FINMA-Umfrage von Anfang 2025 kam auf rund 50 Prozent der befragten Institute mit KI im Einsatz oder in Entwicklung. (FINMA-Umfrage) Das EY Bankenbarometer 2026, basierend auf einer Umfrage bei 100 Banken aus der Schweiz und Liechtenstein Ende 2025, meldet 78 Prozent, die sich mit der Umsetzung von KI-Projekten beschäftigen, nach 53 Prozent im Vorjahr. Kantonalbanken liegen mit 87 Prozent vorn, Regionalbanken bei 75 Prozent. Dass KI gar kein Thema sei, hörten die Studienautoren nur noch von einigen Privatbanken. (EY Bankenbarometer 2026 via Netzwoche)

Die IFZ-Studie Bank-IT und Sourcing 2026 der HSLU, für die Führungskräfte aus 43 Retailbanken befragt wurden, zeigt eine differenziertere Rangfolge: Erstmals messen rund die Hälfte der Banken KI eine hohe Bedeutung zu, was Platz 4 bedeutet, hinter Cybersecurity mit 95 Prozent, Prozessautomatisierung mit 74 Prozent und digitaler Unterstützung des Beratungspersonals mit 65 Prozent. Die Studienautoren merken an, dass KI in diesen drei Bereichen bereits implizit enthalten ist. 51 Prozent der Banken lagern KI-Leistungen aus; internes Know-how bauen vor allem grössere Institute auf, während der KI-Einsatz im Zahlungsverkehr und in der Geldwäschereibekämpfung oft ausgelagert wird. (HSLU-Studie via Netzwoche)

Die verschiedenen Prozentzahlen widersprechen sich nicht, sie messen Unterschiedliches: „setzt ein” gegen „beschäftigt sich mit der Umsetzung” gegen „misst hohe Bedeutung zu”. Die Richtung ist in allen drei Erhebungen dieselbe.

Bei einzelnen Instituten ist die Belegdichte sehr unterschiedlich. Was öffentlich dokumentiert ist:

UBS kündigte im Quartalsabschluss Q3/2024 rund 50’000 Microsoft-Copilot-Lizenzen an und stellte den KI-Assistenten „Red” vor. Red basiert im Kern auf der Microsoft-Plattform, wurde für UBS-Anwendungsfälle dediziert weiterentwickelt und war Ende 2024 für etwa 20’000 Mitarbeitende in der Schweiz, Hongkong und Singapur vorgesehen; die Rollouts sollten bis März 2025 abgeschlossen sein. Der Bereich mit externen Informationen wird in der Schweiz gehostet, der Zugriff auf das öffentliche ChatGPT ist blockiert. Red zeigt Quellen mit Link zum Originaldokument an und hat eine Feedbackschleife sowie definierte Guardrails. (IFZ Retail Banking Blog)

Zürcher Kantonalbank hat „ZKB ChatGPT” nach einer zweimonatigen Testphase seit Oktober 2024 im Einsatz; Mitarbeitende haben Zugang zu einer eigenen Version mit Zugriff auf interne Daten. Häufigste Anwendungen sind Recherche, Texterstellung und Zusammenfassungen. (Microsoft Switzerland News Center)

Migros Bank ist von den dokumentierten Fällen am weitesten im Kundenkontakt: Der digitale Assistent auf Basis der Plattform von ParetoLabs beantwortet nach Angaben aus dem IFZ-Blog monatlich mehr als 15’000 Anfragen. Dazu kommen ein Secure AI Chat und ein E-Mail-Assistent für Mitarbeitende. Der Kundenassistent arbeitet autonom, der E-Mail-Assistent nach dem Human-in-the-Loop-Prinzip mit redaktioneller Verantwortung beim Mitarbeitenden. Als nächster Schritt ist der Ausbau in Richtung agentischer Workflows geplant. (IFZ Retail Banking Blog)

Swissquote verfolgt die oben beschriebene Investition in eigene Infrastruktur, mit Fokus auf Betrugserkennung und digitalen Assistenten. Der persönliche Assistent „Yuhlia” wird in der App der Plattform Yuh getestet. Nach Angaben von CEO Marc Bürki werden bereits Anwendungen vollständig von KI-Systemen programmiert. (Netzwoche)

Sygnum hat den beschriebenen Agententest durchgeführt. (Netzwoche)

Valiant hat laut IFZ KI bei Übungen des Krisenstabs eingesetzt, um in kurzer Zeit einen strukturierten Lageüberblick zu erstellen. Mehrere Banken nutzen im Hypothekarprozess die SaaS-Lösung Hypodossier zur Dokumentenklassifikation und Datenextraktion, inklusive Hinweisen auf Inkonsistenzen. (IFZ Retail Banking Blog)

Für Julius Bär ist im Zusammenhang mit dem Restrukturierungsprogramm von einem erwarteten KI-Beitrag zu den Einsparungen berichtet worden; belastbare öffentliche Angaben zur konkreten Architektur oder Governance liegen mir nicht vor. Für Vontobel, Pictet und die meisten übrigen Privatbanken gilt dasselbe: Es gibt Ranglisten zur digitalen Reife, aber keine überprüfbaren Angaben dazu, wie KI-Anwendungen technisch aufgesetzt und kontrolliert sind. Diese Lücke sollte man als Lücke stehen lassen und nicht durch Analogieschlüsse füllen.

Das Muster über alle belegten Fälle hinweg ist eindeutig und deckt sich mit dem IFZ-Befund: Die überwiegende Mehrheit der Anwendungen unterstützt Mitarbeitende in Unterstützungsprozessen. In den Kernprozessen Finanzieren, Sparen, Vorsorgen, Anlegen und Zahlen ist KI kaum im Einsatz. (IFZ Retail Banking Blog) Die Migros Bank am Kundenkontakt und Sygnum mit dem Transaktionsagenten sind die Ausnahmen, die die Regel bestätigen.

Einschätzung

Drei Punkte, die ich für die wichtigsten halte und die als meine Bewertung zu lesen sind, nicht als Wiedergabe von Quellen.

Das Compliance-Problem ist überwiegend ein Engineering-Problem. Fast jede Erwartung aus der AM 08/2024 lässt sich auf eine technische Eigenschaft abbilden: Inventarvollständigkeit auf Egress-Kontrolle, Nachvollziehbarkeit auf Logging und Versionierung, Testanforderungen auf eine CI-integrierte Eval-Suite, Datenqualität auf Pipelines mit Prüfungen. Wer diese Dinge baut, hat die Dokumentation praktisch als Nebenprodukt. Wer sie nicht baut, schreibt Dokumente über einen Zustand, den er nicht messen kann. Der zweite Weg ist kurzfristig billiger und in einer Vor-Ort-Kontrolle nicht haltbar.

Der unterschätzte Punkt ist die Vollständigkeit, nicht die Tiefe. Die meisten Institute, die ich im Umfeld beobachte, haben für ihre Vorzeigeanwendung eine ordentliche Dokumentation. Das Risiko liegt nicht dort, sondern bei den zwanzig kleinen Automatisierungen, die niemand als KI eingetragen hat, und bei den eingekauften Werkzeugen, die still ein Modell aufgerüstet haben. Wenn ich eine einzige Massnahme priorisieren müsste, wäre es die technische Bündelung des Modellzugangs, nicht wegen der Kosten, sondern weil sie die Frage „Was läuft bei uns eigentlich?” beantwortbar macht.

Erklärbarkeit wird überschätzt, Reproduzierbarkeit unterschätzt. In den Diskussionen dominiert die Frage, ob man ein LLM erklären kann. Der Anspruch, den die FINMA formuliert, ist niedriger und praktischer: Plausibilität und Robustheit beurteilen können. Das lässt sich mit Quellenbindung, Testabdeckung und Ablationen erreichen. Deutlich schwieriger und weniger diskutiert ist, den Zustand einer Antwort so festzuhalten, dass sie zwei Jahre später in einem Rechtsfall noch rekonstruierbar ist. Modellversionen werden abgekündigt, Prompts ändern sich, Wissensbasen werden aktualisiert. Wer das nicht von Anfang an versioniert, kann später nicht mehr sagen, warum das System damals so geantwortet hat. Und genau das ist die Frage, die in einem Streitfall gestellt wird.

Der regulatorische Rahmen wird sich bis Ende 2027 weiter konkretisieren: EJPD-Vernehmlassung, SIF-Bericht, die verschobenen EU-Fristen. An der Grundlogik ändert das wenig. Wer heute Inventar, Gateway, Evals und Versionierung sauber aufsetzt, wird die kommenden Anforderungen weitgehend erfüllen. Wer darauf wartet, bis eine Norm ihm sagt, was zu tun ist, baut in der Zwischenzeit Systeme, die er nachträglich nicht mehr belegen kann.

Quellen

Regulatorik und Aufsicht

Rechtliche Einordnung

Studien und Marktdaten

Bankspezifische Fälle

Passend dazu