Der Grundgedanke ist einfach, aber wirkungsvoll: Ein KI-Modell ist selten selbsterklärend. Ob ein Klassifikationsmodell für die Kreditwürdigkeit, ein Sprachmodell im Kundenservice oder ein Bilderkennungsmodell in der Qualitätskontrolle – ohne begleitende Dokumentation bleibt für Außenstehende unklar, unter welchen Bedingungen das Modell trainiert wurde, für welche Einsatzzwecke es gedacht ist und wo es zuverlässig arbeitet. Genau diese Lücke schließt die Model Card: Sie bündelt die entscheidenden Informationen in einem einheitlichen, wiederkehrenden Format, das sich über verschiedene Modelle hinweg vergleichen lässt.
Das Konzept stammt ursprünglich aus der Forschung zu verantwortungsvoller KI und wurde Ende der 2010er-Jahre bekannt. Die Kernidee lautete: So wie ein Lebensmittel eine Nährwerttabelle trägt, sollte auch ein KI-Modell eine standardisierte Kurzbeschreibung erhalten, die Transparenz über Leistung und Grenzen schafft – besonders im Hinblick auf mögliche Verzerrungen (Bias) über verschiedene Personengruppen hinweg. Inzwischen sind Model Cards ein etablierter Baustein guter KI-Praxis und finden sich in vielen Modell-Repositorien, Plattformen und internen Governance-Prozessen.
Am Anfang war die Model Card ein wissenschaftlicher Vorschlag, um die Dokumentation von Machine-Learning-Modellen zu vereinheitlichen. Der praktische Reiz zeigte sich schnell: Modelle wandern durch viele Hände – von der Entwicklung über die Validierung bis in den Betrieb – und werden häufig von Personen genutzt, die nicht an ihrer Entstehung beteiligt waren. Ohne begleitendes Dokument geht Wissen verloren, sobald Mitarbeitende wechseln oder ein Modell von einem externen Anbieter bezogen wird. Die Model Card konserviert dieses Wissen an einem definierten Ort.
Heute ist der Begriff bewusst offen: Es gibt keine einzige, verbindlich vorgeschriebene Struktur, sondern eine Familie von Vorlagen mit gemeinsamen Grundelementen. Manche Organisationen nutzen sehr knappe Cards von ein bis zwei Seiten, andere umfangreiche Dokumente mit detaillierten Auswertungen. Entscheidend ist nicht die Länge, sondern dass die wesentlichen Fragen konsistent und ehrlich beantwortet werden.
Eine Model Card ist ausdrücklich kein Werbeprospekt. Ihr Wert liegt gerade darin, dass sie auch die Grenzen und Schwächen eines Modells benennt: für welche Personengruppen oder Datensituationen die Leistung nachlässt, welche Annahmen dem Training zugrunde lagen und welche Einsatzfälle ausdrücklich nicht empfohlen sind. Diese ehrliche Selbstauskunft unterscheidet die Model Card von reiner Produktkommunikation – und macht sie erst zum vertrauenswürdigen Governance-Instrument.
Wichtig ist zudem die Abgrenzung zur reinen Code-Dokumentation. Eine Model Card beschreibt nicht in erster Linie, wie ein Modell technisch implementiert ist, sondern was es tut, wie gut, für wen und mit welchen Einschränkungen. Sie richtet sich damit bewusst auch an nicht-technische Adressat:innen – an Fachbereiche, Datenschutz, Recht und Management, die eine fundierte Einschätzung treffen müssen, ohne den Quellcode zu lesen.
Der wohl wichtigste Nutzen ist Transparenz. Eine Model Card macht sichtbar, was ein Modell leistet und wo seine Grenzen liegen. Das hilft nicht nur den Entwickelnden, sondern vor allem den nachgelagerten Nutzenden: Fachbereiche können einschätzen, ob ein Modell für ihren Anwendungsfall geeignet ist; Datenschutz und Recht erkennen, ob personenbezogene Daten im Spiel sind; die Geschäftsführung versteht das Risikoprofil, ohne selbst tief in die Technik einsteigen zu müssen. Transparenz ist damit die Voraussetzung für fundierte Entscheidungen über den Einsatz von KI.
Der zweite große Nutzen ist die Governance. In einer wachsenden KI-Landschaft verliert man schnell den Überblick, welche Modelle im Einsatz sind, wer sie verantwortet und wann sie zuletzt bewertet wurden. Model Cards bilden das dokumentarische Rückgrat eines KI-Inventars: Jedes Modell erhält einen definierten Steckbrief, der zentral auffindbar ist. Das erleichtert Freigabeprozesse, interne Prüfungen und die Beantwortung von Anfragen – etwa von Auftraggebern, Auditor:innen oder Aufsichtsbehörden.
Der Charme einer guten Model Card liegt darin, dass sie unterschiedlichen Zielgruppen dient, ohne für jede ein eigenes Dokument zu erfordern. Die folgende Übersicht zeigt, wer typischerweise welchen Nutzen zieht.
Der häufigste Einwand lautet, Model Cards seien zusätzlicher Dokumentationsaufwand ohne unmittelbaren Ertrag. In der Praxis kehrt sich diese Rechnung oft um. Der Aufwand, eine Card zu erstellen, ist überschaubar, weil die enthaltenen Informationen ohnehin während der Entwicklung entstehen – sie werden nur an einem Ort zusammengeführt. Der Nutzen dagegen entsteht wiederholt: bei jeder Freigabe, jeder Prüfung, jeder Lieferantenanfrage und jedem Personalwechsel. Gerade im Mittelstand, wo Wissen häufig an einzelnen Personen hängt, ist diese Konservierung besonders wertvoll.
Hinzu kommt ein Effekt, der oft unterschätzt wird: Das Ausfüllen einer Model Card ist ein strukturierter Nachdenkprozess. Wer die Frage „Für welche Fälle ist dieses Modell ausdrücklich nicht geeignet?“ ehrlich beantworten muss, erkennt Risiken oft überhaupt erst. Die Card ist damit nicht nur Dokumentation, sondern auch ein Frühwarninstrument, das blinde Flecken sichtbar macht.
Am Anfang jeder Card stehen die grundlegenden Identifikationsdaten. Dazu gehören der Name und die Version des Modells, das Erstellungs- bzw. Veröffentlichungsdatum, der Modelltyp (etwa ein Klassifikationsmodell, ein Sprachmodell oder ein Regressionsmodell), die verantwortliche Organisation oder Person sowie eine Kontaktstelle für Rückfragen. Ergänzend werden häufig die Lizenz, verwendete Basismodelle oder Bibliotheken und Verweise auf weiterführende Dokumentation aufgeführt. Diese Angaben klingen banal, sind aber die Voraussetzung dafür, ein Modell überhaupt eindeutig zu referenzieren – gerade wenn mehrere Versionen im Umlauf sind.
Der Abschnitt zum Verwendungszweck ist oft der wertvollste. Hier wird beschrieben, für welche vorgesehenen Anwendungsfälle das Modell entwickelt wurde, welche Nutzergruppen es adressiert und – besonders wichtig – für welche Einsatzfälle es ausdrücklich nicht geeignet ist. Ein Bilderkennungsmodell für die industrielle Qualitätskontrolle etwa mag hervorragend Kratzer auf Metalloberflächen erkennen, aber völlig ungeeignet sein, medizinische Aufnahmen zu bewerten. Die klare Benennung dieser Grenze verhindert gefährliche Fehlanwendungen. Aus unserer Erfahrung ist dieser Abschnitt der stärkste Hebel, um KI-Risiken frühzeitig zu adressieren.
Der Abschnitt zu den Trainingsdaten beschreibt, auf welcher Datengrundlage das Modell gelernt hat: Herkunft, Umfang, abgedeckte Zeiträume, Auswahl- und Aufbereitungsschritte sowie bekannte Lücken. Diese Angaben sind entscheidend, um die Repräsentativität und mögliche Verzerrungen einzuschätzen. Wenn ein Modell etwa überwiegend auf Daten einer bestimmten Region oder Zeitperiode trainiert wurde, ist seine Übertragbarkeit auf andere Kontexte begrenzt.
Die Metriken dokumentieren, wie die Leistung gemessen wurde und mit welchen Ergebnissen. Gute Model Cards begnügen sich nicht mit einer einzelnen Gesamtkennzahl, sondern schlüsseln die Leistung nach relevanten Untergruppen auf – etwa nach Geschlecht, Altersgruppe oder anderen sensiblen Merkmalen, soweit rechtlich zulässig und sinnvoll. So wird sichtbar, ob ein Modell für bestimmte Gruppen systematisch schlechter arbeitet. Wichtig ist, die Testbedingungen und die Aussagekraft der Zahlen transparent zu machen, statt Metriken ohne Kontext zu präsentieren.
Der Abschnitt zu den Limitierungen schließlich benennt bekannte Schwächen, Annahmen, ethische Erwägungen und Risiken – etwa die Gefahr von Fehlausgaben, die Anfälligkeit für bestimmte Eingaben oder die Notwendigkeit menschlicher Kontrolle. Dieser Abschnitt ist das Herzstück einer ehrlichen Model Card und unterscheidet sie am deutlichsten von reiner Produktkommunikation.
Die Grundidee ist überall dieselbe: standardisierte Transparenz über einen KI-bezogenen Gegenstand. Die Formate unterscheiden sich vor allem darin, was sie dokumentieren – ein einzelnes Modell, den zugrunde liegenden Datensatz oder ein zusammengesetztes System aus mehreren Komponenten. In der Praxis ergänzen sich diese Artefakte und werden häufig miteinander verknüpft.
Während die Model Card das Modell beschreibt, richten Data Sheets (auch „Datasheets for Datasets“) den Blick auf den zugrunde liegenden Datensatz. Sie beantworten Fragen wie: Warum und für welchen Zweck wurde der Datensatz erstellt? Wie wurde er zusammengesetzt und erhoben? Welche Vorverarbeitung fand statt? Für welche Verwendungen ist er geeignet – und für welche nicht? Data Sheets sind besonders wertvoll, weil viele Modellprobleme ihre Ursache in den Daten haben. Wer Modell und Datensatz gemeinsam dokumentiert, schafft eine deutlich belastbarere Nachvollziehbarkeit.
Reale KI-Anwendungen bestehen selten aus einem einzelnen Modell. Häufig arbeiten mehrere Modelle, Regelwerke und Sicherheitsmechanismen zusammen. Genau hier setzen System Cards an: Sie dokumentieren nicht ein isoliertes Modell, sondern das Zusammenspiel der Komponenten im Gesamtsystem – einschließlich Schutzmaßnahmen, Filtern und dem Verhalten unter realen Bedingungen. Für komplexe Anwendungen liefert eine System Card oft das aussagekräftigere Bild als die Summe einzelner Model Cards, weil erst das Zusammenspiel das tatsächliche Risikoprofil bestimmt.
AI FactSheets verfolgen die Idee eines standardisierten Faktenblatts für KI-Dienste – analog zu den Datenblättern, die in vielen technischen Branchen üblich sind. Sie bündeln Transparenz-Informationen über den gesamten Lebenszyklus eines KI-Dienstes und sollen es Anwendenden erleichtern, dessen Vertrauenswürdigkeit einzuschätzen. In der Praxis überschneiden sich AI FactSheets inhaltlich stark mit Model Cards; der Unterschied liegt eher in der Betonung eines durchgängigen, lebenszyklusorientierten und stärker standardisierten Rahmens.
Der EU AI Act – die Verordnung (EU) 2024/1689 – verlangt für Hochrisiko-KI-Systeme nach aktuellem Stand unter anderem eine umfassende technische Dokumentation, Angaben zu Trainings-, Validierungs- und Testdaten (Daten-Governance), zur erreichten Genauigkeit und Robustheit sowie zu bekannten Risiken und zur vorgesehenen menschlichen Aufsicht. Genau diese Inhalte deckt eine gut geführte Model Card in weiten Teilen ab. Sie ist zwar kein rechtlich definiertes Pflichtdokument im Sinne der Verordnung, kann aber als praktischer Baustein dienen, um die geforderten Informationen strukturiert bereitzustellen. Ob und in welchem Umfang eine Model Card konkrete Nachweispflichten erfüllt, ist eine Frage des Einzelfalls und sollte fachjuristisch geprüft werden.
Hinzu kommen die Transparenzpflichten des AI Act. Für Hochrisiko-Systeme sieht die Verordnung nach aktuellem Stand vor, dass Betreiber hinreichende Informationen über das System erhalten, um es sachgerecht einsetzen und beaufsichtigen zu können. Eine Model Card, die Verwendungszweck, Grenzen und nötige Aufsicht klar benennt, unterstützt diese Informationsweitergabe entlang der Wertschöpfungskette – etwa vom Anbieter an den Betreiber.
Die ISO/IEC 42001 ist die internationale Norm für KI-Managementsysteme (AI Management System, AIMS). Sie beschreibt, wie eine Organisation den verantwortungsvollen Umgang mit KI systematisch organisiert – mit Rollen, Richtlinien, Risikobetrachtung, Kontrollen und kontinuierlicher Verbesserung. Model Cards fügen sich hier natürlich ein: Sie sind ein konkretes, wiederkehrendes Dokumentationsartefakt, mit dem ein KI-Managementsystem seine Modelle erfasst, bewertet und nachvollziehbar hält. Wer ein AIMS nach ISO/IEC 42001 aufbaut, findet in Model Cards ein praktisches Werkzeug, um die Transparenz- und Dokumentationsanforderungen der Norm operativ zu erfüllen.
Der Zusammenhang ist wechselseitig: Die Norm liefert den organisatorischen Rahmen – wer ist zuständig, wie werden Modelle freigegeben, wie wird überwacht –, und die Model Card liefert das konkrete Dokument, das je Modell mit Inhalt gefüllt wird. Zusammen ergibt sich eine belastbare Struktur, die sowohl interne Governance als auch externe Nachweisfähigkeit stützt.
Ein wichtiger Grundsatz zum Schluss dieses Kapitels: Model Cards sind ein Instrument guter Praxis, kein rechtlicher Freifahrtschein. Sie erhöhen die Wahrscheinlichkeit, regulatorische Anforderungen erfüllen zu können, ersetzen aber weder die individuelle rechtliche Bewertung noch die vollständige, formal geforderte Dokumentation. Die konkrete Ausgestaltung im Einzelfall gehört in fachkundige Hände – dies ist keine Rechtsberatung.
Der größte Fehler in der Praxis ist, die Model Card als nachträgliche Fleißaufgabe zu behandeln. Wird sie erst nach Fertigstellung des Modells rekonstruiert, sind wichtige Details oft schon verloren – etwa die genaue Datenauswahl oder die Gründe für bestimmte Entscheidungen. Deutlich besser ist es, die Card parallel zur Entwicklung aufzubauen: Jeder Schritt, der ohnehin dokumentiert werden sollte, fließt direkt in die Card ein. So entsteht sie fast nebenbei und bleibt inhaltlich korrekt.
Modelle ändern sich – durch Re-Training, neue Daten oder angepasste Parameter. Eine Model Card ohne Versionsbezug wird deshalb schnell irreführend. Deshalb gehört zu jeder Card eine klare Versionierung, die eindeutig festhält, auf welchen Modellstand sie sich bezieht und wann sie zuletzt aktualisiert wurde. Bewährt hat sich, die Card gemeinsam mit dem Modell zu versionieren – etwa im selben Repository –, sodass Modell und Dokumentation nicht auseinanderlaufen.
Damit eine Card gepflegt wird, braucht sie eine verantwortliche Person oder Rolle. In der Praxis bewährt sich eine geteilte Verantwortung: Die technische Pflege liegt oft bei den Entwickelnden, während Governance oder Compliance über die Vollständigkeit und Aktualität wachen. Entscheidend ist, dass die Zuständigkeit ausdrücklich benannt ist – eine Card, für die sich niemand verantwortlich fühlt, veraltet zwangsläufig.
Am unteren Ende der Aufwandsskala steht die strukturierte Textvorlage: ein einfaches Dokument oder eine Markdown-Datei mit festen Abschnitten, die für jedes Modell ausgefüllt werden. Dieser Ansatz ist unschlagbar niedrigschwellig und für den Einstieg oder für Organisationen mit wenigen Modellen völlig ausreichend. Der Vorteil liegt in der sofortigen Verfügbarkeit ohne technische Hürden; der Nachteil ist, dass Pflege und Konsistenz allein von Disziplin abhängen.
Eine Stufe darüber liegen standardisierte Vorlagen und Frameworks, die von der Community oder im Rahmen von Plattformen bereitgestellt werden. Sie geben eine erprobte Struktur vor, sodass nicht jede Organisation das Rad neu erfinden muss. Viele Modell-Repositorien und ML-Plattformen bieten inzwischen eingebaute Model-Card-Formate an, die sich direkt neben dem Modell pflegen lassen – das hält Modell und Dokumentation zusammen.
Mit wachsender Modellanzahl gewinnt die Automatisierung an Bedeutung. Es gibt Werkzeuge und Bibliotheken, die Teile einer Model Card automatisch aus dem Trainingsprozess befüllen – etwa Metriken, Datenstatistiken oder Versionsangaben. Der Charme liegt darin, dass Zahlen nicht manuell abgetippt werden müssen und damit weniger fehleranfällig sind. Ideal ist eine Integration in die bestehende MLOps-Pipeline: Bei jedem Training wird eine aktuelle Card mitgeneriert oder aktualisiert, sodass Dokumentation und Modell synchron bleiben.
Für Organisationen mit vielen Modellen bieten sich zudem Model-Registry- und Governance-Plattformen an, die Model Cards zentral verwalten, versionieren und mit Freigabe- und Audit-Workflows verknüpfen. Solche Lösungen lohnen sich vor allem dort, wo Modelle in nennenswerter Zahl produktiv laufen und wo Nachweisfähigkeit gegenüber internen oder externen Stellen gefragt ist.
Der erste Rat aus unserer Beratungspraxis lautet: klein anfangen. Wählen Sie nicht sofort alle Modelle, sondern beginnen Sie mit den ein bis drei wichtigsten – idealerweise solchen, die produktiv laufen und ein spürbares Risiko oder eine hohe Geschäftsbedeutung haben. An diesen Pilotfällen entwickeln Sie eine schlanke Vorlage, sammeln Erfahrung und schaffen ein Muster, das sich später auf weitere Modelle übertragen lässt.
Der zweite Rat: an Bestehendes andocken. Viele Informationen für eine Model Card existieren bereits – in Projektdokumentationen, Datenschutz-Verzeichnissen, Testberichten oder E-Mails. Die Card führt sie an einem Ort zusammen, statt neue Erhebungen zu erfordern. Wer bereits DSGVO-Strukturen oder ein KI-Inventar pflegt, hat einen großen Teil der Grundlage schon geschaffen und muss die Model Card nur damit verknüpfen.
Ein besonders wichtiger Punkt für den Mittelstand: Die meisten Unternehmen entwickeln keine eigenen Modelle, sondern nutzen fertige KI-Dienste und -Modelle von Anbietern. Auch hier lohnt sich eine Model Card – als zusammenfassende Betreiber-Sicht. Fordern Sie beim Anbieter die vorhandene Dokumentation an (viele stellen eigene Model Cards bereit) und ergänzen Sie sie um Ihre spezifische Nutzung: In welchem Anwendungsfall setzen Sie das Modell ein, welche menschliche Aufsicht haben Sie vorgesehen, welche Grenzen sind für Ihren Kontext relevant? So schaffen Sie Transparenz auch für zugekaufte KI und erfüllen Ihre Sorgfaltspflichten als Betreiber.
Die grundlegendste Grenze ist, dass eine Model Card nur so gut ist wie die Informationen, die hineingeschrieben werden. Sie ist eine Selbstauskunft und keine unabhängige Prüfung. Eine Card kann unvollständig, geschönt oder schlicht veraltet sein. Sie ersetzt daher weder ein KI-Audit noch eine gründliche Validierung, sondern dokumentiert lediglich, was die verantwortliche Stelle über das Modell weiß und offenlegt. Transparenz ist eine notwendige, aber keine hinreichende Bedingung für Vertrauenswürdigkeit.
Der Bezug zur DSGVO ist zweischneidig. Einerseits unterstützt eine Model Card den Datenschutz: Der Abschnitt zu den Trainingsdaten hilft, die Herkunft und Art der verwendeten Daten nachvollziehbar zu machen, was der Rechenschaftspflicht zugutekommt. Angaben zu Grenzen und Risiken können in eine Datenschutz-Folgenabschätzung (DSFA) einfließen, und die Transparenz über die Funktionsweise stützt Informationspflichten gegenüber betroffenen Personen.
Andererseits ist bei der Card selbst Vorsicht geboten: Sie sollte keine personenbezogenen Daten enthalten, die für ihren Zweck nicht erforderlich sind. Es geht darum, ein Modell zu beschreiben – nicht darum, Trainingsbeispiele mit Personenbezug offenzulegen. Der Grundsatz der Datenminimierung gilt auch für die Dokumentation. Wo Metriken nach sensiblen Merkmalen aufgeschlüsselt werden, um Fairness zu prüfen, ist zudem sorgfältig zu prüfen, ob und wie das datenschutzkonform möglich ist. Ob im konkreten Fall eine DSFA nötig ist und wie Model Card und Datenschutz zusammenspielen, ist eine Frage des Einzelfalls und sollte mit Datenschutz- und Rechtskundigen geklärt werden.
