— VendorVet

von VendorVet (LX AI)

Gemäß der Verordnung (EU) 2024/1689 müssen Anbieter von Hochrisikoproducten technische Dokumentationen erstellen, die die Konformität vor dem Marktzugang nachweisen. Teams erstellen oft die offensichtlichen Teile und übersehen dabei, was die Prüfer zuerst öffnen: Zusammenfassungen der Datensätze, Designs mit menschlicher Aufsicht und Überwachung nach dem Marktzugang. Jede generierte Gliederung sollte als Entwurf betrachtet werden, der gegen das Amtsblatt der EU überprüft werden muss, und nicht als fertige Einreichung.

Was die Dokumentationspflicht tatsächlich abdeckt

Artikel 11 und Anhang IV legen den Inhalt der Dokumentation für Systeme mit hohem Risiko fest. Das Paket umfasst den beabsichtigten Zweck, Designentscheidungen, Entwicklungsgeschichte, Leistungsansprüche und die tatsächlich durchgeführten Risikomanagementmaßnahmen. Die Kommission fasst den Akt als risikobasiertes Rahmenwerk mit schwereren Pflichten für den Einsatz mit hohem Risiko zusammen; beginnen Sie mit dieser Einrahmung, bevor Sie ein benutzerdefiniertes Template erstellen (Europäische Kommission — KI-Gesetz).

Der verbindliche Text ist die Verordnung selbst auf EUR-Lex (Verordnung (EU) 2024/1689). Sekundäre Blogs und Präsentationsfolien sind nur nützlich, nachdem Sie auf den Artikel und den Anhang verweisen können, der jede Behauptung unterstützt. Ich behandele die Dokumentation als eine lebende Dateisammlung unter Versionskontrolle, nicht als ein einmaliges PDF, das eine Woche vor einer Demo exportiert wurde.

Lebenszyklus, nicht ein Freeze-Frame

Wenn das Modell geändert wird, die Trainingsmenge aktualisiert oder eine Sicherheitssteuerung umkonfiguriert wird, muss die Dokumentation die Änderung zeigen. Änderungshinweise, Besitzer und Datum sind ebenso wichtig wie die erste Aufzeichnung. Wenn ein Deployer fragt: "Welche Build-Version war am Dienstag in Produktion?", sollten Sie aus demselben Datensatz antworten, der die Konformität unterstützt — und nicht aus einem Slack-Thread.

Schritt-für-Schritt-Arbeitsablauf, den wir verwenden, bevor wir ein Paket als "fertig" bezeichnen

- Bestätigen Sie, dass das System unter Artikel 6 / Anhang III als hochrisikig eingestuft wird (oder als solches behandelt wird), bevor Sie einen Dokumentationsbaum erstellen. Wenn es nicht hochrisikig ist, sollten Sie nicht zu viel über die Vollständigkeit von Anhang IV in Verkaufskopien behaupten. - Öffnen Sie Anhang IV und erstellen Sie für jedes Thema einen Ordner oder ein Ticket: allgemeine Beschreibung, Design-Spezifikationen, Entwicklungsprozess, Daten, Risikomanagement, Tests, Überwachung und menschliche Aufsicht. - Weisen Sie einem einzelnen Besitzer pro Thema zu. Gemeinsame Besitzverhältnisse ohne Namen sind der Grund, warum Abschnitte leer bleiben. - Erstellen Sie mit Produkt- und Ingenieurteams im Raum. Rechtsberatung prüft Behauptungen; Ingenieure liefern Beweiswege (Konfigurationen, Dashboards, Testberichte). - Verknüpfen Sie jede Behauptung mit einem Artefakt: einer Zusammenfassung der Datensätze, einem Logging-Schema, einem Runbook, einer Zeile im Risikoregister. Unverknüpfte Prosa ist ein Geruch. - Gehen Sie das Paket gegen das Live-System durch: stimmt die Logging-Konfiguration mit den Behauptungen in Artikel 12 überein? Stimmt der Override-Pfad in der Benutzeroberfläche mit dem Text in Artikel 14 überein? - Planen Sie einen Aktualisierungs-Trigger: Versionswechsel des Modells, wesentliche Änderung der Datensätze, neue Deployer-Klasse oder ernsthafter Vorfall. Es ersetzt nicht die Urteilsfindung oder Beratung von benannten Stellen. Verwenden Sie das Produkt, um Auslassungen frühzeitig zu erkennen; verwenden Sie das Amtsblatt, um Streitigkeiten zu klären.

Zusammenfassungen von Datensätzen, die Teams überspringen (Artikel 10)

Artikel 10 erwartet eine Datenverwaltung: Trainings-, Validierungs- und Testdaten sollten für den beabsichtigten Zweck relevant und repräsentativ sein, mit einer Überprüfung auf Voreingenommenheit und Lücken, die die Leistung für die von dem System betroffenen Personen beeinträchtigen würden. Prüfer suchen nach einer Zusammenfassung der verwendeten Daten und deren Überprüfung - nicht nach einem Marketing-Modellkarten mit drei Adjektiven.

Eine Checkliste-Zeile, die „Daten überprüft“ sagt, ohne dass eine Zusammenfassung dahinter steht, scheitert an der ersten ernsthaften Überprüfung. Schreiben Sie die Zusammenfassung so, dass ein neuer Ingenieur folgende Fragen beantworten kann: Quellbereiche, Zeitfenster, bekannte Schiefe, Ausschlussregeln und wie Labels produziert oder überprüft wurden. Wenn personenbezogene Daten in der Pipeline sind, halten Sie Ihre GDPR-Rollen und -Grundlagen konsistent mit der Beschreibung der Verarbeitung an anderen Stellen; die EDPB-Leitlinienbibliothek ist die praktische Überprüfung für diese Sprache (EDPB-Richtlinien und Best Practices).

Checkliste - Datenbeweis

- Inventar von Trainings-/Validierungs-/Testsets mit Eigentümer und letztem Aktualisierungsdatum - Repräsentativitätsnotizen, die an den beabsichtigten Zweck gebunden sind (wer ist im Umfang, wer ist ausgeschlossen) - Methode zur Überprüfung von Voreingenommenheit und Fehlern - auch wenn unvollkommen - mit angegebener Restrisiko - Labeling- oder Annotierungsprozess, einschließlich Qualitätskontrollen - Aufbewahrungs- und Zugriffsregeln für die Datensätze selbst

Menschliche Aufsichtsentwurf (Artikel 14)

Artikel 14 fordert eine sinnvolle menschliche Aufsicht: Schnittstellen und Kontrollen, die es einer Person ermöglichen, Ausgaben zu überwachen, zu interpretieren und bei Bedarf zu überschreiben. "Menschen bleiben im Kreis" ist kein Mechanismus. Dokumentieren Sie den spezifischen Überschreibungspfad, wer ihn ausüben darf, wie das System signalisiert, dass ein Mensch eingreifen sollte, und was passiert, wenn der Mensch nicht verfügbar ist.

Bei Agenten-Produkten bedeutet dies oft einen harten Stopp vor einer folgenreichen Aktion (Veröffentlichung der Shortlist, Versand der Kreditentscheidung, Aktualisierung der Akte), nicht einen dekorativen Genehmigungsknopf, der nach drei Sekunden automatisch feuert. Koppeln Sie die UI-Beschreibung mit der Laufzeitrichtlinie: welche Rollen, welche Umgebungen, welche Audit-Ereignisse werden ausgelöst, wenn die Überschreibung verwendet wird.

Checkliste — Nachweis der Aufsicht

- Benannte Aufsichtsrollen und Eskalationspfad - UI- oder API-Steuerungen, die die KI-Aktion tatsächlich pausieren oder umkehren - Signale/Schwellenwerte, die eine menschliche Überprüfung erfordern - Schulung oder Handbuch für die Menschen, die die Aufsicht führen - Nachweis, dass Überschreibungsevents protokolliert werden

Nachmarküberwachung und Protokollierung (Artikel 12 und 72)

Artikel 12 erfordert eine automatische Protokollierung, die für die Rückverfolgbarkeit ausreicht, mit einer Mindestspeicherfrist von sechs Monaten für Hochrisikosysteme. Artikel 72 ergänzt die Pflichten zur Meldung von schwerwiegenden Vorfällen. Teams dokumentieren das Modell und vergessen den Laufzeitnachweisplan. Kombinieren Sie die Dokumentation mit der tatsächlichen Protokollierungskonfiguration, damit beide übereinstimmen.

Wenn Sie bereits GenAI-Überwachung durchführen, ordnen Sie Spans und Ereignisse den Fragen zu, die eine Nachmarküberprüfung stellen wird: welche Eingabeklasse, welche Modellversion, welche Richtlinienentscheidung, welche menschliche Aktion. Die GenAI-Konventionen von OpenTelemetry sind ein praktischer technischer Referenzpunkt für die konsistente Benennung dieser Felder über Dienste hinweg (OpenTelemetry — GenAI-Überwachung). Das Gesetz verlangt nicht OTel; konsistente Spuren machen es jedoch einfacher, die Ansprüche von Artikel 12 zu verteidigen.

Häufige Fehler in Dokumentationspaketen

- Schreiben für das Broschüreninhaltsverzeichnis, nicht für das Anhangverzeichnis. Hübsche Diagramme, die nie Themen aus Anhang IV zitieren, verschwenden Überprüfungszeit. - Kopieren einer US-RMF-Arbeitsmappe und Umbenennen in "AI-Act-Paket“. Das NIST-AI-Risikomanagement-Framework (NIST AI RMF) ist nützlich für Prozessvokabular, aber es ersetzt nicht den Inhalt von Artikel 11 / Anhang IV. - Dokumentieren des Modells von gestern. Die Produktion hat sich bereits bewegt; das Paket nicht. - Leere Deployer-Anweisungen lassen. Die Transparenz von Artikel 13 gegenüber Deployern ist leicht zu übersehen, wenn das Anbieter-Team nur mit sich selbst spricht. - Ein Checklist als „zertifiziert“ bezeichnen. Diese Sprache überbeansprucht. Checklisten reduzieren das Omissionsrisiko; sie bescheinigen jedoch keine Konformität.

Entscheidungskriterien: Paket versenden oder weiterentwickeln

Behandeln Sie das Paket als release-blockierend für einen Hochrisikostart, wenn einer der folgenden Punkte zutrifft:

- Keine Zusammenfassung der Daten, der von einer dritten Partei gefolgt werden kann - Kein beschriebener Mechanismus für menschliche Überwachung, der an eine reale Kontrolle geknüpft ist - Protokollspeicherung unter sechs Monaten oder Protokolle, die keine Entscheidung rekonstruieren können - Risikoregister mit keinem Eigentümer für Restrisiken - Beabsichtigter Zweck so vage, dass eine Annex-III-Zuordnung unmöglich ist

Sie können immer noch interne Prototypen versenden, die den EU-Hochrisikoeinsatz nie berühren. Seien Sie ehrlich über den Umfang in schriftlicher Form. Mehrdeutige Sprache wie "wir kommen dem in spiritu nach" ist schlimmer als ein klarer "noch nicht hochrisig / noch nicht auf dem EU-Markt"-Status.

Was dies nicht ist

Diese Seite ist keine Rechtsberatung, keine Bewertung durch eine benannte Stelle und keine Garantie dafür, dass Ihr System der Verordnung (EU) 2024/1689 entspricht. VendorVet beansprucht keine 100%ige Abdeckung, erfindet keine Kunden-Gewinnraten und ersetzt keinen Rechtsrat oder eine Konformitätsbewertung, wo eine erforderlich ist. Eine Checkliste hilft Ihnen, Themen zusammenzustellen und zu überprüfen; die verbindliche Pflicht bleibt die in Artikel 11 und Anhang IV beschriebene Dokumentation, die von qualifizierten Personen in Ihrer Organisation erstellt wird.

Schluss

Beginnen Sie mit dem Text des Amtsblatts, ordnen Sie die Themen von Anhang IV den Eigentümern zu und füllen Sie dann die drei Lücken, die die Prüfer zuerst öffnen: Daten, Aufsicht und Protokollierung. Halten Sie das Paket versioniert mit dem System. Wenn das Modell oder der Datensatz verschoben wird, verschieben Sie die Dokumentation im gleichen Release-Zug. Für die Entscheidung über die Risikostufe, die über all dies liegt, lesen Sie unser Schwestertext über die Risikostufen des EU-AI-Gesetzes.