AI-Act-Dokumentation: was die Behörde verlangt und wie Sie sie aufbauen

Welche Dokumente verlangt der AI Act für ein Hochrisiko-KI-System?

Fünf Arbeitsergebnisse: die technische Dokumentation nach Art. 11 und Anhang IV, die Risikoakte nach Art. 9, die Beschreibung der Daten-Governance nach Art. 10, den Protokollierungsplan nach Art. 12 und die Betriebsanleitung zusammen mit der Beschreibung der menschlichen Aufsicht nach Art. 13 und Art. 14. Alle fünf liegen beim Anbieter, und alle fünf müssen am 2. Dezember 2027 existieren.

Die Aufzählung führt in die Irre, wenn Sie sich fünf getrennte Ordner vorstellen. Anhang IV Nummer 5 zieht die Beschreibung des Risikomanagementsystems herein, Nummer 2 die Daten-Governance und die Bewertung der Aufsichtsmaßnahmen, Nummer 9 den Plan zur Beobachtung nach dem Inverkehrbringen. In der Praxis funktioniert ein einziger versionierter Dokumentenbaum. Fünf parallele Word-Dateien widersprechen sich nach einem halben Jahr.

Bis wann muss die Dokumentation fertig sein?

Für eigenständige Hochrisiko-Systeme nach Anhang III ab dem 2. Dezember 2027, für in Produkte eingebettete Systeme nach Anhang I ab dem 2. August 2028. Die Verordnung (EU) 2026/1744, der Digital Omnibus on AI, trat am 27. Juli 2026 in Kraft und verschob Kapitel III Abschnitte 1 bis 3, also die Art. 8 bis 27.

Sechzehn zusätzliche Monate klingen großzügig. Der größere Teil dieser Dokumentation lässt sich nachträglich nicht herstellen. Anhang IV Nummer 2 verlangt datierte und von einer verantwortlichen Person unterzeichnete Testprotokolle, die Begründung der Entwurfsentscheidungen und die Kompromisse, die Sie dabei eingegangen sind. Wer im Herbst 2027 anfängt, produziert eine Rekonstruktion, und die ist in einem Audit schwer zu verteidigen.

Offen ist die nationale Seite. Welche Stelle in Deutschland nach Art. 70 als Marktüberwachungsbehörde benannt ist, konnten wir zum Redaktionsschluss am 14. August 2026 keiner zitierfähigen Quelle entnehmen, und deutsche Zuständigkeiten raten wir in einem Compliance-Text nicht. Für den Inhalt Ihrer Unterlagen ändert das nichts, weil die Verordnung unmittelbar gilt. Für den Meldeweg nach Art. 73 klären Sie den Adressaten besser mit Ihrer Rechtsberatung, bevor Sie den Prozess festschreiben.

Was gehört in die technische Dokumentation nach Art. 11 und Anhang IV?

Anhang IV hat neun Nummern: allgemeine Beschreibung des Systems, Details des Entwicklungsprozesses, Betrieb und Überwachung, Begründung der Leistungsmetriken, Risikomanagementsystem, Änderungen über den Lebenszyklus, angewandte Normen, Kopie der EU-Konformitätserklärung und der Plan zur Beobachtung nach dem Inverkehrbringen. Art. 11 Abs. 1 verlangt all das vor dem Inverkehrbringen und danach fortlaufend aktuell.

1. Allgemeine Beschreibung des Systems

Zweckbestimmung, Name des Anbieters, Version und ihr Verhältnis zu früheren Versionen. Dazu kommt, wie das System mit externer Hardware, Software oder anderen KI-Systemen zusammenwirkt, die Software- und Firmware-Stände, die Vertriebsformen (eingebettete Software, Download, API), die Hardware im Betrieb und eine Grundbeschreibung der Benutzeroberfläche.

In einem laufenden Projekt veraltet dieses Kapitel am schnellsten. Wer alle zwei Wochen ausliefert, kann die Versionshistorie nicht von Hand pflegen; sie muss aus dem Release-Prozess erzeugt werden. Geschrieben wird das Kapitel vom Produktverantwortlichen, die Versionsdaten liefert die Entwicklung.

2. Entwicklungsprozess und Systemelemente

Der längste Abschnitt und der, den es am seltensten wirklich gibt. Seine acht Unterpunkte decken die Entwicklungsmethoden und die Verwendung vortrainierter Modelle oder Werkzeuge Dritter ab, die Entwurfsspezifikation mit der allgemeinen Logik des Algorithmus, die Begründung der wesentlichen Entwurfsentscheidungen, das Optimierungsziel, die Architektur und die für das Training eingesetzte Rechenleistung, Datenblätter zu den Datensätzen, die Bewertung der Aufsichtsmaßnahmen nach Art. 14, vorab festgelegte Änderungen, die Validierungs- und Testverfahren samt Prüfung auf diskriminierende Wirkung und schließlich die Cybersicherheitsmaßnahmen.

Die Verordnung verlangt Testprotokolle datiert und von der verantwortlichen Person unterzeichnet. Diese eine Anforderung ist der Grund, warum sich das Kapitel nicht am Projektende schreiben lässt. Sitzt Ihr Modell auf einem vortrainierten Modell hinter einer geschlossenen API, steht hier, was Sie einsetzen, in welcher Version und wie Sie es angepasst haben. Wer genau deshalb lieber selbst betreibt, findet die technischen Grenzen in unserem Text zu lokal betriebenen KI-Modellen.

Geschrieben wird das Kapitel von der Entwicklungsleitung und dem ML-Engineer, die Testprotokolle zeichnet, wer die Tests durchgeführt hat, und die Lizenzbedingungen der Fremdkomponenten prüft die Rechtsabteilung.

3. Betrieb, Überwachung und Kontrolle

Fähigkeiten und Leistungsgrenzen des Systems, der Grad der Genauigkeit aufgeschlüsselt nach den Personen und Gruppen, für die das System bestimmt ist, vorhersehbare unbeabsichtigte Ergebnisse und die Risikoquellen für Gesundheit, Sicherheit, Grundrechte und Nichtdiskriminierung. Hierher gehört auch die technische Umsetzung der menschlichen Aufsicht nach Art. 14 und die Spezifikation der Eingabedaten.

Die nach Gruppen aufgeschlüsselte Genauigkeit ist die Anforderung, an der eine einzelne globale Metrik scheitert. Sie brauchen einen segmentierten Evaluationsdatensatz und ein Attribut, nach dem Sie segmentieren. Das öffnet eine datenschutzrechtliche Frage, für die Art. 10 Abs. 5 eine Ausnahmegrundlage bereithält. Geschrieben vom ML-Engineer, freigegeben vom Produktverantwortlichen.

4. Begründung der Leistungsmetriken

Ein kurzes Kapitel, das fast alle überspringen. Ein F1-Wert von 0,91 genügt nicht. Sie müssen begründen, warum F1 für diese Zweckbestimmung die richtige Metrik ist und warum nicht Recall, Precision oder Kalibrierung. Bei einem Scoring-Modell im Kreditgeschäft läuft der Unterschied darauf hinaus, wem ein falsch positives Ergebnis mehr schadet und wem ein falsch negatives. Geschrieben vom ML-Engineer, gegengelesen von einer unabhängigen Person im Haus.

5. Das Risikomanagementsystem

Nummer 5 verlangt eine detaillierte Beschreibung des Risikomanagementsystems nach Art. 9. Das ist Thema des nächsten Abschnitts, weil es sich als eigenständige Akte besser führen lässt und von hier nur referenziert wird.

6. Änderungen über den Lebenszyklus

Ein Änderungsprotokoll darüber, was der Anbieter über den Lebenszyklus am System geändert hat. Dieses Kapitel hat eine juristische Kante: nach Art. 25 kann eine wesentliche Änderung die Rollen kippen, und wer bisher Betreiber war, wird zum Anbieter. Die Entwicklung führt das Protokoll, ob eine Änderung als wesentlich gilt, entscheidet die Rechtsabteilung.

7. Liste der angewandten harmonisierten Normen

Aufzuführen sind die harmonisierten Normen, die Sie angewandt haben und deren Fundstellen im Amtsblatt der Europäischen Union veröffentlicht sind. Wurde keine harmonisierte Norm angewandt, müssen Sie die stattdessen gewählten Lösungen detailliert beschreiben, mit denen Sie die Anforderungen aus Kapitel III Abschnitt 2 erfüllen. Eine fehlende Norm ist also keine Befreiung, sondern mehr Schreibarbeit. Welche Normen bereits harmonisiert sind, prüfen Sie besser in der aktuellen Liste des Amtsblatts, denn dieser Stand bewegt sich.

8. Kopie der EU-Konformitätserklärung

Die Erklärung nach Art. 47 ist schriftlich, maschinenlesbar und wird in eigener Verantwortung des Anbieters ausgestellt. Für die meisten Anhang-III-Systeme ist der Weg der Konformitätsbewertung nach Art. 43 die interne Kontrolle, der Anbieter stellt die Erklärung also selbst aus, ohne notifizierte Stelle. Unterschrieben wird sie von der Geschäftsführung oder einer bevollmächtigten Führungskraft, weil das eine Haftungsübernahme ist und keine Formalie.

9. Plan zur Beobachtung nach dem Inverkehrbringen

Der Plan nach Art. 72 beschreibt, wie Sie Daten aus dem Realbetrieb sammeln und auswerten und wie diese Erkenntnisse in das Risikomanagement zurücklaufen. Art. 72 Abs. 3 verpflichtet die Kommission, dafür per Durchführungsrechtsakt eine Vorlage zu erlassen; die im Verordnungstext genannte Frist war der 2. Februar 2026. Ob die endgültige Vorlage veröffentlicht ist, konnten wir zum Redaktionsschluss aus keiner öffentlichen Quelle bestätigen. Strukturieren Sie den Plan deshalb so, dass er sich später in eine Vorlage überführen lässt.

Was steht in der Risikoakte nach Art. 9?

Art. 9 Abs. 2 beschreibt das Risikomanagement als fortlaufenden, iterativen Prozess über den gesamten Lebenszyklus mit regelmäßiger Überprüfung. Vier Schritte: bekannte und vernünftigerweise vorhersehbare Risiken ermitteln, sie für die bestimmungsgemäße Verwendung und für vorhersehbaren Fehlgebrauch abschätzen, weitere Risiken aus den Betriebsdaten bewerten und gezielte Risikomanagementmaßnahmen ergreifen.

Eine Zeile in dieser Akte taugt nur, wenn eine außenstehende Person daraus erkennt, was passiert ist. Dazu gehören Kennung und Beschreibung des Risikos, das betroffene Schutzgut (Gesundheit, Sicherheit oder ein Grundrecht), geschätzte Eintrittswahrscheinlichkeit und Auswirkung, die Minderungsmaßnahme, das Restrisiko und dessen Annahme, der Verweis auf den Test, der die Minderung belegt, der Name der verantwortlichen Person und das Datum der nächsten Überprüfung.

Art. 9 Abs. 5 verlangt, dass das Restrisiko sowohl je Einzelrisiko als auch insgesamt als vertretbar beurteilt wird, vorrangig durch Konzeption und Entwicklung gesenkt, danach durch Schutzmaßnahmen und zuletzt durch Information und Schulung nach Art. 13. Art. 9 Abs. 9 hebt die Wirkung auf Personen unter 18 Jahren und auf andere schutzbedürftige Gruppen gesondert hervor.

Von der anderen Seite bindet die Vorfallbehandlung die Akte. Nach Art. 73 ist ein schwerwiegender Vorfall unmittelbar nach Feststellung des Kausalzusammenhangs zu melden, spätestens jedoch binnen 15 Tagen; bei einer weitreichenden Verletzung oder einem Vorfall nach Art. 3 Nr. 49 Buchstabe b binnen 2 Tagen. Wenn aus einem Vorfall keine neue Zeile in der Risikoakte entsteht, lebt die Akte nicht.

Wie schreiben Sie die Beschreibung der Daten-Governance nach Art. 10?

Art. 10 Abs. 2 nennt acht Punkte zu Trainings-, Validierungs- und Testdatensätzen: die Entwurfsentscheidungen, den Erhebungsprozess und die Herkunft der Daten, bei personenbezogenen Daten den ursprünglichen Erhebungszweck, die Aufbereitungsschritte (Annotation, Kennzeichnung, Bereinigung, Aktualisierung, Anreicherung, Aggregation), die getroffenen Annahmen, die Bewertung von Verfügbarkeit und Menge, die Prüfung auf Verzerrungen samt Gegenmaßnahmen und die Ermittlung von Datenlücken.

Nach Art. 10 Abs. 3 müssen Datensätze relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig im Hinblick auf die Zweckbestimmung sein. Art. 10 Abs. 4 verlangt, die geografischen, kontextuellen, verhaltensbezogenen und funktionalen Besonderheiten zu berücksichtigen. Wird das System nicht mit dem Training von Modellen entwickelt, begrenzt Art. 10 Abs. 6 diese Absätze auf den Testdatensatz.

Die häufigste Lücke ist nicht die Verzerrungsprüfung, sondern der Nachweis der Datenherkunft. Im Mittelstand stammen die Trainingsdaten fast immer aus dem eigenen ERP oder CRM, wo der ursprüngliche Erhebungszweck Rechnungsstellung oder Kundenverwaltung war. Art. 10 Abs. 2 Buchstabe b verlangt, das aufzuschreiben, und mit der Zweckbindung der DSGVO muss es ebenfalls zusammenpassen.

Was der Omnibus an der Verzerrungsprüfung geändert hat

Art. 10 Abs. 5 gab ursprünglich nur Anbietern von Hochrisiko-Systemen eine Ausnahmegrundlage, um besondere Kategorien personenbezogener Daten zur Erkennung und Korrektur von Verzerrungen zu verarbeiten, unter sechs strengen Bedingungen: keine andere wirksame Möglichkeit, technische Grenzen der Wiederverwendung, strenge Zugriffskontrolle und Vertraulichkeit, keine Übermittlung an Dritte, Löschung nach der Korrektur und eine dokumentierte Begründung. Der Digital Omnibus hat diese Grundlage auf alle KI-Systeme ausgeweitet und den Maßstab der strengen Erforderlichkeit wiederhergestellt (Freshfields, 10.07.2026).

Gute Nachricht für alle, die Verzerrungen bisher nicht gemessen haben, weil ihnen die Rechtsgrundlage für geschützte Attribute fehlte. Schlechte Nachricht für alle, die das jetzt als Freibrief lesen: die sechs Bedingungen sind geblieben, und die dokumentierte Begründung ist eine davon.

Was muss protokolliert werden, und wie lange bewahren Sie Protokolle auf?

Art. 12 Abs. 1 verlangt, dass ein Hochrisiko-System die automatische Aufzeichnung von Ereignissen über seine Lebensdauer technisch ermöglicht. Art. 12 Abs. 2 nennt drei Zwecke: Erkennung risikobehafteter Situationen und wesentlicher Änderungen, Unterstützung der Beobachtung nach dem Inverkehrbringen gemäß Art. 72 und die Überwachung des Betriebs durch den Betreiber nach Art. 26 Abs. 5. Die Untergrenze der Aufbewahrung liegt bei sechs Monaten.

Für die biometrische Fernidentifizierung setzt Art. 12 Abs. 3 ein konkretes Minimum: Beginn und Ende jeder Verwendung, die Referenzdatenbank, gegen die abgeglichen wurde, die Eingabedaten, zu denen die Suche einen Treffer ergab, und die Identifizierung der natürlichen Personen, die nach Art. 14 Abs. 5 die Ergebnisse überprüfen.

An dieser Stelle sehen wir in vielen Entwicklungsteams denselben Denkfehler. Ein Trace aus einem LLM-Observability-Werkzeug ist kein Protokoll im Sinne von Art. 12. Der Trace ist für Entwickler gebaut, meist gesampelt, wenige Wochen aufbewahrt, und er enthält den Prompt. Das Protokoll nach Art. 12 dient der Prüfbarkeit, lebt über sechs Monate hinaus und sollte personenbezogene Daten nur im erforderlichen Umfang tragen. Beide Systeme können sich speisen, ersetzen einander aber nicht. Was eine Observability-Schicht technisch leistet, steht in unserem Vergleich von LangFuse und LangSmith.

Der Protokollierungsplan selbst ist ein kurzes Dokument. Er listet die Ereignistypen, die erfassten Felder, Rechtsgrundlage und Minimierung personenbezogener Daten, die Aufbewahrungsdauer, die Zugriffsrechte und den Weg, auf dem das Protokoll einer Behörde nach Art. 21 Abs. 2 übergeben werden kann.

Was muss in der Betriebsanleitung und in der Beschreibung der menschlichen Aufsicht stehen?

Art. 13 Abs. 3 nennt sechs Punkte: Identität und Kontaktdaten des Anbieters, Fähigkeiten und Leistungsgrenzen des Systems, vorab festgelegte Änderungen, die Aufsichtsmaßnahmen nach Art. 14, die erforderlichen Rechen- und Hardwareressourcen samt erwarteter Lebensdauer und Wartung sowie eine Beschreibung der Mechanismen, mit denen Betreiber die Protokolle erfassen und auswerten können.

Der schwere Punkt sind Fähigkeiten und Grenzen. Dazu gehören die Zweckbestimmung, das getestete Niveau von Genauigkeit, Robustheit und Cybersicherheit mit den zugehörigen Metriken, jeder bekannte Umstand, der dieses Niveau beeinflussen kann, die Risiken bei vorhersehbarem Fehlgebrauch, die technischen Möglichkeiten zur Erklärung der Ausgabe, die Leistung für bestimmte Personen oder Gruppen und die Vorgaben für die Eingabedaten.

Menschliche Aufsicht ist eine Konstruktionsanforderung

Nach Art. 14 Abs. 1 ist das System so zu gestalten, dass natürliche Personen es wirksam beaufsichtigen können, auch über geeignete Mensch-Maschine-Schnittstellen. Art. 14 Abs. 4 zählt fünf Fähigkeiten auf, die der aufsichtführenden Person zu ermöglichen sind: Fähigkeiten und Grenzen verstehen und Anomalien erkennen, sich des Automatisierungsbias bewusst bleiben, die Ausgabe richtig interpretieren, sich gegen die Nutzung entscheiden oder die Ausgabe überschreiben und den Betrieb anhalten.

Mit einem Satz ist dieses Kapitel nicht erledigt. Wenn in der Beschreibung steht, dass die Nutzerin die Entscheidung überschreiben kann, es in der Oberfläche aber keine Schaltfläche gibt, die das protokolliert tut, widersprechen sich Dokument und System. Im Audit gewinnt das System.

Für die biometrische Identifizierung ergänzt Art. 14 Abs. 5 ein Vieraugenprinzip: aufgrund einer Identifizierung darf erst gehandelt werden, wenn mindestens zwei natürliche Personen mit der nötigen Kompetenz, Ausbildung und Befugnis das Ergebnis getrennt überprüft und bestätigt haben.

Sind Sie Anbieter oder Betreiber, und wann kippt die Rolle?

Die Dokumentationspflichten aus Kapitel III Abschnitt 2 treffen den Anbieter. Wer ein fremdes KI-System nur einsetzt, ist Betreiber und hat das kürzere Pflichtenheft aus Art. 26. Nach Art. 25 wechselt die Rolle jedoch, sobald Sie das System unter eigenem Namen anbieten, es wesentlich verändern oder seine Zweckbestimmung so ändern, dass es hochriskant wird.

Für deutsche Unternehmen ist das die wirtschaftlich wichtigste Frage im ganzen Text, weil die Ausgangslage klar ist. Nach der Erhebung des ifo Instituts vom 5. Juni 2026 entwickeln nur wenige Unternehmen selbst, der große Rest kauft ein.

Aus diesen Zahlen folgt ein praktischer Rat. Prüfen Sie zuerst, ob Sie überhaupt Anbieter sind, bevor Sie ein Dokumentationsprojekt aufsetzen. Und lesen Sie Ihre Lieferantenverträge daraufhin, wer die Unterlagen nach Anhang IV liefert, in welcher Sprache, in welcher Frist und was passiert, wenn der Lieferant den Betrieb einstellt. Diese Klausel fehlt in den meisten Verträgen, die wir sehen.

Die Betreiberseite bleibt trotzdem Arbeit. Art. 26 verlangt, die Aufsicht kompetenten, geschulten und befugten Personen zu übertragen, die Eingabedaten im eigenen Verantwortungsbereich relevant zu halten, Arbeitnehmervertretung und betroffene Beschäftigte vor dem Einsatz am Arbeitsplatz zu informieren und die vom Anbieter erhaltenen Informationen für die Datenschutz-Folgenabschätzung nach Art. 35 DSGVO zu verwenden.

Wer schreibt welches Dokument, und wann wird es aktualisiert?

Aktuell bleibt eine Dokumentation nur, wenn jedes Arbeitsergebnis eine benannte verantwortliche Person und ein auslösendes Ereignis hat. Die Verordnung schreibt keine Organisationsform vor, sondern ein Ergebnis: Art. 11 Abs. 1 verlangt eine aktuell gehaltene technische Dokumentation, Art. 9 Abs. 2 eine regelmäßig überprüfte Risikobetrachtung.

Das größte Risiko für die Aktualität ist nicht Trägheit, sondern dass niemand bemerkt, wann eine Aktualisierung fällig wäre. Bauen Sie einen Prüfpunkt in den Release-Prozess ein: berührt eine Änderung das Modell, die Trainingsdaten, die Zweckbestimmung oder die Oberfläche, geht das Release erst raus, wenn das betroffene Kapitel nachgezogen wurde.

Was verlangt eine Behörde, und wie schnell müssen Sie liefern?

Art. 21 Abs. 1 verpflichtet den Anbieter, auf begründetes Verlangen einer zuständigen Behörde alle Informationen und Unterlagen herauszugeben, die die Konformität mit Kapitel III Abschnitt 2 belegen, in einer für die Behörde leicht verständlichen Sprache. Art. 21 Abs. 2 ergänzt den Zugang zu den Protokollen nach Art. 12 Abs. 1. Für das Übermittelte gilt die Vertraulichkeit nach Art. 78.

Eine in Tagen gemessene Frist enthält Art. 21 nicht. Sie ergibt sich aus dem nationalen Verfahrensrecht und aus dem Auskunftsersuchen. Wer heute plant, fährt besser damit, aus dem Verordnungstext zu arbeiten als aus vermuteter Behördenpraxis.

Was ein deutscher Einkauf zusätzlich verlangt

In der Praxis kommt die Datenschutzfrage vor der AI-Act-Frage. Wo Sie personenbezogene Daten im Auftrag verarbeiten, ist ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO Pflicht, mit den zehn in Art. 28 Abs. 3 vorgeschriebenen Inhalten. Ein fehlender oder fehlerhafter Vertrag hat sein eigenes Risiko von 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes. In der Bitkom-Befragung von 604 Unternehmen ab 20 Beschäftigten, veröffentlicht am 11. März 2026, waren Datenschutzanforderungen mit 77 Prozent die größte externe Hürde für den KI-Einsatz.

Der zweite Strang ist NIS2. Das deutsche Umsetzungsgesetz NIS2UmsuCG änderte das BSIG, wurde am 5. Dezember 2025 im Bundesgesetzblatt verkündet und trat am Folgetag in Kraft; betroffen sind nach openKRITIS etwa 30.000 Unternehmen. Weil NIS2 in die Lieferkette hineinreicht, gibt ein betroffener Kunde seine Sicherheitsanforderungen an Sie als Lieferanten weiter und will die Nachweise schriftlich. Diese Nachweise überschneiden sich mit dem AI-Act-Paket, sind aber nicht dieselbe Menge; beide Seiten bilden wir in unserem Angebot zur NIS2-Compliance ab.

Die Aufbewahrung nach Art. 18 beträgt zehn Jahre ab Inverkehrbringen oder Inbetriebnahme: technische Dokumentation, Unterlagen des Qualitätsmanagementsystems, von einer notifizierten Stelle genehmigte Änderungen und Entscheidungen sowie die EU-Konformitätserklärung. Auf der Sanktionsseite steht die zweite Stufe von Art. 99: 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Für KMU und Start-ups macht Art. 99 Abs. 6 den niedrigeren Betrag zur Obergrenze.

Was gilt, wenn Ihr System nicht hochriskant ist?

Fällt das System unter eine Nummer des Anhangs III, stufen Sie es aber über die Ausnahme in Art. 6 Abs. 3 als nicht hochriskant ein, verlangt Art. 6 Abs. 4 eine dokumentierte Bewertung vor dem Inverkehrbringen oder der Inbetriebnahme, und die Registrierung nach Art. 49 Abs. 2 bleibt bestehen. Auf Verlangen ist die Bewertung vorzulegen. Bei Profiling natürlicher Personen ist die Ausnahme ausgeschlossen.

Vier Fälle kommen in Betracht: Das System erfüllt eine eng gefasste Verfahrensaufgabe, es verbessert das Ergebnis einer zuvor abgeschlossenen menschlichen Tätigkeit, es erkennt Entscheidungsmuster oder Abweichungen davon, ohne die menschliche Bewertung ohne angemessene Überprüfung zu ersetzen, oder es führt eine vorbereitende Aufgabe aus. In allen Fällen gilt zusätzlich, dass vom System kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte ausgehen darf. Wenn Sie die Einstufung Schritt für Schritt durchgehen wollen, führt unser Entscheidungsbaum für Hochrisiko-KI-Systeme durch dieselben Prüfpunkte.

Das Memo zur Ausnahme ist ein kurzes Dokument, lohnt aber eine strenge Struktur: Zweckbestimmung des Systems, in Betracht kommende Nummer des Anhangs III, einschlägiger Ausnahmefall mit Begründung, Begründung für das Fehlen von Profiling, die Risikoanalyse, die das Fehlen eines erheblichen Risikos stützt, Unterschrift mit Datum und der Zeitpunkt der nächsten Bewertung. Das ist unsere empfohlene Struktur, keine gesetzliche Form.

Art. 6 Abs. 5 verpflichtet die Kommission zu Leitlinien über die praktische Abgrenzung zwischen hochriskant und nicht hochriskant. Der Digital Omnibus hat diese Frist auf den 2. August 2027 verschoben. Bis dahin trägt die Einstufung Ihre eigene Begründung, was in unserer Lesart zur Vorsicht rät: im Grenzfall ist die Behandlung als Hochrisiko-System teurer, aber verteidigbar, während eine falsche Ausnahme unter Art. 99 fällt.

Die Registrierungspflicht für selbst als nicht hochriskant eingestufte Anhang-III-Systeme hat der Omnibus beibehalten, mit geringerem Verwaltungsaufwand. Die Pflicht ist also nicht verschwunden, es sind nur weniger Felder auszufüllen.

Was Sie mitnehmen sollten

Wenn Sie das minimale Paket suchen, mit dem ein Anhang-III-System starten kann, steht es in unserer Checkliste für Hochrisiko-KI-Systeme. Einstufung, Dokumentenaufbau und Auditvorbereitung als Projekt gehören zu unserem Angebot zur AI-Act-Compliance.

Dieser Text ist eine Information auf Basis der genannten Quellen und ersetzt keine rechtliche Prüfung des konkreten Systems. Einstufung und Dokumentationsinhalt unterscheiden sich von System zu System, und die nationalen Durchführungsregeln bewegen sich noch.