EU AI Act: Wenn KI im Spiel ist, wird der Nachweis zur Pflicht

Wer KI in ein Produkt oder einen Geschäftsprozess einbaut, kennt die Diskussion: Funktioniert es? Meistens ja. Die Frage, die der AI Act stellt, ist eine andere. Sie lautet: Können Sie zeigen, dass es geprüft wurde, wie tief, mit welchem Ergebnis und mit welchem Restrisiko? Ein Modell, das im Demo-Termin überzeugt, ist damit noch kein zulässiges System. Prüfbarkeit und Nachweis sind keine Kür mehr, sie sind Bestandteil der Rechtspflicht.

Was seit wann gilt

Die Verordnung (EU) 2024/1689 ist am 1. August 2024 in Kraft getreten und seit dem 2. August 2026 anwendbar. Am 27. Juli 2026 ist eine Änderungsverordnung in Kraft getreten, der sogenannte AI Omnibus, die einen Teil der Fristen verschiebt. Der Stand nach diesen Änderungen:

Warum die Verschiebung kein Grund zum Zurücklehnen ist

Sechzehn zusätzliche Monate klingen nach Luft. Sie sind es nicht, und zwar aus einem sehr praktischen Grund: Die geforderten Nachweise entstehen während der Entwicklung, nicht danach. Wer im Herbst 2027 anfängt, Belege zu sammeln, stellt fest, dass die Daten von damals fehlen, die Testläufe nicht dokumentiert sind und niemand mehr weiß, warum eine bestimmte Schwelle so gewählt wurde. Ein Risikomanagement, das über den ganzen Lebenszyklus laufen soll, lässt sich nicht rückwirkend führen.

Dazu kommt: Die Verbote und die Transparenzpflichten gelten bereits. Artikel 50 des AI Act gilt seit dem 2. August 2026. Die Transparenzpflichten unterscheiden sich nach Rolle und Use Case. Für Betreiber generativer KI-Systeme gilt eine Kennzeichnungspflicht für KI-generierte oder manipulierte Texte, wenn diese veröffentlicht werden, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren. Wurde ein Text von fachkundigen Personen inhaltlich geprüft oder redaktionell kontrolliert und trägt eine Person oder Organisation die redaktionelle Verantwortung, muss dieser veröffentlichte Text nach den Leitlinien der Europäischen Kommission nicht allein wegen seiner KI-Unterstützung gekennzeichnet werden.

Was der AI Act inhaltlich verlangt

Vorweg die Abgrenzung, weil sie oft untergeht: Der AI Act gilt für KI-Systeme, nicht für Software allgemein. Die Pflichten sind nach Rolle und Risikoklasse gestuft. Am umfangreichsten sind sie für Hochrisiko-Systeme; daneben stehen die Verbote, die Transparenzpflichten des Artikels 50 und eigene Regeln für KI-Modelle mit allgemeinem Verwendungszweck. Eine allgemeine Pflicht, Software oder Services zu testen, enthält die Verordnung nicht.

Für Hochrisiko-Systeme steht in Kapitel III der Verordnung eine Liste von Anforderungen, die sich fast wörtlich in die Sprache des Testmanagements übersetzen lässt:

• Artikel 9, Risikomanagementsystem: ein fortlaufender Prozess über den gesamten Lebenszyklus, nicht eine einmalige Einschätzung. Er enthält die eigentliche Testpflicht, dazu gleich mehr.
• Artikel 10, Daten und Daten-Governance: Anforderungen an die Datensätze für Training, Validierung und Test.
• Artikel 11, technische Dokumentation: Sie muss vorliegen, bevor das System in Verkehr kommt.
• Artikel 12, Aufzeichnungspflichten: Das System muss Ereignisse protokollieren.
• Artikel 13, Transparenz gegenüber Betreibern: eine Gebrauchsanweisung, mit der ein Betreiber das System überhaupt beurteilen kann.
• Artikel 14, menschliche Aufsicht: Das System muss so gebaut sein, dass Menschen wirksam eingreifen können.
• Artikel 15, Genauigkeit, Robustheit und Cybersicherheit: Hochrisiko-Systeme müssen ein angemessenes Maß davon erreichen.
• Artikel 17, Qualitätsmanagementsystem: Das Ganze muss organisatorisch verankert sein.

Der letzte Punkt ist der unbequeme. „Ein angemessenes Maß an Genauigkeit und Robustheit“ ist keine Aussage, die man behaupten kann. Man muss sie messen, und zwar so, dass die Messung nachvollziehbar bleibt: definierte Test Cases, definierte Kriterien, dokumentierte Ergebnisse, benannte Restrisiken.

Testen steht ausdrücklich im Text

An einer Stelle wird die Verordnung ungewöhnlich konkret. Artikel 9 Absatz 6 verlangt, dass Hochrisiko-KI-Systeme getestet werden, „um die am besten geeigneten gezielten Risikomanagementmaßnahmen zu ermitteln“; durch das Testen werde sichergestellt, dass sie „stets im Einklang mit ihrer Zweckbestimmung funktionieren und die Anforderungen dieses Abschnitts erfüllen“. Absatz 8 legt fest, wann und wogegen: zu jedem geeigneten Zeitpunkt während des gesamten Entwicklungsprozesses und in jedem Fall vor dem Inverkehrbringen oder der Inbetriebnahme, und zwar „anhand vorab festgelegter Metriken und Wahrscheinlichkeitsschwellenwerte, die für die Zweckbestimmung des Hochrisiko-KI-Systems geeignet sind“.

Das ist eine Testpflicht mit Abnahmekriterien, formuliert in einer EU-Verordnung. Vorab festgelegte Metriken und Schwellenwerte sind nichts anderes als Exit-Kriterien in einem Testkonzept. Wer sie erst nach dem Testlauf festlegt, erfüllt den Wortlaut nicht, denn dann sind sie nicht vorab festgelegt, sondern an das Ergebnis angepasst.

Auch wer KI nur einsetzt, hat Pflichten

Ein verbreiteter Irrtum ist, der AI Act betreffe nur die Hersteller. Artikel 26 verpflichtet auch die Betreiber eines Hochrisiko-Systems, also die Unternehmen, die es einkaufen und benutzen. Sie müssen technische und organisatorische Maßnahmen treffen, damit das System entsprechend der Gebrauchsanweisung verwendet wird. Sie müssen die menschliche Aufsicht Personen übertragen, die dafür kompetent, geschult und befugt sind. Soweit sie die Eingabedaten kontrollieren, müssen diese für den Zweck relevant und hinreichend repräsentativ sein. Sie müssen den Betrieb überwachen und den Anbieter informieren, wenn Risiken oder Auffälligkeiten auftreten. Und sie müssen die automatisch erzeugten Protokolle aufbewahren, mindestens sechs Monate, soweit sie darüber verfügen.

Das ist bemerkenswert: Es sind fast alles Anforderungen an einen Prozess, nicht an ein Produkt. Genau solche Prozesse baut Testmanagement.

Warum das eine Testmanagement-Aufgabe ist

Wer einen KI-Anteil in einem geschäftskritischen Service hat, steht vor derselben Aufgabe wie beim risikobasierten Testen, nur mit höherem Einsatz: Man muss begründen, welche Funktion wie tief geprüft wird, und man muss es belegen können. Vier Dinge tragen den Nachweis:

• Ein Risikobild, das jede Anforderung nach Eintrittswahrscheinlichkeit und Auswirkung bewertet und daraus die Testtiefe ableitet. Es ist zugleich der Einstieg in das Risikomanagement nach Artikel 9.
• Ein prüffähiges Testkonzept mit Teststrategie, Testarten, Abdeckungszielen und Entry-/Exit-Kriterien. Ohne definierte Kriterien gibt es kein „ausreichend geprüft“, sondern nur ein Gefühl.
• Eine Requirements-Traceability-Matrix, die zeigt, welche Anforderung durch welchen Test abgedeckt ist. Sie ist das Bindeglied zwischen „wir haben getestet“ und „wir können zeigen, was wie geprüft wurde“.
• Ein dokumentierter Freigabe-Nachweis mit Ergebnis, offenen Punkten und benannten Restrisiken. Das ist das Dokument, nach dem in einer Prüfung als Erstes gefragt wird.

Nichts davon ist KI-spezifisch, und das ist die gute Nachricht. Wer Qualität ohnehin datenbasiert steuert, muss für den AI Act keine zweite Welt aufbauen. Er muss seine bestehende Nachweiskette auf den KI-Anteil ausdehnen und dabei ein paar Besonderheiten berücksichtigen, etwa dass ein Modell nicht deterministisch antwortet und Test Cases deshalb mit Toleranzen und Wiederholungen arbeiten müssen.

Wer was macht

Damit keine falsche Erwartung entsteht: Qelivia plant, steuert und dokumentiert das Testen. Wir erstellen das Risikobild, das Testkonzept, den Autoren-Standard und den Freigabe-Nachweis, und wir führen Review und Abnahme des Testfallbestands durch. Die Tests selbst führt Ihr Team durch, in Ihrem Tool oder in einer von uns bereitgestellten Testumgebung. Das hat denselben fachlichen Grund wie bei jedem anderen Mandat: Das system- und fachspezifische Detailwissen liegt bei Ihnen, und niemand von außen kann es seriös ersetzen.

Ebenso deutlich: Ein Testkonzept ist keine Konformitätsbewertung und ersetzt weder eine rechtliche Prüfung noch die Benannte Stelle, wo eine gefordert ist. Was Testmanagement liefert, ist die belastbare technische Grundlage, auf der beides überhaupt erst aufsetzen kann.

Fazit

Der AI Act ersetzt keine klassische Qualitäts- oder Funktionsprüfung. Für betroffene Systeme verlangt er je nach Rolle und Risikoklasse jedoch nachvollziehbare Prozesse, Dokumentation, Transparenz und Risikomanagement. Strukturierte Testnachweise sind dafür eine belastbare Grundlage. Die späteren Hochrisiko-Termine verschaffen Zeit, sie nehmen die Aufgabe nicht weg. Wer die Zeit nutzt, um Prüfbarkeit von Anfang an in Konzept und Ablauf einzubauen, hat den Nachweis später als Nebenprodukt. Wer wartet, muss ihn rekonstruieren, und genau das geht bei Testergebnissen nicht.

Hinweis: Dieser Artikel gibt den Stand vom 25. August 2026 wieder und fasst öffentlich zugängliche Quellen der EU-Institutionen zusammen. Er ist keine Rechtsberatung. Ob und in welcher Rolle Ihr Unternehmen vom AI Act betroffen ist, gehört anwaltlich geprüft.