Art. 16 EU AI Act: Die Pflichtenliste für Anbieter

Wer den EU AI Act zum ersten Mal liest, sucht meist nach einer einzigen Frage: Was genau muss ich eigentlich tun? Für Anbieter von Hochrisiko-KI-Systemen gibt es darauf eine erstaunlich konkrete Antwort. Artikel 16 der Verordnung (EU) 2024/1689 listet die Pflichten auf — nicht als Prinzipien, sondern als Aufzählung. Er ist damit der Einstiegspunkt in das gesamte Kapitel III, Abschnitt 3.

Das macht Art. 16 zugleich zum meistunterschätzten Artikel der Verordnung. Denn er beschreibt nichts Neues, sondern verweist. Fast jeder seiner Buchstaben zeigt auf einen anderen Artikel, in dem die eigentliche Arbeit steckt. Wer Art. 16 als Checkliste abhakt, ohne die Verweisungen zu öffnen, unterschätzt den Aufwand systematisch.

Was Art. 16 tatsächlich anordnet

Die Norm richtet sich an Anbieter — also an diejenigen, die ein Hochrisiko-KI-System entwickeln oder entwickeln lassen und unter eigenem Namen oder eigener Marke in Verkehr bringen oder in Betrieb nehmen. Die Definition steht in Art. 3 Nr. 3. Wichtig ist die Abgrenzung zum Betreiber (Deployer): Wer ein System nur einsetzt, fällt grundsätzlich unter Art. 26 — kann aber nach Art. 25 in die Anbieterrolle rutschen, etwa durch wesentliche Änderungen oder durch Anbringen des eigenen Namens.

Die Pflichten selbst lassen sich in vier Blöcke gliedern:

Produktbezogene Anforderungen. Das System muss die Anforderungen aus Abschnitt 2 erfüllen — also Risikomanagement (Art. 9), Daten-Governance (Art. 10), technische Dokumentation (Art. 11), Protokollierung (Art. 12), Transparenz gegenüber Betreibern (Art. 13), menschliche Aufsicht (Art. 14) sowie Genauigkeit, Robustheit und Cybersicherheit (Art. 15). Diese sieben Artikel sind der eigentliche Kern.

Organisationsbezogene Anforderungen. Anbieter müssen ein Qualitätsmanagementsystem nach Art. 17 unterhalten. Das ist kein Papier-Add-on, sondern ein dokumentierter Prozess über den gesamten Lebenszyklus: Entwicklungsstrategie, Prüfverfahren, Datenverwaltung, Änderungssteuerung, Verantwortlichkeiten.

Nachweisbezogene Anforderungen. Dazu gehören die Aufbewahrung der technischen Dokumentation und der automatisch erzeugten Protokolle (Art. 18, Art. 19), das Konformitätsbewertungsverfahren nach Art. 43, die EU-Konformitätserklärung nach Art. 47, die CE-Kennzeichnung nach Art. 48 und die Registrierung in der EU-Datenbank nach Art. 49.

Reaktionsbezogene Anforderungen. Anbieter müssen Korrekturmaßnahmen ergreifen und informieren, wenn ein System nicht konform ist (Art. 20), zuständigen Behörden auf begründetes Verlangen Auskunft und Zugang geben (Art. 21) und barrierefreie Nutzbarkeit sicherstellen, soweit die einschlägigen Unionsvorschriften das verlangen.

Der Kontrollpunkt heißt Zuordenbarkeit

Interessant an Art. 16 ist eine Nebenpflicht, die leicht überlesen wird: Anbieter müssen ihren Namen, ihren eingetragenen Handelsnamen oder ihre eingetragene Marke sowie eine Kontaktanschrift auf dem System selbst angeben — oder, wo das nicht möglich ist, auf der Verpackung oder in den beiliegenden Unterlagen.

Das wirkt banal, ist aber die Grundlage für alles Weitere. Marktüberwachungsbehörden brauchen einen Adressaten. Betreiber brauchen jemanden, an den sie Vorfälle melden. Und nachgelagerte Anbieter, die ein System in ihre eigene Wertschöpfungskette integrieren, brauchen Klarheit darüber, wessen Konformitätserklärung sie eigentlich in der Hand halten.

In der Praxis ist genau das häufig unklar. Ein Modell wird über eine API bezogen, in eine eigene Anwendung eingebettet, unter eigenem Produktnamen an Kunden ausgeliefert — und die Frage, wer hier Anbieter ist, wird erst gestellt, wenn eine Behörde anfragt. Art. 25 löst diese Frage rechtlich, Art. 16 macht sie sichtbar.

Warum die Liste ohne Evidenz nicht funktioniert

Art. 16 formuliert Pflichten, nicht Nachweisformate. Die Verordnung geht offenkundig davon aus, dass ein Anbieter, der diese Pflichten erfüllt, das auch belegen kann — sonst wären Art. 18, Art. 19 und Art. 21 sinnlos.

Das ist der Punkt, an dem viele Programme scheitern. Nicht daran, dass Risikomanagement fehlt, sondern daran, dass niemand rekonstruieren kann, welche Risikobewertung zu welchem Zeitpunkt für welche Modellversion galt. Ein Risikomanagementsystem nach Art. 9 ist ausdrücklich ein kontinuierlicher, iterativer Prozess über den gesamten Lebenszyklus. Wer den Prozess führt, aber die Zwischenstände nicht versioniert, hat die Pflicht erfüllt und den Nachweis verloren.

Praktisch heißt das: Für jeden Buchstaben von Art. 16 sollte klar sein, welches Artefakt ihn belegt, wo dieses Artefakt liegt, wer es erzeugt hat, wann es entstanden ist und auf welche Systemversion es sich bezieht. Diese fünf Angaben sind die Mindest-Metadaten einer belastbaren Nachweiskette. Ohne sie ist Dokumentation nur Text.

Für Anbieter, die zusätzlich ein KI-Managementsystem nach ISO/IEC 42001 aufbauen, ergibt sich hier eine natürliche Verzahnung: Das Statement of Applicability und die Annex-A-Maßnahmen liefern die organisatorische Struktur, Art. 16 liefert die regulatorische Zielsetzung. Die Reifegradbetrachtung über AIMS (ISO 42001 × CMMI v3) zeigt dann, ob ein Prozess nur einmal durchlaufen wurde oder tatsächlich wiederholbar und gesteuert ist. Das ist der Unterschied zwischen einer bestandenen Erstprüfung und einem System, das auch beim dritten Audit trägt.

Zeitrahmen und Einordnung

Mit dem Digital Omnibus verschiebt sich die Durchsetzung der Hochrisiko-Anforderungen auf den 02.12.2027. Das klingt nach Zeit, ist aber für Anbieter knapp: Konformitätsbewertung, technische Dokumentation, Qualitätsmanagementsystem und Registrierung müssen zu diesem Zeitpunkt nicht begonnen, sondern abgeschlossen sein. Vorgelagert stehen je nach Verfahren die Einbindung einer notifizierten Stelle und die Verfügbarkeit harmonisierter Normen.

Wer heute anfängt, arbeitet mit Vorlauf. Wer 2027 anfängt, arbeitet gegen die Uhr — und zwar in einem Markt, in dem Prüfkapazität knapp sein dürfte.

Eine praktische Einstiegsreihenfolge, die sich bewährt hat: erst die eigene Rolle je System eindeutig klären (Anbieter oder Betreiber), dann die Klassifizierung nach Art. 6 und Anhang III, dann die Lücken gegen die sieben Artikel aus Abschnitt 2, und erst danach die formalen Schritte Konformitätsbewertung, Erklärung, CE, Registrierung. Wer in umgekehrter Reihenfolge beginnt, produziert Formalien ohne Substanz.

Eine ausführlichere Übersicht der Hochrisiko-Kategorien und ihrer Einordnung finden Sie auf hochrisiko-ki.com.

Fazit

Art. 16 ist kein eigenständiger Pflichtenkatalog, sondern das Inhaltsverzeichnis eines umfangreichen Programms. Seine Stärke liegt in der Vollständigkeit: Wer die Liste durchgeht und für jede Position ein benanntes, versioniertes, zuordenbares Artefakt vorweisen kann, hat den Nachweisstand, den eine Behörde nach Art. 21 erwarten darf.

Die eigentliche Arbeit besteht nicht darin, die Pflichten zu kennen, sondern darin, ihre Erfüllung dauerhaft belegbar zu halten — über Modellversionen, Teamwechsel und Jahre hinweg. Genau dafür braucht es Trust-Infrastructure: nachvollziehbare Herkunft, unveränderbare Spuren, prüfbare Zuordnung. Compliance ist dann das Ergebnis, nicht der Ausgangspunkt.

Mehr zur AEGIRA Trust-Platform: aegira.ai

Quellen: Verordnung (EU) 2024/1689 (EU AI Act), insbesondere Art. 3, 16–21, 25, 43, 47–49; ISO/IEC 42001:2023. Dieser Beitrag ersetzt keine Rechtsberatung.