Ist AI-generierter Code in einer Bank erlaubt? Eine Antwort aus Sicht der Rückverfolgbarkeit.

Irgendwo in der Schweiz wird diese Woche ein Engineering Lead in einem Risikoausschuss mit der Frage konfrontiert: „Dürfen wir AI-generierten Code tatsächlich in Produktion nehmen?“ Das klingt nach einer Ja-oder-Nein-Frage. Ist es aber nicht – und genau hier liegt der Fehler vieler interner AI-Richtlinien: Sie behandeln sie wie eine solche.

Hier ist die Antwort, die vor der FINMA, einem externen Auditor und Ihrem eigenen Verwaltungsrat Bestand hat:

AI-generierter Code ist als Kategorie weder erlaubt noch verboten. Erlaubt ist Code, dessen Herkunft, Review und Freigabe Sie nachweisen können – Zeile für Zeile, Merge für Merge.

Die Frage ist nicht, ob es erlaubt ist. Entscheidend ist die Nachweisbarkeit.

Was die Schweizer Regulierung tatsächlich besagt

Die Schweiz hat kein spezifisches AI-Gesetz für Banken – und genau das ist der springende Punkt. Im Dezember 2024 veröffentlichte die FINMA die Aufsichtsmitteilung 08/2024 zu Governance und Risikomanagement beim Einsatz künstlicher Intelligenz. Ihre Kernaussage: Die bestehenden, technologieneutralen und prinzipienbasierten regulatorischen Anforderungen gelten für AI genauso wie für andere Technologien. In der Praxis erwartet die FINMA von den beaufsichtigten Instituten, dass sie:

• ein Verzeichnis der AI-Anwendungen führen und deren Risiken klassifizieren;
• klare Zuständigkeiten bis hin zu namentlich benannten Rollen festlegen;
• die Datenqualität sicherstellen;
• kontinuierlich testen und überwachen;
• Prozesse dokumentieren und Ergebnisse erklären können;
• kritische Systeme einer unabhängigen Überprüfung unterziehen.

Die FINMA stellte zudem fest, dass sich viele Finanzinstitute noch in einer frühen Phase beim Aufbau dieser Governance-Strukturen befinden. Die Kluft zwischen „wir nutzen AI-Tools“ und „wir können AI-Tools steuern“ ist deshalb derzeit eines der deutlichsten Reifegrad-Signale, die eine Aufsichtsbehörde wahrnimmt.

Für Schweizer Institute sind zwei weitere Aspekte relevant:

• Der EU AI Act (Verordnung (EU) 2024/1689) – relevant für Schweizer Banken mit EU-Bezug. Kundenbeziehungen, Tochtergesellschaften oder ausgelagerte Funktionen in der EU können entsprechende Compliance-Anforderungen auch für Schweizer Institute relevant machen.
• Das revidierte Schweizer Datenschutzgesetz (DSG) – regelt unter anderem, welche Daten den eigenen Sicherheitsbereich verlassen dürfen, wenn ein Coding Assistant Kontext an ein Modell übermittelt. Quellcode kann Personendaten, Zugangsdaten oder Geschäftslogik enthalten, deren Schutz vertraglich zugesichert wurde.

Nichts davon verbietet AI-gestützte Softwareentwicklung. Der Schweizer Bankensektor setzt entsprechende Technologien bereits schrittweise ein: Raiffeisen führte Anfang 2024 Copilot Chat als bewussten ersten Schritt vor einer tieferen Tool-Integration ein, während Pictet einen internen LLM-basierten Assistenten auf Basis eigener Wissensdatenbanken betreibt. UBS hat Microsoft 365 Copilot weltweit für Mitarbeitende eingeführt und nutzt daneben einen eigenen Assistenten. Das Unternehmen berichtet von mehr als 300 aktiven AI-Anwendungsfällen und betont öffentlich, dass Governance, Erklärbarkeit und kontrollierte Einführung zentrale Bestandteile seiner AI-Strategie sind.

Das Signal der Branche ist eindeutig: AI-Adoption ist Mainstream; Governance macht den Unterschied.

Die Frage, die Ihr Auditor tatsächlich stellen wird

Sobald AI Teil Ihres SDLC ist, dreht sich das Audit nicht mehr nur um die Frage „Nutzen Sie AI-Tools?“. Stattdessen entsteht eine Kette von fünf Fragen zur Nachweisbarkeit:

1. Bestandsaufnahme. Welche AI-Tools und welche Versionen davon sind Teil Ihrer Delivery-Pipeline – einschliesslich Tools, die ein Team möglicherweise informell eingeführt hat?
2. Attribution. Können Sie für jede Änderung in Produktion nachweisen, welche Teile von AI vorgeschlagen und welche von einem Menschen geschrieben oder akzeptiert wurden? Ein Commit-Verlauf mit der Aussage „AI hat es geschrieben“, aber ohne klar benannte verantwortliche Person, besteht diesen Test nicht.
3. Human Gates. Wo genau findet die menschliche Überprüfung zwischen dem AI-Output und einer relevanten Änderung statt – und können Sie nachweisen, dass dieser Kontrollpunkt tatsächlich genutzt und nicht nur konfiguriert wurde? Branch-Protection-Screenshots dokumentieren eine Policy. Approval-Logs mit Reviewer-Identität, Zeitstempel und Entscheidungsgrundlage liefern dagegen Nachweise.
4. Datenpfad. Welche Informationen haben Ihre Sicherheitsgrenze in Richtung eines Drittanbieter-Modells verlassen? Wo wurden sie verarbeitet und gespeichert? Und ist das Training mit Ihren Daten vertraglich und technisch ausgeschlossen – verifiziert und nicht nur aus Marketingaussagen abgeleitet?
5. Reproduzierbarkeit. Wenn sich ein Produktionsvorfall auf eine AI-gestützte Änderung von vor vier Monaten zurückführen lässt: Können Sie den Review-Prozess rekonstruieren, durch den diese Änderung genehmigt wurde?

Wenn Sie diese fünf Fragen beantworten können, beantwortet sich die Frage „Ist das erlaubt?“ weitgehend von selbst.

Drei Arten von Schweizer Banken, drei unterschiedliche Schwerpunkte

Die Nachweiskette ist grundsätzlich dieselbe. Wo sie besonders unter Druck gerät, hängt jedoch vom jeweiligen Institutstyp ab.

Die internationale Bank – etwa in der Grössenordnung der UBS. Die Herausforderung liegt in der Breite und in unterschiedlichen Jurisdiktionen. Ein globales Institut betreibt eigenes Platform Engineering, sodass Kontrollmechanismen in grossem Massstab direkt in interne Pipelines integriert werden können – und müssen: maschinenlesbare AI-Attribution auf Commit-Ebene, verbindliche Review-Stufen und ein zentralisiertes Tool-Inventar für Tausende von Engineers. Die grenzüberschreitende Ebene erhöht die Komplexität zusätzlich: EU-Einheiten bringen DORA und den EU AI Act direkt ins Spiel, sodass dieselbe Änderung möglicherweise sowohl den prinzipienbasierten Erwartungen der FINMA als auch den detaillierteren EU-Anforderungen entsprechen muss. Auch das Konzentrationsrisiko ist ein eigenes Aufsichtsthema: Wenn ein einzelner Modellanbieter einen grossen Teil Ihrer Assistenzsysteme unterstützt, gelten die Bedenken rund um Drittanbieter-Abhängigkeiten auch für Ihren SDLC – nicht nur für kundenorientierte AI-Systeme. Und jede Bank, die eine Fusion integriert, kennt eine weitere Realität: Zwei geerbte Toolchains bedeuten zwei unterschiedliche Nachweismodelle, die zunächst miteinander in Einklang gebracht werden müssen.

Die Kantonalbank. Hier stellt sich die Frage anders, weil ein erheblicher Teil des Codes häufig nicht intern entwickelt wird. Wenn das Core Banking auf Plattformen wie Avaloq oder Finnova basiert und wesentliche Teile der Entwicklung ausgelagert sind, wird die Frage nach AI-generiertem Code vor allem zu einer Frage der Vendor Governance: Nutzt Ihr Core-Banking-Anbieter oder Engineering-Partner AI in der Entwicklung? Unter welchen Kontrollen? Und kann er Ihnen die Nachweise liefern, die Ihr Auditor letztlich von Ihnen verlangen wird? Die Outsourcing-Anforderungen der FINMA bedeuten, dass das Institut auch für ausgelagerte Leistungen Verantwortung trägt. „Unser Anbieter nutzt AI – fragen Sie ihn“ ist daher keine ausreichende Antwort. Hinzu kommt die kantonale Dimension: Aufgrund der öffentlichen Trägerschaft und – in vielen Fällen – einer Staatsgarantie kann die Reputationsrisikotoleranz bei einem AI-bezogenen Vorfall besonders gering sein. Die praktische Konsequenz: Anforderungen zur Offenlegung des AI-Einsatzes in der Entwicklung, Nachweise zur Attribution und Klauseln zum Ausschluss der Nutzung von Daten für Trainingszwecke sollten frühzeitig in Lieferantenverträgen geregelt werden.

Die Privatbank. Hier steht die Vertraulichkeit im Mittelpunkt. Der Schutz von Kundendaten ist nicht nur eine Compliance-Anforderung – er ist Teil des Produkts. Zwei Themen rücken dadurch besonders in den Vordergrund: Datenresidenz und Prompt-Retention – also welche Informationen ein Coding Assistant tatsächlich übermittelt, wo sie verarbeitet werden, was zwischengespeichert wird und ob Systeme mit kundenidentifizierenden Daten betroffen sind – sowie das Risiko massgeschneiderter Legacy-Systeme. Jahrzehntealte Portfolio- und CRM-Systeme sind häufig nur unvollständig dokumentiert. Gerade deshalb sind AI-gestützte Änderungen attraktiv – weil institutionelles Wissen knapp ist. Gleichzeitig sind ungeprüfte AI-Änderungen in solchen Systemen besonders schwer zu erkennen. Da Privatbanken häufig mit Engineering-Partnern arbeiten, muss die Nachweiskette auch über den Partner hinweg funktionieren: Ein Delivery-Team, das keine Attribution auf Commit-Ebene und keine Gate-Protokolle nachweisen kann, bringt neben höherer Delivery-Geschwindigkeit auch Audit-Risiko mit.

Die Antwort zur Rückverfolgbarkeit in einem Absatz

Zulässig ist, was Sie nachweisen können. Konkret bedeutet das fünf Artefakte, auf die sich ein Auditor stützen kann: ein versioniertes Verzeichnis der AI-Tools im SDLC; eine Attribution auf Commit-Ebene, die AI-vorgeschlagene von menschlich vorgenommenen Änderungen unterscheidet; Human-Gate-Protokolle mit namentlich genannten Reviewern und Zeitstempeln; Vendor Agreements mit verifiziertem Ausschluss der Nutzung Ihrer Daten für Trainingszwecke und definierten Aufbewahrungsfristen; sowie einen reproduzierbaren Nachweispfad von jeder produktiven Änderung zurück zum Review, durch den sie genehmigt wurde. Institute, die über diese Nachweise verfügen, fragen nicht mehr, ob AI-generierter Code zulässig ist. Sie bringen ihn in Produktion – schneller als diejenigen, die noch über diese Frage debattieren, und mit einer Audit-Dokumentation, die die Diskussion beendet, bevor sie beginnt.