Jedes KI-System hat eine eigene Dokumentenakte. Darin liegen drei verschiedene Dinge, die oft verwechselt werden: frei anlegbare Dokumente, vier reservierte technische Nachweise mit fester Bedeutung, und die Konformitätserklärung als abschließende Aussage. Wer diese drei auseinanderhält, hat eine Akte, aus der sich das Anhang-IV-Dossier fast von selbst füllt.

Auf einen Blick

Enthalten ab: Starter (Kernfunktion)
Wo in der App: KI-System öffnen → Dokumentation
Ergebnis: Versionierte Dokumentenakte je System, Grundlage für Anhang IV und Export
API: /api/v1/documentation

Die drei Ebenen der Akte

1. Freie Dokumente

Beliebig viele Einträge mit Titel, Dokumenttyp, Kurzfassung und Inhalt. Sprache (Deutsch oder Englisch) und Status (Entwurf oder Final) werden pro Dokument gesetzt. Hier landet alles, was das System beschreibt, aber keinen reservierten Platz hat: Architekturbeschreibungen, Betriebshandbücher, Freigabeprotokolle.

2. Vier technische Nachweise

Bias-Bewertung, Datenherkunft, Modell-Änderungsprotokoll und Risikominderungsmaßnahmen. Jeder Typ existiert pro System genau einmal und kommt mit einer vorbefüllten Gliederung. Diese vier fragen Prüfer zuerst ab – deshalb sind sie feste Plätze und keine Freitextdokumente.

3. Konformitätserklärung

Die abschließende Aussage zum System: Geltungsbereich, eigener Erklärungstext, Name der freigebenden Person und eine ausdrückliche Bestätigung. Beim Speichern wird ein Faktenschnappschuss mitgeschrieben – die Erklärung bleibt damit auch dann nachvollziehbar, wenn sich die Systemdaten später ändern.

Anhang-IV-Dossier

Die vierte Ausbaustufe für Hochrisiko-Systeme: sieben Sektionen mit Pflichtfeldern, eigenem Freigabe-Workflow und Versionsnummer. Sie hat eine eigene Doku-Seite.

Die vier technischen Nachweise

Jeder Slot wird mit einer Gliederung vorbefüllt, die Sie überschreiben. Die Gliederung ist der Hinweis darauf, was ein Prüfer an dieser Stelle erwartet.

Nachweis	Vorgegebene Gliederung	Anhang-IV-Sektion
Bias-Bewertung	Geltungsbereich und geschützte Gruppen · Metriken und Schwellwerte · Ergebnisse und Befunde · Abhilfen und Verantwortliche	Daten-Governance
Datenherkunft	Datenquellen und Rechtsgrundlage · Transformationsschritte · Speicherung und Aufbewahrung · Zugriffskontrollen und Freigaben	Daten-Governance
Modell-Änderungsprotokoll	Version/Tag und Releasedatum · Änderungsgrund · Auswirkungs- und Risikoprüfung · Freigabe und Rollback-Plan	Test und Validierung
Risikominderungsmaßnahmen	Beschreibung der Maßnahme · verknüpfte Risiken · Wirksamkeitsnachweis · Restrisiko und Prüftermin	Test und Validierung

Nachweis-Metadaten je Dokument

Zusätzlich zum Inhalt trägt jedes Dokument vier Felder, die aus einem Text einen steuerbaren Nachweis machen:

Verantwortliche Rolle – wer den Nachweis pflegt. Nicht eine Person, sondern eine Rolle, damit der Nachweis einen Personalwechsel überlebt.
Fälligkeitsdatum – wann der Nachweis spätestens aktualisiert sein muss.
Version – die Fassung, auf die sich der Inhalt bezieht (z. B. die Modellversion).
Artefakt-Links – Verweise auf die eigentlichen Dateien oder Systeme, falls der Nachweis anderswo liegt.

FINAL ist eine Freigabe, kein Formatierungsschalter

Ein technischer Nachweis lässt sich nur auf FINAL setzen, wenn der zugehörige Governance-Workflow freigegeben ist. Der Versuch, den Status vorher zu setzen, wird mit einer Fehlermeldung abgelehnt – das ist beabsichtigt: „Final" bedeutet in einem Audit „von der zuständigen Stelle freigegeben", nicht „fertig getippt".

Der Dokumentations-Assistent

Der Assistent führt je System durch bis zu elf Schritte. Schritte, die für das System rechtlich nicht gelten, zeigt er gar nicht erst an. Stattdessen steht über der Schrittleiste eine Zeile wie „3 Schritte entfallen für dieses System“, die jeden ausgeblendeten Schritt mit seiner Rechtsgrundlage nennt. Welche Schritte erscheinen, hängt von Risikostufe und Rolle ab:

Situation	Sichtbare Schritte
Hochrisiko, Anbieter	Alle: System & Verantwortliche, Annex IV: Stammdaten, Annex IV: Workflow & Freigabe, Maßnahmen, Assurance, technische Nachweise, Post-Market Monitoring & Incidents, laufende Überwachung & CAPA, Ingestion, Go-Live Gate & Trust Pack, Konformitätserklärung & Export.
Hochrisiko, nur Betreiber	System, Maßnahmen, Assurance, Monitoring & Incidents (Art. 26 Abs. 5, Art. 73), laufende Überwachung, Go-Live Gate (Art. 26 Abs. 1). Es entfallen Annex IV, technische Nachweise und Konformitätserklärung. Das sind Anbieterpflichten (Art. 10, 11, 15, 16, 47).
Begrenztes oder minimales Risiko	System, Maßnahmen, Assurance.
Verbotene Praktik	System, Maßnahmen, Assurance. Betriebs- und Hochrisiko-Schritte entfallen, weil das System nicht betrieben werden darf.
Noch nicht bewertet oder Rolle offen	System, Maßnahmen, Assurance, mit dem Hinweis, dass weitere Schritte erscheinen, sobald Risikostufe und Rolle feststehen.

Information

Ausnahme: Hat ein System für einen ausgeblendeten Schritt bereits Daten (etwa einen erfassten Vorfall), bleibt der Schritt sichtbar. So werden keine Einträge unerreichbar. Der Ingestion-Schritt erscheint nur, wenn Datenquellen angebunden sind. Der Fortschritt zählt nur die sichtbaren Schritte.

Assurance-Abschnitte je Rolle und Risiko

Auch der Assurance-Bereich blendet aus, was nicht gilt („x Abschnitte entfallen für Ihre Rolle“ bzw. „… für dieses System“). Ohne gespeicherte Rolle wird nichts nach Rolle eingeschränkt; die App bittet dann, die Rolle festzulegen.

Abschnitt	Gilt für
Einstufung & Rollen, KI-Kompetenz-Nachweise	Immer (Art. 6, Art. 4)
Anbieter- und Lieferkettenregister	Ab begrenztem Risiko
Regeln zur menschlichen Aufsicht, Monitoring- und Observability-Profile, Behörden-Antwortfälle	Hochrisiko, beide Rollen
QMS-Artefakte, Risikoregister, Datensatz-Register, Validierungs-Suiten, Pipeline-Gates, Modellregister & Herkunft, Release-Orchestrierung	Hochrisiko, Anbieter (Art. 9, 10, 11, 15, 17, 43 Abs. 4)
Behörden- & Konformitätspaket	Hochrisiko, Anbieter; öffentliche Betreiber wegen der Registrierung nach Art. 49 Abs. 3
Grundrechte-Folgenabschätzung	Hochrisiko, Betreiber im Anwendungsbereich von Art. 27 Abs. 1 (öffentliche Stellen, Erbringer öffentlicher Dienste, Anhang III Nr. 5 lit. b/c)

Vorbefüllung von „Einstufung & Rollen“

Was die App schon weiß, müssen Sie nicht noch einmal eintippen:

Risikokategorie: immer das Ergebnis der neuesten Risikobewertung. Sie ist im Profil nicht editierbar; das Backend schreibt sie bei jedem Speichern.
Eigene Rolle: Anbieter oder Betreiber aus der neuesten abgeschlossenen Rechtslogik. Vorbefüllt, aber änderbar, etwa für Einführer, Händler oder eine bewusste Abweichung.
Systemtyp: GPAI-Modell nur, wenn das Inventar angibt, dass Sie das Modell selbst bereitstellen oder trainieren; sonst KI-System.
Zweckbestimmung und Begründung: Vorschläge aus dem Inventar bzw. aus der Begründung der neuesten Risikobewertung, die Sie per Klick übernehmen.

Empfohlene Reihenfolge

1System im Inventar anlegen und Risikobewertung durchführen – erst danach ist klar, welche Nachweistiefe nötig ist.
2Die vier technischen Nachweise befüllen. Die vorgegebene Gliederung ist die Checkliste dafür.
3Ergänzende Dokumente anlegen: Betriebshandbuch, Bedienungsanleitung, Freigabeprotokolle.
4Governance-Freigabe einholen und die Nachweise auf FINAL setzen.
5Bei Hochrisiko-Systemen: Anhang-IV-Dossier befüllen, das auf diese Nachweise zurückgreift.
6Konformitätserklärung abschließen und den Systemreport exportieren.

Dokumentation & Nachweise