Wenn ein QA-Team einer Bank KI-gestützte Testwerkzeuge evaluiert, beginnt das Gespräch tendenziell mit denselben Fragen, die jedes Ingenieurteam stellen würde: Wie viele Testfälle generiert es, wie genau ist die Generierung, wie gut ist die Testwartung, welche Frameworks werden unterstützt? Das sind berechtigte Fragen. Sie sind jedoch der falsche Ausgangspunkt, da sie das Problem der KI-gestützten Qualitätssicherung in einem regulierten Finanzinstitut so behandeln, als wäre es dasselbe Problem wie die KI-gestützte Qualitätssicherung in einem SaaS-Startup. Das ist es nicht.
Der Unterschied liegt nicht im zu testenden Code, sondern darin, was nach dem Ausführen der Tests geschieht. Für das QA-Team eines Start-ups reicht es aus zu wissen, ob die Software funktioniert. Für eine Bank birgt dieselbe Frage eine zusätzliche Anforderung – den Nachweis gegenüber Vorgesetzten, Prüfern und – während der DORA-Umsetzungsphase, die 2026 begann – gegenüber zuständigen nationalen Behörden, die nun aktiv prüfen, ob die Programme für Resilienztests Beweise liefern, die einer behördlichen Prüfung standhalten.
Diese Unterscheidung ist das, worum sich Qualigentic aufgebaut hat. Nicht als generisches KI-Testwerkzeug mit einem nachträglich angefügten Compliance-Modul, sondern als eine Plattform, die von Anfang an für die spezifischen Einschränkungen der Qualitätssicherung in regulierten Branchen konzipiert wurde. Um zu verstehen, was das bedeutet, muss man präzise darlegen, was generische KI-Testwerkzeuge tatsächlich leisten, wo sie gut funktionieren und wo die Architektur einer regulierten Institution Anforderungen schafft, für deren Erfüllung sie nie konzipiert wurden.
Es wäre ungenau und wenig hilfreich, Werkzeuge wie GitHub Copilot, Testim oder KI-gestützte Testfunktionen in universellen Entwicklungsplattformen zu ignorieren. Sie lösen reale Probleme für Entwicklungsteams und das tun sie gut in Kontexten, in denen diese Probleme im Vordergrund stehen.
Testgenerierung und -wartung
Die Kernkompetenz der meisten KI-Testtools ist die Testgenerierung aus Code oder Spezifikation. Anhand einer Funktionssignatur, einer Klassenstruktur oder einer natürlichsprachlichen Beschreibung des erwarteten Verhaltens können diese Tools Testfälle schneller und systematischer generieren, als ein menschlicher Ingenieur, der Tests von Grund auf schreibt. Sie decken Grenzbedingungen ab, die leicht übersehen werden, erzeugen konsistente Testmuster im gesamten Codebestand und reduzieren den Zeitaufwand für ein grundlegendes Abdeckungsniveau. Für Teams, die zu wenig testen – was auf die meisten Ingenieurteams zutrifft –, ist dies daher eine echte und wesentliche Verbesserung.
Eine sekundäre Fähigkeit ist die Unterstützung bei der Testwartung: Erkennen, wann eine Codeänderung einen Test veraltet gemacht hat, Aktualisierungen vorschlagen, Tests kennzeichnen, die möglicherweise nicht mehr das testen, was sie zu testen scheinen. Capgemini's World Quality Report 2025-26 stellt fest, dass in den meisten Unternehmen 60–70% des QA-Aufwands für die Pflege bestehender Tests aufgewendet wird, anstatt neue Tests zu erstellen. Folglich setzt jedes Tool, das diesen Aufwand verringert, erhebliche technische Kapazitäten frei, und mehrere KI-Testtools leisten dies recht gut.
Was diese Werkzeuge jedoch nicht leisten konnten, war die Erstellung einer strukturierten, nachvollziehbaren und prüffähigen Aufzeichnung, die jeden Test mit der spezifischen regulatorischen Anforderung verknüpft, der er gerecht wird, mit unterzeichneten Ausführungsprotokollen, rollenbasierter Zugriffskontrolle, wer Ergebnisse genehmigen kann, und konfigurierbaren Aufbewahrungsrichtlinien, die den regulatorischen Verpflichtungen der Institution entsprechen. Das ist kein fehlendes Feature. Es ist eine völlig andere Produktkategorie.
Wo die Architektur regulierter Institutionen die Anforderungen ändert
Es gibt zwei strukturelle Einschränkungen in regulierten Finanzinstituten, die die Anforderungen an die Testinfrastruktur für KI neu gestalten. Die erste ist die Datengrenze. Das zweite ist das Format der Nachweise.
Das Problem des Drittanbieterrisikos, das Cloud-basierte QA-Tools im Rahmen der DORA schaffen
Im Januar 2026 bestätigte die deutsche BaFin durch unverbindliche Leitlinien, dass KI-Systeme, die bei Finanzinstituten eingesetzt werden – einschließlich Tools für Tests und Qualitätssicherung –, unter den DORA-Rahmen für die ICT-Governance fallen. Dies hat direkte Auswirkungen auf jede Bank oder Versicherung, die im Rahmen ihres DORA-Resilienztestprogramms eine cloudbasierte KI-Testplattform evaluiert.
Unter DORA Artikel 28–31 müssen IKT-Dienstleister, die kritische Funktionen unterstützen, formell verwaltet werden: Kritikalität wird bewertet, vertragliche Anforderungen, die den Spezifikationen der Verordnung entsprechen, werden festgelegt, und die Überwachung erfolgt kontinuierlich. Folglich ist ein Cloud-basiertes KI-Testtool, das testbezogene Daten von Systemen verarbeitet, die kritische Funktionen unterstützen, unter diesem Rahmen ein IKT-Drittanbieter, der eine formelle Verwaltung erfordert. Die Institution, die das Tool zur Verbesserung ihrer DORA-Konformität eingeführt hat, hat gleichzeitig einen neuen DORA-Risikoeintrag für Drittanbieter geschaffen, der verwaltet werden muss.
On-Premise-Bereitstellung löst nicht nur das Problem des Datenperimeters. Sie beseitigt eine Abhängigkeit von einem Drittanbieter für IKT, die andernfalls gemäß Artikel 28–31 der DORA verwaltet, vertraglich geregelt und überwacht werden müsste.
Dies ist keine hypothetische Sorge für zukünftige aufsichtsrechtliche Überprüfungen. Es ist eine Lücke in der Unternehmensführung, die ab dem Zeitpunkt der Einführung des Tools besteht und.
Wie der Vergleich in der Praxis aussieht
Anstatt eines Funktionsvergleichs, der abstrahiert, wie diese Werkzeuge tatsächlich verwendet werden, ist es nützlicher, die spezifischen Szenarien zu beschreiben, in denen die Wahl zwischen einem generischen KI-Testwerkzeug und einem Compliance-orientierten zu unterschiedlichen Ergebnissen führt.
Im Szenario der Aufsichtsüberprüfung steht ein Team, das ein generisches KI-Testwerkzeug verwendet, vor einem Problem der Zusammenstellung: Es müssen Datensätze aus CI/CD-Protokollen extrahiert, mit Anforderungen aus einem separaten System abgeglichen, die Freigabe aus einem separaten Genehmigungsworkflow bestätigt und das Ergebnis in einem Format präsentiert werden, das die spezifische Frage des Vorgesetzten beantwortet. Die Informationen mögen alle vorhanden sein. Sie existieren jedoch in mehreren Systemen und in Formaten, die für den Entwicklungsbetrieb und nicht für die regulatorische Einreichung bestimmt sind. Die Zusammenstellung selbst ist ein Risiko – unvollständige, verspätete oder inkonsistent formatierte Nachweise stellen eine Compliance-Lücke dar, unabhängig davon, ob die zugrunde liegenden Tests solide waren.
Das Problem der Klassifizierung von Zwischenfällen
Im Szenario der Vorfallklassifizierung setzt das anfängliche Benachrichtigungsfenster von 4 Stunden gemäß den Meldepflichten der DORA voraus, dass die Einrichtung die Art und den Umfang des Vorfalls schnell ermitteln kann, einschließlich der Frage, ob das betroffene System kürzlich getestet wurde und was diese Tests gezeigt haben. Ein Team, dessen Testaufzeichnungen über Entwicklungswerkzeuge verteilt sind und manuell zusammengestellt werden müssen, hat keine 4 Stunden für die Abfrage übrig.
Was Qualigentic nicht ist
Präzision darüber, was ein Werkzeug leistet, erfordert gleiche Präzision darüber, was es nicht leistet. Qualigentic ist kein Ersatz für das technische Urteilsvermögen, das Qualitätssicherung in komplexen Systemen erfordert. Es weiß nicht, welche Fehlermodi für das Risikoprofil einer bestimmten Institution am wichtigsten sind. Es interpretiert keine regulatorischen Anforderungen und bestimmt nicht, welche IKT-Systeme gemäß DORA kritische Funktionen unterstützen. Es ersetzt nicht die Domänenexpertise von QS-Teams, die verstehen, wie die Systeme ihrer Institution unter Bedingungen funktionieren, für die kein automatisiertes System trainiert wurde, diese vorherzusehen.
Die Frage, die die Wahl klärt
Wenn wir mit QA-Leads und CTOs in regulierten Institutionen über Qualigentic sprechen, ist die Konversation, die am meisten Klarheit schafft, kein Feature-Vergleich. Es ist diese: Wenn bei Ihrer nächsten aufsichtsrechtlichen Prüfung Nachweise für die Resilienztests Ihrer drei kritischsten IKT-Systeme verlangt werden, was werden Sie vorweisen können und wie lange wird es dauern, diese vorzulegen?
Die Infrastrukturlücke hinter der Testlücke
Wenn die Antwort Vertrauen beinhaltet – eine strukturierte Aufzeichnung, die innerhalb von Minuten abrufbar ist, mit einer ununterbrochenen Kette von der Anforderung bis zum unterzeichneten Ausführungsprotokoll –, dann ist die aktuelle Infrastruktur wahrscheinlich ausreichend. Wenn die Antwort jedoch Unsicherheit darüber beinhaltet, wo sich die Aufzeichnungen befinden, ob sie vollständig sind oder ob sie das Format erfüllen, das ein Vorgesetzter erwartet, dann liegt die Lücke nicht im Testen selbst. Sie liegt in der Infrastruktur, die das Testen umgibt – der Ebene, die Aufzeichnungen von Entwicklungsqualität in Beweise von regulatorischer Qualität umwandelt.
Das ist keine Lücke, die ein besseres generisches KI-Testtool schließt. Vielmehr erfordert es eine Infrastruktur, die für die spezifischen Anforderungen einer regulierten Institution entwickelt wurde – mit On-Premise-Bereitstellung, Compliance-orientierten Evidenzkettchen und RBAC-gesteuerten Freigabeworkflows, die in die Architektur integriert sind und nicht nachträglich hinzugefügt werden.
Die Wahl zwischen Werkzeugen hängt nicht davon ab, welches mehr Testfälle generiert. Es geht darum, welches Beweise liefert, die eine Aufsichtsprüfung überstehen. In regulierten Branchen sind dies unterschiedliche Produkte.
