Ein vollständiger Dokumentationsordner kann trotzdem das falsche KI-Release beschreiben. Gleichen Sie vor der Freigabe bewertete Zweckbestimmung, Systemrevision, Testsuite und Überwachungsplan mit unveränderlichen Nachweisen ab. Automatisieren Sie Referenz- und Versionsprüfungen; die fachliche Eignung und rechtliche Tragfähigkeit beurteilen verantwortliche Prüfer. Eine passende Prüfsumme ist keine Konformitätsbewertung.
Dieser Beitrag beschreibt eine vorgeschlagene technische Kontrolle für Dokumentationsprozesse. Er ist keine Rechtsberatung, keine amtliche Vorlage für Anhang IV und kein Compliance-Zertifikat. Qualifizierte Rechtsberater müssen Systemklassifizierung, Akteursverantwortung, anwendbare Vorschriften und Termine, vereinfachte Dokumentationswege sowie Wechselwirkungen mit Produktrecht prüfen, bevor Sie eine echte Nachweismatrix einsetzen.
Warum vorhandene Dateien als Freigabekriterium nicht reichen
Betrachten Sie einen hypothetischen Inspektionsassistenten beim Wechsel von Release r16 zu r17. Im Ordner liegen Zweckbeschreibung, unterschriebener Prüfbericht und Überwachungsplan. Alle Links funktionieren. Der Bericht bewertet jedoch r16 mit eval-7, während der Kandidat eval-8 benötigt; der Überwachungsplan bezieht sich noch auf purpose-2 statt purpose-3. Die Dateizählung meldet Vollständigkeit. Der Nachweisabgleich zeigt, dass das Paket diesen Kandidaten nicht trägt.
Das ist eine andere Aufgabe als der Aufbau einer Architektur für Logging und technische Dokumentation. Logging zeichnet den Betrieb auf. Der Abgleich prüft Beziehungen zwischen unabhängig gepflegten Nachweisen. Auch das LLM-Release-Bundle erfüllt einen anderen Zweck: Es fixiert Laufzeitabhängigkeiten für Reproduzierbarkeit und Rollback. Das Dokumentationspaket erläutert das bewertete System, Kontrollen, Grenzen und Prüfgrundlagen. Beide benötigen gemeinsame Identitäten, sind aber nicht austauschbar.
Beginnen Sie mit einem geprüften Geltungsbereich
Artikel 11 in der EUR-Lex-Konsolidierung beschreibt, dass technische Dokumentation eines Hochrisiko-KI-Systems vor dem Inverkehrbringen oder der Inbetriebnahme erstellt und aktuell gehalten wird. Technisch folgt daraus eine Versionsbeziehung, nicht die Verpflichtung, genau die hier vorgeschlagene JSON-Struktur zu verwenden.
Die Referenz der Kommission zu Anhang IV verbindet Zweckbestimmung und Systemversion, relevante Softwareversionen, Validierung und Tests, Änderungen im Lebenszyklus sowie Überwachung nach dem Inverkehrbringen. Nummer 2(g) nennt Testprotokolle sowie datierte und von verantwortlichen Personen unterzeichnete Prüfberichte. Ein Digest im Manifest ersetzt weder die Unterschrift noch die fachliche Bewertung der Tests.
Die Quellenprüfung am 8. Oktober 2026 umfasste die Konsolidierung und den ändernden Rechtsakt im Amtsblatt. Die Erläuterung der Kommission zu Artikel 11 weist ausdrücklich darauf hin, dass der angezeigte Text noch nicht an Änderungen angepasst wurde. Nutzen Sie diese Seite zur Orientierung, nicht als aktuellen rechtlichen Regelbestand. Konsolidierungen sind Dokumentationshilfen; für die rechtliche Auslegung sind die authentischen Amtsblatttexte und qualifizierte Prüfung maßgeblich. Leiten Sie daraus nicht ab, dass jede genannte Vorschrift bereits auf jeden Einsatz anwendbar ist.
Lassen Sie Rechts- und Compliance-Verantwortliche ein versioniertes Geltungsbereichsverzeichnis pflegen. Jedes möglicherweise relevante Element erhält eine Anwendbarkeitsentscheidung, Begründung und verantwortete Prüfreferenz. Vereinfachte Formulare und kombinierte Produktdokumentation sind Gegenstand rechtlicher Prüfung, kein Anlass zum stillen Löschen von Zeilen. Eine allgemeine Modellkarte kann das Systemdossier unterstützen, ersetzt aber nicht das Dossier eines Hochrisiko-KI-Systems.
Eine maschinenlesbare Matrix ohne versteckte Lücken
Verwenden Sie ein unabhängig kontrolliertes Geltungsbereichsverzeichnis und ein Nachweismanifest. Andernfalls kann ein Autor die Prüfung bestehen, indem er eine unbequeme Zeile entfernt. Das Verzeichnis definiert erwartete Element-IDs; das Manifest liefert die Nachweise. Versionieren Sie beide und speichern Sie ihre Digests mit dem Prüfergebnis.
Das folgende JSON ist ein bewusst unvollständiges synthetisches Lehrbeispiel, keine rechtliche Festlegung der erforderlichen Nachweise. Feldnamen bleiben über Sprachversionen hinweg stabil. Ersetzen Sie den SHA-256-Platzhalter durch einen berechneten Digest; ein echtes Schema muss den Platzhalter ablehnen. Das Beispiel enthält nur ein anwendbares Element und lässt den größten Teil von Anhang IV aus.
{"system_id":"inspection-assist","release_id":"r17","purpose_revision":"purpose-3","policy_ref":"reviewed-scope-1","rows":[{"element":"IV-2g","applicability":"applicable","scope_rationale":"Tests für den bewerteten Inspektionsablauf","owner":"evaluation-owner","system_id":"inspection-assist","release_id":"r17","purpose_revision":"purpose-3","evidence_type":"test_report","artifact_ref":"evidence/report-r17.json","sha256":"REPLACE_WITH_COMPUTED_SHA256","review_status":"pending","review_ref":"review-42","missing_reason":""}]}
Kennzeichnen Sie ausgeschlossene Elemente mit applicability=not_applicable, ausdrücklicher na_reason, Verantwortlichem und geprüfter Geltungsbereichsentscheidung. Ein fehlendes Feld bedeutet unbekannt, nicht nicht-anwendbar. Behalten Sie bei fehlenden Nachweisen die Zeile mit missing_reason und einem Verantwortlichen für die Behebung bei. Eine dokumentierte Begründung darf einen fehlenden Bericht nicht in einen bestandenen Nachweis verwandeln.
Erlauben Sie produktiv mehrere Nachweisreferenzen je Element und die Zuordnung eines Artefakts zu mehreren Elementen. Die Testimplementierung nutzt eine Referenz je Zeile, damit die Prüfungen nachvollziehbar bleiben. Reale Referenzen benötigen unveränderliche Objektversionen, Zugriffsbedingungen, Nachweistyp, Erstellungs- und Prüfherkunft sowie eine ausdrückliche Bindung an die bewertete Konfiguration. Schreiben Sie ein unverändertes Architekturdokument nicht für jeden Build neu: Eine geprüfte Weiterverwendungsentscheidung kann seine Gültigkeit für ein neues Release begründen, ohne das ursprüngliche Artefakt zu verändern.
Prüfen Sie Identität, Bytes und Bedeutung getrennt
Erstens: Validieren Sie Manifest- und Richtlinienschema, bevor Sie Referenzen auflösen. Lehnen Sie doppelte Element-IDs, unbekannte Anwendbarkeitswerte, fehlerhafte Digests und ungeprüfte Geltungsbereichsrevisionen ab. Vergleichen Sie erwartete Element-IDs mit vorhandenen Zeilen. Ein syntaktisch gültiges leeres Array darf ein nicht leeres geprüftes Verzeichnis nicht erfüllen.
Zweitens: Laden Sie Nachweise über einen freigegebenen Repository-Adapter, nicht über beliebige URLs aus dem Manifest. Fehlendes Objekt, verweigerter Zugriff und Backend-Zeitüberschreitung sind unterschiedliche Befunde; alle bleiben für die Freigabe ungeklärt. Dokumentieren Sie, welcher berechtigte Dienst und welcher Prüfer zugreifen konnten. Erzeugen Sie weder einen SSRF-Pfad noch unbeschränkte Kopien vertraulicher Berichte im Build-Protokoll.
Drittens: Berechnen Sie den Hash der tatsächlich geladenen Bytes der fixierten Objektversion. Vergleichen Sie ihn mit dem geprüften Manifest. Aktualisieren Sie den erwarteten Digest nach einer Abweichung nicht automatisch; damit würden Sie veränderte Nachweise ungeprüft akzeptieren. Lesen Sie den Bericht oder seine kontrollierten Begleitmetadaten und vergleichen Sie system_id, release_id und purpose_revision mit Kandidat und Zeilenbindung. Ein passender Dateiname reicht nicht.
Viertens: Vergleichen Sie die Testsuite-Revision mit der für diesen Kandidaten genehmigten Suite, produktiv einschließlich Datensatz- und Evaluatorrevision. Eine neuere Suite ist nicht automatisch für jedes historische Release verbindlich. Der Fehler liegt in der Abweichung von der geprüften Kandidatenrichtlinie. Bewahren Sie den ersetzten Bericht historisch auf; überschreiben Sie ihn nicht, damit der Ordner aktuell wirkt.
Fünftens: Binden Sie den Überwachungsplan an dieselbe bewertete Zweckbestimmung und relevante Betriebskonfiguration. Die Prüfung erkennt einen Revisionskonflikt; sie kann nicht beurteilen, ob der Plan die richtigen Personengruppen, Risiken, Kennzahlen oder Eskalationspflichten abdeckt. Dafür benötigen Sie Fach- und Domänenprüfung. Haben sich Zweck oder Entscheidungsbefugnis geändert, übergeben Sie die Fakten an die separate Prüfung einer wesentlichen Veränderung, nicht an eine automatische rechtliche Klassifizierung.
Geben Sie STRUCTURALLY_RECONCILED nur aus, wenn keine strukturellen Befunde verbleiben. Für diese Prüfung bleiben technical_adequacy=NOT_ASSESSED und legal_sufficiency=NOT_ASSESSED immer erhalten. Das Ergebnis unterstützt eine autorisierte Freigabeentscheidung; es ist keine Bereitstellungsberechtigung.
Entscheidungstabelle: Nachweiszustände gezielt bearbeiten
| Befund | Technisch feststellbar | Vorgeschlagene Freigabeaktion | Verantwortlich |
|---|---|---|---|
| Fehlende Referenz oder Zugriffsausfall | Erforderlicher Nachweis nicht abrufbar | Kandidat zurückhalten; berechtigten Zugriff oder geprüften Nachweis herstellen | Nachweisverantwortlicher |
| Digest-Abweichung | Geladene Bytes weichen von der Erwartung ab | Beide Versionen sichern; Ursache klären und Prüfung neu öffnen | Repository-Verantwortlicher |
| Release- oder Systemkonflikt | Nachweisbindung beschreibt anderen Kandidaten | Passenden Nachweis oder geprüfte Weiterverwendungsbindung beschaffen | Release-Verantwortlicher |
| Ersetzte Testsuite | Bericht widerspricht Kandidatenrichtlinie | Erforderliche Tests wiederholen oder begründete Richtlinienänderung prüfen | Evaluierungsverantwortlicher |
| Konflikt zwischen Überwachung und Zweck | Plan und bewerteter Zweck haben andere Revisionen | Plan und Zweck abgleichen; betriebliche Abdeckung beurteilen | Betrieb und Fachprüfer |
| Unbegründeter Ausschluss oder fehlende Zeile | Geprüfte Abdeckung unvollständig | Geltungsbereich erneut prüfen; nie stillschweigend ausschließen | Compliance-Verantwortlicher |
| Alle Strukturprüfungen bestanden | Referenzen und konfigurierte Bindungen stimmen | Fachliche Eignung und autorisierte Freigabe prüfen lassen | Technische und rechtliche Prüfer |
Zurückhalten bedeutet hier, die Kandidatenfreigabe nach der vorgeschlagenen internen Richtlinie zu blockieren. Es ist keine Anweisung, ein laufendes Industriesystem abzuschalten. Betriebssicherheit, Incident Response und mögliche rechtliche Aussetzungspflichten bleiben getrennte, genehmigte Prozesse.
Was die synthetische Prüfung tatsächlich erkannt hat
Für diesen Beitrag wurde eine lokale Python-Testimplementierung mit synthetischen JSON-Artefakten im Speicher und SHA-256-Prüfungen ausgeführt. In 12 mit Assertions geprüften Fällen lieferte sie die erwarteten Befunde: eine fehlerfreie Ausgangskonfiguration sowie fehlender Nachweis, veränderte Bytes, falsches Release, ersetzte Suite, abweichender Überwachungszweck, gelöschte Zeile, unbegründeter Ausschluss, ausstehende Prüfung, doppelte Zeile, ungeklärte Anwendbarkeit und falsches System. Das sind Implementierungstests, keine Kundenergebnisse und kein Beweis rechtlicher Vollständigkeit.
Die Ausgangskonfiguration ergab {"state":"STRUCTURALLY_RECONCILED","issues":[],"legal_sufficiency":"NOT_ASSESSED","technical_adequacy":"NOT_ASSESSED"}. Das Entfernen des Prüfberichts ergab DANGLING_REFERENCE und MISSING_REASON. Ein zusätzliches Leerzeichen-Byte im weiterhin gültigen JSON ergab BYTES_CHANGED. Ein geänderter Zweck im Überwachungsplan ergab selbst nach neu berechnetem Digest noch PURPOSE_REVISION_MISMATCH. Integrität und Kontextkonsistenz sind unabhängige Prüfungen.
Den Kernalgorithmus können Sie so nachbilden: Initialisieren Sie Befundliste und Menge bereits gesehener Elemente. Prüfen Sie je Zeile Verantwortlichen, Geltungsbereichsbegründung, Nachweistyp und Prüfreferenz; weisen Sie doppelte oder ungeprüfte Elemente zurück. Behandeln Sie geprüfte Ausschlüsse gesondert. Laden Sie für anwendbare Zeilen die Bytes, vergleichen Sie SHA-256, lesen Sie kontrollierte Metadaten und vergleichen Sie die drei Identitätsfelder sowie die erforderliche Suite. Ergänzen Sie nach der Schleife COVERAGE_MISSING für jedes erwartete, aber nicht gesehene Element. Geben Sie Befunde und beide NOT_ASSESSED-Felder zurück, auch bei Erfolg.
Die Testimplementierung vertraut absichtlich ihrer lokalen Richtlinie und den Prüfstatus-Zeichenketten. Ein produktiver Dienst muss diese Datensätze authentifizieren, Prüferbefugnisse und Signaturherkunft verifizieren, fehlerhafte Eingaben behandeln und den gesamten Nachweisgraphen prüfen. Das Wort reviewed beweist keine Prüfung. Die ausgeführte Testimplementierung enthält außerdem keine Netzwerkzugriffskontrolle, Aufbewahrungsregeln, Widerrufsprüfung oder Nebenläufigkeitssicherung.
Schließen Sie die Lücke zwischen Prüfung und Freigabe
Fixieren Sie ein Prüftupel aus Kandidatendigest, Digest der Geltungsbereichsrichtlinie, Dokumentationsmanifest-Digest und Nachweisobjektversionen. Binden Sie menschliche Prüfung und abschließende Freigabetransaktion daran. Aktualisieren Sie die aktuelle Release-Referenz per Compare-and-Swap. Ändert sich eine gebundene Eingabe, verwerfen Sie das Ergebnis und wiederholen Sie betroffene Prüfungen. Sonst kann eine korrekte Prüfung Minuten später ein anderes Paket freigeben.
Die Weiterverwendung alter Nachweise braucht eine verantwortete Erklärung, die das bestehende Artefakt mit dem neuen Kandidaten verknüpft und seine fortdauernde Gültigkeit begründet. Implementieren Sie dafür keinen globalen Schalter zum Ignorieren von Release-Konflikten. Trennen Sie Speicherintegrität und Vertrauen: Hashes erkennen Änderungen gegenüber einer vertrauenswürdigen Erwartung. Wer Bericht und Manifest gemeinsam überschreiben kann, kann jedoch Konsistenz herstellen. Schützen Sie Manifest, Geltungsbereichsverzeichnis und Prüfprotokoll durch Funktionstrennung und geeignete Signatur- beziehungsweise Zugriffskontrollen.
Aufwand, Grenzen und Checkliste für die Rechtsprüfung
Hashberechnung und Abruf großer Artefakte verursachen I/O und verlängern die Freigabe. Fixieren Sie unveränderliche Versionen und verwenden Sie verifizierte inhaltsadressierte Objekte erneut, prüfen Sie aber aktuelle Prüferzugriffe und Berechtigungen gesondert. Ein zwischengespeicherter Digest beweist nicht, dass ein Prüfer den Nachweis noch einsehen kann. Setzen Sie die Kontrolle an Release- und relevanten Änderungsgrenzen ein, statt bei jeder Inferenz Dokumente abzurufen.
Strikte Identitätsprüfungen können außerdem unnötig blockieren, wenn unveränderte Nachweise gültig bleiben. Geprüfte Weiterverwendungsentscheidungen reduzieren überflüssige Tests, kosten jedoch Prüfzeit und dürfen nicht zu pauschalen Ausnahmen werden. Messen Sie das Alter ungeklärter Nachweise, wiederholt fehlende Verantwortliche, Abrufausfälle und wiedereröffnete Prüfungen. Berichten Sie den Anteil ausgefüllter Zeilen nicht als Compliance-Wert.
Klären Sie vor dem Einsatz mit qualifizierten Prüfern: System- und Akteursgeltungsbereich; aktuellen Rechtsstand und Anwendungsvorschriften; erwartete Elemente aus Anhang IV samt begründeten Ausschlüssen; vereinfachte oder kombinierte Dokumentationswege; erforderliche Berichtsunterschriften und Prüferbefugnisse; sowie Aufbewahrung, Vertraulichkeit und Nachweiszugang. Lassen Sie anschließend fachlich beurteilen, ob Tests und Überwachung die Zweckbestimmung tatsächlich abdecken. Strukturelle Konsistenz beantwortet diese Fragen nicht.
Beginnen Sie mit einem Kandidaten, nicht einer neuen Governance-Plattform
Wählen Sie ein anstehendes Release, seine Zweckbeschreibung, einen Prüfbericht und den Überwachungsplan. Fixieren Sie deren Identitäten, vereinbaren Sie das geprüfte Geltungsbereichsverzeichnis und führen Sie die beschriebenen Fehlerinjektionen aus, bevor Sie den Abgleich verpflichtend vor die Freigabe setzen. Der erste nützliche Fortschritt ist ein Prüfer, der jede Abweichung erklären kann, nicht ein weiteres grünes Dashboard.
Ich unterstütze Plattform- und Compliance-Teams dabei, solche Nachweisbeziehungen in testbare Freigabekontrollen zu übersetzen. Bringen Sie Kandidatenmanifest, Dokumentationsindex und einen veralteten Prüfbericht in eine technische Nachweisprüfung ein; die rechtliche Bewertung bleibt bei qualifizierten Rechtsberatern. Das Ergebnis sollte eine überschaubare, ausdrücklich zugewiesene Aufgabenliste und eine Freigabe sein, die an die tatsächlich geprüften Nachweise gebunden bleibt.
