Der EU AI Act aus der Sicht dessen, der das System baut

Ob ein System unter dem AI Act als Hochrisiko fällt, entscheidet am Ende eine juristische Einordnung, nicht ich. Was ich beitragen kann: die technischen Voraussetzungen, die so eine Einordnung überhaupt erst prüfbar machen. Ohne die ist jede rechtliche Bewertung ein Rätsel mit fehlenden Angaben.

Was mir in Projekten auffällt: die Fragen, die der AI Act aufwirft, sind fast dieselben, die ich aus Compliance-Reviews für RAG-Systeme schon kenne. Nachvollziehbarkeit, menschliche Aufsicht, Dokumentation. Der AI Act macht daraus eine formale Pflicht statt einer guten Idee.

Was aus Ingenieurssicht dazugehört

Nachvollziehbarkeit kommt zuerst. Eine Entscheidung oder eine Aussage des Systems muss sich auf eine Quelle oder einen Ablauf zurückführen lassen. Das ist derselbe Punkt wie Quellenbindung: ein Modell, das Belege erfindet, kann seine eigene Entscheidung nicht dokumentieren, weil es keine gab, nur eine plausible Formulierung.

Dann menschliche Aufsicht, und zwar nicht als Lippenbekenntnis im Nutzungshinweis, sondern als Stelle im Ablauf, an der ein Mensch eingreifen kann, bevor eine Aussage nach draußen geht. Beim Audit-Assistenten heißt das: ein Finding aus der KI ist ein Entwurf mit Normbezug, keine fertige Aussage. Der Auditor prüft und gibt frei.

Dazu gehört Dokumentation der Betriebsdaten. Bei einem RAG-System ist das greifbarer als bei einem trainierten Modell: welche Dokumente stehen im Index, welche Version, wann aktualisiert. Ein System, das nicht sagen kann, welche Inhalte in seinem Index liegen und aus welcher Fassung, hat schon vor der rechtlichen Frage ein Betriebsproblem.

Genauso wichtig ist das Verhalten bei erwartbaren Fehlern. Was passiert, wenn Retrieval nichts findet? Sagt das System „keine Antwort" oder füllt es die Lücke? Das ist Evaluation und Quellenbindung in einem, nur mit einer neuen Überschrift.

Und schließlich Transparenz gegenüber dem Nutzer. Weiß der Nutzer, dass er mit einem KI-System spricht, und nicht mit einem Menschen? Das klingt banal, ist aber in Chat-Oberflächen, die bewusst menschlich klingen sollen, keine Selbstverständlichkeit. Eine Kennzeichnung ist ein UI-Detail, kein Architekturproblem, und wird trotzdem regelmäßig vergessen, weil sie in keinem Sprint als Aufgabe auftaucht.

Die Kategorie entscheidet die Tiefe, nicht die Technik

Nicht jedes LLM-Projekt braucht das volle Programm. Ein interner Assistent, der Meeting-Notizen zusammenfasst, steht an einer anderen Stelle als ein System, das in einem Bewerbungsprozess vorsortiert oder Aussagen für ein Zertifizierungsaudit liefert. Die Einordnung, wo ein konkretes System landet, ist wieder eine juristische Frage. Was ich technisch beisteuern kann: die Antwort auf „was tut das System eigentlich, wessen Interessen betrifft die Ausgabe", sauber genug aufgeschrieben, dass eine Einordnung darauf aufbauen kann. Ein System, dessen Funktionsweise niemand in drei Sätzen erklären kann, lässt sich auch nicht seriös einordnen.

Die technische Akte

Aus anderen EU-Produktregulierungen kennt man das Prinzip einer technischen Dokumentation, die belegt, wie ein Produkt funktioniert und warum es sicher ist. Für ein KI-System ist das Äquivalent eine Beschreibung, die festhält: welche Daten fließen ein, welche Entscheidung oder Ausgabe entsteht, wo ein Mensch eingreifen kann, wie das System getestet wurde. Ich schreibe diese Beschreibung mit, wenn sie noch nicht existiert, weil sie ohnehin die Grundlage für Onboarding, Wartung und den nächsten Architektur-Review ist. Dass sie auch für eine rechtliche Prüfung nützlich ist, ist ein Nebeneffekt guter Ingenieursarbeit, nicht der Grund, sie zu schreiben.

Wo ich vorsichtig bin

Ich bin kein Jurist und werde in einem Review nicht behaupten, ein System sei „AI-Act-konform". Was ich liefere, ist die technische Grundlage: eine Liste, was das System tut, mit welchen Daten, mit welcher Aufsicht, mit welcher Nachvollziehbarkeit. Die Einordnung in eine Risikokategorie und die daraus folgenden Pflichten gehören in die Hand von jemandem mit der entsprechenden Ausbildung.

Was ich in Gesprächen öfter erlebe, als mir gefällt: ein Team hofft, dass ein gutes Modell die Einordnung automatisch erleichtert. Das stimmt so nicht. Die Einordnung hängt am Zweck und am Kontext des Systems, nicht an der Modellwahl. Ein kleines, sauber dokumentiertes System mit klarer Aufsicht steht aus Compliance-Sicht oft besser da als ein großes Modell ohne beides.

Was das für den Rollout heißt

Die Punkte, die ein Review für den AI Act braucht, sind fast identisch mit den Punkten, die ich ohnehin vor einem Rollout prüfe: Quellenbindung, Evaluation, Observability, wer die Aufsicht trägt. Wer diese Hausaufgaben schon vor einer rechtlichen Prüfung gemacht hat, kommt in dieses Gespräch mit Antworten statt mit einem leeren Blatt.

Der praktische Nebeneffekt: dieselbe Dokumentation, die ein System für den AI Act belegbar macht, macht es auch für den eigenen Betrieb wartbar. Ein Team, das weiß, welche Version welches Index gerade live ist und wer ein Finding freigegeben hat, braucht diese Angaben nicht nur für einen Prüfer, sondern für den nächsten Vorfall im eigenen Haus.

Was der Readiness-Check daraus macht

Der LLM-Readiness-Check prüft technische Reife, nicht rechtliche Konformität. Aber die Fundstellen überlappen sich fast vollständig: eine Lücke bei Quellenbindung oder Nachvollziehbarkeit, die im Check auftaucht, ist genau die Lücke, die eine spätere rechtliche Prüfung ebenfalls findet.

Die Leistung dahinter: KI-Engineering. Verwandt: Halluzinationen als Compliance-Problem, Evaluation in Produktion.

Wer jetzt anfängt, diese Punkte in ein bestehendes System einzuziehen, tut das ohnehin nicht wegen eines Gesetzes allein. Ein System, das niemand nachvollziehen kann, ist ein Betriebsrisiko, unabhängig davon, welche Verordnung gerade greift.