AI in der regulierten Software-Delivery: DORA, EU AI Act und FINMA – der umfassende Leitfaden.

1 · Die Regulierungswelle: Was gilt für wen und wann?

Die Frage ist nicht, ob AI erlaubt ist. Entscheidend ist, welche Nachweise Sie erbringen müssen. Die Schweiz hat kein AI-spezifisches Bankengesetz – und das bewusst. Die FINMA-Leitlinie 08/2024 macht die bestehenden technologieneutralen, prinzipienbasierten Anforderungen für AI explizit: Führen Sie ein Verzeichnis der AI-Anwendungen, klassifizieren Sie deren Risiken, weisen Sie den benannten Rollen Verantwortlichkeiten zu, stellen Sie die Datenqualität sicher, testen und überwachen Sie kontinuierlich, dokumentieren Sie und sorgen Sie dafür, dass kritische Systeme unabhängig überprüft werden können. Die FINMA stellte zudem fest, dass sich die meisten Institute beim Aufbau dieser Strukturen noch in einem frühen Stadium befinden – was die Reife der Governance derzeit zu einem sichtbaren Unterscheidungsmerkmal macht.

Rund um diesen Schweizer Kern greifen drei weitere Regelwerke. DORA gilt für Finanzunternehmen in der EU – und erstreckt sich vertraglich auch auf deren IKT-Anbieter, sodass Schweizer Lieferanten von EU-Institutionen vertragliche Anforderungen an Resilienz, Vorfallmeldungen und Prüfungsrechte erfüllen müssen. DasEU AI Act ist vor allem für Schweizer Banken relevant, die über Kunden, Tochtergesellschaften oder ausgelagerte Funktionen einen Bezug zur EU haben; die meisten AI-Anwendungen im Softwareentwicklungszyklus (SDLC) fallen zwar nicht unter die Hochrisikokategorien, doch gelten weiterhin Transparenz- und Bestandserfassungspflichten. Das revidierte Schweizer Datenschutzgesetz (revDSG) regelt, was Ihren Sicherheitsperimeter verlässt, wenn ein Tool Code-Kontext an ein Modell sendet – Quellcode enthält häufiger personenbezogene Daten und geschützte Geschäftslogik, als Teams annehmen.

Und realistisch betrachtet: Vieles fällt auch nicht darunter. Ein interner Programmierassistent ist kein AI-System mit hohem Risiko im Sinne des AI-Gesetzes; ein Dokumentationsgenerator löst keine Modellrisikoregelungen aus, die für Kreditentscheidungen entwickelt wurden. Übermässige Compliance verschwendet Budget ebenso zuverlässig, wie mangelnde Compliance Beanstandungen nach sich zieht – erst klassifizieren, dann verhältnismässig kontrollieren.

2 · Was Prüfer tatsächlich zu AI im SDLC fragen

Die Diskussion im Rahmen des Audits zum Thema AI in Ihrem SDLC hat sich auf eine feste Abfolge von fünf Fragen konzentriert. Erstens – Bestandsaufnahme: Welche AI-Tools in welchen Versionen kommen in Ihrer Delivery-Pipeline zum Einsatz, einschliesslich derjenigen, die ein Team im letzten Quartal informell eingeführt hat? Zweitens – Zuordnung: Können Sie bei jeder Änderung in der Produktion nachweisen, welche Teile von der AI vorgeschlagen und welche von Menschen verfasst oder genehmigt wurden? Drittens – Gates: An welcher Stelle findet eine menschliche Überprüfung zwischen dem AI-Ergebnis und allen daraus resultierenden Massnahmen statt, und können Sie nachweisen, dass das Gate tatsächlich durchlaufen und nicht nur konfiguriert wurde? Viertens – Datenpfad: Was hat Ihren Sicherheitsbereich verlassen und ist in ein Modell eines Drittanbieters gelangt? Wo wird es gespeichert, und ist das Training mit Ihren Daten vertraglich und technisch ausgeschlossen?Fünftens – Reproduzierbarkeit: Wenn sich ein Vorfall auf eine AI-unterstützte Änderung von vor Monaten zurückführen lässt, können Sie dann die Überprüfung rekonstruieren, durch die diese genehmigt wurde?

Der Fehler liegt darin, Audit-Fragen mit Demo-Antworten zu beantworten. „Unser Tool verfügt über eine Approval-Funktion“ ist eine Demo-Antwort. Die Audit-Antwort ist ein Log-Export mit namentlich genannten Reviewern, Zeitstempeln und Entscheidungen für eine Stichprobe realer Merges. „Der Anbieter sagt, er trainiere nicht mit unseren Daten“ ist eine Demo-Antwort; die Audit-Antwort besteht aus der unterzeichneten Klausel sowie dem Konfigurations-Screenshot und dem Verifizierungstest. Genau diese Lücke zwischen beiden soll das Begleitdokument zu diesem Leitfaden – die Audit-Readiness-Checkliste – schliessen, bevor es ein Prüfer tut.

3 · Menschliche Aufsicht: belastbare Gates gestalten

Die Aufsichtsbehörden fordern eine „menschliche Kontrolle“. Die Wirtschaftsprüfer verlangen etwas Strengeres: eine Kontrolle, die einer kritischen Überprüfung standhält. Ein belastbares Gate dokumentiert vier Elemente: die Identität des Reviewers, seine Kompetenz für diese Art von Änderung, Zeitpunkt und Gegenstand des Reviews sowie die Entscheidungsgrundlage. Entfernt man auch nur ein Element, wird aus „ein Mensch hat auf ‚Genehmigen‘ geklickt“ eine reine Formalität.

Die Einordnung folgt der Autonomie. Wo AI lediglich Vorschläge unterbreitet, trägt das übliche Code-Review-System die Last – vorausgesetzt, AI-gestützte Änderungen werden gekennzeichnet, damit die Prüfer wissen, was sie prüfen. Wo AI ausführt, müssen Kontrollpunkte technisch durchgesetzt werden: ein Branch-Protection-Mechanismus, der nicht umgangen werden kann, Pipeline-Regeln, die die Weitergabe ungeprüfter AI-Änderungen blockieren, sowie Batch-Gates mit definierter Stichprobenauswahl, wo eine vollständige Überprüfung nicht praktikabel ist. Das Prinzip, das dieses Modell belastbar macht: Die Stärke der Gates muss mit dem Autonomiegrad steigen, und die zugehörigen Nachweise müssen ohne grossen Zusatzaufwand verfügbar sein. Unser Modernisierungs-Framework ist das praktische Beispiel – jede von der AI ausgeführte Änderung wird an einem technisch durchgesetzten Gate gehalten, jede Genehmigung wird anhand eines Commit-SHA protokolliert.

4 · Nachweise und Rückverfolgbarkeit: vom Commit zum Audit-Trail

Nachweisführung ist eine Lieferkette: Entweder verläuft sie lückenlos von der ersten Analyse bis zum Produktions-Commit, oder sie existiert nicht, wenn man sie braucht. Die Glieder der Kette in der Reihenfolge: Verknüpfung mit dem Commit-SHA – Für jede AI-gestützte Änderung muss nachvollziehbar sein, welches Tool und welche Version sie vorgeschlagen haben, wer sie genehmigt hat und unter welcher Richtlinie dies geschah. Aufbewahrungsrichtlinie für Prompts und Responses — definiert, dokumentiert und bewusst begrenzt: Sie bewahren gerade so viel auf, dass Entscheidungen rekonstruiert werden können, und erstellen kein Schattenarchiv Ihrer Codebasis in den Chat-Protokollen; der Konflikt mit dem Datenschutz ist real, lösen Sie ihn daher durch Richtlinien und nicht durch Zufall. Architekturentscheidungen als Nachweis — ein Retrieval-only-Zugriff, bei dem Client-Code niemals als Trainingsmaterial dient, ist eine Kontrollmassnahme, die Sie nachweisen können, nicht nur behaupten. Prüfbare Artefakte – versionierte Analyseberichte (der Systembericht unseres Frameworks umfasst bei einer mittelgrossen Systemlandschaft etwa 194 Seiten) und ein exportierbares Audit-Paket, das ein Prüfer ohne begleitenden Workshop nachvollziehen kann.

Aufbewahrungsfristen sollten sich an Ihren bestehenden Zeitfenstern für Vorfälle und Audits orientieren, anstatt AI-spezifische zu erfinden – wenn Ihr Unternehmen einen Produktionsvorfall von vor drei Jahren untersuchen kann, müssen Ihre AI-Nachweise ebenso weit zurückreichen. Und protokollieren Sie bewusst, nicht maximal: Jedes Artefakt, das Sie aufbewahren, ist auch ein Artefakt, das Sie schützen, offenlegen und schliesslich löschen müssen.

5 · Datenresidenz und Vendor Governance (CH/EU)

Der Datenaufenthaltsort ist eine architektonische Eigenschaft und kein Absatz in den FAQ eines Anbieters. Für beaufsichtigte Schweizer Institute sind die praktikablen Optionen konkret: Verarbeitung des Modelldatenverkehrs in der Schweiz bzw. der EU-Region, vertraglicher und technischer Ausschluss des Trainings mit Ihren Daten sowie festgelegte Aufbewahrungsfristen für alle Daten, mit denen der Anbieter in Berührung kommt. Die Klauseln, auf die es in Vereinbarungen mit Modellanbietern tatsächlich ankommt, lassen sich kurz zusammenfassen: Training Exclusion (verifiziert – eine Konfiguration, die Sie per Screenshot dokumentieren können, keine Marketingseite), Retention & Deletion (was wird zwischengespeichert, wo und wie lange), Subprocessor-Transparenz (wer sieht den Datenverkehr noch, unter welcher Rechtsordnung), und – sofern DORA Sie über EU-Kunden betrifft – Audit- und Exit-Rechte , die es Ihnen ermöglichen, mit intakten Nachweisen auszusteigen.

Dann der ehrliche Satz, den die meisten Anbieter in ihren Präsentationen auslassen: Der regulierte Stack ist mit einem Kostenaufschlag verbunden. Standort in der Schweiz/EU, dedizierte Kapazität, erweiterte Protokollierung und vertraglich festgelegte Prüfungsrechte kosten mehr als der Standardweg über Hyperscaler – und das ist deutlich zu erkennen. Planen Sie diesen Aufschlag explizit im Budget ein und verteidigen Sie ihn als das, was er ist: der Preis dafür, den Aufsichtsbehörden mit Konfigurationsexporten statt mit Entschuldigungen zu antworten. Das ist weitaus günstiger als die Alternative – nämlich mitten in einem Audit festzustellen, dass Ihre Bereitstellungspipeline Kundencode über einen nicht nachverfolgten Unterauftragsverarbeiter leitet.

6 · Das Compliance-Betriebsmodell

Governance versagt an den Schnittstellen zwischen den Rollen – legen Sie diese Schnittstellen daher bewusst fest. Eine funktionierende Aufteilung: Das Engineering verantwortet die technische Umsetzung der Kontrollen – Gates, Tagging und die Erzeugung von Nachweisen –, da von aussen aufgesetzte Kontrollen unter Termindruck umgangen werden. Der CISO ist für den Kontrollkatalog und dessen Überprüfung verantwortlich: Welche Gates müssen vorhanden sein, wie werden sie getestet und welches Stichprobenverfahren gilt? Der Bereich Risiko/Compliance ist für die Klassifizierung und die Schnittstelle zur Aufsichtsbehörde zuständig: Welche Anwendungen gehören zu welcher Risikoklasse, was wird gemeldet und wie lautet der Prüfbericht? Anbieter und Lieferpartner sind vertraglich verpflichtet, Nachweise in Ihrem Format zu liefern – ihre Bescheinigung ist ein Beitrag zu Ihrer Dokumentation, niemals ein Ersatz dafür.

Geben Sie dem System einen Rhythmus, sonst verfällt es: vierteljährliche Aktualisierung der Nachweise (Bestandsaufnahme, Klauseln, Konfigurationen erneut überprüft), regelmässige Stichproben der Gate-Protokolle durch jemanden, der die Gates nicht erstellt hat, und einen festen Termin, bei dem Engineering und Compliance anstehende Änderungen an AI-Tools vor der Einführung prüfen, statt erst nach deren Entdeckung. Durch dieses letzte Ritual entgeht die Compliance zudem der „Department-of-No“-Falle – wird sie frühzeitig einbezogen, prägt sie den Prozess; wird sie erst spät einbezogen, kann sie nur noch blockieren. Das Endziel, für das sich dieser Leitfaden einsetzt: Compliance ist ein Delivery-Feature. Entwickeln Sie für Audits, nicht nur für Demos – dann wird das Audit zur Formalität statt zum Projekt.

7 · Häufig gestellte Fragen