Was Art. 15 konkret verlangt
Art. 15 Abs. 1 AI Act verpflichtet Anbieter von Hochrisiko-KI-Systemen dazu, diese so zu konzipieren und zu entwickeln, dass sie “ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit erreichen” und dies “während ihres gesamten Lebenszyklus” beständig tun. Das ist keine einmalige Prüfung vor dem Inverkehrbringen, sondern eine fortlaufende Pflicht – Genauigkeit und Robustheit müssen auch nach Monaten im produktiven Einsatz noch stimmen, nicht nur im Testlauf.
Die Norm bleibt bewusst technologieoffen: Was “angemessen” ist, hängt vom konkreten System, seinem Einsatzkontext und den damit verbundenen Risiken ab. Für die Praxis heißt das: Sie müssen selbst begründen und dokumentieren können, warum Ihr gewähltes Maß an Genauigkeit, Robustheit und Cybersicherheit für den jeweiligen Anwendungsfall ausreicht.
Genauigkeit: Metriken gehören in die Betriebsanleitung
Art. 15 Abs. 3 verlangt, dass die Maße an Genauigkeit und die relevanten Genauigkeitsmetriken “in den ihnen beigefügten Betriebsanleitungen angegeben” werden. Das ist eine sehr konkrete Dokumentationspflicht, die in der Praxis häufig zu kurz kommt: Viele technische Dokumentationen enthalten Trainings- und Validierungsergebnisse, aber keine für Betreiber verständliche Angabe, welche Genauigkeit unter welchen Bedingungen zu erwarten ist.
Die Kommission soll laut Art. 15 Abs. 2 die Entwicklung von Benchmarks und Messmethoden fördern, insbesondere über Metrologie- und Benchmarking-Behörden. Bis entsprechende Standards etabliert sind, liegt die Auswahl geeigneter Metriken jedoch bei Ihnen als Anbieter – und diese Auswahl muss nachvollziehbar sein.
Robustheit: Fehler, Störungen und Rückkopplungsschleifen
Art. 15 Abs. 4 fordert, dass Hochrisiko-KI-Systeme “so widerstandsfähig wie möglich gegenüber Fehlern, Störungen oder Unstimmigkeiten” sind – ausdrücklich auch solche, die aus der Interaktion mit natürlichen Personen oder anderen Systemen entstehen. Gefordert sind dafür technische und organisatorische Maßnahmen; die Norm nennt technische Redundanz sowie Sicherungs- oder Störungssicherheitspläne als mögliche Ansätze.
Ein Punkt, der in der Praxis oft übersehen wird, betrifft Systeme, die nach der Inbetriebnahme weiterlernen. Für diese schreibt Abs. 4 explizit vor, dass das Risiko verzerrter Ausgaben durch Rückkopplungsschleifen – also selbstverstärkende Fehlmuster, die künftige Entscheidungen beeinflussen – beseitigt oder minimiert werden muss, mit angemessenen Risikominderungsmaßnahmen. Wer ein kontinuierlich lernendes System betreibt, ohne einen Prozess zur Erkennung solcher Rückkopplungsschleifen zu haben, hat hier eine klare Lücke.
Cybersicherheit: KI-spezifische Angriffsvektoren
Art. 15 Abs. 5 verlangt Widerstandsfähigkeit gegen Versuche unbefugter Dritter, “Verwendung, Ausgaben oder Leistung durch Ausnutzung von Systemschwachstellen” zu verändern. Die technischen Lösungen müssen den jeweiligen Umständen und Risiken angemessen sein – auch hier gilt: kein Pauschalmaßstab, sondern eine risikobasierte Begründungspflicht.
Besonders relevant ist, dass die Norm konkrete KI-spezifische Angriffsarten benennt, für die Maßnahmen zum Verhüten, Erkennen, Reagieren, Beseitigen und Kontrollieren vorzusehen sind:
- Data Poisoning: Manipulation des Trainingsdatensatzes
- Model Poisoning: Manipulation vortrainierter Komponenten, die beim Training verwendet werden
- Adversarial Examples / Model Evasion: Eingabedaten, die das Modell zu Fehlern verleiten sollen
- Angriffe auf vertrauliche Daten oder Modellmängel
Das ist der Punkt, an dem klassische IT-Sicherheitskonzepte oft nicht ausreichen. Ein Penetrationstest, der nur klassische Netzwerk- und Anwendungssicherheit prüft, deckt Data-Poisoning-Szenarien oder Adversarial-Attacken auf das Modell selbst in der Regel nicht ab. Wer Cybersicherheit für ein Hochrisiko-KI-System nachweisen will, braucht ein Konzept, das explizit auf diese Angriffsvektoren eingeht.
Typische Lücken in der Praxis
Drei Muster tauchen immer wieder auf: Erstens fehlen nachvollziehbare Genauigkeitsmetriken in der Betriebsanleitung, weil Entwicklung und Dokumentation getrennt laufen. Zweitens gibt es für kontinuierlich lernende Systeme keinen definierten Prozess zur Überwachung von Rückkopplungsschleifen. Drittens wird Cybersicherheit als reines IT-Thema behandelt, ohne KI-spezifische Bedrohungen wie Data- oder Model-Poisoning in die Risikoanalyse einzubeziehen. Alle drei Lücken lassen sich mit vertretbarem Aufwand schließen – vorausgesetzt, sie werden erkannt, bevor eine Marktaufsichtsbehörde oder ein Kunde danach fragt.
Ob Ihr System überhaupt als Hochrisiko-KI im Sinne des AI Act gilt und welche Pflichten aus Art. 15 im Detail für Sie greifen, lässt sich mit unserem kostenlosen Risiko-Check unter /einstufung in wenigen Minuten einordnen.