Onchain Model Cards: Warum Blockchain die Vertrauenslücke bei KI-Modellen schließen kann

KI-Modelle werden immer komplexer, doch die Dokumentation bleibt oft unvollständig. Ein neues Konzept namens Onchain Model Cards soll hier Abhilfe schaffen – indem es kritische Modellinformationen unveränderlich in der Blockchain verankert. Doch wie funktioniert das genau und wo stoßen die Techniken an ihre Grenzen?

Das Kernproblem: Dokumentation vs. Realität

Ein klassisches Beispiel zeigt, warum herkömmliche Modellkarten in die Irre führen können: Ein Entwicklungsteam veröffentlicht eine Karte mit dem Hinweis „Dieses Modell ist für den Support-Einsatz freigegeben“. Später wird die Karte auf „experimentell“ geändert – doch die alte Blockchain-Eintrag verweist weiterhin auf dieselbe Modellbezeichnung. Die Nutzer sehen eine stabile Referenz, während sich die zugrunde liegenden Informationen bereits geändert haben.

Onchain Model Cards zielen darauf ab, solche stillen Änderungen zu verhindern. Sie sollen nicht vortäuschen, dass ein Hash in der Blockchain automatisch Sicherheit, Lizenzrechte oder Datenherkunft beweist. Stattdessen geht es darum, konkrete Aussagen zu verankern, die sich nicht nachträglich manipulieren lassen.

Was eine Onchain Model Card wirklich leisten kann

Eine Onchain Model Card ist kein Allheilmittel, sondern ein präzises Werkzeug mit klar definierten Grenzen. Sie dokumentiert:

• Welche Bytes der Modellkarte tatsächlich überprüft wurden
• Welche konkreten Aussagen („Claims“) in der Blockchain verankert sind
• Wer die Aussagen ausgestellt hat
• Welche vorherigen Versionen ersetzt wurden
• Was die Karte ausdrücklich nicht behauptet

Ein zentraler Unterschied zu herkömmlichen Modellkarten liegt in der Struktur der Informationen. Während klassische Karten oft frei formulierte Texte sind, extrahiert die Onchain-Version gezielt definierte Felder wie:

• Geplante Nutzung des Modells
• Bekannte Einschränkungen
• Verwendete Datensätze
• Lizenzinformationen
• Bewertungsergebnisse
• Versionshinweise

Der Unterschied zwischen Repository und Claim

In der Praxis werden Modellkarten häufig als Teil eines Versionsverwaltungssystems wie dem Hugging Face Hub gepflegt. Dort sind sie oft als Markdown-Dateien in einem Repository abgelegt – und damit potenziell änderbar. Eine Onchain Model Card löst dieses Problem nicht, indem sie einfach auf das Repository verweist. Stattdessen wird ein spezifischer Ausschnitt der Karte extrahiert, kanonisiert und in der Blockchain gespeichert.

Ein Beispiel für die Struktur einer solchen „Claim-Receipt“ könnte so aussehen:

{
  "receipt_type": "ai.model_card_claim_receipt.v1",
  "card_subject": "org/model-name",
  "model_repository": "
  "source_revision": "commit:abc123...",
  "card_path": "README.md",
  "claim_extraction": [
    "intended_use",
    "limitations",
    "datasets",
    "license_field",
    "evaluation_summary",
    "version_note"
  ],
  "canonicalization": "RFC8785-JCS-for-extracted-json-claims",
  "source_card_digest": "sha256:...",
  "claim_set_digest": "sha256:...",
  "digest_uri": "ni:///sha-256;<claim_set_digest>",
  "issuer": "did:example:issuer-key-context",
  "signature_profile": {
    "path": "vc_data_integrity",
    "vc_data_integrity": "proof + verificationMethod profile"
  },
  "supersedes": "previous_receipt_hash",
  "effective_from": "2026-06-02T00:00:00Z",
  "limits": [
    "nur Modellkarten-Aussagen",
    "keine Gewichtsidentität des Modells",
    "keine Benchmark-Wahrheit",
    "keine Laufzeit-Attestierung"
  ]
}

Diese Receipt bleibt absichtlich schlanker als die vollständige Modellkarte. Ihr Zweck ist es, die überprüften Aussagen und ihre Grenzen zu verankern – nicht, jede mögliche Modellinformation in die Blockchain zu zwängen.

Warum Hashing nicht alles erklärt

Ein häufiges Missverständnis ist die Annahme, ein Hash in der Blockchain beweise automatisch die Richtigkeit oder Vollständigkeit eines Modells. Doch ein Hash kann nur die Integrität der extrahierten Daten sicherstellen – nicht ihre Bedeutung oder Gültigkeit.

Die Extraktion der Claims muss daher vor dem Hashing erfolgen. Die Onchain Model Card sollte nicht versuchen, den gesamten frei formulierten Markdown-Text zu hashen. Stattdessen werden die relevanten Felder als strukturierte JSON-Daten serialisiert und dann kanonisiert (z. B. nach RFC 8785). Erst dieser kanonisierte JSON-String wird dann gehasht.

Wichtig: Ein solcher Hash sagt nichts darüber aus, ob die Benchmarks fair durchgeführt wurden, ob die Datensätze rechtlich einwandfrei sind oder ob das Modell im Einsatz tatsächlich wie beschrieben funktioniert.

Wer darf was behaupten? Die Rolle des Ausstellers

Eine signierte Claim-Receipt beweist zunächst nur, dass eine bestimmte Entität zu einem bestimmten Zeitpunkt eine bestimmte Aussage über bestimmte Daten getroffen hat. Sie macht die Aussage nicht automatisch wahr oder vertrauenswürdig.

Daher ist der Kontext des Ausstellers entscheidend. Standards wie das Verifiable Credentials Data Model 2.0 oder Verifiable Credential Data Integrity 1.0 bieten Rahmenwerke für vertrauenswürdige Aussagen. Doch auch hier gilt: Die Glaubwürdigkeit hängt davon ab, ob der Aussteller überhaupt berechtigt ist, solche Aussagen zu treffen.

Ein Beispiel: Ein Entwicklerteam stellt eine Claim-Receipt für sein eigenes Modell aus. Ein Nutzer muss dann selbst bewerten, ob das Team tatsächlich die nötige Expertise oder Neutralität besitzt, um solche Aussagen zu treffen. Eine dezentrale Identität (DID) nach dem DID Core Standard kann helfen, die Identität des Ausstellers zu verifizieren – aber sie ersetzt keine inhaltliche Prüfung.

Ethereum und strukturierte Signaturen

Für Implementierungen auf Ethereum oder kompatiblen Blockchains bietet sich EIP-712 an. Dieser Standard ermöglicht typisierte strukturierte Signaturen, die besser lesbar und verifizierbar sind als reine Hash-Werte. Allerdings sollte man die verschiedenen Signaturprofile nicht vermischen:

• VC Data Integrity (für verifizierbare Credentials)
• RFC 8785 (für kanonisierte JSON-Daten)
• EIP-712 (für typisierte Ethereum-Signaturen)

Jedes dieser Profile hat eigene Regeln für Darstellung und Verifizierung. Eine Onchain Model Card sollte daher klar kennzeichnen, welches Profil verwendet wird – und welche Aussagen damit tatsächlich abgesichert sind.

Fazit: Transparenz ja, Allheilmittel nein

Onchain Model Cards bieten einen vielversprechenden Ansatz, um die Nachvollziehbarkeit von KI-Modellen zu verbessern. Sie können helfen, die Vertrauenswürdigkeit von Modelldokumentationen zu erhöhen – aber nur, wenn ihre Grenzen klar kommuniziert werden.

Wichtig ist zu verstehen, dass sie keine Sicherheitsgarantien bieten und keine rechtlichen oder ethischen Bewertungen ersetzen. Stattdessen schaffen sie eine Grundlage für transparente, nachprüfbare Aussagen – und das ist ein entscheidender Schritt in Richtung vertrauenswürdiger KI-Systeme. Die nächsten Jahre werden zeigen, ob sich das Konzept in der Praxis durchsetzt und wie es mit bestehenden Standards wie Verifiable Credentials oder dezentralen Identitäten harmoniert.