Der EU AI Act: Was er für Softwareentwickler bedeutet

Der EU AI Act trat am 1. August 2024 in Kraft. Obwohl seine Bestimmungen bis 2027 schrittweise eingeführt werden, sind die technischen Konsequenzen bereits spürbar: Rückverfolgbarkeit, Erklärbarkeit und Audit‑Anforderungen sind nun rechtliche Verpflichtungen für bestimmte KI‑Systeme und keine optionalen Qualitätspraktiken. Das bedeutet, dass ein Versäumnis, diese Vorgaben zu erfüllen, rechtliche Haftung nach sich ziehen kann.

Der risikobasierte Rahmen

Das Gesetz klassifiziert KI‑Systeme in vier Risikostufen, jede Stufe mit spezifischen Verpflichtungen.

Stufe	Beispiele	Engineering‑Verpflichtungen
Inakzeptables Risiko (verboten)	Soziales Scoring durch Regierungen, Echtzeit‑Biometrie‑Überwachung im öffentlichen Raum	Darf in der EU nicht gebaut oder eingesetzt werden
Hohes Risiko	Lebenslaufscreening, Kreditscoring, Medizinprodukte, kritische Infrastruktur, Strafverfolgung	Vollständige Konformitätsbewertung, technische Dokumentation, menschliche Aufsicht, Protokollierung
Begrenztes Risiko	Chatbots, Deep‑Fake‑Generatoren	Transparenzpflichten (offene KI‑Interaktion)
Minimales Risiko	Spam‑Filter, KI in Videospielen	Keine spezifischen Verpflichtungen

Die entscheidende Frage für jedes Engineering‑Team ist, ob das eigene System in die Kategorie der hochrisikobehafteten KI‑Anwendungen fällt. Der EU AI Act definiert hochrisikobehaftete Systeme in Anhang III, der acht wesentliche Bereiche – etwa Beschäftigung, Bildung, kritische Infrastruktur, Strafverfolgung – umfasst. Sobald unser System Entscheidungen in einem dieser Bereiche trifft oder maßgeblich beeinflusst, wird es nach dem Gesetz als hochriskant eingestuft, was sofortige Pflichten zur Dokumentation, Protokollierung und menschlichen Aufsicht nach sich zieht.

Was Hochrisiko‑Systeme haben müssen

Für hochrisikobehaftete KI‑Systeme schreibt das Gesetz spezifische technische Maßnahmen vor, die Engineering‑Anforderungen sind und keine bloßen politischen Aussagen.

Technische Dokumentation

Vor der Markteinführung eines hochrisikobehafteten Systems muss der Anbieter eine umfassende Dokumentation erstellen, die Folgendes abdeckt:

• eine allgemeine Beschreibung des Systems und seines beabsichtigten Zwecks;
• die Designspezifikationen, einschließlich der Trainingsmethodik, verwendeten Daten und bekannter Einschränkungen;
• den Risikomanagementprozess und seine Ergebnisse;
• die Genauigkeits‑, Robustheits‑ und Cybersicherheitsmaßnahmen; und
• den Plan zur Marktüberwachung nach der Inbetriebnahme.

Diese Dokumentation muss während des gesamten Lebenszyklus des Systems aktuell gehalten werden. Ein Modell‑Update, das das Verhalten ändert, erfordert aktualisierte Dokumentation.

Protokollierung und Audit‑Trails

Hochrisiko‑Systeme müssen automatisch Ereignisse protokollieren, die eine nachträgliche Untersuchung ermöglichen. Das Gesetz legt fest, dass Protokolle Folgendes abdecken müssen:

• den Zeitraum jeder Nutzung des Systems;
• die Referenzdatenbank, gegen die Eingabedaten geprüft wurden;
• die Eingabedaten, die zu einer bestimmten Ausgabe geführt haben; und
• die Identität der an der Überprüfung beteiligten natürlichen Personen.

Ohne diese Aufzeichnungen könnten wir im Streitfall nicht rekonstruieren, welche Daten zu welcher Entscheidung geführt haben, und würden damit gegen die gesetzlichen Vorgaben verstoßen. Für den Nachweis der Protokollierung sind spezifische Formate nicht vorgeschrieben. Der Anbieter muss jedoch sicherstellen, dass die Protokolle alle relevanten Informationen enthalten, um eine nachträgliche Untersuchung zu ermöglichen.

Menschliche Aufsicht

Hochrisiko‑Systeme müssen so gestaltet sein, dass natürliche Personen sie effektiv überwachen können. Das bedeutet, dass das System interpretierbar genug sein muss, damit ein Aufseher seine Ausgaben verstehen kann; Aufseher müssen in der Lage sein, einzugreifen, zu überschreiben oder das System anzuhalten. Das System darf keinen Automatisierungs‑Bias erzeugen – es darf Ausgaben nicht so präsentieren, dass menschliche Überprüfung entmutigt wird.

Ein System, das nur ein Ergebnis mit hohem Konfidenzwert zeigt, verleitet den Nutzer dazu, die Entscheidung ungeprüft zu übernehmen; deshalb muss die Oberfläche Unsicherheit und relevante Einflussfaktoren deutlich machen.

Automatisierungs‑Bias ist ein Engineering‑Problem, das sowohl technische als auch Benutzererfahrungselemente berührt. Ein System, das einen Konfidenzwert von 97 % neben einer Entscheidung anzeigt, wird viel seltener überschrieben als eines, das dieselbe Entscheidung mit ihrer Unsicherheit und den treibenden Faktoren präsentiert. Die Anforderung zur menschlichen Aufsicht bedeutet, dass die Schnittstelle nicht nur eine nominale, sondern echte Aufsicht unterstützen muss.

Genauigkeit, Robustheit und Cybersicherheit

Hochrisiko‑Systeme müssen angemessene Genauigkeitsniveaus für ihren beabsichtigten Zweck erreichen, robust gegenüber Fehlern und Inkonsistenzen in Eingabedaten sein und widerstandsfähig gegen feindliche Manipulation. Diese Anforderungen müssen dokumentiert und getestet werden – nicht nur behauptet.

Allzweck‑KI‑Modelle

Das Gesetz führt spezifische Verpflichtungen für Anbieter von Allzweck‑KI‑Modellen (GPAI) ein. Anbieter von GPAI‑Modellen müssen:

• technische Dokumentation pflegen;
• EU‑Urheberrecht bezüglich Trainingsdaten einhalten;
• eine Zusammenfassung der Trainingsdaten veröffentlichen; und
• für Modelle mit systemischem Risiko (über einem Rechen‑Aufwand‑Schwellenwert von 10^25 FLOPs) adversarielle Tests durchführen, schwerwiegende Vorfälle dem Europäischen KI‑Büro melden und Cybersicherheitsmaßnahmen implementieren.

Diese Anforderungen betreffen Organisationen, die Foundation‑Modelle trainieren und freigeben, nicht nur diejenigen, die sie nutzen.

Der Konformitätsbewertungsprozess

Bevor ein hochrisikobehaftetes KI‑System in der EU eingesetzt werden kann, muss es eine Konformitätsbewertung durchlaufen. Für die meisten hochrisikobehafteten Systeme ist das eine Selbst‑assessment gegen die Anforderungen des Gesetzes, dokumentiert in einer technischen Datei. Für bestimmte hochrisikobehaftete Systeme (biometrische Identifikation, kritische Infrastruktur) ist eine Dritt‑partei‑Bewertung durch eine benannte Stelle erforderlich. Der Selbst‑Assessment wird von einem internen Compliance‑Officer unterschrieben, um die Verbindlichkeit zu sichern.

Die Konformitätsbewertung ist kein einmaliges Ereignis. Sie muss wiederholt werden, wenn das System wesentlich geändert wird – einschließlich wenn das Modell neu trainiert wird, wenn sich die Trainingsdaten wesentlich ändern oder wenn sich der beabsichtigte Zweck ändert.

Was das in der Praxis bedeutet

Für Teams, die KI‑Funktionen in bestehende Produkte einbauen: Wir prüfen zuerst, ob unser Produkt in einem hochrisikobehafteten Bereich operiert. Liegt das vor, erstellen wir die geforderte Dokumentation, implementieren lückenlose Protokollierung und bauen echte Aufsichtsmechanismen ein, bevor wir das System in der EU ausrollen.

Für Teams, die KI‑native Produkte bauen: Wir entwerfen von Anfang an für Auditierbarkeit. Das Nachrüsten von Protokollierung, Erklärbarkeit und menschlichen Override‑Mechanismen in ein bereits eingesetztes System ist erheblich schwieriger als deren Einbau von Beginn an.

Für Teams, die Drittanbieter‑KI‑APIs verwenden: Wenn wir ein Drittanbieter‑KI‑System in eine hochrisikobehaftete Anwendung integrieren, sind wir der Betreiber und teilen die Verpflichtungen mit dem Anbieter. Wir können Compliance nicht an den API‑Anbieter auslagern. Deshalb fordern wir vom Anbieter ein Data‑Sheet, das Modell‑Limitationen und Trainings‑Provenienz offenlegt, und wir implementieren Wrapper‑Code, der jede Anfrage, Antwort und das zugehörige Konfidenz‑Metric protokolliert.

Zeitplan

Datum	Verpflichtung
Februar 2025	Verbotene KI‑Praktiken untersagt
August 2025	GPAI‑Modell‑Verpflichtungen gelten
August 2026	Hochrisiko‑KI‑System‑Verpflichtungen gelten (Anhang III)
August 2027	Hochrisiko‑KI‑Systeme in regulierten Produkten

Die Frist August 2026 für Anhang‑III‑Systeme ist für die meisten Engineering‑Teams die bedeutendste. Systeme, die Konformitätsbewertung, Dokumentation und Protokollierungsinfrastruktur erfordern, müssen diese Arbeit vor der Frist abgeschlossen und getestet haben – nicht erst dann damit beginnen.

Ein Hinweis zur Februar‑2025‑Frist

Das Verbot inakzeptabler KI‑Praktiken (soziales Scoring, Echtzeit‑Biometrie‑Überwachung im öffentlichen Raum) trat im Februar 2025 in Kraft und gilt bereits. Fällt ein System in diese Kategorie, ist die Frage nicht Compliance‑Planung – sondern ob das System in der EU überhaupt legal betrieben werden kann.

Was das Gesetz nicht vorschreibt

Das Gesetz legt Anforderungen fest, überlässt aber die Implementierungsentscheidungen Ingenieuren und Organisationen. Es schreibt kein bestimmtes Logging‑Format, kein bestimmtes ML‑Framework und keine bestimmte Erklärbarkeits‑Technik vor. Das ist beabsichtigt: Der EU AI Act ist technologieneutral. Die Verpflichtung besteht darin, das Ergebnis zu erreichen (auditierbare, beaufsichtigte, genaue Systeme) – nicht ein bestimmtes Werkzeug dafür zu verwenden.

Das bedeutet, Engineering‑Teams haben Spielraum bei der Art und Weise, wie sie die Anforderungen erfüllen, müssen aber nachweisen können, dass sie sie erfüllt haben. Die Dokumentation von Designentscheidungen, Testergebnissen und Risikobewertungen ist das, was diesen Nachweis ermöglicht.