Zum Inhalt springen
Reality Graph

Regulierung

Der EU AI Act verlangt Aufzeichnungen. Das hier schreibt ein Run.

DiffChecksScopeeine Regelgeprüfteingeschränktblockiert
Der EU AI Act verlangt von Betreibern von Hochrisiko-KI-Systemen Aufzeichnungen darüber, was passiert ist (Artikel 12), und eine menschliche Aufsicht, die tatsächlich ausgeübt wird (Artikel 14). Reality Graph erzeugt Belege dieser Form nebenbei, einfach weil es so arbeitet: eine dauerhafte Aufzeichnung je Run, Belege aus Git und eine Freigabe, die an genau den Stand gebunden ist, für den sie erteilt wurde. Das ist darauf ausgelegt, eurer eigenen Bewertung etwas Faktisches zu geben, auf dem sie steht. Konform macht es euch nicht, eine Zertifizierung gibt es nicht, und die rechtliche Bewertung bleibt bei euch und eurer Rechtsberatung.

Zuletzt aktualisiert:

Die Zuordnung

Pflichten auf der einen Seite, Belege auf der anderen

Zwei Pflichten der Verordnung beschreiben Dinge, die eine Maschine herstellen kann: eine Aufzeichnung dessen, was passiert ist, und eine Entscheidung, die ein Mensch getroffen hat. Die Tabelle stellt beides dem gegenüber, was ein Run auf eure Platte schreibt, und benennt jeweils den Teil, den Reality Graph nicht abdeckt.
Was die Verordnung von Betreibern verlangtWas Reality Graph auf den Tisch legtWas es nicht tut
Aufzeichnungen darüber, was das System getan hat (Artikel 12)Eine dauerhafte lokale Aufzeichnung je Run und dessen Review, über die exakte ID auffindbar und Neustarts überdauernd.Aufgezeichnet werden Coding-Runs auf eurer Maschine, nicht der Betrieb eines KI-Systems in Produktion. Eine schlichte lokale Datei: kein Server, keine Aufbewahrungsregel, nichts Geteiltes.
Ereignisse, die auf das Geschehene zurückführbar sindGeänderte Dateien und Diffs, die Reality Graph selbst aus Git liest, statt sie der Darstellung des Modells über die eigene Arbeit zu entnehmen.Git ist Voraussetzung, und die Erfassung bricht oberhalb von 500 KB bereinigtem Diff bewusst ab, statt ein Teilbild zu melden.
Ergebnisse, die prüfbar sind statt behauptetFreigegebene Kommandos laufen als argv-Liste ohne Shell, und der beobachtete Exit-Code wird festgehalten, markiert als von Reality Graph ausgeführt oder von der Betreiberin bestätigt.Grün heißt, das Kommando endete mit Null, nicht, dass die Aufgabe richtig gelöst wurde. Ein bestätigter Exit-Code wird von einem Menschen eingetragen und nie geprüft.
Eine einheitliche Aussage über den AusgangEin Ergebnis aus einer reinen Funktion mit genau einer Aufrufstelle im Produkt; ein Run wird nur gespeichert, wenn er an ein Review mit passendem Hash gebunden ist.Das Ergebnis ist ein Signal für euer Team, kein Zertifikat, und es beweist nicht, dass der Code richtig ist.
Menschliche Aufsicht an der tatsächlichen Änderung (Artikel 14)Eine Freigabe, gebunden an Run, HEAD, Scope und Validierungs-Fingerabdruck, für die sie erteilt wurde, und als veraltet markiert, sobald sich davon etwas bewegt.Eine lokale Bestätigung, keine Identität und keine Signatur. Es gibt keine Konten und keine Möglichkeit festzustellen, wer an der Tastatur saß.
Aufzeichnungen, die vor stiller Veränderung geschützt sindEin Inhalts-Digest auf jedem Validierungsbeleg, dazu ein optionales hash-verkettetes Log, das Änderungen, Umsortierung, fehlende und doppelte Einträge erkennt und offline prüfbar ist.Opt-in, und jedes Anhängen ist ausdrücklich: Governed Runs landen nicht automatisch darin. Digests erkennen unachtsame Änderungen, keinen entschlossenen Angreifer, und nichts ist signiert.
Wie Pflichten, die der EU AI Act Betreibern auferlegt, zu den Belegen stehen, die ein Reality-Graph-Run erzeugt. Einen Beleg zu erzeugen ist nicht dasselbe, wie eine Pflicht zu erfüllen, und keine Zeile behauptet das.

Beide Artikel gelten für Hochrisiko-KI-Systeme. Ein Team, das mit einem Coding-Assistenten normale Software schreibt, ist davon meistens weit entfernt, und Reality Graph klärt die Frage in keine Richtung: Es stuft keine Risikoklasse ein und entscheidet keinen Anwendungsbereich. Rollen, Kategorien und die aktuellen Fristen sind Thema des Artikels zum EU AI Act für Entwicklungsteams; diese Seite bleibt bei den Belegen.

Die Belegspur

Was ein Run mitschreibt, in der Reihenfolge, in der es passiert

Nichts davon wurde einer Verordnung zuliebe hinzugefügt. Es ist die normale Ausgabe eines Runs, und genau deshalb taugt sie überhaupt als Aufzeichnung.

run-8c31.record.txt

Beispiel – illustrativ, keine echten Run-Daten
run         8c31    geöffnet 2026-08-12 09:14    head 4a91f2c
scope       app/billing/**, tests/billing/**
checks      pytest -q        ->  exit 0   (von Reality Graph ausgeführt)
            npm run lint     ->  exit 0   (von der Betreiberin bestätigt)
evidence    geänderte Dateien aus Git gelesen (5 Dateien, 118 Zeilen)
verdict     EINGESCHRÄNKT GEPRÜFT   (ein bestätigtes Ergebnis)
approval    festgehalten bei head 4a91f2c, gebunden an Scope + Fingerabdruck
digest      sha256:9f2c…   Beleg wird markiert, wenn er später editiert wird

Zwei dieser Zeilen tragen den Unterschied, auf dem der Rest der Aufzeichnung ruht. Ein ausgeführtes Ergebnis trägt den Exit-Code, den Reality Graph von einem selbst gestarteten Kommando gelesen hat; ein bestätigtes trägt das, was ein Mensch eingetippt hat, wird nie geprüft und ist der Grund, warum dieser Run als eingeschränkt geprüft endet. Wie das Ergebnis berechnet wird, steht auf der Seite zum Prüfergebnis.

Die Aufzeichnung bleibt lokal und ist über die exakte ID auffindbar, der Run von vor sechs Wochen öffnet sich also so bereitwillig wie der von heute Morgen; der Export ist ein ausdrücklicher Befehl nach dem anderen, ohne Zeitplan und ohne gemeinsames Ziel. Die Freigabe-Zeile verhält sich so, wie eine Reviewerin es sich wünscht: Bewegt sich HEAD, wächst der Scope oder ändert sich, welche Checks zählen, veraltet die Freigabe, statt stillschweigend auf eine Änderung überzugehen, die niemand angesehen hat. Der Mechanismus steht auf der Seite zu Freigaben, und wo die Daten physisch liegen, steht auf der Seite zum Datenweg.

Bewusst so gebaut

Was euch diese Seite nicht sagen wird

Eine Seite über eine Verordnung ist die Stelle, an der Marketingtexte üblicherweise unscharf werden. Dies sind die Sätze, die falsch wären, aufgelistet, damit ihr Fehlen als Entscheidung lesbar ist.

Was ein Run euch hinterlässt

  • Eine dauerhafte lokale Aufzeichnung je Run und Review, über die exakte ID auffindbar und Neustarts überdauernd.
  • Geänderte Dateien und Diffs, die Reality Graph aus Git liest statt aus der Erzählung des Modells.
  • Einen Validierungsbeleg je Check mit dem beobachteten Exit-Code, markiert als ausgeführt oder bestätigt.
  • Ein Ergebnis je Run aus einer Funktion mit einer Aufrufstelle, mit dem Grund daneben.
  • Eine Freigabe, gebunden an Run, HEAD, Scope und Validierungs-Fingerabdruck, veraltet markiert, sobald sich davon etwas bewegt.
  • Ein optionales hash-verkettetes Log, das Änderungen, Umsortierung, fehlende und doppelte Einträge erkennt.

Was es nicht ist

  • Konformität. Kein Artikel der Verordnung wird dadurch erfüllt, dass ein Werkzeug installiert ist, und nichts hier behauptet das.
  • Eine Zertifizierung. Es gibt zu keinem Preis eine, und hinter diesen Aufzeichnungen steht keine externe Prüfung.
  • Eine Risikoeinstufung. Reality Graph entscheidet nicht, ob ein System hochriskant ist oder ob ihr in den Anwendungsbereich fallt.
  • Eine Identität. Die Freigabe ist eine lokale Bestätigung, keine Signatur, und es gibt keine Konten, an denen ein Name hinge.
  • Ein Teamsystem. Ein Operator, eine Maschine: keine Rollen, keine geteilte Historie, kein SSO und kein zentrales Audit.

Validiert unter Linux mit Python 3.12; Windows und macOS sind in der aktuellen Release-Matrix ungeprüft. Die rechtliche Bewertung bleibt bei euch und eurer Rechtsberatung oder eurem DSB.

Fragen, die wirklich gestellt werden

Macht uns das konform?
Nein. Konformität ist eine Eigenschaft eurer Organisation und des Systems, das ihr betreibt, festgestellt durch eure eigene Bewertung, und kein Werkzeug verleiht sie. Was Reality Graph liefert, ist Material für diese Bewertung: eine dauerhafte Aufzeichnung je Run, Diffs aus Git statt aus der Erzählung des Modells, Belege mit dem beobachteten Exit-Code und eine Freigabe, die an den Stand gebunden ist, für den sie erteilt wurde. Ob das eine Pflicht berührt, die euch wirklich trifft, entscheidet eure Rechtsberatung.
Von welchen Artikeln reden wir hier überhaupt?
Artikel 12 zur Protokollierung und Artikel 14 zur menschlichen Aufsicht. Beide gelten für Hochrisiko-KI-Systeme, und beide beschreiben Pflichten, für die eine Maschine etwas Konkretes produzieren kann. Ob sie eure Organisation überhaupt erreichen, ist eine Frage des Anwendungsbereichs, die diese Seite nicht beantwortet.
Ist eine Reality-Graph-Aufzeichnung ein Audit-Trail?
Nur im wörtlichen Sinn: eine lokale Datei, die festhält, was passiert ist, und in ihrer verketteten Form Änderungen, Umsortierung, fehlende und doppelte Einträge erkennt. Es gibt kein zentrales Auditsystem, keine Konten hinter den Einträgen und nichts Signiertes oder Beglaubigtes.
Können wir diese Aufzeichnungen einem Prüfer oder Kunden geben?
Exportieren könnt ihr sie: lokales JSON oder Markdown, auf Zuruf erzeugt und vorher von Home-Pfaden und Secret-förmigen Zeichenketten bereinigt. Sie zeigen, welche Checks liefen, wer was entschieden hat und bei welchem Commit. Sie zeigen nicht, dass der Code richtig ist.
Belegt die Freigabe, dass ein Mensch Aufsicht geführt hat?
Sie belegt, dass eine Freigabe lokal gegen einen Run, einen HEAD, einen Scope und einen Validierungs-Fingerabdruck festgehalten wurde und veraltet, sobald sich davon etwas bewegt. Wer sie erteilt hat, belegt sie nicht: Es gibt keine Konten und keine Möglichkeit, einen Menschen zu verifizieren.

Bringt Belege in das Gespräch, keine Adjektive

Wenn das nächste Mal jemand fragt, wie KI-gestützte Änderungen hier kontrolliert werden, kann die Antwort eine Aufzeichnung mit Datum, Diff und Entscheidung sein.