In den meisten KI-Projekten werden die Bereiche Governance und Testing getrennt voneinander behandelt. Die Dokumentation ist durch Compliance vorgeschrieben. Das Testing validiert das Modell. Kaum jemand verknüpft jedoch beide Bereiche. Die Frage, die wir häufig hören, lautet nicht, ob die Governance-Schicht geprüft werden muss. Sie lautet: „Wer soll das übernehmen und wie, ohne von null einen parallelen Prozess aufzubauen?”
Unsere Antwort ist dieselbe wie beim KI-Testing generell: Die meisten Voraussetzungen sind wahrscheinlich schon vorhanden.
In der Regel wird die technische Seite des KI-Einsatzes ernst genommen. Genauigkeit wird gemessen. Die Sicherheit wird getestet. Die Performance wird getestet. Wenn man jedoch fragt, was getan wurde, um zu prüfen, ob die Governance-Schicht tatsächlich funktioniert, lautet die Antwort fast immer gleich: Sie wurde dokumentiert.
Dokumentation ist jedoch nicht dasselbe wie Verifikation. Eine vor dem Go-live erstellte Risikobewertung sagt beispielsweise nichts darüber aus, ob das Risikomanagement-System sechs Monate später noch aktiv war. Eine Richtlinie, die menschliche Aufsicht beschreibt, sagt nichts darüber aus, ob sie je angewendet wurde. Eine Datenschutz-Folgenabschätzung (DSFA) sagt nichts darüber aus, ob die darin beschriebenen Datenkontrollen im Live-System tatsächlich greifen.
Dies ist vertrautes Terrain für Qualitätsfachleute. In Produktionsumgebungen dokumentiert man nicht, dass ein Sicherheitsmechanismus funktioniert. Man testet ihn unter realen Bedingungen und hält das Ergebnis fest. Ein Governance-Dokument ist eine Absichtserklärung. Ein Testergebnis ist eine Tatsachenaussage. Genau auf diesen Raum zwischen diesen beiden Aspekten sind Qualitätsteams geschult.
Gemäß Artikel 14 des EU AI Acts muss eine wirksame menschliche Aufsicht über Hochrisiko-KI-Systeme gewährleistet sein. Das Wort „wirksam“ trägt dabei das gesamte Gewicht. Es geht nicht um eine Rollenzuweisung oder eine unterzeichnete Verfahrensanweisung. Vielmehr muss nachgewiesen werden, dass der Aufsichtsmechanismus funktioniert, wenn er gebraucht wird.
Dies in eine Testfrage zu übersetzen, ist einfach: Kann die verantwortliche Person tatsächlich sehen, was das System tut? Versteht sie, was sie sieht? Kann sie eingreifen, übersteuern oder das System stoppen, wenn etwas schiefgeht? Gibt es ein Protokoll, das belegt, dass dies in der Praxis geschieht – und nicht nur, dass die Fähigkeit dazu auf dem Papier existiert?
Stellen Sie sich ein Hochrisikosystem mit einer Human-in-the-Loop-Kontrolle vor. Auf dem Papier ist die Aufsicht vorhanden. Es gibt eine namentlich benannte Prüfperson, einen dokumentierten Eskalationspfad und eine Verfahrensanweisung, nach der ein Mensch markierte Entscheidungen freigibt. Dann sucht man nach Belegen. Die Prüfperson wurde jedoch nie geschult, wie ein Problemfall aussieht. Das Überschreiben wurde nie genutzt und das Aufsichtsprotokoll ist leer. Aus Dokumentationssicht ist die Pflicht jedoch erfüllt. Aus Testsicht wurde jedoch nichts geprüft. Die Kontrolle hat als Dokument bestanden, als Kontrolle jedoch versagt.
Das passiert, weil der Testumfang üblicherweise rund um funktionale und nicht-funktionale Anforderungen definiert wird und Governance-Pflichten als Problem anderer enden. Niemand bildet Artikel 14 auf einen Testfall ab. Diese Verknüpfung herzustellen, ist nicht schwierig. Sie muss nur bewusst hergestellt werden.
Sobald man akzeptiert, dass Governance getestet werden kann, ist der Ansatz vertraut: Zunächst werden Pflichten identifiziert und definiert, anschließend wird überprüft, ob sie funktionieren. Genauso wie bei jeder anderen Systemanforderung.
Artikel 9 verlangt ein Risikomanagementsystem, das über den gesamten Lebenszyklus des Systems hinweg aktiv bleibt und nicht nur zum Zeitpunkt des Go-Live. Mithilfe eines Tests kann überprüft werden, ob
das Risikoregister seit dem letzten Modellupdate überprüft wurde,
für identifizierte Risiken Maßnahmen dokumentiert sind und
das, was in der Produktion läuft, noch dem entspricht, was die Risikobewertung abdeckt.
Artikel 12 verlangt eine automatische Protokollierung von Ereignissen während des Betriebs. Ein Test kann prüfen, ob die Protokolle vorhanden sind, ob sie genügend Details enthalten, damit eine Behörde eine Entscheidung nachvollziehen kann, und ob sie nachträglich verändert werden können. Ein bearbeitbares Protokoll ist kein zuverlässiger Nachweis, unabhängig davon, wie es bezeichnet wird.
Die Fairness-Pflichten gemäß Artikel 10 verlangen, dass Trainings- und Testdaten repräsentativ sind und Ausgaben geschützte Gruppen nicht unterschiedlich behandeln. Bias- und Fairness-Testing sind in den meisten seriösen KI-Testing-Programmen bereits integriert. Wenn man es jedoch explizit mit der regulatorischen Pflicht verknüpft, verändert sich, wie Ergebnisse dokumentiert werden und was als bestanden gilt.
All das macht Test-Teams jedoch nicht zu Compliance-Juristen. Es bedeutet lediglich ein Gespräch zu Beginn des Projekts: Welche Pflichten gelten? Wie sieht „Bestanden” im Detail aus? Wo werden die Nachweise aufbewahrt?
Bevor ein Hochrisiko-KI-System gemäß dem EU AI Act in Betrieb genommen werden kann, muss es eine Konformitätsbewertung durchlaufen. Für diese Bewertung sind echte operative Nachweise erforderlich, nicht nur Richtlinien und Pläne. Die technische Dokumentation ist kein Dokument, das man einmal erstellt und dann ablegt. Sie ist ein dynamisches Verzeichnis, das über den gesamten Lebenszyklus des Systems hinweg aktuell gehalten werden muss.
Die Fristen haben sich kürzlich verschoben. So gelten die Hochrisiko-Pflichten nun ab Dezember 2027 für eigenständige Systeme und ab August 2028 für in regulierte Produkte eingebettete Systeme. Es lohnt sich, die Gründe für die Verschiebung der Fristen zu benennen: Die Teile des Gesetzes, die sich mit Testing, Dokumentation und Bewertung befassen, waren laut ursprünglichem Zeitplan am schwersten umzusetzen. Die Anforderungen wurden jedoch nicht abgeschwächt. Das Zeitfenster für die Vorbereitung wurde lediglich verlängert.
Dieses Zeitfenster bietet Chancen, gleichzeitig ist es aber kein Grund, zu warten. Es ist die Zeit, in der die Nachweisbasis aufgebaut werden kann, während das System noch entwickelt wird, statt sie später rekonstruieren zu müssen, wenn die benötigten Aufzeichnungen nie erstellt wurden. Teams, die diese Gewohnheiten frühzeitig entwickeln, müssen deutlich weniger reaktiven Aufwand betreiben und sind bei Fristablauf in einer erheblich stärkeren Position.
Die Governance-Schicht zu testen ist kein eigenständiges Fachgebiet, das einen Neuanfang erfordert. Es handelt sich um strukturiertes Qualitätsdenken, das auf eine neue Klasse von Pflichten angewendet wird. Wer KI-Governance von Beginn an in den Testumfang von der Definition of Done über die Teststrategie bis hin zum Monitoring-Plan einbezieht, bei dem entstehen die Nachweise als natürliches Nebenprodukt der Entwicklung. So hört eine Governance-Aussage auf, eine Absichtserklärung zu sein, und wird zur Tatsache.
Sind Sie bereit, KI-Governance in Ihren Testprozess zu integrieren und die Chancen zu nutzen?
Sprechen Sie uns einfach an! Wir beraten Sie gern und übernehmen die strukturierte Umsetzung der Governance-Pflichten aus dem EU AI Act in Ihre Teststrategie.