EU AI Act Compliance Engineering: Technische Dokumentation, Protokollierung, Aufsicht und Daten-Governance

Das meiste, was zur KI-Verordnung geschrieben wurde, dreht sich um den Anwendungsbereich: In welche Risikoklasse fallen Sie, sind Sie Anbieter oder Betreiber, greift Anhang III bei Ihrem System. Das beantwortet Ihre Rechtsberatung.

Kaum jemand behandelt, was nach dieser Antwort kommt. Ist Ihr System hochriskant, verlangt die Verordnung ein Risikomanagementsystem über den gesamten Lebenszyklus, eine belegbare Daten-Governance, automatische Protokollierung mit definierter Aufbewahrung, technische Dokumentation in vorgegebener Gliederung, menschliche Aufsicht, die konstruiert und nicht bloß behauptet ist, und eine Beobachtung nach dem Inverkehrbringen, die tatsächlich etwas erhebt. Das sind Entwicklungsleistungen. Genau diesen Teil bauen wir.

Wie die Fristen jetzt stehen

Die KI-Verordnung (Verordnung (EU) 2024/1689) ist im August 2024 in Kraft getreten und gilt gestaffelt. Die Staffelung hat sich 2026 geändert, und es lohnt sich, hier genau zu sein, denn diese Änderung hat Geld und Aufmerksamkeit verschoben.

2. Februar 2025: die verbotenen Praktiken und die Pflichten zur KI-Kompetenz gelten.
2. August 2025: die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck gelten.
2. August 2026: die Transparenzpflichten nach Artikel 50 gelten: Offenlegung, dass ein Nutzer mit einem KI-System interagiert, Kennzeichnung synthetischer Inhalte, Offenlegung von Emotionserkennung und biometrischer Kategorisierung sowie Kennzeichnung von Deepfakes.
2. Dezember 2027: die Hochrisiko-Pflichten für eigenständige Systeme, nach dem Digital Omnibus. Rat und Parlament haben die Verschiebung im Mai 2026 vereinbart, die endgültige Zustimmung erfolgte im Juni 2026.
2. August 2028: die Hochrisiko-Pflichten für KI-Systeme, die in regulierte Produkte eingebettet sind.

Wer Anbieter eines Hochrisiko-KI-Systems ist, hat durch die Verschiebung rund sechzehn Monate gewonnen. Weniger Arbeit ist es dadurch nicht geworden, und an den beiden bereits geltenden Pflichten ändert sie nichts: Transparenz nach Artikel 50 und KI-Kompetenz für die Mitarbeitenden, die diese Systeme bedienen.

Was wir bauen

Technische Dokumentation als erzeugtes Artefakt

Anhang IV legt fest, was die technische Dokumentation enthalten muss: Systembeschreibung, Entwurfsentscheidungen, Architektur, Datenanforderungen, gegebenenfalls die Trainingsmethodik, Validierungs- und Testverfahren, Metriken, Maßnahmen des Risikomanagements und die Änderungen über den Lebenszyklus.

Von Hand geschrieben ist dieses Dokument eine Woche nach der Unterschrift veraltet. Wir bauen es als etwas, das Ihre Pipeline erzeugt: Model Cards und Data Sheets aus den Trainings- und Evaluationsläufen, Architektur- und Datenflussbeschreibungen, die neben dem Code gepflegt werden, Evaluationsergebnisse, die an der Version hängen, die sie beschreiben, und eine Änderungshistorie aus Ihrer Versionsverwaltung statt aus jemandes Erinnerung. Das Dokument wird zum Build-Ergebnis.

Automatische Protokollierung nach Artikel 12

Hochrisiko-KI-Systeme müssen über ihre Lebensdauer automatisch protokollieren, und zwar in einer Qualität, die die Nachvollziehbarkeit der Funktionsweise und die Beobachtung nach dem Inverkehrbringen ermöglicht, mit einer dem Zweck angemessenen Aufbewahrung, in bestimmten Fällen mindestens sechs Monate.

In der Praxis heißt das: festlegen, was für Ihr System ein „Ereignis" ist, Eingaben, Ausgaben, Modellversion, Entscheidungspfad und die Identität des beteiligten Menschen erfassen, das Ganze so ablegen, dass es Jahre später noch abfragbar ist, und dabei keine personenbezogenen Daten anhäufen, für die es keine Grundlage gibt. Dieser Zielkonflikt (genug protokollieren für die KI-Verordnung, wenig genug aufbewahren für die DSGVO) ist das eigentliche Entwurfsproblem, und wir arbeiten ihn ausdrücklich mit Ihrem Datenschutz durch.

Daten-Governance nach Artikel 10

Trainings-, Validierungs- und Testdatensätze müssen relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig sein, und sie sind auf Verzerrungen zu untersuchen. Das erfordert eine belegbare Datenherkunft, dokumentierte Provenienz, eine Methodik zur Bias-Bewertung samt Ergebnissen und die Fähigkeit zu rekonstruieren, welche Daten zu welcher Modellversion geführt haben.

Wir bauen die Pipeline, die aus diesen Aussagen überprüfbare statt bloß angestrebte macht: versionierte Datensätze, reproduzierbare Splits, automatisierte Datenqualitätsprüfungen und Bias-Auswertung an den geschützten Merkmalen, die für Ihren Anwendungsfall einschlägig sind.

Menschliche Aufsicht, gebaut statt erklärt

Artikel 14 verlangt, dass Hochrisiko-KI-Systeme so gestaltet sind, dass ein Mensch die Ausgabe verstehen, den Automatisierungsbias im Blick behalten, das Ergebnis richtig deuten, sich gegen dessen Verwendung entscheiden und eingreifen oder das System anhalten kann.

Das ist eine Spezifikation für die Benutzeroberfläche. Wir bauen die Aufsicht in das Produkt hinein: Konfidenz und Unsicherheit ehrlich sichtbar, die Faktoren hinter einer Ausgabe nachvollziehbar, ein Übersteuern, das genauso leicht geht wie das Zustimmen, eine Stopp-Funktion, die funktioniert, und eine Protokollierung jeder Übersteuerung, damit die Beobachtung nach dem Inverkehrbringen etwas hat, woraus sie lernen kann.

Beobachtung nach dem Inverkehrbringen und Meldung schwerwiegender Vorfälle

Ein Plan zur Beobachtung nach dem Inverkehrbringen ist vorgeschrieben, ebenso die Meldung schwerwiegender Vorfälle an die zuständige Behörde. Wir bauen die Telemetrie, die ihn speist: Leistungsmessung gegen die Metriken aus Ihrer Dokumentation, Drift-Erkennung auf Eingaben und Ausgaben, einen Meldeweg für Nutzerprobleme, der auch in der Entwicklung ankommt, und einen Vorfallsprozess, in dem die Meldefristen eingebaut sind, statt während eines Vorfalls entdeckt zu werden.

Transparenzpflichten nach Artikel 50

Bereits in Kraft. Offenlegung, dass ein Nutzer es mit einem KI-System zu tun hat, maschinenlesbare Kennzeichnung synthetischer Audio-, Bild-, Video- und Textinhalte, Deepfake-Kennzeichnung und Offenlegung bei Emotionserkennung. Wir setzen die Hinweisflächen und die Herkunftskennzeichnung der Inhalte um (C2PA Content Credentials, wo das der richtige Mechanismus ist), und sorgen dafür, dass sie die Export- und Re-Encoding-Wege überstehen, auf denen sie sonst üblicherweise verloren gehen.

Registrierung und Unterstützung bei der Konformitätsbewertung

Hochrisiko-KI-Systeme in den Bereichen des Anhangs III müssen vor dem Inverkehrbringen in der EU-Datenbank registriert werden, und Anbieter müssen eine Konformitätsbewertung durchführen. Wir bereiten die technischen Zulieferungen auf (die Dokumentation, das Nachweispaket, die Artefakte des Qualitätsmanagementsystems auf der Entwicklungsseite), und arbeiten mit Ihrer benannten Stelle oder Ihrem internen Bewertungsverfahren zusammen.

Was wir nicht tun

Wir leisten keine Rechtsberatung, und wir sagen Ihnen nicht, in welche Risikoklasse Ihr System fällt. Diese Einstufung ist eine rechtliche Entscheidung mit echten Folgen und gehört zur Rechtsberatung oder zu einer qualifizierten Compliance-Beratung.

Wir verkaufen auch keine KI-Governance-Plattform. Davon gibt es ein großes Angebot, und wenn Sie ein Register Ihrer KI-Systeme und einen Richtlinien-Workflow brauchen, ist eine davon besser für Sie als wir. Wir machen die Entwicklungsarbeit in den Systemen selbst.

Für wen das gedacht ist

Anbieter von Hochrisiko-KI-Systemen nach Anhang III (Personalgewinnung und Beschäftigtenmanagement, Kreditwürdigkeitsprüfung, Versicherungstarifierung, Bewertung in der Bildung, Zugang zu grundlegenden Diensten, biometrische Systeme), die nun bis Dezember 2027 Zeit haben und viel zu bauen.

Hersteller, die KI in regulierte Produkte einbetten (Medizinprodukte, Maschinen, Fahrzeuge), wo die KI-Verordnung auf ein bestehendes Konformitätsregime aufsetzt und beide Dokumentationsstände zusammenpassen müssen.

Unternehmen, die zugekaufte Hochrisiko-KI-Systeme betreiben und dabei eigene Pflichten tragen: menschliche Aufsicht, Relevanz der Eingabedaten, Beobachtung des Betriebs und Aufbewahrung der Protokolle.

Alle, die generative Funktionen an EU-Nutzer ausliefern, denn die Transparenz nach Artikel 50 gilt bereits heute, unabhängig von der Risikoklasse.

Ablauf eines Projekts

Technische Gap-Analyse, zwei bis vier Wochen. Wir nehmen die Einstufung, zu der Ihre Rechtsabteilung gekommen ist, und bewerten Ihre Systeme gegen die daraus folgenden technischen Pflichten. Ergebnis ist ein Gap-Register (Pflicht, Ist-Zustand, was zu bauen ist, Aufwand), mit dem Compliance und Entwicklung gleichermaßen arbeiten können.

Umsetzung, in Phasen, meist beginnend mit Protokollierung und Dokumentationserzeugung, weil alles Weitere Nachweise erzeugt, die irgendwo landen müssen.

Readiness-Review vor der Konformitätsbewertung, mit zusammengestelltem Nachweispaket und ehrlich benannten verbleibenden Lücken.

Normen und Rahmenwerke

Verordnung (EU) 2024/1689 mit den Anhängen III und IV; die harmonisierten Normen, die aus CEN/CENELEC JTC 21 entstehen; ISO/IEC 42001 für KI-Managementsysteme und ISO/IEC 23894 für KI-Risikomanagement; das NIST AI Risk Management Framework, wo eine US-Muttergesellschaft Gleichlauf braucht; und die DSGVO, die nicht verschwindet und die die meisten Entscheidungen zur Protokollierung einschränkt.

Häufige Fragen

Ist die KI-Verordnung verschoben worden?

Teilweise. Der Digital Omnibus hat die Hochrisiko-Pflichten auf den 2. Dezember 2027 für eigenständige Systeme und auf den 2. August 2028 für KI in regulierten Produkten verschoben. Verbotene Praktiken, KI-Kompetenz, die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck und die Transparenzregeln nach Artikel 50 wurden nicht verschoben und gelten jetzt.

Wir setzen nur KI-Systeme anderer Anbieter ein. Haben wir Pflichten?

Ja, als Betreiber. Dazu gehören der Betrieb gemäß der Betriebsanleitung, die Zuweisung der menschlichen Aufsicht an Personen mit der nötigen Kompetenz und Befugnis, die Sicherstellung, dass die Eingabedaten der Zweckbestimmung entsprechen, die Beobachtung des Betriebs und die Aufbewahrung der Protokolle. Das ist weniger als die Pflichten eines Anbieters, aber real, und beachten Sie: Wer ein System wesentlich verändert oder unter eigenem Namen anbietet, kann selbst zum Anbieter werden.

Unser System ist nicht hochriskant. Ist trotzdem etwas zu tun?

Vermutlich zweierlei. Die Transparenz nach Artikel 50 gilt für bestimmte Systeme unabhängig von der Risikoklasse, darunter Chatbots und die Erzeugung synthetischer Inhalte. Und die KI-Kompetenz nach Artikel 4 gilt für Anbieter und Betreiber allgemein. Darüber hinaus lohnt es sich, die Einstufungsentscheidung belegen zu können, falls eine Behörde einmal fragt.

Lässt sich die technische Dokumentation wirklich erzeugen?

Zum größten Teil ja. Architektur, Datensatzbeschreibungen, Evaluationsergebnisse, Metriken, Modellversionen und Änderungshistorie liegen bereits in Ihren Systemen; die Arbeit besteht darin, sie zur Build-Zeit in einer stabilen Struktur einzusammeln. Die wirklich erzählenden Abschnitte (Zweckbestimmung, Risikoanalyse, Entwurfsbegründung) schreiben Menschen, und sie liegen anschließend im selben Repository, damit sie mit allem anderen versioniert werden.

Wie greifen KI-Verordnung und DSGVO ineinander?

Sie überschneiden sich und ziehen gelegentlich in verschiedene Richtungen, besonders bei der Protokollierung. Die KI-Verordnung will Nachvollziehbarkeit, die DSGVO will Datenminimierung und Löschung. Aufgelöst wird das meist über Pseudonymisierung, einen engen Zuschnitt dessen, was protokolliert wird, und definierte Aufbewahrungsfristen zu einem dokumentierten Zweck. Eine Entwurfsentscheidung, einmal und bewusst getroffen.

Werden wir zum Anbieter eines Modells, wenn wir ein fremdes Modell einsetzen?

Nein, aber wer darauf ein KI-System aufbaut, kann Anbieter dieses Systems werden, mit den daran hängenden Pflichten. Wo genau die Grenze verläuft, hängt davon ab, was Sie bauen und wie Sie es darstellen: das ist eine Rechtsfrage. Die technische Konsequenz ist aber eindeutig: Gehen Sie davon aus, dass Sie in jedem Fall eine eigene Dokumentation Ihres Systems brauchen.

Erste Schritte

Sagen Sie uns, was Ihre Systeme tun und wo Ihre Rechtsberatung bei der Einstufung gelandet ist. Wir bewerten, was die Pflichten im Code bedeuten, und liefern Ihnen ein Gap-Register mit einem Aufwand hinter jeder Zeile.

Vereinbaren Sie eine technische Gap-Analyse zur KI-Verordnung.

Weitere Leistungen

KI-Agenten & MCP-Integration: die Systeme bauen, die dieses Regime reguliert
EU-Markteintritt: der übrige EU-Compliance-Stack für digitale Produkte
Web-Barrierefreiheit Sanierung: die andere EU-Pflicht, die sich als Entwicklungsprojekt entpuppt