ŠUBERT META KODEX v3.0

Warum er entstanden ist

AI-Modelle können Unsicherheit ausdrücken und erkennen bis zu einem gewissen Grad, wann sie richtig liegen. Doch die Sicherheit, mit der sie antworten, entspricht oft nicht der tatsächlichen Trefferquote — und Menschen überschätzen sie zusätzlich. In der Studie Steyvers u. a. (Nature Machine Intelligence, 2025) überschätzten Nutzer die Genauigkeit der Modellantworten, und längere Erklärungen steigerten ihr Vertrauen, ohne dass die Antwort richtiger wurde. Ohne Kontrollschicht gelangen so überzeugende, aber unbelegte Behauptungen in Angebote, Verträge und Entscheidungen. Der META KODEX ist eine systematische Methode, um einen Output zu zerlegen, zu prüfen, zu kennzeichnen und zu bewerten, bevor das Unternehmen ihn verwendet.

Die vier Ebenen des Frameworks

Certainty Tagging (MTH-086)

Jede wichtige Behauptung erhält eine Kennzeichnung danach, wie sie entstanden ist, wie stark die Quelle sie stützt und ob sie geprüft wurde. Die Kennzeichnung ist das Ergebnis der Prüfung, kein Ersatz dafür — sie wird erst nach der Prüfung der Grundlage nach den Regeln unten vergeben, nicht danach, wie selbstsicher eine Behauptung klingt.

Proof Engine (PFE-001)

Extraktion der Behauptungen → Suche nach Belegen → Verifikation → Rekonstruktion der Timeline → Trust Scoring. Der Beweiskern des Audits.

Hallucination Detection (MOD-AI-085)

Überwacht das Fabrikationsrisiko, unbelegte Spezifität, innere Inkonsistenz und Muster übertriebener Sicherheit.

Governance & Anti-Autonomy (SYS-GOV-060)

Menschliche Souveränität über AI. Gesteuerte, keine unbegrenzte Autonomie — die Entscheidung bleibt beim Menschen, unter Aufsicht und Verantwortung.

Wie das Scoring 0–10 entsteht

Jeder Output wird nach fünf Kriterien mit je 0–2 Punkten bewertet:

• Struktur — ist der Output logisch gegliedert?
• Faktentrennung — sind Fakten von Interpretation getrennt?
• Varianten — bietet er mehrere Perspektiven, nicht nur eine absolute?
• Risiken — sind Risiken und Auswirkungen benannt?
• Unsicherheiten — werden Grenzen und Unverifiziertes offengelegt?

Ergebnis: PASS (10), ACCEPT WITH NOTE (8–9) oder REJECT (unter 8) — mit der Empfehlung, ob der Output verwendet werden kann oder überarbeitet werden muss.

Was der Score nicht misst: faktische Richtigkeit. Er bewertet, wie der Output mit Fakten und Unsicherheit umgeht. Die Richtigkeit einzelner Behauptungen prüft separat die Proof Engine; im Audit ist das eine eigene Liste — was gehalten hat, was nicht und was sich nicht prüfen ließ. Ein Output mit 10/10 kann eine falsche Angabe enthalten.

Die Audit-Kette

Der Output entsteht zuerst (PRODUCER), dann prüft ihn unabhängig der AUDITOR nach den obigen Kriterien, und schließlich versucht der ADVERSARIAL REVIEWER, ihn zu widerlegen. Erst was alle drei Stufen besteht, gilt als „belastbar".

Regeln der Kennzeichnung

Die acht Kennzeichnungen sind keine einzelne Skala von sicher bis unsicher. Es sind drei Gruppen, die drei verschiedene Fragen beantworten:

• Wie die Behauptung entstanden ist — [I] Inferenz (aus belegten Angaben abgeleitet), [D] Annahme (ungeprüft übernommen, etwa aus der Aufgabe), [S] Spekulation (Möglichkeit ohne Grundlage). Direkt aus der Quelle übernommene Behauptungen haben keine Entstehungs-Kennzeichnung.
• Wie stark die Quelle sie stützt — [F] Fakt, [SD] stark belegt, [P] wahrscheinlich.
• Prüfstatus — [N] unverifiziert (keine Prüfung erfolgt oder Quelle fehlt), [X] strittig (Quellen widersprechen sich oder die Prüfung hat die Behauptung widerlegt).

Vergabe und Kombination

• [F] hat strenge Kriterien: Es gibt eine konkrete, nachvollziehbare Grundlage (Dokument, Datensatz, Berechnung), die Prüfung hat bestätigt, dass sie die ganze Behauptung stützt und nicht nur einen Teil, und geprüft hat jemand anderes als der Autor des Outputs. Fehlt etwas davon, höchstens [SD].
• [SD] — die Quelle stützt den Kern der Behauptung, nicht jedes Detail. [P] — die Stützung ist indirekt oder unvollständig.
• Jede wichtige Behauptung hat genau eine Kennzeichnung für Stützung oder Status; die Entstehungs-Kennzeichnung kommt hinzu, z. B. [I][SD].
• Vorrang: [X] geht allem vor. [N] schließt [F], [SD] und [P] aus — was nicht geprüft wurde, kann nicht belegt sein. Eine Inferenz erhält nie [F], eine Spekulation höchstens [P]. Eine Behauptung mit [D] gilt nur mit ausdrücklich genannter Annahme.
• Quellenqualität (A–D) ist eine andere Achse als die Stärke der Stützung. Quellen bewerte ich separat, von A (primär, amtlich) bis D (nicht nachvollziehbar). Auch eine A-Quelle kann eine konkrete Behauptung nur teilweise stützen — dann erhält die Behauptung [P], nicht [F].

Was die Kennzeichnung erlaubt

• [F], [SD] — verwenden.
• [P], [I], [D] — nur mit genannter Unsicherheit oder Annahme verwenden; gegenüber Kunden, Behörden oder bei Geld erst nach Freigabe durch einen Menschen.
• [N] — vor der Verwendung prüfen.
• [S] — keine Entscheidungsgrundlage.
• [X] — an die zuständige Person eskalieren.

Eine Kennzeichnung, die sich das Modell in seiner Antwort selbst gibt, behandle ich als Vorschlag — es gilt erst die, die die Prüfung der Grundlage bestätigt. Und die Kennzeichnung hat eine Grenze: Eine fälschlich mit [F] markierte Behauptung stärkt das Vertrauen in den Fehler mehr als gar keine Kennzeichnung. Deshalb werden auch die [F] selbst stichprobenartig geprüft.

Woran man erkennt, dass die Kontrolle funktioniert

Das Vorhandensein von Kennzeichnungen beweist allein nichts — ein System ohne Kennzeichnungen muss nicht schlecht gesteuert sein, eines mit Kennzeichnungen nicht gut. Entscheidend sind die Ergebnisse der Prüfung. Ich verfolge drei Kennzahlen:

• Anteil der geprüften [F], die nicht standgehalten haben.
• Anteil wichtiger Behauptungen mit nachvollziehbarer, relevanter Grundlage.
• Anzahl der Fälle, in denen das System an einen Menschen hätte eskalieren müssen und es nicht getan hat.

Verhältnis zum AI Act

Eine Kennzeichnung der Gewissheit verlangt der AI Act nicht. Artikel 50 verpflichtet, Menschen über die Interaktion mit einer AI zu informieren und bestimmte synthetische Inhalte zu kennzeichnen — zur Gewissheit von Behauptungen sagt er nichts. Näher liegen die Artikel 13 und 14 (Interpretierbarkeit der Ergebnisse für Betreiber und menschliche Aufsicht), die jedoch für Hochrisiko-Systeme gelten. Certainty Tagging kann eine unterstützende Maßnahme sein; die Erfüllung von Pflichten belegt es allein nicht.