Seit dem 17. Januar 2025 ist der EU Digital Operational Resilience Act (DORA) für Finanzunternehmen verbindlich anwendbar (ECB, 2025). Gleichzeitig verschärft die FINMA mit dem Rundschreiben 2023/1 seit dem 1. Januar 2024 die Erwartungen an ICT-Risiken und operationelle Resilienz (Grant Thornton, 2024). Für Banken bedeutet das: Testen ist keine reine Engineering-Frage mehr, sondern ein Nachweis gegenüber dem Regulator. Wer in diesem Umfeld automatisiert testet, braucht mehr als grüne Pipelines. Er braucht Nachvollziehbarkeit.

Kurz gefasst: In regulierten Banken muss Testautomatisierung zwei Dinge gleichzeitig leisten: schneller und stabiler testen, und jeden Test als prüfbaren Nachweis dokumentieren. DORA und FINMA verlangen wiederkehrende Resilienz-Tests und lückenlose Nachvollziehbarkeit. KI hilft beim Tempo, erzeugt aber neue Audit-Fragen, die eine Plattform beantworten muss.

Warum regulierte Banken ein anderes Spielfeld sind

In einem normalen SaaS-Team entscheidet die Testabdeckung über die Produktqualität. In einer Bank entscheidet sie zusätzlich über die regulatorische Position. DORA verlangt von Finanzunternehmen ein dokumentiertes, wiederkehrendes Resilienz-Testprogramm; bedeutende Institute müssen mindestens alle drei Jahre ein bedrohungsgeführtes Penetration-Testing (TLPT) nach dem TIBER-EU-Rahmen durchführen, und ab dem dritten Test extern testen lassen (EBA, 2024).

Dazu kommt der EU AI Act, der am 1. August 2024 in Kraft getreten ist und schrittweise greift: verbotene Praktiken seit Februar 2025, die meisten Hochrisiko-Pflichten ab August 2026 (Europäische Kommission). Sobald KI Tests schreibt oder repariert, wird die Frage relevant, wie diese KI-Komponente selbst einzuordnen ist.

Die FINMA wiederum behandelt Auslagerungen wesentlicher Funktionen, inklusive Public Cloud, weiterhin als eines der wichtigsten operationellen Risiken. Rund eines von fünf beaufsichtigten Instituten lagert bereits wesentliche Daten oder Funktionen an Public-Cloud-Anbieter aus (FINMA, 2024). Wo Testumgebungen und Testwerkzeuge laufen, ist damit selbst eine regulatorische Entscheidung.

Was auf dem Spiel steht: die Kosten von Testlücken

Die Folgen unzureichender Tests sind in der Finanzbranche teuer und öffentlich. Die gescheiterte IT-Migration von TSB im Jahr 2018 störte den Betrieb für einen Grossteil der 5,2 Millionen Kunden; der Normalbetrieb war erst im Dezember 2018 wiederhergestellt. Im Dezember 2022 verhängten FCA und PRA eine gemeinsame Strafe von 48,65 Millionen Pfund, dazu kamen 32,7 Millionen Pfund Kundenentschädigung (FCA, 2022).

Auch im laufenden Betrieb summieren sich Ausfälle. Laut dem Observability Forecast für Finanzdienstleister kosten hochkritische IT-Ausfälle Finanzunternehmen im Schnitt 1,8 Millionen US-Dollar pro Stunde; 29 Prozent der Befragten berichten mindestens wöchentlich von hochkritischen Ausfällen (New Relic, 2026).

Dahinter steht ein altbekanntes Muster: Je später ein Fehler entdeckt wird, desto teurer wird er. Das oft zitierte Modell des IBM Systems Sciences Institute beziffert die relative Behebungskostenkurve von rund 1x im Design bis zum 60- bis 100-Fachen nach dem Release (Functionize). Die genauen Faktoren sind umstritten und stammen aus älteren Quellen, doch die Richtung ist unbestritten: Früh testen senkt nicht nur Kosten, es senkt auch die Wahrscheinlichkeit jener operationellen Resilienz-Vorfälle, die zu Strafen wie bei TSB führen.

Manuelles Testen skaliert nicht für regulierte Release-Zyklen

DORA verlangt kein einmaliges Audit, sondern ein laufendes Programm: jährliche Basis-Tests plus periodisches TLPT für bedeutende Institute (ECB, 2025). Bei modernen Release-Frequenzen lässt sich diese Erwartung manuell kaum erfüllen, ohne dass die Testorganisation zum Engpass wird.

Gleichzeitig bindet schon der Unterhalt bestehender Tests einen grossen Teil der Kapazität. Branchenanalysen verorten den Wartungsaufwand bei rund 40 Prozent der QA-Zeit, und der Anteil der Teams mit instabilen Tests steigt (diese Zahlen stammen aus Sekundärquellen geringerer Belastbarkeit und sind als Richtwert zu lesen). Verlässlicher ist der World Quality Report 2024-25: 68 Prozent der Organisationen nutzen generative KI im Quality Engineering oder haben sie nach erfolgreichen Pilotprojekten eingeplant, und 72 Prozent berichten von beschleunigter Automatisierung durch KI (Capgemini, 2024).

Die Botschaft ist klar: Banken brauchen mehr Testabdeckung, nicht mehr Testpersonal. Genau hier setzt KI-gestützte Testautomatisierung an, indem aus einer Anforderung oder einem Jira-Ticket ein ausführbarer Test wird, ohne manuelles Skripten.

KI-gestützte Testautomatisierung, aber auditierbar

Der schwierige Teil ist nicht das Tempo, sondern die Prüfbarkeit. Sobald eine KI Tests generiert oder via Self-Healing repariert, entsteht ein nicht-deterministischer Akteur in der Validierungskette. Sowohl FINMA 2023/1 als auch DORA verlangen aber Nachvollziehbarkeit von Änderungen. Die entscheidende Frage lautet deshalb: Wer testet den KI-Tester?

In einem regulierten Umfeld müssen KI-generierte Tests dieselben Eigenschaften erfüllen wie jeder andere prüfbare Artefakt:

• Menschliche Freigabe: Jeder KI-Vorschlag wird von einer Person bestätigt, statt blind ausgeführt. Human-in-the-Loop ist hier keine Komfort-Funktion, sondern ein Audit-Erfordernis.

• Versionierung und Exportierbarkeit: Tests müssen versionierbar, lesbar und exportierbar sein, ohne proprietäres Format. Nur so bleibt nachvollziehbar, was wann warum getestet wurde.

• Selbstheilende, aber dokumentierte [Locators](/features/self-healing): Wenn sich die UI ändert und Locators automatisch stabilisiert werden, muss diese Anpassung protokolliert werden, nicht im Hintergrund verschwinden.

• Lückenloser Audit-Trail: Jede Änderung an einem Test gehört in dieselbe Change-Management-Kette wie jede andere regulatorisch relevante Änderung.

So wird aus dem vermeintlichen Risiko KI ein Compliance-Vorteil: Die Tests werden schneller erstellt und bleiben trotzdem ein belastbarer Nachweis im DORA-Resilienzprogramm.

On-Premise und Datenresidenz als Compliance-Feature

Ein verbreiteter Irrtum lautet, Testumgebungen und Testdaten seien weniger heikel als die Produktion. Die EDPB-Leitlinien 01/2025 stellen klar, dass pseudonymisierte Daten weiterhin als Personendaten gelten und vollständig der DSGVO unterliegen (EDPB, 2025). Wer Produktionsdaten in Testumgebungen kopiert, nimmt also die vollen Residenz- und Sicherheitspflichten mit, inklusive jeder KI, die diese Daten verarbeitet.

Kombiniert mit dem Fokus der FINMA auf Cloud-Konzentrationsrisiken wird klar, warum die Bereitstellung zählt. Eine cloudbasierte KI-Testplattform ist aus Sicht der FINMA eine Auslagerungsentscheidung nach den Rundschreiben 2018/3 und 2023/1. Eine On-Premise- oder datenresidente Variante ist deshalb kein bloss technisches Detail, sondern ein Compliance-Merkmal. Für Schweizer Banken kann genau das den Ausschlag geben, ob eine Plattform überhaupt in Frage kommt.

Was eine audit-fähige Plattform leisten muss

Wer Testautomatisierung für eine regulierte Bank evaluiert, sollte über grüne Dashboards hinausschauen und auf folgende Eigenschaften achten:

• Tests aus natürlicher Sprache, Recorder oder Spezifikation, damit Fachbereich und Engineering gemeinsam an visuellen Test-Workflows arbeiten.

• Self-Healing für stabile Tests trotz UI-Änderungen, mit protokollierter Anpassung statt Blackbox.

• Human-in-the-Loop-Freigabe für jeden KI-generierten Schritt.

• Exportierbarer, versionierbarer Code ohne Lock-in, sodass bestehende Playwright- oder Selenium-Bestände erhalten bleiben.

• Eine Plattform für Web, Mobile, API und Desktop statt vier getrennter Werkzeuge.

• Wahlweise Cloud oder On-Premise, mit rollenbasiertem Zugriff und Audit-Trail.

Genau auf diese Anforderungen ist Autemos ausgelegt: KI-Tempo bei der Testerstellung, Stabilität durch Self-Healing und die Nachvollziehbarkeit, die ein regulierter Betrieb braucht.

Regulatorische Anforderungen im Überblick

Häufig gestellte Fragen

Macht KI im Testing die Compliance schwieriger?

Nicht zwingend. KI wird zum Problem, wenn sie als Blackbox arbeitet. Mit menschlicher Freigabe, Versionierung und einem Audit-Trail wird ein KI-generierter Test zu einem prüfbaren Nachweis, der DORA- und FINMA-Erwartungen an Nachvollziehbarkeit erfüllt.

Müssen wir wegen DORA unsere bestehenden Tests wegwerfen?

Nein. Bestehende Playwright-, Selenium- und Appium-Bestände lassen sich weiter nutzen. Entscheidend ist, dass die Tests exportierbar und versionierbar bleiben und in ein dokumentiertes, wiederkehrendes Testprogramm eingebettet sind.

Warum ist On-Premise für Banken relevant?

Weil Testdaten auch pseudonymisiert als Personendaten gelten und die FINMA Cloud-Auslagerungen als wesentliches operationelles Risiko behandelt. Eine On-Premise- oder datenresidente Bereitstellung reduziert Auslagerungs- und Residenzrisiken.

Was bedeutet Self-Healing für die Auditierbarkeit?

Self-Healing stabilisiert Tests automatisch, wenn sich die UI ändert. In einem regulierten Umfeld muss jede solche Anpassung protokolliert werden, damit sie Teil der Change-Management-Kette bleibt und nicht unsichtbar im Hintergrund passiert.

Fazit

Für regulierte Banken ist Testautomatisierung zur Schnittstelle zwischen Engineering und Regulator geworden. DORA und FINMA verlangen wiederkehrende, dokumentierte Tests; der AI Act und die DSGVO ziehen klare Grenzen für KI und Daten. Eine Plattform, die KI-Tempo mit Human-in-the-Loop, Self-Healing, exportierbarem Code und On-Premise-Option verbindet, macht aus dieser Pflicht einen Vorteil. Sehen Sie sich in einer kurzen Demo an, wie Autemos audit-fähige Testautomatisierung in der Praxis umsetzt.