Model Card für KI-Modelle: vom Template zum AI-Act-Nachweis

Eine Model Card für KI-Modelle ist ein kurzes, strukturiertes Dokument, das ein trainiertes Modell begleitet: wofür es gedacht ist, wie es trainiert und geprüft wurde und wo es versagt. Vorgeschlagen haben es Google-Forscher 2018 und 2019; Hugging Face machte daraus die README.md jedes Modell-Repositorys. Seit dem 2. August 2025 verlangt die KI-Verordnung (EU AI Act) von Modellanbietern eine Dokumentation, die einer solchen Karte ähnelt, aber länger ist und rechtlich eingefordert werden kann, und ab dem 2. Dezember 2027 schulden Anbieter von Hochrisiko-Systemen eine technische Dokumentation, für die die Karte nur den Anfang bildet. Dieser Leitfaden liest die Model Card so, wie ein Auditor oder eine Marktüberwachungsbehörde sie lesen würde: Was steht darin, was fehlt, welches Gesetz kann sie verlangen und wie wird aus ihr ein Nachweis?

Auf einen Blick

• Eine Model Card ist ein freiwilliges Dokumentationsformat mit neun kanonischen Abschnitten (Mitchell et al., 2019), kein Rechtsdokument.
• Die Hugging-Face-Vorlage ist der De-facto-Standard, deckt aber nur etwa die Hälfte der Felder von Anhang XI und GPAI Model Documentation Form ab.
• Seit dem 2. August 2025 müssen GPAI-Anbieter eine Modelldokumentation führen (Anhang XI), an nachgelagerte Anbieter weitergeben (Anhang XII) und die Trainingsinhalte zusammenfassen; die technische Dokumentation für Hochrisiko-Systeme (Anhang IV) folgt ab dem 2. Dezember 2027.
• Die Transparenz sinkt: Foundation Model Transparency Index Dezember 2025 im Schnitt 41 von 100 Punkten, 17 unter 2024; auf Hugging Face bleiben Umweltauswirkungen, Limitationen und Evaluation am häufigsten leer.
• Zum Nachweis wird eine Model Card erst, wenn sie versioniert, von drei Rollen unterzeichnet, in den Feldnamen der Aufsicht geschrieben und mit dem KI-Systemdatensatz verknüpft ist.

Was ist eine Model Card?

Der Begriff stammt aus dem Aufsatz „Model Cards for Model Reporting“, den Margaret Mitchell, Timnit Gebru und sieben weitere Autorinnen und Autoren im Januar 2019 auf der FAT\*-Konferenz in Atlanta vorstellten; die Vorabfassung erschien im Oktober 2018 als arXiv 1810.03993. Gemeint sind kurze Dokumente, die trainierte Machine-Learning-Modelle begleiten und deren Leistung unter unterschiedlichen Bedingungen mit Benchmarks belegen, etwa über kulturelle, demografische oder phänotypische Gruppen hinweg. Das Papier rechnet zwei Beispiele durch: einen auf CelebA trainierten Klassifikator, der lächelnde Gesichter erkennt, und das Toxizitätsmodell der Perspective API. Adressaten sind Entwickler, Politik und Betroffene. Auf Deutsch ließe sich „Modellsteckbrief“ sagen; durchgesetzt hat sich der englische Begriff. Hugging Face hat das Format in den Alltag geholt. Dort ist die Model Card schlicht die README.md des Modell-Repositorys: Markdown-Text plus ein YAML-Metadatenblock am Anfang, der license, language, datasets, base_model, pipeline_tag, library_name, strukturierte Evaluationsergebnisse und co2_eq_emissions aufnimmt. Die Dokumentation des Hub beschreibt diese Felder, die kommentierte Vorlage erklärt Abschnitt für Abschnitt, was hineingehört. Das Model Card Guidebook von Hugging Face (Ozoani, Gerchick, Mitchell, 2022) hält zudem fest, dass eine vollständige Karte drei Rollen braucht: die Entwicklerin, die „Soziotechnikerin“ (Juristin, Ethikerin, Grundrechtsvertreterin) und die Projektorganisation. Wer diese Besetzung einmal gesehen hat, versteht, warum so viele Karten halb leer bleiben.

Model Card, System Card, Data Card: drei Artefakte, drei Objekte

Die drei Begriffe werden gern vermischt. Die System Card beschreibt das ausgelieferte Produkt: Systemprompts, Schutzmechanismen, angebundene Werkzeuge, Sicherheitsevaluationen. Populär gemacht hat sie OpenAI mit der GPT-4 System Card vom März 2023; Anthropic veröffentlicht für seine Claude-Modelle ebenfalls System Cards. Ein aufschlussreiches Detail: Für die offenen gpt-oss-Modelle legte OpenAI im August 2025 ausdrücklich eine Model Card vor und keine System Card, weil das, was freigegeben wird, die Gewichte sind und kein Produkt. Die Data Card oder das Datasheet wiederum beschreibt den Datensatz; die Vorlage dafür lieferten Gebru et al. 2018 mit Datasheets for Datasets. Die Faustregel für Ihr Dokumentationskonzept lautet also: ein Artefakt pro Objekt, und die Model Card beschreibt die Gewichte.

Die neun Abschnitte einer Model Card und die Frage, die jeder beantwortet

Mitchell et al. schlagen neun Abschnitte vor. Die folgende Tabelle ordnet jedem die Frage zu, die er beantworten soll, und die Schwäche, die uns in der Prüfungspraxis am häufigsten begegnet. <table header-row=“true“> <tr> <td>Abschnitt</td> <td>Welche Frage er beantwortet</td> <td>Typische Schwäche</td> </tr> <tr> <td>Model Details</td> <td>Wer hat das Modell gebaut, in welcher Version, wann, mit welchem Typ, welcher Lizenz, welchem Kontakt?</td> <td>Version und Datum fehlen</td> </tr> <tr> <td>Intended Use</td> <td>Primäre Zwecke, primäre Nutzer, ausgeschlossene Zwecke</td> <td>Als Marketingtext formuliert</td> </tr> <tr> <td>Factors</td> <td>Welche Gruppen, Instrumente oder Umgebungen verändern die Leistung?</td> <td>Nie nach Gruppen aufgeschlüsselt</td> </tr> <tr> <td>Metrics</td> <td>Welche Maße, welche Entscheidungsschwellen, wie wird Streuung berichtet?</td> <td>Metriken ohne Schwellenwerte</td> </tr> <tr> <td>Evaluation Data</td> <td>Welche Datensätze, warum diese, wie vorverarbeitet?</td> <td>Identisch mit den Trainingsdaten</td> </tr> <tr> <td>Training Data</td> <td>Woraus hat das Modell gelernt, oder warum darf das nicht offengelegt werden?</td> <td>„Proprietär“ ohne Herkunftskategorien</td> </tr> <tr> <td>Quantitative Analyses</td> <td>Ergebnisse je Faktor und in der Schnittmenge mehrerer Faktoren</td> <td>Nur ein Gesamtwert</td> </tr> <tr> <td>Ethical Considerations</td> <td>Sensible Daten, Risiken für Leben und Gesundheit, Gegenmaßnahmen</td> <td>Ein Disclaimer statt einer Analyse</td> </tr> <tr> <td>Caveats and Recommendations</td> <td>Was die Evaluation nicht abgedeckt hat</td> <td>Fehlt ganz</td> </tr> </table> Die Hugging-Face-Vorlage ordnet diese neun Punkte neu an: Model Details; Uses mit direkter, nachgelagerter und ausgeschlossener Nutzung; Bias, Risks and Limitations mit Recommendations; Training Details; Evaluation mit Testdaten, Faktoren, Metriken und Ergebnissen; Environmental Impact; Technical Specifications; Citation; Glossary; Authors; Contact; How to Get Started. Inhaltlich bleibt es dieselbe Karte, nur mit einem Umweltfeld und mehr Serviceabschnitten. Hilfreich sind die drei Begriffsbestimmungen aus dem Guidebook, weil sie in Prüfungen immer wieder verwechselt werden. Ein Bias ist eine Verzerrung der Leistung zuungunsten bestimmter Teilpopulationen. Ein Risiko ist ein gesellschaftlich relevanter Schaden, den das Modell verursachen könnte. Eine Limitation ist ein wahrscheinlicher Fehlermodus, auf den die Empfehlungen antworten müssen. Wer die drei sauber trennt, schreibt eine Model Card, die ein Auditor ohne Rückfragen lesen kann.

Was eine Model Card nicht ist: freiwillig, selbstberichtet, ungleichmäßig

Kein Gesetz schreibt das Format vor, niemand prüft die Angaben, und die Autorin entscheidet selbst, was sie misst und was sie weglässt. Zwei Messungen zeigen, was daraus folgt. Erstens der Foundation Model Transparency Index 2025 des Stanford Center for Research on Foundation Models, dritte Ausgabe vom Dezember 2025: 13 Unternehmen wurden an 100 Indikatoren gemessen. Der Durchschnitt lag bei 41 von 100 Punkten, 17 Punkte unter dem Wert von 2024. IBM erreichte 95 Punkte, xAI und Midjourney jeweils 14. Der Trend zeigt nach unten. Zweitens die Analyse von Liang et al. vom Februar 2024, die 32.111 Model Cards auf Hugging Face systematisch ausgewertet hat. Der Trainingsabschnitt ist am zuverlässigsten gefüllt; Umweltauswirkungen, Limitationen und Evaluation bleiben am häufigsten leer, also genau die Abschnitte, die eine Aufsicht zuerst aufschlägt. Ein Nebenbefund: Als die Autoren 42 populären Modellen ausführliche Karten hinzufügten, korrelierte das moderat mit höheren wöchentlichen Downloadzahlen. Für ein Governance-Team folgt daraus eine einfache Regel. Eine Model Card, die Sie von einem Anbieter erhalten, ist eine Behauptung, kein Prüfungsergebnis; sie ist der Ausgangspunkt für Ihre Fragen, nicht deren Antwort. Eine Karte, die Sie selbst veröffentlichen, ist eine Aussage, an der man Sie festhalten wird, vor Kunden, vor Auditoren und im Streitfall vor Gericht. Was Benchmark-Werte in einer Karte belastbar macht, beschreibt unser Beitrag zum KI-Benchmarking. Und weil eine Karte ein Modell zu einem Stichtag beschreibt, braucht es daneben die Überwachung von Modelldrift.

Wo die Model Card auf den EU AI Act trifft

Die KI-Verordnung verwendet das Wort Model Card an keiner Stelle, verlangt aber an zwei Stellen eine Dokumentation mit vertrauter Feldliste: bei KI-Modellen mit allgemeinem Verwendungszweck (GPAI) und bei Hochrisiko-Systemen.

KI-Modelle mit allgemeinem Verwendungszweck: Artikel 53, Anhang XI und das Model Documentation Form

Artikel 53 Absatz 1 gilt seit dem 2. August 2025 und verpflichtet Anbieter von GPAI-Modellen zu vier Dingen: (a) eine technische Dokumentation mit mindestens den Elementen des Anhang XI, laufend aktualisiert und auf Anfrage für das AI Office (das KI-Büro der Kommission) und die nationalen Behörden bereitgehalten; (b) eine Dokumentation für nachgelagerte Anbieter mit mindestens den Elementen des Anhang XII, damit diese Fähigkeiten und Grenzen des Modells verstehen; (c) eine Urheberrechtsstrategie; (d) eine öffentliche Zusammenfassung der Trainingsinhalte nach der Vorlage, die das AI Office am 24. Juli 2025 veröffentlicht hat. Nach Artikel 53 Absatz 2 sind Modelle unter freier und quelloffener Lizenz mit öffentlich zugänglichen Parametern von (a) und (b) befreit, es sei denn, sie bergen ein systemisches Risiko. Was ein solches Modell ausmacht, erläutert unser Beitrag zu General-Purpose AI. Abschnitt 1 des Anhang XI liest sich wie eine erweiterte Model Card: Aufgaben und Integrationsziele, Richtlinien zur zulässigen Nutzung, Veröffentlichungsdatum und Vertriebswege, Architektur und Parameterzahl, Modalitäten, Lizenz; dazu Integrationsmittel, Design- und Trainingsmethodik samt Begründung, Daten (Art, Herkunft, Kuratierung, Anzahl der Datenpunkte, Umfang, Erkennung von Verzerrungen), Rechenaufwand in Gleitkommaoperationen, Trainingsdauer und Energieverbrauch. Abschnitt 2 kommt bei systemischem Risiko hinzu: Evaluationsstrategien und -ergebnisse, Adversarial Testing und Red Teaming, Systemarchitektur. Der Praxisleitfaden für GPAI-Modelle, dessen Endfassung am 10. Juli 2025 vorlag und den Kommission und KI-Gremium am 1. August 2025 bestätigt haben, übersetzt das in ein Model Documentation Form. Maßnahme 1.1 des Transparenzkapitels: jedes Feld beim Inverkehrbringen dokumentieren, aktuell halten, frühere Fassungen zehn Jahre aufbewahren. Maßnahme 1.2: eine Kontaktstelle veröffentlichen, nachgelagerten Anbietern die einschlägigen Felder binnen 14 Tagen übermitteln, dem AI Office liefern, was es anfordert. Maßnahme 1.3: Qualitätskontrolle, Integrität, Schutz vor Veränderung. Das Formular ist im Kern eine Model Card mit einer dritten Spalte: Für jedes Feld geben drei Kästchen an, ob es an das AI Office, an die national zuständigen Behörden oder proaktiv an nachgelagerte Anbieter geht. Abgefragt werden der rechtliche Name des Anbieters, das Datum des Inverkehrbringens auf dem Unionsmarkt, ein Hash oder Endpunkt als Echtheitsnachweis, Modellabhängigkeiten (woraus feinabgestimmt wurde), die Parameterzahl mit zwei signifikanten Stellen für das AI Office und als Bandbreite (von 1 bis 500 Millionen bis über 1 Billion) für alle anderen, maximale Ein- und Ausgabegrößen, Vertriebskanäle, Lizenz, Richtlinie zur zulässigen Nutzung, vorgesehene Einsatzzwecke in etwa 200 Wörtern, zulässige und unzulässige KI-Systemtypen, der Trainingsprozess samt Entscheidungsgründen in etwa 400 Wörtern, die Datenherkunft nach Kategorien (Web-Crawling, private Datensätze Dritter, Nutzerdaten, öffentliche Datensätze, synthetische Daten), Maßnahmen zur Erkennung ungeeigneter Quellen einschließlich CSAM und NCII, Maßnahmen gegen erkennbare Verzerrungen, Trainingsdauer in Kalenderzeit und Hardwaretagen, Rechenaufwand in FLOPs, Energie in Megawattstunden sowie ein mit Benchmarks belegter Wert für den Inferenzaufwand. Was Behörden erhalten, schützt Artikel 78 als Geschäftsgeheimnis.

Hochrisiko-KI-Systeme: Anhang IV, Artikel 13 und die Karte für den Betreiber

Bei Hochrisiko-Systemen verlangen Artikel 11 und Anhang IV die technische Dokumentation vor dem Inverkehrbringen, in neun Punkten: allgemeine Beschreibung (Zweckbestimmung, Anbieter, Versionen, Interaktionen, Hardware, Betriebsanleitung); Entwicklung (Methoden, vortrainierte Modelle Dritter, Designspezifikationen, Architektur, Datenanforderungen mit Herkunft, Kennzeichnung und Bereinigung, Bewertung der menschlichen Aufsicht, vorab festgelegte Änderungen, Validierung und Tests mit Metriken zu Genauigkeit, Widerstandsfähigkeit und diskriminierenden Auswirkungen, Cybersicherheit); Überwachung und Kontrolle (Leistung für bestimmte Personen oder Gruppen, vorhersehbare unbeabsichtigte Ergebnisse, Eingabedaten); die Eignung der Metriken; das Risikomanagementsystem nach Artikel 9; Änderungen über den Lebenszyklus; angewandte harmonisierte Normen; die EU-Konformitätserklärung; der Plan zur Beobachtung nach dem Inverkehrbringen nach Artikel 72. Artikel 18 verlangt zehn Jahre Aufbewahrung. Artikel 13 Absatz 3 beschreibt die Betriebsanleitung, und das ist die Model Card aus Sicht des Betreibers: Identität des Anbieters, Zweckbestimmung, Genauigkeit mit ihren Metriken, Widerstandsfähigkeit, Cybersicherheit, bekannte und vorhersehbare Fehlanwendungsrisiken, Leistung für bestimmte Gruppen, Spezifikationen der Eingabedaten, vorab festgelegte Änderungen, Maßnahmen der menschlichen Aufsicht, Rechen- und Hardwarebedarf, erwartete Lebensdauer und Wartung, Protokollierungsmechanismen. Die Fristen haben sich durch den Digitalen Omnibus verschoben (Verordnung (EU) 2026/1744, Amtsblatt vom 24. Juli 2026, in Kraft seit dem 27. Juli 2026): eigenständige Hochrisiko-Systeme des Anhangs III ab dem 2. Dezember 2027, in Produkte eingebettete Systeme des Anhangs I ab dem 2. August 2028. KMU und nun auch kleine Midcaps dürfen das vereinfachte Formular der Kommission für die technische Dokumentation verwenden, dieselben neun Bereiche mit weniger Text. Welche Systeme überhaupt betroffen sind, zeigt unser Beitrag zur Einstufung von Hochrisiko-KI-Systemen; den Weg bis zur CE-Kennzeichnung erklärt der Beitrag zur Konformitätsbewertung. Betreiber müssen das System nach Artikel 26 gemäß der Betriebsanleitung nutzen und für Anwendungsfälle des Anhangs III im öffentlichen Sektor sowie einige private eine Grundrechte-Folgenabschätzung nach Artikel 27 durchführen, die genau bei dieser Karte ansetzt. Beides fließt in die KI-Systemdokumentation ein.

Gap-Audit: die Hugging-Face-Vorlage gegen die gesetzlichen Feldlisten

Die folgende Gegenüberstellung ist unsere Lesart, keine amtliche Zuordnung. Sie zeigt, wo eine sorgfältig ausgefüllte Model Card nach Hugging-Face-Vorlage die Felder von Anhang IV, Anhang XI und Model Documentation Form bereits trifft und wo sie leer bleibt. <table header-row=“true“> <tr> <td>Abschnitt der Vorlage</td> <td>Was Anhang IV, Anhang XI oder das Formular verlangen</td> <td>Lücke</td> </tr> <tr> <td>Model Details</td> <td>Allgemeine Angaben: rechtlicher Name, Datum des Inverkehrbringens in der Union, Echtheits-Hash, Modellabhängigkeiten</td> <td>Fehlt</td> </tr> <tr> <td>Uses</td> <td>Nutzung: Link zur Richtlinie für zulässige Nutzung, KI-Systemtypen, in die das Modell eingehen darf oder nicht, in 200 bis 300 Wörtern</td> <td>Teilweise fehlend</td> </tr> <tr> <td>Bias, Risks and Limitations</td> <td>Maßnahmen zur Erkennung ungeeigneter Quellen und erkennbarer Verzerrungen</td> <td>Fehlt: die Vorlage hält Ergebnisse fest, das Formular fragt nach den Erkennungsmethoden</td> </tr> <tr> <td>Training Details</td> <td>Trainingsprozess und Daten: Entscheidungsgründe, Herkunftskategorien, Anzahl der Datenpunkte mit signifikanten Stellen, Kuratierung, CSAM- und NCII-Maßnahmen</td> <td>Fehlt</td> </tr> <tr> <td>Evaluation</td> <td>Anhang XI Abschnitt 2 und Anhang IV Nr. 2(g): Evaluationsstrategien, Adversarial Testing, Metriken zu diskriminierenden Auswirkungen, Schwellenwerte</td> <td>Teilweise vorhanden</td> </tr> <tr> <td>Environmental Impact</td> <td>Energieverbrauch: das CO2-Feld der Vorlage kommt nahe, das Formular will Megawattstunden mit zwei signifikanten Stellen und die Methodik</td> <td>Teilweise vorhanden</td> </tr> <tr> <td>Technical Specifications</td> <td>Modelleigenschaften und Rechenressourcen: Parameterzahl, maximale Ein- und Ausgabegröße, FLOPs, Trainingsdauer in Hardwaretagen</td> <td>Teilweise vorhanden</td> </tr> <tr> <td>Kein Abschnitt</td> <td>Anhang IV Nr. 2(e) bis 2(h) und 3 bis 9: menschliche Aufsicht, vorab festgelegte Änderungen, Cybersicherheit, Risikomanagement, Lebenszyklusänderungen, Normen, Konformitätserklärung, Plan zur Beobachtung nach dem Inverkehrbringen</td> <td>Fehlt</td> </tr> <tr> <td>Kein Abschnitt</td> <td>Artikel 13 Absatz 3 Buchstaben e und f: erwartete Lebensdauer, Wartung, Protokollierung</td> <td>Fehlt</td> </tr> </table> Umgekehrt enthält die Vorlage Abschnitte, nach denen kein Gesetz fragt: Citation, Glossary, How to Get Started, Authors. Genau sie machen die Karte lesbar. Streichen Sie sie nicht. Die bessere Strategie ist, die Model Card zu behalten und die gesetzlichen Felder darunter zu ergänzen, statt die Karte durch ein Formular zu ersetzen, das niemand freiwillig liest. Wie Sie die gefundenen Lücken priorisieren und nachdokumentieren, beschreibt unser Beitrag zum Modellrisikomanagement.

Jenseits der EU: wo sonst eine Model Card erwartet wird

Die Union ist nicht der einzige Ort, an dem die Karte inzwischen vorausgesetzt wird.

• USA, FDA. Der Entwurf der Leitlinie vom 7. Januar 2025 zu KI-gestützten Softwarefunktionen in Medizinprodukten enthält in Anhang E eine Musterkarte für Anwender und medizinisches Fachpersonal und in Anhang F eine beispielhafte 510(k)-Zusammenfassung mit ausgefüllter Karte. Die FDA schreibt ausdrücklich, dass sie weder eine Model Card noch ein bestimmtes Format verlangt, verweist aber auf Forschung, nach der eine Karte das Vertrauen der Nutzer erhöhen kann. Zum Zeitpunkt dieses Textes ist das Dokument weiterhin ein Entwurf.
• Kalifornien, SB 53. Der Transparency in Frontier Artificial Intelligence Act, unterzeichnet am 29. September 2025 und seit dem 1. Januar 2026 in Kraft, verpflichtet Entwickler von Frontier-Modellen (mehr als 10\^26 Rechenoperationen im Training), vor oder bei der Bereitstellung einen Transparenzbericht zu veröffentlichen: Veröffentlichungsdatum, unterstützte Sprachen und Modalitäten, vorgesehene Einsatzzwecke, Einschränkungen, Kontakt. Große Entwickler mit mehr als 500 Millionen Dollar Jahresumsatz ergänzen Zusammenfassungen ihrer Bewertung katastrophaler Risiken. Verstöße kosten bis zu 1 Million Dollar je Fall, durchgesetzt vom kalifornischen Attorney General (Analyse von Clifford Chance); unser Beitrag zum kalifornischen KI-Transparenzgesetz vergleicht es mit der KI-Verordnung.
• New York, RAISE Act. Unterzeichnet am 19. Dezember 2025, geändert am 27. März 2026, anwendbar ab dem 1. Januar 2027: veröffentlichte Sicherheitsprotokolle, Meldung von Vorfällen binnen 72 Stunden, Strafen bis zu 1 Million Dollar und bei Wiederholung 3 Millionen Dollar (Zusammenfassung von Wiley). Zur Abgrenzung: Was ist ein Frontier Model?
• NIST AI RMF. Das Playbook zum Risikomanagement-Rahmenwerk des NIST führt Model Cards und System Cards unter den vorgeschlagenen, freiwilligen Dokumentationspraktiken; unsere Einführung in das NIST AI RMF zeigt, wo sie im Rahmenwerk sitzen.
• Europa außerhalb der KI-Verordnung. Die vom Europäischen Datenschutzausschuss in Auftrag gegebene Checkliste für KI-Audits (Gemma Galdon Clavell, Januar 2023) eröffnet die Prüfung mit einem Abschnitt „Model Card“, der auf die Artikel der DSGVO verweist. Das AI Impact Assessment v2.0 des niederländischen Ministeriums für Infrastruktur (Dezember 2024) fragt im Transparenzkapitel schlicht, ob es eine Model Card oder eine gleichwertige Dokumentation gibt.
• Normen. ISO/IEC 42001 kennt in Anhang A Maßnahmenbereiche zur technischen Dokumentation des KI-Systems, zur Systemdokumentation und Information für Nutzer sowie zur Datenherkunft. Ein Zertifizierungsauditor fragt, wo diese Dokumentation liegt und wie sie aktuell gehalten wird; eine gepflegte Karte ist die kürzeste Antwort.
• Lieferkette. CycloneDX 1.5 hat im Juni 2023 eine Machine-Learning-Stückliste eingeführt, deren Komponententyp machine-learning-model die Felder einer solchen Karte spiegelt. Eine Karte kann also in einer SBOM mitreisen.

In Deutschland verdient zweierlei Beachtung. Das BSI befasst sich in seinen Leitfäden mit der Sicherheit von KI-Systemen, und das gemeinsame Papier von BSI und ANSSI zu Zero-Trust-Architekturen für LLM-Systeme nennt Model Cards ausdrücklich als Baustein; die Bundesnetzagentur ist als Marktüberwachungsbehörde nach der KI-Verordnung benannt und wird genau diese Dokumente anfordern. Ein seltenes Beispiel aus dem öffentlich-rechtlichen Bereich liefert das ZDF, das unter algorithmen.zdf.de öffentliche Model Cards für seine Algorithmen veröffentlicht.

Wie man eine Model Card schreibt, die ein Audit übersteht: sechs Schritte

Aus den Feldlisten oben lässt sich ein Arbeitsprogramm ableiten. Jeder Schritt endet mit einem Dokument, das Sie vorlegen können.

1. Eine Karte pro Modellversion, nach Freigabe unveränderlich. Jede neue Version bekommt eine neue Model Card, die alte bleibt archiviert. Ein Änderungsprotokoll benennt, was sich an Daten, Training, Evaluation oder Zweckbestimmung geändert hat; das entspricht Nr. 6 des Anhang IV und der Zehnjahresfrist aus Maßnahme 1.1 des Praxisleitfadens. Ergebnis: eine Versionshistorie mit Änderungsprotokoll.
2. Die gesetzlichen Felder zuerst, im Vokabular der Aufsicht. Rechtlicher Name, Veröffentlichungsdatum und Datum des Inverkehrbringens in der Union, Abhängigkeiten, Lizenz, Richtlinie zur zulässigen Nutzung, vorgesehene und ausgeschlossene Einsatzzwecke, zulässige KI-Systemtypen. Wer diese Felder in den Begriffen des Formulars führt, muss sie bei einer Anfrage nicht übersetzen. Ergebnis: ein Stammdatenblatt des Modells in Behördensprache.
3. Aufgeschlüsselt evaluieren und berichten, was Artikel 13 verlangt. Genauigkeit mit Metriken und Schwellenwerten, Widerstandsfähigkeit, Cybersicherheit, Leistung für bestimmte Gruppen; dazu Testdaten, die nicht die Trainingsdaten sind. Wie Benchmark-Werte prüffest erhoben werden, zeigt unser Beitrag zum KI-Benchmarking. Ergebnis: ein Evaluationsbericht mit disaggregierten Ergebnissen.
4. Daten nach Herkunftskategorien dokumentieren. Web-Crawling, Datensätze Dritter, Nutzerdaten, öffentliche Datensätze, synthetische Daten, jeweils mit Anzahl der Datenpunkte, Kuratierungsschritten und den Maßnahmen zur Erkennung ungeeigneter Quellen und Verzerrungen. Welche Prozesse das voraussetzt, zeigt unser Data-Governance-Framework. Ergebnis: ein Datenherkunftsnachweis je Trainingskorpus.
5. Drei Rollen unterzeichnen, eine Person verantwortet. Entwicklerin, Soziotechnikerin und Projektorganisation zeichnen die Karte ab; ein namentlich benannter Owner hält sie aktuell, mit Überprüfung bei jeder Freigabe und mindestens einmal jährlich. Ergebnis: ein Freigabeprotokoll mit Unterschriften und Prüfkalender.
6. Die Karte mit dem Systemdatensatz verknüpfen. Eintrag im KI-Inventar, Risikoregister, Betriebsanleitung, Vorfallprotokoll, Lieferantenvertrag. Verlangen Sie von Lieferanten die Felder des Anhang XII, schreiben Sie die 14-Tage-Pflicht und eine vierteljährliche Aktualisierung in den Vertrag; ein Praxisleitfaden für Juristinnen schlägt genau eine solche Klausel vor, mit Architektur, Datenherkunft, Genauigkeitsbenchmarks, Methodik der Bias-Tests und Monitoring-Ergebnissen. Mehr dazu in unserer Lieferanten-Due-Diligence für KI. Ergebnis: ein verknüpfter Systemdatensatz mit Vertragsanhang.

Sechs Schritte, sechs Dokumente. Zusammen bilden sie die Dokumentationsakte, die eine Behörde heute nach Artikel 53 und ab Dezember 2027 nach Anhang IV anfordern kann.

Model Cards im KI-Systemdatensatz

Eine Model Card beschreibt ein Modell. Eine Aufsicht fragt nach einem System: nach dem Bewerbungsfilter, dem Kreditscoring, dem Diagnoseassistenten, in dem das Modell arbeitet. Das Register ist die Stelle, an der beides zusammenkommt. Jeder Systemdatensatz führt seine Modellkomponenten auf; jede Komponente trägt ihre Kartenfelder und ihre Versionsnummer; ändert sich die Karte, weil ein neues Basismodell eingezogen ist oder die Evaluation andere Werte liefert, öffnet das die Risikobewertung und die Betriebsanleitung erneut. Ohne diese Verknüpfung liegen Karten in Git-Repositories, Verträge in SharePoint und Risikobewertungen in Tabellen, und die Frage „Zeigen Sie mir die Dokumentation zu diesem Modell“ wird zur Suche. AI Sigil legt die Model Card deshalb direkt neben die Kontrollen des jeweiligen Rahmenwerks, mit dem Systemdatensatz als gemeinsamem Anker. Die Antwort auf die Anfrage einer Behörde ist dann ein Bericht und keine Recherche. Wie ein solches KI-Register aufgebaut ist, beschreiben wir zusammen mit der KI-Systemdokumentation.

Häufige Fragen

Was ist eine Model Card, einfach erklärt? Eine Model Card ist ein kurzer Steckbrief für ein trainiertes KI-Modell. Sie beantwortet in wenigen Abschnitten, wer das Modell gebaut hat, wofür es gedacht ist und wofür nicht, mit welchen Daten es trainiert und geprüft wurde, wie gut es für verschiedene Gruppen funktioniert und wo seine Grenzen liegen. Das Format stammt aus einem Aufsatz von Google-Forscherinnen aus dem Jahr 2019; auf Hugging Face ist es die README.md jedes Modells. Ist eine Model Card Pflicht? Das Format selbst nicht. Pflicht ist aber zunehmend der Inhalt: Seit dem 2. August 2025 müssen Anbieter von GPAI-Modellen nach Artikel 53 der KI-Verordnung eine technische Dokumentation nach Anhang XI führen; ab dem 2. Dezember 2027 schulden Anbieter von Hochrisiko-Systemen die technische Dokumentation nach Anhang IV; in Kalifornien veröffentlichen Frontier-Entwickler seit dem 1. Januar 2026 Transparenzberichte nach SB 53. Wer eine vollständige Karte führt, hat für alle drei Pflichten den Grundstock. Worin unterscheiden sich Model Card und System Card? Die Model Card beschreibt die Gewichte: Architektur, Trainingsdaten, Evaluation, Grenzen. Die System Card beschreibt das ausgelieferte Produkt, in dem ein oder mehrere Modelle arbeiten: Systemprompts, Schutzmechanismen, angebundene Werkzeuge, Sicherheitstests und Verhalten im Einsatz. OpenAI hat die System Card mit GPT-4 im März 2023 populär gemacht, veröffentlichte für die offenen gpt-oss-Modelle im August 2025 aber bewusst eine Model Card, weil dort nur Gewichte freigegeben wurden. Faustregel: ein Artefakt pro Objekt. Erfüllt eine Hugging-Face-Model-Card die KI-Verordnung? Nein. Nach unserer Gegenüberstellung deckt die Vorlage etwa die Hälfte der Felder des Anhang XI ab und keinen der Governance-Punkte des Anhang IV: menschliche Aufsicht, Risikomanagement, Cybersicherheit, Konformitätserklärung, Beobachtung nach dem Inverkehrbringen und Protokollierung fehlen ganz. Auch rechtlicher Name, Unionsmarktdatum, Datenherkunft nach Kategorien und die Methoden zur Erkennung ungeeigneter Quellen fehlen. Die Karte ist ein guter Anfang für die Dokumentation, aber für sich allein kein Nachweis gegenüber einer Behörde. Wer sollte die Model Card schreiben? Nicht die Entwicklerin allein. Das Model Card Guidebook von Hugging Face nennt drei Rollen: die Entwicklerin, die die technischen Abschnitte füllt; die Soziotechnikerin, also Juristin, Ethikerin oder Grundrechtsvertreterin, die Risiken, Verzerrungen und Grenzen prüft; und die Projektorganisation, die Vollständigkeit und Freigabe verantwortet. Dazu gehört ein namentlich benannter Owner, der die Karte über den Lebenszyklus pflegt und bei Anfragen von Behörden oder Kunden Auskunft gibt. Wie oft muss eine Model Card aktualisiert werden? Bei jeder neuen Modellversion und bei jeder Änderung an Daten, Training, Evaluation oder Zweckbestimmung, dazu mindestens einmal im Jahr eine Überprüfung ohne Anlass. Der Praxisleitfaden für GPAI-Modelle verlangt, frühere Fassungen zehn Jahre aufzubewahren; Artikel 18 der KI-Verordnung sieht dieselbe Frist für die technische Dokumentation von Hochrisiko-Systemen vor. Eine Karte, die nicht versioniert ist, lässt sich im Nachhinein keinem bestimmten Modellstand mehr zuordnen.

Fazit

Die Model Card ist das am weitesten verbreitete Vokabular, um ein KI-Modell zu beschreiben. Entworfen wurde sie für Transparenz, nicht für Compliance, und genau deshalb bleibt sie freiwillig, selbstberichtet und ungleichmäßig gefüllt. Die KI-Verordnung hat inzwischen eine längere Fassung derselben Karte für Modellanbieter ins Gesetz geschrieben und wird dasselbe im Dezember 2027 für Anbieter von Hochrisiko-Systemen tun; die US-Bundesstaaten verlangen Transparenzberichte mit demselben Gerüst. Die Aufgabe eines Governance-Teams besteht deshalb nicht darin, die Model Card zu ersetzen, sondern sie zu vervollständigen, zu versionieren, unterzeichnen zu lassen und mit dem System zu verbinden, dem sie dient. AI Sigil legt die Karte jedes Modells neben seinen KI-Systemdatensatz, seine Risiken und seine Kontrollen, damit die Dokumentation, die eine Behörde anfordert, bereits existiert.