{"id":44482,"date":"2026-06-26T09:00:40","date_gmt":"2026-06-26T07:00:40","guid":{"rendered":"https:\/\/2b-advice.com\/?p=44482"},"modified":"2026-06-28T13:44:50","modified_gmt":"2026-06-28T11:44:50","slug":"modele-de-fiche-de-gouvernance-ia","status":"publish","type":"post","link":"https:\/\/2b-advice.com\/fr\/2026\/06\/26\/model-card-ai-governance-vorlage\/","title":{"rendered":"Fiche de r\u00e9f\u00e9rence pour la gouvernance de l'IA : contenu, mod\u00e8le et mise en \u0153uvre"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Ein Medikament ohne Beipackzettel w\u00fcrden die meisten Menschen nicht einnehmen. Jedenfalls nicht freiwillig. Man will wissen, wof\u00fcr es gedacht ist, wann man es besser nicht nimmt, welche Nebenwirkungen bekannt sind, welche Dosierung gilt und wann man \u00e4rztlichen Rat braucht.<\/p>

Bei KI-Modellen sind Unternehmen erstaunlich gro\u00dfz\u00fcgiger.<\/p>

Da wird ein Modell eingebunden, ein Anbieter pr\u00e4sentiert gute Benchmarks, ein Fachbereich sieht Produktivit\u00e4t, die IT pr\u00fcft die Integration, und irgendwo im Projekt steht dann ein Satz wie: \u201eDas Modell ist bereits validiert.\u201c<\/p>

Sch\u00f6n. Von wem? F\u00fcr welchen Zweck? Mit welchen Daten? Unter welchen Bedingungen? Mit welchen Grenzen? F\u00fcr welche Nutzer? Mit welchem Risiko? Und wer merkt eigentlich, wenn sich das Modell im Betrieb anders verh\u00e4lt als erwartet?<\/p>

Genau hier kommt die Model Card ins Spiel.<\/p>

Kurz gesagt:<\/b> Eine Model Card ist eine strukturierte Beschreibung eines KI-Modells. Sie dokumentiert Zweck, Modellversion, Anbieter, intended use, Datenbezug, Leistungsgrenzen, Risiken, Evaluation, Owner, Freigaben und Review-Bedingungen. F\u00fcr AI Governance wird sie erst dann wertvoll, wenn sie mit AI Inventory, Use Case, Risikoklassifikation, Datenschutzpr\u00fcfung, Freigabe, Monitoring und Review verbunden ist. Ailance AI Governance bildet genau diese Verbindung als Workflow ab.<\/span><\/p>

Eine Model Card ist im Kern der Beipackzettel eines KI-Modells. Nicht im Sinne eines Marketingdokuments. Nicht als h\u00fcbsche PDF-Anlage f\u00fcr den Auditordner. Sondern als strukturierte Beschreibung, die erkl\u00e4rt, wof\u00fcr ein Modell gedacht ist, wof\u00fcr es gerade nicht geeignet ist, welche Daten und Bewertungen zugrunde liegen, welche Leistungsgrenzen bekannt sind, welche Risiken bestehen und unter welchen Bedingungen es eingesetzt werden darf.<\/p>

Das urspr\u00fcngliche Konzept der Model Cards wurde in der Forschung als Format f\u00fcr transparentes Model Reporting vorgeschlagen. Model Cards sollen Modelle begleiten und unter anderem Intended Use, Performance-Eigenschaften, Evaluation, relevante Einsatzkontexte und Grenzen offenlegen. Gerade bei Anwendungen mit m\u00f6glicher Wirkung auf Menschen wird diese Transparenz entscheidend, weil ein Modell in einem Kontext gut funktionieren und in einem anderen Kontext erheblich problematisch werden kann. (arXiv)<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Warum Model Cards in Unternehmen oft falsch verstanden werden<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In vielen Unternehmen werden Model Cards als Dokumentation behandelt. Das ist nicht v\u00f6llig falsch. Nat\u00fcrlich dokumentiert eine Model Card. Aber wenn sie nur als Dokumentation verstanden wird, wird ihr wichtigster Nutzen verschenkt.<\/p>

Ich sehe in Projekten h\u00e4ufig genau dieses Muster: Es gibt ein Dokument, alle sind erleichtert, und trotzdem kann sp\u00e4ter niemand erkl\u00e4ren, warum das Modell genau so freigegeben wurde. Das Problem ist dann nicht, dass nichts dokumentiert wurde. Das Problem ist, dass die Dokumentation keine Entscheidung tr\u00e4gt.<\/p>

Dann entsteht ein statisches Dokument, das einmal erstellt, in einem Projektordner abgelegt und sp\u00e4ter im Audit hervorgeholt wird. Es steht dort, welches Modell genutzt wurde, vielleicht noch wer der Anbieter ist, vielleicht ein paar technische Angaben, vielleicht ein Benchmark. Das sieht ordentlich aus. Es hilft nur begrenzt, wenn die entscheidenden Fragen im Betrieb auftauchen.<\/p>

Denn AI Governance braucht keine Dokumentation um der Dokumentation willen. Sie braucht verwertbaren Kontext.<\/p>

Legal muss verstehen, ob Vertragszusagen, Haftung, Nutzungsbedingungen und regulatorische Rollen zum Einsatz passen. Datenschutz<\/a> muss erkennen, ob personenbezogene Daten betroffen sind, ob Zweckbindung, Transparenz und Betroffenenrisiken sauber bewertet wurden. IT und Security m\u00fcssen wissen, welche technischen Abh\u00e4ngigkeiten, Schnittstellen, Datenfl\u00fcsse und Schutzma\u00dfnahmen relevant sind. Der Fachbereich muss verstehen, was das Modell leisten kann und wo es nicht blind verwendet werden darf. Das Management braucht am Ende eine Entscheidungsgrundlage, keine technische Bedienungsanleitung.<\/p>

Eine gute Model Card verbindet diese Perspektiven.<\/p>

Sie ist also nicht einfach ein technisches Datenblatt. Sie ist eine \u00dcbersetzungsleistung zwischen Modell, Use Case, Risiko und Betrieb.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Der Toolname sagt wenig. Der Use Case entscheidet.<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Ein h\u00e4ufiger Fehler in AI Governance ist, dass \u00fcber Tools gesprochen wird, als w\u00e4ren sie schon der eigentliche Anwendungsfall.<\/p>

\u201eWir nutzen ChatGPT.\u201c<\/p>

\u201eWir nutzen ein \u00dcbersetzungsmodell.\u201c<\/p>

\u201eWir nutzen eine KI-Funktion in unserem CRM.\u201c<\/p>

\u201eWir nutzen ein Modell zur Klassifikation.\u201c<\/p>

Das ist ein Anfang. Aber es reicht nicht.<\/p>

Dasselbe Modell kann in einem Kontext v\u00f6llig unkritisch sein und in einem anderen ein erhebliches Risiko erzeugen. Ein Modell, das interne Texte zusammenfasst, ist anders zu bewerten als ein Modell, das Bewerbungen vorsortiert, Kundeninteraktionen bewertet, medizinische Hinweise strukturiert, Betrugswahrscheinlichkeiten berechnet oder juristische Einsch\u00e4tzungen vorbereitet.<\/p>

Der Unterschied liegt nicht nur im Modell, sondern auch im Einsatz, in den Daten und in der Wirkung. Aber auch in der Frage, ob ein Mensch wirklich entscheidet oder nur noch abnickt.<\/p>

Deshalb muss eine Model Card immer mit dem Use Case verbunden werden. Sie beschreibt nicht nur, was das Modell technisch ist. Sie muss erkl\u00e4ren, wie es im Unternehmen verwendet wird.<\/p>

Erst aus dieser Verbindung wird Governance.<\/p>

Ein isoliertes Modellprofil sagt: \u201eDas Modell kann etwas.\u201c<\/p>

Eine gute Model Card im Governance-Prozess sagt: \u201eDieses Modell darf in diesem konkreten Kontext unter diesen Bedingungen eingesetzt werden.\u201c<\/p>

Das ist der Unterschied zwischen Hoffnung und Steuerbarkeit.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Was eine Model Card leisten muss<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Model Card Vorlage: Welche Inhalte mindestens enthalten sein sollten<\/b><\/b><\/span><\/p>

Eine Model Card sollte nicht bei Modellname und Anbieter enden. Damit sie f\u00fcr AI Governance, Datenschutz, Legal, IT, Security und Management nutzbar wird, braucht sie eine klare Mindeststruktur.<\/span><\/p>

  • Modellname, Version, Anbieter und Modelltyp<\/span><\/li>
  • konkreter Use Case im Unternehmen<\/span><\/li>
  • intended use und ausgeschlossene Nutzungen<\/span><\/li>
  • fachlicher Owner und verantwortliche Stellen<\/span><\/li>
  • Datenquellen, Eingabedaten und Ausgabedaten<\/span><\/li>
  • Angaben zu Training, Test, Evaluation oder bekannten Leistungswerten<\/span><\/li>
  • bekannte Grenzen, Fehlertypen und Unsicherheiten<\/span><\/li>
  • Datenschutz- und Security-Relevanz<\/span><\/li>
  • Risikoklassifikation und m\u00f6gliche EU-AI-Act-Relevanz<\/span><\/li>
  • Anforderungen an menschliche Aufsicht<\/span><\/li>
  • Freigabestatus und Freigabebedingungen<\/span><\/li>
  • Review-Zyklen und Ausl\u00f6ser f\u00fcr erneute Pr\u00fcfung<\/span><\/li>
  • Monitoring, Vorf\u00e4lle und \u00c4nderungsmanagement<\/span><\/span><\/li><\/ul>

    Diese Struktur macht aus einer Model Card mehr als eine technische Beschreibung. Sie macht sichtbar, unter welchen Bedingungen ein KI-Modell im Unternehmen verantwortbar eingesetzt werden kann.<\/span><\/p>

    Eine Model Card muss zuerst den Zweck kl\u00e4ren. Warum wird das Modell eingesetzt? Welche Aufgabe \u00fcbernimmt es? Unterst\u00fctzt es einen Menschen, oder beeinflusst es faktisch eine Entscheidung? Wird ein Ergebnis nur als Vorschlag genutzt, oder entsteht daraus ein operativer Prozessschritt? Diese Unterscheidung ist entscheidend, weil ein Modell nicht abstrakt riskant oder harmlos ist. Der konkrete Einsatz macht den Unterschied.<\/p>

    Danach braucht es eine verst\u00e4ndliche Beschreibung des Modells und seiner Grenzen. Welche Modellart wird genutzt? Handelt es sich um ein generatives Sprachmodell, ein Klassifikationsmodell, ein Scoring-Modell, ein Bilderkennungsmodell oder eine eingebettete Anbieterfunktion? Welche Version ist betroffen? Welche bekannten Einschr\u00e4nkungen gibt es? Welche Fehlertypen sind realistisch? Wo produziert das Modell \u00fcberzeugend klingende, aber falsche Ergebnisse? Wo ist menschliche Pr\u00fcfung zwingend?<\/p>

    Dann wird es praktisch: Welche Daten gehen hinein, welche Daten wurden f\u00fcr Training, Anpassung, Test oder Evaluation verwendet, und welche Daten entstehen im Betrieb? Gerade hier treffen Technik, Datenschutz und Security aufeinander. Eine Model Card, die \u00fcber Daten schweigt, ist wie ein Beipackzettel ohne Wirkstoffangabe.<\/p>

    Der EU AI Act zeigt sehr deutlich, warum solche Informationen nicht akademisch sind. F\u00fcr Hochrisiko-KI-Systeme verlangt er unter anderem Risikomanagement, Daten- und Daten-Governance, technische Dokumentation, Aufzeichnungspflichten, Transparenz, Informationen f\u00fcr Betreiber, menschliche Aufsicht sowie Robustheit, Genauigkeit und Cybersicherheit. Diese Anforderungen zeigen, dass AI Governance nicht bei einer Modellbezeichnung stehen bleiben kann. Sie muss Informationen \u00fcber Zweck, Betrieb, Risiken und Kontrolle verf\u00fcgbar machen. (EUR-Lex)<\/p>

    Eine Model Card muss au\u00dferdem die Leistungsf\u00e4higkeit des Modells so beschreiben, dass sie f\u00fcr den konkreten Einsatz brauchbar ist. Durchschnittswerte helfen nur begrenzt. Ein hoher Benchmark kann beeindruckend aussehen und trotzdem f\u00fcr den eigenen Use Case wenig aussagen. Entscheidend ist, ob das Modell unter den Bedingungen zuverl\u00e4ssig genug arbeitet, unter denen es im Unternehmen eingesetzt werden soll.<\/p>

    Genau hier wird die Model Card unbequem. Sie zwingt dazu, nicht nur die St\u00e4rken des Modells zu beschreiben, sondern auch seine Grenzen und das ist gut.<\/p>

    Denn Governance beginnt dort, wo die Grenzen sichtbar werden.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    Warum Model Cards Recht, Technik und Betrieb verbinden<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Ich glaube, viele Diskussionen \u00fcber KI bleiben deshalb unbefriedigend, weil die beteiligten Rollen unterschiedliche Sprachen sprechen.<\/p>

    Technik fragt: Wie funktioniert das Modell?<\/p>

    Legal fragt: Wer haftet und welche Verpflichtungen gelten?<\/p>

    Datenschutz fragt: Welche Daten, welcher Zweck, welche Betroffenenrisiken?<\/p>

    Security fragt: Welche Angriffsfl\u00e4chen, welche Datenfl\u00fcsse, welche Schutzma\u00dfnahmen?<\/p>

    Der Fachbereich fragt: Hilft es im Alltag?<\/p>

    Management fragt: K\u00f6nnen wir das verantworten?<\/p>

    Alle Fragen sind berechtigt. Alle sind unvollst\u00e4ndig, wenn sie isoliert bleiben.<\/p>

    Die Model Card ist eine M\u00f6glichkeit, diese Perspektiven in eine gemeinsame Sprache zu bringen. Sie zwingt nicht alle Beteiligten dazu, Entwickler zu werden. Sie zwingt auch nicht den Fachbereich, Rechtsgutachten zu schreiben. Sie schafft einen Ort, an dem die relevanten Informationen zusammengef\u00fchrt werden.<\/p>

    Das ist ihr eigentlicher Wert.<\/p>

    Eine Model Card sollte deshalb so geschrieben sein, dass sie ein technischer Ansprechpartner ernst nimmt, Legal damit arbeiten kann, Datenschutz die relevanten Punkte findet und der Fachbereich versteht, was im Alltag erlaubt, riskant oder ausgeschlossen ist.<\/p>

    Wenn nur Data Scientists sie verstehen, ist sie zu technisch.<\/p>

    Wenn nur Juristen sie verstehen, ist sie zu abstrakt.<\/p>

    Wenn niemand sie im Betrieb nutzt, ist sie Dekoration.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    Der Beipackzettel muss lesbar sein<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Die Beipackzettel-Metapher ist nicht zuf\u00e4llig gew\u00e4hlt.<\/p>

    Ein Beipackzettel ist nicht die Arzneimittelforschung. Er ersetzt nicht die Zulassung. Er ist auch keine Bedienungsanleitung f\u00fcr den Chemiker. Er \u00fcbersetzt relevante Informationen f\u00fcr die sichere Anwendung.<\/p>

    Genau das sollte eine Model Card leisten.<\/p>

    Sie muss nicht jeden technischen Detailwert enthalten. Sie muss die Informationen enthalten, die f\u00fcr verantwortliche Nutzung erforderlich sind. Was ist der bestimmungsgem\u00e4\u00dfe Einsatz? Welche Nutzung ist ausgeschlossen oder riskant? Welche Daten sind betroffen? Welche Grenzen sind bekannt? Welche menschliche Kontrolle ist erforderlich? Welche Bedingungen gelten f\u00fcr Freigabe, Monitoring und Review?<\/p>

    Der EU AI Act spricht bei Hochrisiko-Systemen ausdr\u00fccklich von Informationen, die Betreiber in die Lage versetzen sollen, ein System korrekt und angemessen zu nutzen. Dazu geh\u00f6ren auch Informationen \u00fcber intended purpose, Einschr\u00e4nkungen, vorhersehbaren Fehlgebrauch und menschliche Aufsicht. Die Verordnung betont, dass Informationen verst\u00e4ndlich, umfassend, zug\u00e4nglich und f\u00fcr die Zielnutzer geeignet sein sollen. (EUR-Lex)<\/p>

    Das ist exakt der Punkt.<\/p>

    Eine Model Card darf nicht nur formal vollst\u00e4ndig sein. Sie muss im Unternehmen verstanden werden. Sonst ist sie nicht Governance, sondern Ablage.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    Model Cards sind kein Ersatz f\u00fcr AI Governance<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Eine Model Card allein macht noch keine Governance. Genauso wenig wie ein Beipackzettel allein gute Medizin macht.<\/p>

    Sie ist ein Baustein.<\/p>

    Der Wert entsteht erst, wenn die Model Card in einen AI-Governance-Workflow eingebettet wird. Ein Use Case wird beschrieben. Das betroffene Modell wird identifiziert. Die Model Card liefert technischen, fachlichen und regulatorischen Kontext. Datenschutz, Legal, Security und Fachbereich pr\u00fcfen auf derselben Grundlage. Die Freigabe wird dokumentiert. Monitoring und Review werden geplant. Wenn sich Modell, Anbieter, Datenquellen, Zweck oder Einsatzbedingungen \u00e4ndern, wird die Bewertung aktualisiert.<\/p>

    Dann wird aus Dokumentation ein Steuerungsinstrument.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    Model Card, AI Inventory und DSFA: Warum diese Elemente zusammengeh\u00f6ren<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Eine Model Card beschreibt das Modell. Das AI Inventory zeigt, welche KI-Systeme, KI-Funktionen und Use Cases im Unternehmen existieren. Eine DSFA oder Datenschutzpr\u00fcfung bewertet, ob und wie personenbezogene Daten betroffen sind. F\u00fcr sich allein betrachtet bleibt jedes dieser Elemente unvollst\u00e4ndig.<\/span><\/p>

    Erst die Verbindung macht AI Governance belastbar.<\/span><\/p>

    Das AI Inventory beantwortet die Frage: Welche KI-Anwendungen gibt es im Unternehmen? Die Model Card beantwortet die Frage: Was wissen wir \u00fcber das Modell, seine Grenzen, Daten, Risiken und Einsatzbedingungen? Die Datenschutzpr\u00fcfung beantwortet die Frage: Welche Auswirkungen hat der konkrete Einsatz auf personenbezogene Daten und Betroffene? Der Governance-Workflow beantwortet die Frage: Wer pr\u00fcft, wer entscheidet, wer dokumentiert und wann wird erneut bewertet?<\/span><\/p>

    Ailance AI Governance verbindet diese Elemente in einer gemeinsamen Struktur. Model Cards stehen dort nicht isoliert neben Use Cases, Risiken und Freigaben, sondern werden Teil eines nachvollziehbaren Entscheidungswegs.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t