Model Cards erklärt: KI-Modelle für Vertrauen, Transparenz und Compliance dokumentieren

Wenn KI-Systeme von der Entwicklung in die Produktion übergehen, fehlt den für die Bereitstellung verantwortlichen Teams oft der Kontext, um zu beurteilen, ob ein KI-Modell in ihren spezifischen Workflow passt. Die Benchmark-Ergebnisse eines Modells erfassen nicht, wo es evaluiert wurde, an welchen Populationen es getestet wurde oder wo es wahrscheinlich eine schlechtere Leistung erbringen wird. Ohne diese Informationen beruhen Bereitstellungsentscheidungen eher auf Annahmen als auf Fakten – und die Konsequenzen tragen die nachgelagerten Teams, Nutzer:innen und Prozesse.

Model Cards gehen dieses Problem direkt an. Eine Model Card dokumentiert, was ein Modell ist, womit es trainiert und evaluiert wurde, wie es unter relevanten Bedingungen abschneidet, wo es nicht verwendet werden sollte und welche Risiken Prüfer:innen verstehen müssen. Die Dokumentation erfüllt eine Koordinationsfunktion, wenn KI tiefer in die Produktion vordringt. Data Scientists, Risikoprüfer:innen, Compliance-Teams und nachgelagerte Integrator:innen teilen selten denselben Kontext, und eine Model Card bietet ihnen ein gemeinsames Artefakt als Referenz.

Eine Model Card ist ein standardisiertes Dokument, das den Zweck, die Trainingsdaten, die Performance-Eigenschaften, die vorgesehenen Verwendungszwecke, bekannte Einschränkungen, Fairness-Überlegungen und ethische Aspekte eines KI- oder ML-Modells beschreibt. Sie bietet Prüfer:innen eine konsistente Referenz für die Entscheidung, ob ein Modell für einen bestimmten Workflow geeignet ist. Model Cards helfen dabei, die Verpflichtung zu einer verantwortungsvollen KI in die Praxis umzusetzen.

Das Konzept wurde in „Model Cards for Model Reporting“, einem ACM-Paper aus dem Jahr 2019, das von der KI-Forscherin Margaret Mitchell und Kolleg:innen verfasst wurde, vorgestellt. Das Paper definiert Model Cards als kurze Dokumente, die trainierte ML-Modelle begleiten und Benchmark-Evaluierungen unter Bedingungen dokumentieren, die für die geplante Anwendung des Modells relevant sind – gegebenenfalls einschließlich demografischer, kultureller, phänotypischer und intersektionaler Gruppen.

Eine Model Card wird manchmal mit einer Nährwertkennzeichnung verglichen, aber für Enterprise-Teams ist die treffendere Analogie ein Software-Release-Artefakt: ein versionierter Datensatz, der an eine bestimmte Modellversion gebunden ist, sodass Prüfer:innen den vorgesehenen Verwendungszweck, die Evaluierungsdaten, die aufgeschlüsselte Performance, Vorbehalte und empfohlene Bereitstellungspraktiken einsehen können.

Eine Model Card unterscheidet sich von einem Datenblatt für Datasets. Ein Datenblatt dokumentiert die Motivation, die Zusammensetzung, den Erfassungsprozess und die empfohlenen Verwendungszwecke eines Datasets. Eine Model Card dokumentiert das mit diesen Daten trainierte oder evaluierte Modell, einschließlich seiner Performance und der Angabe, wo es verwendet werden sollte und wo nicht.

Mitchell et al. schlugen eine Struktur für Model Cards vor, die Teams eine einheitliche Möglichkeit bietet, Modelldetails, den vorgesehenen Verwendungszweck, die Performance und Einschränkungen zu dokumentieren. Das genaue Format kann je nach Unternehmen, Modelltyp und Risikostufe variieren, aber die kanonischen Abschnitte bleiben eine nützliche Grundlage.

1. Modelldetails

Der Abschnitt zu den Modelldetails identifiziert das Modell und das dafür verantwortliche Team. Er enthält in der Regel den Modellnamen, die Version, das Veröffentlichungsdatum, den Modelltyp, die Lizenz, Zitate oder Paper-Referenzen, den:die Eigentümer:in und Kontaktinformationen.

Ohne Version, Eigentümer:in oder Datum ist eine Model Card weniger nützlich, da Prüfer:innen nicht erkennen können, welches Modell sie beschreibt, ob sie die aktuell bereitgestellte Version widerspiegelt oder an wen sie sich wenden können, wenn sich die Performance ändert.

2. Vorgesehener Verwendungszweck

Der Abschnitt zum vorgesehenen Verwendungszweck beschreibt, wofür das Modell entwickelt wurde, wer es voraussichtlich nutzen wird und welche Anwendungsfälle außerhalb seines vorgesehenen Rahmens liegen. Ein Modell, das zur Klassifizierung von Support-Tickets für das Routing entwickelt wurde, ist nicht zwangsläufig für Entscheidungen über Anspruchsberechtigungen oder rechtsverbindliche Antworten geeignet.

Nicht vorgesehene Verwendungszwecke sollten direkt angegeben werden. Das Risiko eines Modells steigt oft, wenn es in einem Workflow wiederverwendet wird, der seinem ursprünglichen Kontext ähnelt, aber andere Daten, Nutzer:innen, Konsequenzen oder regulatorische Verpflichtungen mit sich bringt.

3. Faktoren

Der Abschnitt zu den Faktoren identifiziert Bedingungen, die die Performance des Modells beeinflussen können: demografische Faktoren, Umweltbedingungen, Datenerfassungsmethoden, instrumentelle Unterschiede, Sprachvariationen, Geografie, Gerätetyp oder andere kontextspezifische Variablen.

Für ein Computer-Vision-Modell könnten relevante Faktoren Beleuchtung, Bildauflösung oder Hautton sein. Für ein Sprachmodell könnten dies Dialekt, Fachvokabular oder Dokumentformat sein. Für ein Enterprise-Prognosemodell könnten diese Faktoren Region, Saisonalität, Produktkategorie oder Kundensegment umfassen.

4. Metriken

Der Abschnitt zu den Metriken erklärt, wie das Modell evaluiert wurde. Er kann Genauigkeit, Präzision, Recall, F1-Score, Falsch-Positiv-Rate, Falsch-Negativ-Rate, Latenz, Kalibrierung, Robustheitsmaße oder aufgabenspezifische Metriken umfassen.

Aggregierte Performance-Zahlen reichen nicht aus. Der Abschnitt zu den Metriken sollte erklären, warum die ausgewählten Metriken für den Anwendungsfall wichtig sind, welche Schwellenwerte angewendet wurden und wie sich diese Schwellenwerte auf nachgelagerte Entscheidungen auswirken.

5. Evaluierungsdaten

Der Abschnitt zu den Evaluierungsdaten beschreibt die Datasets, die zum Testen des Modells verwendet wurden – woher sie stammen, warum sie ausgewählt wurden, wie sie vorverarbeitet wurden und ob sie die vorgesehene Bereitstellungsumgebung des Modells widerspiegeln.

Ein Modell, das mit sauberen, ausgewogenen oder synthetischen Daten evaluiert wurde, kann sich bei Produktionsdaten mit fehlenden Werten, Klassenungleichgewichten, mehrdeutigen Labels oder Distribution Drift anders verhalten.

6. Trainingsdaten

Der Abschnitt zu den Trainingsdaten beschreibt die Datasets, die zum Trainieren des Modells verwendet wurden: Quelle, Motivation, Vorverarbeitungsschritte, Einschluss- und Ausschlusskriterien sowie bekannte Einschränkungen. Wenn ein separates Datenblatt für das Trainings-Dataset existiert, kann die Model Card darauf verweisen, anstatt die Details zu duplizieren.

Bei Foundation-Modellen oder Modellen, die mit großen Datensammlungen trainiert wurden, muss dieser Abschnitt möglicherweise den Trainingsmix, Daten-Cutoffs, Filterpraktiken und Kategorien ausgeschlossener Inhalte abdecken. Für feinangepasste Modelle sollte er das Basismodell von den Daten für die Feinanpassung unterscheiden und beschreiben, wie die Feinanpassung das erwartete Verhalten verändert.

7. Quantitative Analysen

Der Abschnitt zu den quantitativen Analysen schlüsselt die Performance nach relevanten Faktoren auf. Hier berichten Teams über die aufgeschlüsselte Performance, Subgruppenanalysen und intersektionale Analysen.

Die aggregierte Genauigkeit kann akzeptabel erscheinen, während die Performance je nach Sprache, Region, Gerätetyp oder demografischer Gruppe variiert. Die Dokumentation dieser Unterschiede zeigt den Bereitstellenden, wo möglicherweise zusätzliche Tests, Überwachungen oder Abhilfemaßnahmen erforderlich sind.

8. Ethische Erwägungen

Der Abschnitt zu ethischen Überlegungen beschreibt sensible Anwendungsfälle, potenzielle Schäden, Bias-Aspekte, Missbrauchsrisiken und Maßnahmen zur Risikominderung. Er sollte auf dem tatsächlichen Kontext des Modells basieren und nicht als generischer Risikoabsatz verfasst sein.

Bei einem Einstellungsmodell umfassen relevante Überlegungen beispielsweise demografischen Bias, Proxy-Variablen und Anforderungen an die menschliche Überprüfung. Bei einem Modell für das Gesundheitswesen gehören Patientensicherheit, Repräsentativität der Population und Eskalationspfade zu den Überlegungen. Bei einer Anwendung für generative KI umfassen die Überlegungen Halluzinationen, übermäßiges Vertrauen, Datenschutzverletzungen, unsichere Ausgaben und Prompt Injection.

9. Vorbehalte und Empfehlungen

Der Abschnitt zu Vorbehalten und Empfehlungen bietet den Bereitstellern praktische Orientierungshilfen, wie etwa bekannte Einschränkungen, offene Fragen, erforderliches Monitoring, empfohlene menschliche Aufsicht, ungeeignete Kontexte, Auslöser für ein Retraining und zusätzliche Tests, die vor der Bereitstellung durchzuführen sind.

Hier ist die Model Card für Nutzer:innen außerhalb des Entwicklungsteams besonders wertvoll. Ein Vorbehalt wie „nicht für Dokumente mit mehr als 20 Seiten evaluiert“ oder „erfordert menschliche Überprüfung bei Empfehlungen zur Kontoschließung“ gibt nachgelagerten Teams eine konkrete Grenze vor, an der sie sich orientieren können.

Nicht jedes Modell benötigt den gleichen Dokumentationsgrad. Ein risikoarmes internes Analytics-Modell, ein kundenorientiertes Modell und ein Foundation Model bringen unterschiedliche Verpflichtungen, Zielgruppen und Aktualisierungsmuster mit sich. Die Card sollte dem Bereitstellungskontext und den potenziellen Auswirkungen des Modells entsprechen.

Nur intern

Für rein interne Modelle kann eine schlanke Card ausreichend sein. Ein kurzer Datensatz, der den Zweck des Modells, den:die Eigentümer:in, Trainingsdaten, Evaluierungsdaten, den Monitoring-Ansatz und das Überprüfungsdatum abdeckt, verhindert, dass das Modell zu einer undokumentierten Abhängigkeit innerhalb eines Dashboards, einer Pipeline oder eines operativen Prozesses wird.

Kundenorientiert

Kundenorientierte oder in Produkte eingebettete Modelle benötigen eine umfassendere Dokumentation. Wenn sich ein Modell auf die Nutzererfahrung, Kunden-Workflows oder regulierte Geschäftsprozesse auswirkt, benötigen Prüfer:innen folgende Informationen: Verwendungszweck, nicht vorgesehene Anwendungsfälle, Performance nach relevanten Faktoren, Evaluierungsdaten, bekannte Einschränkungen, Erwartungen an die menschliche Aufsicht und ein Änderungsprotokoll.

Foundation Models

Foundation Models und feinangepasste Varianten erfordern in der Regel eine erweiterte Dokumentation. Eine Model Card für ein Foundation Model kann Stichtage für das Training, Sicherheitsevaluierungen, Red-Team-Ergebnisse, Jailbreak-Resistenz, inhaltliche Einschränkungen, das Modellverhalten bei feindlichen Prompts und Leitfäden für nachgelagerte Entwickler:innen enthalten. OpenAI, Google DeepMind und andere Modellanbieter veröffentlichen System Cards oder Model Cards, die diesem breiteren Dokumentationsmuster für wichtige Releases folgen.

Hochrisikosysteme

Hochrisiko-KI-Systeme benötigen möglicherweise auch eine Dokumentation, die regulatorische Verpflichtungen unterstützt. Gemäß dem EU AI Act müssen Anbieter von Hochrisiko-KI-Systemen eine technische Dokumentation erstellen, bevor sie ein System auf den Markt bringen oder in Betrieb nehmen. Anhang IV legt fest, was diese Dokumentation abdecken muss: Verwendungszweck, Anbieter, Version, Entwicklungsprozess, Datenanforderungen, Testverfahren und Maßnahmen zum Risikomanagement.

Versionierung ist unerlässlich. Jedes Retraining, jedes Ereignis zur Feinanpassung, jede wesentliche Änderung der Evaluierung oder jedes Update, das sich auf die Bereitstellung auswirkt, sollte eine neue Card-Version oder ein dokumentiertes Update der bestehenden Version nach sich ziehen. Die Card sollte Datum, Modellversion, Änderungszusammenfassung und den:die überprüfende:n Eigentümer:in enthalten, damit Teams das Modellverhalten mit dem Artefakt verknüpfen können, das es beschreibt.

Die besten Cards werden für die Personen geschrieben, die das Modell bereitstellen. Sie beschreiben, was das Modell leisten kann, wo es getestet wurde, wo es fehlschlagen könnte und was ein Team überprüfen sollte, bevor es sich darauf verlässt.

Überzeugende Model Cards zeichnen sich in der Regel durch Folgendes aus:

• Performance anhand von Metriken quantifizieren, die zum Anwendungsfall passen
• Performance nach relevanten Faktoren aufschlüsseln
• Nicht vorgesehene Anwendungsfälle direkt benennen
• Auf den Eintrag in der Modell-Registry, die Dokumentation der Trainingsdaten und die Evaluierungsdaten verlinken
• Eigentümer:in, Datum, Version und Änderungsprotokoll angeben
• Erwartungen an die Überprüfung nach einem Retraining oder wesentlichen Änderungen dokumentieren

Häufige Fehlerquellen sind ebenso wichtig zu berücksichtigen:

• Marketingtexte, die als Dokumentation dienen, helfen Prüfer:innen nicht dabei, das Bereitstellungsrisiko einzuschätzen.
• Platzhalter, fehlende Untergruppenaufschlüsselung, keine explizite Angabe zu nicht vorgesehenen Anwendungsfällen und keine Kontaktperson für Fragen machen das Dokument unbrauchbar.
• Rein aggregierte Metriken sind besonders riskant, da sie eine ungleichmäßige Performance über Gruppen, Umgebungen oder Datenbedingungen hinweg verbergen können.

Vorlagen und Model-Card-Generatoren helfen Teams dabei, Metadaten zu erfassen, Metriken zu organisieren und das Problem des leeren Blattes bei der Dokumentation zu vermeiden. Der operative Aspekt sollte jedoch nicht übersehen werden: die Zuweisung eines:einer Verantwortlichen, die Verknüpfung der Card mit der richtigen Modellversion, die Aktualisierung nach einem Retraining und die Sicherstellung, dass Prüfer:innen der Card als Teil des Release-Prozesses vertrauen können.

Erfahren Sie, wie Sie ein Modell in einem Notebook erstellen, das Modell in der Snowflake Model Registry speichern und das Modell per SQL bereitstellen:

Model Cards sind einfacher zu pflegen, wenn die dahinterstehenden Informationen nah an den Daten, Modellen und Governance-Kontrollen liegen, die sie beschreiben. Die Snowflake AI Data Cloud wurde entwickelt, um Teams eine Möglichkeit zu bieten, Daten und KI-Governance in einer gemeinsamen Umgebung zu verwalten, sodass die Modelldokumentation auf kontrollierte Metadaten zurückgreifen kann, anstatt auf manuelle Aktualisierungen angewiesen zu sein.

Die Snowflake Model Registry bietet eine Möglichkeit, Modelle und deren Metadaten in Snowflake zu verwalten, unabhängig von Herkunft und Typ. Sie unterstützt Modellversionen, Artefakte, Metadaten und Inferenz-Workflows und bietet Teams einen Ort, um eine Model Card mit der Modellversion zu verknüpfen, die sie dokumentiert.

Dieser versionierte Registry-Kontext ist wertvoll, da eine Model Card eine spezifische Modellversion beschreiben muss: die verwendeten Trainingsdaten, die ausgewählten Evaluierungsdaten, die gemeldeten Metriken, den genehmigten Verwendungszweck, die erfassten Vorbehalte und den:die zugewiesene:n Monitoring-Verantwortliche:n zu einem bestimmten Zeitpunkt.

Snowflake Horizon Catalog kann die Pflege von Model Cards ebenfalls unterstützen, indem Governance-Kontext rund um Daten-Assets offengelegt wird, einschließlich Definitionen, Lineage und Richtlinienverhalten. Lineage-Funktionen ermöglichen es Nutzer:innen, unterstützte Objekte zu überprüfen und Upstream- oder Downstream-Abhängigkeiten zu verfolgen. Bei Model Cards helfen Lineage und Metadaten-Kontext den Teams dabei, zu dokumentieren, welche kontrollierten Daten-Assets für das Training oder die Evaluierung verwendet wurden und wie diese Assets mit Downstream-Anwendungen zusammenhängen.

Snowflake Cortex AI umfasst KI-Observability-Funktionen zur Evaluierung generativer KI-Anwendungen und -Agenten mit Metriken wie Genauigkeit, Latenz, Nutzung und Kosten. Snowflake unterstützt auch semantische Ansichten, die es Teams ermöglichen, verifizierte Abfragen auszuführen, Evaluierungsläufe zu überprüfen und Regressionen im Laufe der Zeit zu verfolgen. Diese Ergebnisse können als Belege für die Abschnitte zu Metriken, Vorbehalten und Empfehlungen in der Model Card dienen.

Darüber hinaus spiegelt die ISO/IEC 42001-Zertifizierung von Snowflake ein unabhängig bewertetes KI-Managementsystem und Governance-Framework wider.

Eine Model Card ist nicht nur eine Compliance-Checkbox. Sie bietet die Dokumentation, die ein Modell für Prüfer:innen, Bereitsteller:innen und Risikoverantwortliche nutzbar macht, die verstehen müssen, was es tut, wo es getestet wurde und wo es nicht eingesetzt werden sollte.

Die Investition in die Implementierung von Model Cards macht sich bei zunehmender Skalierung bezahlt. Da Unternehmen immer mehr Modelle in immer mehr Workflows bereitstellen, wird die Fähigkeit, jedes einzelne Modell schnell zu bewerten – seine Herkunft, seine Performance unter verschiedenen Bedingungen, seine bekannten Grenzen – zu einer operativen Anforderung. Model Cards sorgen dafür, dass diese Bewertung evidenzbasiert bleibt.