Fällt Ihr KI-System unter eine Hochrisiko-Kategorie in Anhang III des EU AI Act, schulden Sie ein technisches Dokumentationspaket, bevor es live geht. Artikel 11 und Anhang IV legen fest, was darin enthalten sein muss: eine Beschreibung des Systems, die Daten, auf denen es trainiert und getestet wurde, seine Leistung und seine Grenzen, die menschliche Aufsicht darüber und das Monitoring, das Sie nach der Inbetriebnahme betreiben. Das Paket muss aktuell sein, und eine prüfende Stelle muss ihm folgen können.
Genau diese zweite Anforderung wird von den meisten Teams unterschätzt. Die Liste der Überschriften in Anhang IV ist kurz und gut lesbar, und ein zusammenfassendes Foliendeck kann jede einzelne davon abhaken. Unter jeder Überschrift Nachweise zu liefern, die eine prüfende Person bis zu einem System, einer Dataset-Version oder einem Evaluations-Lauf zurückverfolgen kann, ist eine andere Aufgabe. Das ist Engineering-Arbeit.
Was Anhang IV tatsächlich verlangt
Anhang IV ist eine neunteilige Struktur. Nüchtern gelesen verlangt er:
- Eine allgemeine Beschreibung des Systems: Zweckbestimmung, die Personen, die es entwickelt haben, Versionen und die Art, wie es mit anderer Software interagiert.
- Die Details, wie es gebaut wurde: Design-Entscheidungen, Modellarchitektur, die Daten und die Trainingsmethodik, einschließlich dessen, was Sie gegen bekannte Grenzen unternommen haben.
- Validierung und Testung: die verwendeten Metriken, die Ergebnisse, die Grenzen der Genauigkeit und die Logs, die sie belegen.
- Das Risikomanagementsystem, abgebildet auf Artikel 9.
- Die Änderungen, die Sie über den Lebenszyklus vorgenommen haben, und warum.
- Die angewandten harmonisierten Normen oder die stattdessen eingesetzten technischen Lösungen.
- Eine Kopie der EU-Konformitätserklärung.
- Den Plan zur Beobachtung nach dem Inverkehrbringen.
Bei einem Fintech-System werden hier die Abstraktionen auf die Probe gestellt. „Beschreibung der Daten” ist kein Absatz. Für ein Transaction-Monitoring-Modell bedeutet es die Quellsysteme, wie das Entity Resolution durchgeführt wurde, wie Sie die Point-in-time-Korrektheit hergestellt haben und was Sie getan haben, um die Trainings-Features frei von Lookahead zu halten. Eine prüfende Person, die die Domäne kennt, wird fragen, wie ein Feature, das aus einem Aggregat über ein volles Quartal berechnet wurde, in einem Modell landet, das ein Ereignis mitten im Quartal scort. Wenn Ihre Antwort nur im Kopf einer Data Scientist steckt, hält die Dokumentation nicht stand.
Bauen Sie es als Nachweis auf
Der Fehlermodus, den wir am häufigsten sehen, ist ein Dokument, das im Nachhinein von jemandem geschrieben wurde, der beschreibt, was das Team seiner Meinung nach getan hat. Es liest sich gut. Es überlebt die zweite Nachfrage nicht. Die Lösung ist, jeden Anhang-IV-Abschnitt aus einem System of Record zu speisen und den Fließtext darauf verweisen zu lassen.
Konkret heißt das:
- Dataset-Beschreibungen ziehen aus der Lineage. Jeder Trainings- und Evaluationssatz trägt eine Version, die Queries oder Extrakte, die ihn erzeugt haben, und eine Abstimmung zurück auf das Quell-Ledger, sodass Zeilenzahlen und Summen mit den Büchern übereinstimmen.
- Modelleinträge kommen aus einem Inventar. Die Version in der Dokumentation ist die registrierte Version, mit demselben Identifier, den auch Change-Management- und Monitoring-Systeme verwenden.
- Leistungsabschnitte hängen die Evaluations-Läufe selbst an: den Eval-Satz, die Metriken darauf, die Confusion Matrix und die Stelle, an der das False-Positive-Budget für die Alert-Queue gesetzt wurde, die ein Mensch bearbeitet.
- Der Abschnitt zu den Grenzen benennt die Segmente, in denen die Genauigkeit sinkt. Kunden mit dünner Datenhistorie, ein neuer Korridor, ein Produkt, das nach dem Trainings-Cutoff gelauncht wurde. Sagen Sie, wo das Modell schwach ist und welche Aufsicht diese Schwäche abdeckt.
Wenn die Dokumentation aus diesen Quellen zusammengesetzt wird, wird ihre Aktualisierung zu einem Build-Schritt. Ein Retraining erzeugt eine neue Dataset-Version, einen neuen Inventareintrag und einen frischen Evaluations-Lauf, und die entsprechenden Abschnitte werden neu generiert. So verhindern Sie, dass die Anforderung „aktuell gehalten” aus Artikel 11 zu einer Dauerbelastung wird.
Der rote Faden Risikomanagement muss echt sein
Anhang IV Punkt 4 verweist auf das Risikomanagementsystem nach Artikel 9, und das ist der Teil, den Sie nicht generieren können. Artikel 9 verlangt einen kontinuierlichen Prozess: die Risiken, die das System birgt, identifizieren, sie einschätzen, entscheiden, was akzeptabel ist, Maßnahmen ergreifen und überprüfen, ob die Maßnahmen wirken, sobald das System läuft.
Bei einem Kredit- oder Fraud-Modell liest sich die ehrliche Fassung davon wie eine im Voraus geschriebene technische Post-mortem. Was passiert, wenn die Eingangsdaten driften. Was eine Fehlentscheidung eine reale Person kostet und wie sie sie anficht. Wo Straight-through Processing erlaubt ist und wo ein Mensch abzeichnen muss. Was das Monitoring beobachtet, bei welchen Schwellen es eskaliert und wer den Pager trägt. Der Audit Trail, der es Ihnen erlaubt, Monate später zu rekonstruieren, warum ein bestimmter Antragsteller eine bestimmte Entscheidung erhalten hat.
Prüfende lesen diesen Abschnitt daraufhin, ob die Maßnahmen mit den Risiken verbunden sind. Ein generisches „das Modell wird auf Drift überwacht” zieht eine Nachfrage nach sich: auf welchen Features überwacht, gegen welches Referenzfenster, und was passiert zum Quartalsende, wenn die Volumina aus Gründen verrutschen, die nichts mit dem Modell zu tun haben. Wenn Ihr Monitoring-Plan das beantwortet, tut die Dokumentation ihre Arbeit. Wenn nicht, liegt die Lücke im System, und das Dokument hat sie nur sichtbar gemacht.
Wo das Paket üblicherweise zerbricht
Drei Dinge fehlen typischerweise, wenn wir einen Entwurf öffnen. Die Data-Lineage stimmt nicht ab, sodass sich die „Beschreibung der Daten” nicht belegen lässt. Die Evaluationszahlen im Dokument passen zu keinem gespeicherten Lauf, weil sie aus einem Notebook abgetippt wurden, das sich seither geändert hat. Und die auf dem Papier beschriebene menschliche Aufsicht ist nicht die Aufsicht, die in Produktion existiert, wo die Queue unter Last stillschweigend auf Auto-Clear umgestellt wurde.
Jedes dieser Probleme ist behebbar, und jedes ist als Systemeigenschaft billiger zu beheben denn als Dokumentänderung. Bauen Sie die Lineage so, dass sich der Datenabschnitt selbst beweist. Registrieren Sie Modelle, sodass die Version in der Datei die Version in Produktion ist. Loggen Sie die Evaluations-Läufe, sodass die Zahlen zu Zitaten werden, auf die Sie zeigen können. Tun Sie das, und Anhang IV wird zu einem Bericht, den Sie auf Abruf neu generieren, und genau das muss er sein, wenn jemand zur Prüfung kommt.
Häufige Fragen
Muss die technische Dokumentation fertig sein, bevor das System live geht?
Ja. Artikel 11 verlangt, dass die Dokumentation existiert und aktuell gehalten wird, bevor ein Hochrisikosystem in Verkehr gebracht oder in Betrieb genommen wird, und die Konformitätsbewertung nimmt darauf Bezug. Ein Dokument, das nach dem Go-live datiert ist, signalisiert, dass die Bewertung auf etwas beruhte, das noch gar nicht existierte.
Kann die Model Card eines Anbieters den Anhang IV ersetzen?
Nein. Eine Model Card deckt in der Regel nur das Modell isoliert ab. Anhang IV verlangt das gesamte System: die Data Governance drumherum, die Maßnahmen zur menschlichen Aufsicht, das Monitoring, das Sie in Produktion betreiben, und das Risikomanagement, das all das zusammenhält. Sie können ein Anbieter-Artefakt zitieren, aber das Paket auf Systemebene verantworten weiterhin Sie.
Wie viel von Anhang IV lässt sich automatisch erzeugen?
Die Teile, die durch Systeme gestützt sind: Dataset-Lineage, Einträge im Modellinventar, Evaluations-Läufe, Drift- und Monitoring-Logs. Die Teile, die eine Beurteilung erfordern, etwa die Begründung des Risikomanagements und das Design der menschlichen Aufsicht, müssen von Menschen geschrieben werden, die sie verteidigen können. Das Ziel: die Nachweise automatisch befüllen und die Begründung von Hand schreiben.