Model Card

Eine Model Card (deutsch: Modellkarte) ist ein kurzer, standardisierter Steckbrief für ein KI-Modell. Sie beschreibt in festen Abschnitten, wofür das Modell gebaut wurde, mit welchen Daten es trainiert wurde, wie gut es in verschiedenen Personengruppen funktioniert und wo seine Grenzen liegen. Das Format wurde 2019 von einem Forschungsteam um Margaret Mitchell bei Google vorgeschlagen und ist heute ein Standard-Bestandteil, wenn Unternehmen ein KI-Modell freigeben, dokumentieren oder von Prüfern (Audit) kontrollieren lassen.

Was ist eine Model Card?

Der Begriff geht auf das Paper „Model Cards for Model Reporting" von Mitchell, Wu, Zaldivar et al. zurück, vorgestellt 2019 auf der FAT*-Konferenz (heute FAccT, die wissenschaftliche Fachkonferenz zu Fairness, Verantwortlichkeit und Transparenz von Algorithmen). Der Vorschlag adressierte eine konkrete Lücke: veröffentlichte Modelle wurden in wissenschaftlichen Aufsätzen und Code-Ablagen (Repositories) meist ohne klare Angaben dazu ausgeliefert, wofür sie gedacht sind, wie zuverlässig sie in unterschiedlichen Bevölkerungs- oder Nutzergruppen entscheiden und wo ihre bekannten Grenzen liegen. Model Cards liefern diese Angaben in einem festen Raster, das eine Fachabteilung, ein internes Prüfteam oder eine Aufsichtsbehörde lesen und bewerten kann.

Im Lifecycle begleitet eine Model Card das Modell von der Freigabe bis zur Außerbetriebnahme. Als kuratierte Zusammenfassung liegt sie neben dem Modell in der Registry oder im Repository und wird mit jeder Version fortgeschrieben; Trainings-Logs und die vollständige technische Dokumentation existieren daneben und werden aus der Karte referenziert.

Die Standard-Abschnitte nach Mitchell et al. bilden das Grundraster: Model Details (Bezeichnung, Version, Datum, Modell-Typ, Hyperparameter, Kontakt, Lizenz), Intended Use (primärer und sekundärer Nutzungsbereich, ausgeschlossene Anwendungen), Factors (relevante Untergruppen, Instrumente, Umgebungen), Metrics (verwendete Modellmetriken und Entscheidungsschwellen mit Begründung der Metrik-Wahl), Evaluation Data (Datensätze, Motivation, Vorverarbeitung), Training Data (soweit veröffentlichbar, sonst Aggregate und Verweise), Quantitative Analyses (unitäre und intersektionale Ergebnisse pro Untergruppe), Ethical Considerations (Risiken, sensible Kontexte, Minderung) und Caveats and Recommendations (bekannte Grenzen, offene Punkte, Empfehlungen zur Nachprüfung).

Formal existieren mehrere Varianten. Hugging Face verwendet ein YAML-Frontmatter mit Markdown-Body; das Google Model Card Toolkit erzeugt JSON und HTML aus TFX- und ML-Metadata-Objekten; die Databricks Mosaic AI Model Registry bindet Karten als Beschreibung des Modell-Objekts in Unity Catalog ein, verknüpft mit Lineage über Trainings-Runs, Daten und Feature-Tabellen. OpenAI, Anthropic und Meta veröffentlichen für ihre Foundation-Modelle eigene Varianten (System Cards, Model Cards), die um Trainings-Datenmengen, Sicherheits-Evaluierungen, Red-Teaming-Ergebnisse, Halluzinations-Raten und Nutzungsrichtlinien erweitert sind. Für agentische Systeme kommen Werkzeug-Landschaft, Guardrails, Eskalations-Regeln und Beobachtbarkeits-Konfiguration als zusätzliche Blöcke hinzu.

Regulatorisch verankert der EU AI Act in Anhang IV Anforderungen an die technische Dokumentation von Hochrisiko-Systemen, die inhaltlich stark überlappen (Zweck, Systemarchitektur, Trainings- und Validierungsdaten, Leistungs- und Robustheits-Kennzahlen, bekannte Grenzen). NIST AI RMF führt Model Documentation unter „Transparent" und „Accountable"; ISO/IEC 42001:2023 fordert dokumentierte Nachweise über den Modell-Lifecycle. Eine sorgfältig geführte Model Card deckt große Teile dieser Pflichten in einem einzigen Artefakt ab; sie ersetzt aber weder die vollständige Konformitäts-Akte nach AI Act noch die Modell-Risiko-Analyse.

Abgrenzung zu Datasheets, Model Registry, Explainable AI und Model Documentation

Fünf Begriffe stehen im Umfeld der Model Card und werden im Alltag oft vermischt.

Datasheets for Datasets sind das Schwester-Format aus dem Paper von Gebru, Morgenstern, Vecchione et al. (2018/2021). Sie dokumentieren die Datengrundlage (Erhebung, Zusammensetzung, Bias in den Daten, Verwendungshinweise); die Model Card dokumentiert das trainierte Modell. In einer sauberen Governance-Kette verweist die Model Card auf die Datasheets ihrer Trainings- und Evaluations-Daten; Karte und Datasheet ergänzen sich.

Eine Model Registry ist ein System-Objekt, also eine Datenbank mit API, die Modelle, Versionen, Aliases und Berechtigungen verwaltet. Die Model Card ist ein Dokumentations-Artefakt an oder in der Registry. Die Registry liefert die Infrastruktur, verknüpft die Karten mit Lineage und macht sie versionierbar; die Karte selbst ist Inhalt.

Explainable AI liefert Methoden, um Modell-Entscheidungen nachvollziehbar zu machen (SHAP, LIME, Counterfactual Explanations). XAI-Ergebnisse sind Input für den Analyse-Abschnitt einer Model Card, insbesondere für globale Feature-Beiträge und stichprobenartige Fall-Erklärungen. Die Karte ist der Rahmen, XAI die Methode.

Model Documentation im weiten Sinn umfasst zusätzlich Trainings-Notebooks, Experiment-Logs, Config-Files, Deployment-Manifeste und Ops-Runbooks. Die Model Card fasst diese Volldokumentation in einer kuratierten, adressatengerechten Kurzform zusammen. Für die Konformitätsbewertung nach EU AI Act, Anhang IV ist die Karte ein Bestandteil der Akte; für das Modell-Risiko-Management liefert sie einen Teil der Nachweise, ergänzt um Validierungs-Bericht, Monitoring-Konzept und Freigabe-Beschluss.

Beispiel: Kreditscoring-Modell und LLM-basierter Wissensassistent

Ein Kreditscoring-Modell wird über die Databricks Mosaic AI Model Registry produktiv gesetzt. Die Model Card liegt als Beschreibung am Modell-Objekt in Unity Catalog, versioniert wie die Modellversion selbst. Sie führt den Zweck (Antragsprüfung Privatkunden Ratenkredit), den Modell-Typ (Gradient-Boosted Trees), die Trainingsdaten (Zeitraum, Filialen, ausgeschlossene Kohorten), die Leistungsdaten pro Untergruppe (True-Positive-Rate über Geschlecht und Altersgruppe), die Fair-Metrik (Equal Opportunity mit 5-Prozent-Toleranz), das XAI-Verfahren (TreeSHAP), die bekannten Grenzen (keine belastbare Aussage bei sehr dünner Filial-Historie) und die Empfehlungen zur Nachprüfung (halbjährliche Fairness-Prüfung, Rekalibrierung bei Drift-Schwelle X). Dieselbe Karte dient als Basis für die technische Dokumentation nach EU AI Act, Anhang IV; für die Konformitätsbewertung eines Hochrisiko-Systems wird sie um die Risiko-Management-Akte und die Post-Market-Monitoring-Konfiguration ergänzt.

Ein LLM-basierter Wissensassistent im Kundenservice hat eine Model Card mit erweiterten Feldern: Foundation-Modell und Version, RAG-Konfiguration (Vektor-Store, Retriever, Top-k, Chunking-Strategie), Guardrails (Refusal-Regeln, PII-Filter), Sicherheits-Evaluierungen (Prompt-Injection-Testset, PII-Leak-Rate, Halluzinations-Rate auf domänenspezifischem Evaluations-Set) und Handoff-Regeln zum Menschen. Die Karte wird nach jedem Modell-Update aus der Evaluations-Pipeline automatisiert erzeugt und mit dem Modell-Objekt in der Registry verknüpft. Für die Freigabe wird die aktualisierte Karte gegen die vorherige Version geprüft; Abweichungen in Sicherheits-Metriken jenseits definierter Toleranzen sind Freigabe-Blocker.