Was gehört in eine Model Card für AI Governance?

Kurzantwort

Eine Model Card für AI Governance sollte nicht nur beschreiben, welches KI-Modell eingesetzt wird, sondern strukturiert dokumentieren, wofür das Modell genutzt wird, welche Version im Einsatz ist, wer Anbieter oder Betreiber ist, welche Datenquellen verwendet werden, welche Performance-, Bias- und Risikoinformationen vorliegen, welche Einschränkungen bekannt sind, wie das Modell mit einem konkreten KI-Use-Case verbunden ist, welche Freigaben erteilt wurden und wann die nächste Überprüfung erforderlich ist.

Damit eine Model Card auch im laufenden Betrieb belastbar bleibt, darf sie nicht als statischer PDF-Anhang verstanden werden. Sobald sich Modellversion, Datenquelle, Provider, Zweck, Metriken oder Risikobewertung ändern, muss auch die Model Card aktualisiert, geprüft und versioniert werden.

Warum eine Model Card nach dem Go-live weitergeführt werden muss

Model Cards werden in vielen Organisationen noch wie ein Dokumentationsanhang behandelt, der einmal erstellt und anschließend abgelegt wird. Häufig enthält ein solches Dokument einige technische Informationen zum Modell, Angaben zu Trainingsdaten, Metriken oder bekannten Einschränkungen sowie einen Link zur Dokumentation des Anbieters. Sobald der KI-Use-Case jedoch produktiv eingesetzt wird, können sich genau jene Grundlagen verändern, auf denen die ursprüngliche Dokumentation beruht.

• Das Modell wird aktualisiert.
• Der Anbieter führt eine neue Version ein.
• Eine Datenquelle wird ergänzt.
• Der Fachbereich nutzt den Output anders als ursprünglich beschrieben.
• Neue Risiken werden erkannt.
• Eine Performance-Metrik verändert sich.
• Ein Monitoring-Hinweis bleibt offen.
• Eine Freigabebedingung läuft aus.

Wenn die Model Card solche Änderungen nicht nachvollzieht, bildet sie nicht mehr die produktive Modellrealität ab, sondern nur noch einen früheren Stand. Entscheidend ist daher nicht, ob eine Model Card einmal erstellt wurde, sondern ob ihre Inhalte weiterhin mit der tatsächlichen Modellnutzung übereinstimmen. Fehlt diese Übereinstimmung, entsteht ein Governance-Problem, weil Prüfungen, Freigaben und Verantwortlichkeiten auf einer veralteten Grundlage beruhen können.

Warum Model Cards in AI Governance anders verstanden werden müssen

In AI Governance geht es nicht nur darum, ein Modell technisch zu beschreiben, sondern darum, seinen Einsatz im Unternehmen steuerbar, prüfbar und verantwortbar zu machen. Ein statisches Dokument reicht dafür nicht aus, weil ein Modell in mehreren Use Cases eingesetzt werden kann, derselbe Provider verschiedene Modellversionen bereitstellt, ein KI-Tool mehrere Modelle verwenden kann und sich die Risikobewertung je nach Zweck, Datenquelle oder Entscheidungseinfluss erheblich unterscheidet.

Eine Model Card sollte deshalb in einer AI-Governance-Plattform als lebendes Betriebsobjekt verstanden werden, das Modell, Anbieter, Daten, Use Case, Risiko, Freigabe, Monitoring und Review miteinander verbindet. Erst durch diese Verknüpfung wird aus einer technischen Beschreibung ein Bestandteil des laufenden Governance-Prozesses.

Das Problem mit dem PDF-Verständnis

Ein PDF kann für einen Export, eine Prüfung, einen Nachweis gegenüber Kunden, Auditoren oder internen Gremien oder als Momentaufnahme durchaus sinnvoll sein. Als Betriebsmodell ist es jedoch nur eingeschränkt geeignet, weil ein statisches Dokument nicht automatisch erkennt, ob die dokumentierte Version noch aktiv ist, ob ein Use Case inzwischen auf eine andere Datenquelle zugreift, ob ein Review erforderlich geworden ist, ob eine Freigabe noch zur aktuellen Modellversion passt oder ob Risiken und Maßnahmen offen sind.

Ebenso wenig kann ein PDF zuverlässig zwischen einem historischen und einem produktiven Stand unterscheiden oder anzeigen, wer eine Änderung zuletzt geprüft hat. Die zentrale Frage lautet deshalb nicht: „Haben wir eine Model Card als Dokument?“, sondern: „Wird die Model Card als Teil des laufenden AI-Governance-Prozesses gepflegt?“

Was eine Model Card leisten muss

Eine Model Card sollte in AI Governance mindestens fünf Funktionen erfüllen, die über eine reine Modellbeschreibung hinausgehen.

1. Strukturierte Modellbeschreibung: Sie dokumentiert Name, Version, Anbieter, Modelltyp, Zweck, Einsatzgrenzen und technische Grundinformationen.
2. Verbindung mit konkreten KI-Use-Cases: Sie stellt den Bezug zum tatsächlichen Einsatz her, weil ein Modellrisiko erst im konkreten Nutzungskontext sinnvoll bewertet werden kann.
3. Dokumentation von Bewertungen: Sie erfasst unter anderem Performance, Bias, Erklärbarkeit, Robustheit, Datenschutz, Informationssicherheit und bekannte Einschränkungen.
4. Unterstützung von Entscheidungen: Sie schafft die Grundlage dafür, Freigaben einer konkreten Modellversion und einem konkreten Use Case zuzuordnen.
5. Aktualität im Betrieb: Sie macht Änderungen an Version, Datenquelle, Provider, Zweck, Metriken oder Risiko nachvollziehbar.

Diese Funktionen machen aus einer Model Card eine Betriebsdokumentation, die nicht nur den Ist-Stand beschreibt, sondern auch in Prüf-, Freigabe- und Reviewprozesse eingebunden werden kann.

Welche Felder wirklich gebraucht werden

Eine gute Model Card sollte nicht überwiegend aus Freitext bestehen, sondern strukturierte Felder enthalten, damit Informationen geprüft, gefiltert, berichtet und aktualisiert werden können. Welche Felder im Einzelnen erforderlich sind, hängt vom jeweiligen Governance-Modell ab; typischerweise gehören jedoch folgende Bereiche dazu.

Modellidentität

• Modellname
• interne Modell-ID
• Modellversion
• Modelltyp
• Provider
• Betreiber
• Hosting- oder Bereitstellungsmodell
• Status
• Gültig ab
• letzte Änderung
• nächster Review

Einsatzkontext

• verbundene KI-Use-Cases
• Zweck des Einsatzes
• betroffene Geschäftsprozesse
• Nutzergruppen
• Output-Typ
• Entscheidungseinfluss
• menschliche Kontrolle
• Einsatzgrenzen
• nicht zulässige Nutzungen

Daten und Datenquellen

• Trainingsdaten, soweit bekannt
• Eingabedaten im konkreten Use Case
• angebundene Datenquellen
• personenbezogene Daten
• besondere Kategorien personenbezogener Daten
• vertrauliche Unternehmensdaten
• Datenherkunft
• Datenqualität
• Aktualität der Daten
• Datenfluss und Speicherorte

Performance und Metriken

• relevante Leistungsmetriken
• Testdatum
• Testumgebung
• Testdatensatz
• bekannte Abweichungen
• Fehlerraten
• Schwellenwerte
• Monitoring-Ergebnisse
• Vergleich zur vorherigen Version

Bias, Fairness und Erklärbarkeit

• bekannte Bias-Risiken
• getestete Gruppen oder Szenarien
• Fairness-Bewertungen
• Erklärbarkeitsansatz
• Grenzen der Erklärbarkeit
• bekannte Fehlermuster
• erforderliche menschliche Prüfung

Risiken und Kontrollen

• Risikoklassifikation
• Datenschutzrisiken
• Sicherheitsrisiken
• rechtliche Risiken
• operative Risiken
• Reputationsrisiken
• Kontrollmaßnahmen
• offene Maßnahmen
• Restrisiko
• Risikoakzeptanz

Provider und Drittbezug

• Anbieter
• Vertragsgrundlage
• Dokumentation des Anbieters
• Subdienstleister oder relevante Drittparteien
• Speicher- und Verarbeitungsorte
• Support- und Änderungsinformationen
• SLA oder Betriebsinformationen
• Informationspflichten bei Modelländerungen

Freigabe und Governance

• Owner
• Model Owner
• Use Case Owner
• Reviewer
• DPO / Datenschutzprüfung
• Legal Review
• IT Security Review
• Fachbereichsfreigabe
• Managementfreigabe, falls erforderlich
• Freigabedatum
• Freigabebedingungen
• Reviewintervall

Änderungen und Versionierung

• Änderungshistorie
• Vorher-/Nachher-Werte
• Grund der Änderung
• auslösende Person oder Rolle
• betroffene Use Cases
• erforderliche erneute Freigaben
• historische Versionen
• aktueller produktiver Stand

Die Liste ist umfangreich, was jedoch kein Selbstzweck ist. Eine Model Card ist kein Deckblatt, sondern ein Betriebsobjekt, das die für Governance relevanten Informationen so zusammenführt, dass sie im laufenden Betrieb nachvollziehbar und auswertbar bleiben.

Warum der Use Case entscheidend ist

Ein Modell allein sagt wenig über das tatsächliche Risiko aus, weil dasselbe Sprachmodell beispielsweise für interne Textentwürfe oder für die Vorbewertung von Beschwerden, Bewerbungen, Kundenanfragen oder Risikofällen eingesetzt werden kann. Obwohl das technische Modell identisch oder ähnlich ist, unterscheiden sich die Governance-Anforderungen je nach Einsatz erheblich.

Deshalb muss eine Model Card immer mit dem konkreten Use Case verbunden werden, für den relevant ist, mit welchen Daten das Modell arbeitet, welchen Output es erzeugt, welchen Einfluss dieser Output auf Entscheidungen hat und wer dafür verantwortlich ist. Ohne diese Verbindung bleibt die Model Card technisch; erst durch den Einsatzkontext wird sie governancefähig.

Modellversionen sind keine Randnotiz

Viele Organisationen unterschätzen die Bedeutung von Modellversionen, obwohl bereits eine neue Version fachlich relevante Auswirkungen haben kann. Sie kann die Antwortqualität verbessern, zugleich neue Fehlermuster erzeugen, bestehende Prompts anders interpretieren, andere Schwellenwerte benötigen oder neue Sicherheitsmechanismen enthalten. Auch Provider-Dokumentation, Freigaben, Kundeninformationen oder interne Richtlinien können davon betroffen sein.

Eine belastbare Model Card sollte deshalb nicht nur den Modellnamen, sondern auch die produktive Version und deren Änderungshistorie dokumentieren. Für Audits, Vorfälle oder spätere Managemententscheidungen muss nachvollziehbar sein, welche Version geprüft und freigegeben wurde, welche Version produktiv war, welche Use Cases davon abhingen und welche Änderung einen neuen Review ausgelöst hat.

Datenquellen ändern das Risiko

Eine Model Card muss neben dem Modell auch die Datenrealität des konkreten Einsatzes erfassen, weil derselbe Modelltyp je nach verarbeiteten Daten völlig unterschiedlich zu bewerten sein kann. Relevant ist daher unter anderem, ob öffentliche Produktinformationen, Kundendaten, Beschäftigtendaten, besondere Kategorien personenbezogener Daten oder vertrauliche Unternehmensinformationen verarbeitet werden, ob Retrieval-Augmented Generation eingesetzt wird, welche internen Systeme angebunden sind und ob Daten für Training oder Fine-Tuning verwendet oder beim Anbieter gespeichert werden.

Ändert sich eine Datenquelle, kann sich damit auch die Risikobewertung verändern. Deshalb muss festgelegt sein, wer die Model Card in diesem Fall aktualisiert und wer prüft, ob aus der Änderung ein neuer Review oder eine erneute Freigabe erforderlich wird.

Provider-Informationen müssen gepflegt werden

Viele KI-Systeme beruhen auf externen Modellen, Plattformen, APIs oder eingebetteten KI-Funktionen, weshalb auch Provider-Informationen Bestandteil der Model Card sein sollten. Dazu gehören insbesondere Anbieter, Vertragsgrundlage, technische Dokumentation, eingesetzte Version, Änderungsinformationen, Datenübertragung, Speicherorte, Sicherheits- und Datenschutzinformationen, relevante Subdienstleister sowie Betriebs- und Verfügbarkeitsinformationen.

Da Anbieter Modelle, Funktionen, Nutzungsbedingungen, Datenverarbeitungsoptionen, Sicherheitsdokumentation oder Schnittstellen verändern können, müssen auch diese Angaben gepflegt werden. Andernfalls verliert die Model Card an Aussagekraft, weil die dokumentierten Rahmenbedingungen nicht mehr mit dem tatsächlich genutzten Dienst übereinstimmen.

Performance ist nur relevant, wenn sie zum Use Case passt

Model Cards enthalten häufig Metriken wie Accuracy, Precision, Recall, F1 Score, Error Rate, Robustness, Hallucination Rate sowie False Positives oder False Negatives. Solche Kennzahlen sind jedoch nur dann aussagekräftig, wenn klar ist, worauf sie sich beziehen, denn eine globale Hersteller-Benchmark ist nicht automatisch ein belastbarer Nachweis für den konkreten Unternehmenseinsatz.

Für die Governance ist daher entscheidend, welche Metrik für den jeweiligen Use Case relevant ist, auf welchem Testdatensatz und in welcher Umgebung gemessen wurde, welche Schwellenwerte gelten, welche Fehler kritisch sind, wer die Ergebnisse bewertet und welche Maßnahmen ausgelöst werden, wenn die Performance unter einen definierten Grenzwert fällt. Ebenso sollte dokumentiert werden, ob und wie die Performance nach dem Go-live weiter überwacht wird.

Bias und Fairness gehören nicht in eine Fußnote

Bei vielen KI-Anwendungen ist Bias kein theoretisches Thema, sondern eine konkrete Governance-Frage, weil bestimmte Gruppen systematisch benachteiligt werden können, Trainings- oder Eingabedaten unausgewogen sein können oder Ergebnisse für einzelne Fallgruppen schlechter ausfallen. Eine Model Card sollte deshalb festhalten, welche Bias-Risiken bekannt sind, welche Gruppen oder Szenarien getestet wurden, welche Grenzen die Tests haben, welche Schutzmaßnahmen vorgesehen sind und in welchen Fällen eine menschliche Prüfung erforderlich bleibt.

Auch diese Bewertung ist nicht dauerhaft gültig. Wenn sich Datenquellen, Modellversionen, Schwellenwerte oder Einsatzkontext ändern, muss geprüft werden, ob die bisherige Bias- und Fairness-Bewertung weiterhin trägt.

Erklärbarkeit ist kontextabhängig

Nicht jeder KI-Use-Case benötigt dieselbe Form von Erklärbarkeit. Bei einem internen Zusammenfassungstool sind die Anforderungen andere als bei einem System, das Risiken priorisiert, Entscheidungen vorbereitet oder Menschen unterschiedlich behandelt. Eine Model Card sollte deshalb nicht lediglich angeben, ob ein Modell „erklärbar“ ist, sondern beschreiben, welche Art von Erklärung verfügbar ist, für wen sie gedacht ist, wie Ergebnisse plausibilisiert werden, welche Grenzen bestehen und welche menschliche Prüfung vorgesehen ist.

Erklärbarkeit ist damit keine isolierte Checkbox, sondern ein Bestandteil des Betriebsmodells, der sich nach dem konkreten Einsatz und dem möglichen Einfluss auf Entscheidungen richten muss.

Freigabe muss versionsbezogen sein

Eine Freigabe ist nur dann belastbar, wenn nachvollziehbar ist, auf welchen Stand sie sich bezieht. Wird ein KI-Use-Case auf Grundlage einer bestimmten Model Card geprüft und freigegeben, müssen Modellversion, Datenquellen, Risikobewertung und Freigabebedingungen eindeutig zugeordnet werden können.

Bei wesentlichen Änderungen, etwa einer neuen Modellversion, einem neuen Provider, einer zusätzlichen Datenquelle, einem geänderten Zweck, einem anderen Nutzerkreis, einem veränderten Output, neuen Bias-Hinweisen oder offenen Sicherheits- und Datenschutzmaßnahmen, muss anschließend geprüft werden, ob die bestehende Freigabe weiter gilt oder ein neuer Review erforderlich ist. Die Model Card sollte deshalb mit dem Freigabeprozess verbunden sein und nicht nur als Anlage dienen.

Reviews und Wiedervorlagen

Eine Model Card bleibt nur dann belastbar, wenn sie regelmäßig überprüft wird, weshalb nachvollziehbar sein muss, wann zuletzt geprüft wurde, wer den Review durchgeführt hat, welche Änderungen festgestellt wurden, welche Maßnahmen daraus entstanden sind und wann der nächste Review fällig ist. Ebenso wichtig ist die Prozesslogik für überfällige Reviews, Erinnerungen und Eskalationen.

Viele AI-Governance-Prozesse scheitern nicht an der ersten Dokumentation, sondern daran, dass nach dem Go-live keine klare Verantwortung für die laufende Pflege besteht. Deshalb braucht eine Model Card einen eindeutigen Owner, ein Reviewdatum und eine definierte Eskalationslogik.

Was Auditoren und RFPs wirklich wissen wollen

In RFPs wird häufig gefragt, ob Model Cards unterstützt werden, obwohl diese Frage allein wenig darüber aussagt, wie belastbar der Governance-Prozess tatsächlich ist. Aussagekräftiger ist, ob Model Cards strukturierte Objekte sind, mit konkreten Use Cases verbunden werden können, Versionierung und Reviews unterstützen, Freigaben versionsbezogen abbilden und Änderungen an Modellversionen oder Datenquellen neue Prüfungen auslösen können.

Ebenso relevant ist, ob Provider-Informationen gepflegt werden, Bias, Performance und Risiken strukturiert dokumentiert werden können, Reviewfristen und Erinnerungen vorhanden sind, historische Stände zu einem Auditzeitpunkt nachvollziehbar bleiben und offene Maßnahmen mit der Model Card verknüpft werden. Solche Fragen trennen eine operative AI Governance von einer reinen Dokumentenablage.

Model Card als Betriebsobjekt in Ailance AI Governance

In einer AI-Governance-Plattform wie Ailance sollte eine Model Card nicht isoliert betrachtet werden, sondern mit den Objekten und Prozessen verbunden sein, die für den tatsächlichen Betrieb relevant sind. Dazu gehören insbesondere AI Use Cases, AI Tools, Provider, Datenquellen, Risiken, Maßnahmen, Freigaben, Reviews, Richtlinien, Rollen und Verantwortlichkeiten, Nachweise, Versionen und Monitoring-Ergebnisse.

Durch diese Verknüpfungen entsteht ein Governance-Kontext, in dem unterschiedliche Rollen jeweils auf die für sie relevanten Informationen zugreifen können: Der Model Owner sieht den aktuellen Modellstand, Legal die Provider- und Vertragsinformationen, Datenschutz die datenschutzbezogenen Aspekte, IT Security die technischen und organisatorischen Anforderungen und der Fachbereich die geltenden Einsatzgrenzen und Freigabebedingungen. Für das Management werden Status, Risiko und offene Maßnahmen nachvollziehbar, ohne dass Informationen aus verschiedenen Dokumenten zusammengesucht werden müssen.

Eine einfache Gegenüberstellung

Die Gegenüberstellung zeigt, dass eine Model Card erst dann governancefähig wird, wenn sie nicht nur dokumentiert, sondern im laufenden Betrieb gepflegt, mit relevanten Prozessen verknüpft und bei Änderungen erneut bewertet werden kann.

Die wichtigste Managementfrage

Die wichtigste Frage zur Model Card lautet nicht, ob eine Organisation eine solche Dokumentation besitzt, sondern wer dafür verantwortlich ist, dass sie aktuell bleibt. Diese Verantwortung umfasst unter anderem die Aktualisierung bei neuen Modellversionen oder Datenquellen, die Neubewertung bei veränderten Performance-Metriken, die Prüfung bestehender Freigaben sowie die Dokumentation und Eskalation offener Risiken.

Wenn dafür keine eindeutigen Rollen und Abläufe definiert sind, bleibt die Model Card ein Dokument, das zwar Informationen enthält, aber nicht zuverlässig in den AI-Governance-Prozess eingebunden ist.

Fazit

Model Cards sollten in AI Governance nicht als statische PDF-Anhänge verstanden werden, sondern als Betriebsdokumentation, die nach dem Go-live weitergeführt wird. Damit sie ihren Nachweiswert behalten, müssen sie strukturiert, gepflegt, versioniert und reviewfähig sein und mit Use Cases, Datenquellen, Providern, Risiken, Freigaben und Monitoring verbunden werden.

Nur auf dieser Grundlage lässt sich später nachvollziehen, welche Modellversion im Einsatz war, welche Datenquellen genutzt wurden, welche Metriken galten, welche Bias- oder Performance-Risiken bekannt waren, welche Freigabe erteilt wurde und welche Änderungen einen neuen Review ausgelöst haben. Genau diese Nachvollziehbarkeit unterscheidet eine belastbare Governance-Dokumentation von einer einmalig abgelegten Modellbeschreibung.

Wer aktualisiert bei Ihnen die Model Card, wenn Datenquelle oder Version wechseln?

Fragen und Antworten

Was gehört in eine Model Card für AI Governance?

Eine Model Card sollte Modellname, Version, Provider, Zweck, Use-Case-Bezug, Datenquellen, Performance-Metriken, Bias- und Erklärbarkeitsinformationen, Risiken, Kontrollen, Freigaben, Owner, Reviewdatum und Änderungshistorie enthalten.

Warum reicht eine Model Card als PDF nicht aus?

Ein PDF kann eine Momentaufnahme sein, steuert aber keinen laufenden Prozess. Es löst keine Reviews aus, zeigt nicht automatisch die produktive Version, verbindet Risiken nicht mit Maßnahmen und macht Änderungen nur schwer nachvollziehbar.

Warum muss eine Model Card nach dem Go-live gepflegt werden?

Weil sich Modellversionen, Datenquellen, Providerinformationen, Performance, Risiken und Einsatzkontext ändern können. Ohne Aktualisierung passt die dokumentierte Modellrealität nicht mehr zur produktiven Modellrealität.

Wer sollte für eine Model Card verantwortlich sein?

In der Regel braucht es einen Model Owner oder eine vergleichbare verantwortliche Rolle. Je nach Organisation können zusätzlich Use Case Owner, Datenschutz, Legal, IT Security, Data Science und Compliance beteiligt sein.

Wie hängt eine Model Card mit einem AI Use Case zusammen?

Das Modellrisiko entsteht im Einsatzkontext. Deshalb sollte die Model Card mit den konkreten Use Cases verbunden sein, in denen das Modell verwendet wird.

Welche Rolle spielt Versionierung bei Model Cards?

Versionierung zeigt, welche Modellversion geprüft, freigegeben und produktiv eingesetzt wurde. Sie ist entscheidend, um Änderungen und Freigaben später nachvollziehen zu können.

Welche Datenquellen sollten dokumentiert werden?

Dokumentiert werden sollten insbesondere Eingabedaten, angebundene interne Systeme, Trainings- oder Fine-Tuning-Daten soweit relevant, personenbezogene Daten, vertrauliche Daten, Datenherkunft und Datenqualität.

Was bedeutet Reviewfähigkeit bei einer Model Card?

Reviewfähigkeit bedeutet, dass eine Model Card regelmäßig geprüft wird, einen Owner hat, ein Reviewdatum besitzt, Änderungen nachvollziehbar sind und offene Maßnahmen verfolgt werden.

Was sollte ein RFP zu Model Cards fragen?

Ein RFP sollte fragen, ob Model Cards strukturierte Objekte sind, ob sie mit Use Cases verbunden werden können, ob Versionierung und Reviews unterstützt werden, ob Freigaben versionsbezogen sind und ob Änderungen an Modellversion oder Datenquelle neue Prüfungen auslösen können.

Wie unterstützt Ailance AI Governance Model Cards?

Ailance AI Governance sollte Model Cards als strukturierte Betriebsobjekte behandeln und sie mit Use Cases, Tools, Providern, Datenquellen, Risiken, Freigaben, Reviews, Maßnahmen und Nachweisen verbinden.