Dossier · Auditor

KI-generierten Code auditieren: was ein Sorgfalts-Record wirklich enthält

Sie sollen Code abnehmen, den niemand von Hand geschrieben hat. Er wurde generiert. Er besteht seine Tests. Und die Tests wurden gegen dieselben Annahmen geschrieben wie der Code — sie stimmen ihm bauartbedingt zu. Was genau bleibt da zu prüfen?

Das ist die neue Gestalt einer alten Aufgabe. Der zu prüfende Gegenstand ist nicht länger die Arbeit eines Menschen, die man befragen kann; er ist Output. Die Frage, die ein Auditor beantworten muss — tut das, was es tun sollte? — hat sich nicht geändert. Die verfügbare Evidenz schon.

Warum die üblichen Artefakte Korrektheit nicht prüfen

Drei Dinge werden als Beleg angeboten. Keines davon prüft, ob der Code richtig ist.

Provenienz sagt Ihnen, woher der Code kommt, nicht ob er sich richtig verhält. Die Provenienz-Standards sagen das selbst — Attestierung deckt Lieferkette, Signaturen, Build-Integrität. Zu Korrektheit schweigt sie bewusst.

Test-Coverage sagt Ihnen, dass Tests liefen und Zeilen ausgeführt wurden. Sie sagt nicht, dass die Tests das Richtige prüfen. Wenn Tests und Code aus derselben Absicht stammen — zunehmend vom selben Modell, im selben Durchgang — kodieren sie dieselben Annahmen. Eine Test-Suite kann grün sein, weil der Code korrekt ist, oder weil der Test demselben Fehler zustimmt. Coverage kann beides nicht unterscheiden.

Ein LLM-Code-Review liest den Code und kommentiert ihn. Aber ein Prüfer, der seine Meinung aus dem Code ableitet, erbt dessen blinden Fleck. Hat das Modell die Absicht beim Schreiben missverstanden, missversteht es sie beim Prüfen gleich. Das ist KI, die KI prüft. Es ist keine unabhängige Prüfung.

Das gemeinsame Versagen darunter hat einen Namen: intent drift — Code, der von der Absicht abweicht, während er jeden daneben geschriebenen Test besteht. Eine Studie von 2025 hat das an drei Frontier-Modellen gemessen: gefragt, ob Code seiner Spezifikation entspricht, urteilten sie schon ohne Zusatz unzuverlässig — und der Zwang, das Verdikt zusätzlich zu erklären und Korrekturen vorzuschlagen, verschlechterte es deutlich, im schlimmsten Fall von 52% auf 11%. Das zusätzliche Schlussfolgern schärfte sie nicht; sie nahmen Fehler an, die es nicht gab, und wiesen korrekten Code zurück (Jin & Chen, ASE 2025). Je mehr ein LLM wie ein Prüfer schlussfolgern soll, desto weniger ist seinem Verdikt zu trauen.

In diesem Versagen steckt schon die Korrektur: Das Verdikt darf nicht das des Modells sein. Im Folgenden wird ein Modell einmal benutzt — um den Standard vorzuschlagen — und nie als Richter; das Urteilen läuft auf der CPU gegen ein eingefrorenes Artefakt, wo kein Schlussfolgern mehr übrig ist, das entgleisen könnte. Einfrieren macht den Vorschlag nicht richtig — ein eingefrorener Fehlgriff ist reproduzierbar falsch. Was das Einfrieren kauft, ist etwas anderes: Der Standard wird zum lesbaren Artefakt, das ein Auditor direkt angreifen kann, und die Herleitung läuft mehrfach, wobei Instabilität als Unterspezifikation ausgewiesen wird statt weggemittelt. Determinismus ist ein Anspruch über Re-Litigation, nie über Wahrheit.

Was Unabhängigkeit tatsächlich verlangt

Eine unabhängige Prüfung braucht eine Referenz, die der Code nicht kontaminiert haben kann. Die Referenz muss aus der Absicht stammen, hergeleitet blind zum Code-Rumpf.

Das ist der ganze Mechanismus, nüchtern gesagt. Aus Signatur und Docstring einer Funktion — der artikulierten Absicht — wird ein Standard hergeleitet, ohne den Rumpf zu lesen. Dann wird der Code gegen diesen Standard gefeuert. Weil der Standard die Implementierung nie gesehen hat, teilt er ihren blinden Fleck nicht. Die eigenen Tests eines Menschen finden nur Fehler, nach denen zu suchen er dachte. Ein aus der Absicht hergeleiteter, code-blinder Standard ist nicht so begrenzt.

Die Unabhängigkeit ist genau umrissen — zum Rumpf, nicht zum Intent. Und die Herkunft der Absicht wiegt ebenso schwer. Eine Absicht, die ein Mensch geschrieben hat, ist eine wirklich getrennte Quelle. Eine Absicht, die das Modell neben dem Rumpf mit-generiert hat und die ein Mensch dann las und billigte, ist nicht dasselbe: Ratifikation beweist Zurechenbarkeit, nicht Unabhängigkeit — eine geteilte Fehllesart kann ein Nicken überleben. agetra verwischt die beiden nicht. Der Record trägt die Provenienz der Absicht — authored, ratified oder unknown — und die Stärke des Unabhängigkeits-Anspruchs folgt diesem Feld. Ein Standard ist nur so unabhängig wie die Absicht dahinter; der Record hält fest, welche Art geliefert wurde, statt die beste anzunehmen.

Zwei Eigenschaften machen das Ergebnis auditierbar statt bloß zu einer weiteren Meinung:

  • Der Rumpf wird nie gelesen. Der Standard wird allein aus dem Interface projiziert — Signatur und Docstring. Ihr Code bleibt lokal. Was quert, ist eine rumpf-freie Beschreibung der Absicht, nicht mehr.
  • Das Verdikt ist deterministisch. Die Herleitung des Standards ist der eine Schritt, an dem ein Modell beteiligt ist, und er passiert einmal; danach wird der Standard eingefroren. Das Verdikt — erfüllt der Code den eingefrorenen Standard? — läuft auf der CPU gegen die eingefrorenen Artefakte, ohne Modell in der Schleife. Ein erneuter Lauf reproduziert es exakt. Es gibt nichts Nicht-Deterministisches, das neu zu verhandeln wäre.

Die Anatomie eines Sorgfalts-Records

Ein Record ist auditierbar, wenn man aufzählen kann, was er enthält, und jeden Teil nachprüfen kann. Das hält ein Sorgfalts-Record:

  • Die Absicht, gegen die geprüft wurde — die exakte Signatur und der Docstring, eingefroren und versioniert, mit ihrer Provenienz: von einem Menschen verfasst (authored), aus einem generierten Entwurf ratifiziert oder unknown. Ändert sich die Absicht, ist das ein neuer Record, kein stilles Update.
  • Der Standard — das aus dieser Absicht hergeleitete Orakel, eingefroren. Sie können einsehen, woran der Code tatsächlich gemessen wurde.
  • Das Verdikt, pro Verhaltens-Klausel — einer von drei Zuständen: konform, abweichend oder nicht entscheidbar. Kein Score. Wo die Prüfung Zähne hat, sagt sie es; wo sie nicht entscheiden kann, sagt sie auch das.
  • Der explorierte Eingabe-Raum — die Reproduktions-Eingaben, inklusive der Version aller verwendeten Standard-Daten (Zeitzonen, numerische Standards). Reproduktion heißt, dieselbe Exploration erneut zu fahren, nicht einer Zusammenfassung zu trauen.
  • Was er nicht deckt — out-of-scope liegende Flächen und alles ausdrücklich Verzichtete, benannt. Ein Record, der seine eigenen Grenzen nicht zeigen kann, ist keine Evidenz, sondern Dekoration. Es gibt kein falsches 100%-Grün.
  • Provenienz des Akts — wann er lief, wer die Absicht ratifiziert hat, und die Tatsache, dass er allein aus der CPU reproduziert, ohne Modell-Neuaufruf.

Schematisch die Felder, die ein Auditor prüft (maschinenlesbar, EN):

intent:        <hash of frozen signature + docstring>
  provenance:  authored | ratified | unknown
standard:      <hash of derived oracle>
verdict:
  - clause: <behavioral clause>   state: conforming | diverging | can't-tell
inputs:        <explored space + standard-data version>
out-of-scope:  <named surfaces>   waived: <named, with reason>
ratified-by:   <identity that confirmed the intent>
reproduces:    cpu-replay, no model

Was er ist — und was nicht

Ein Record findet Abweichungen im explorierten Eingabe-Raum. Ihre Abwesenheit behauptet er nicht. Diese Unterscheidung ist sein ehrlicher Kern: der erfüllte Maßstab ist Sorgfalt, nicht Perfektion. Ein Lauf ist Beleg, dass Sie hingesehen haben — sorgfältig, auf eine Weise, die eine andere Partei reproduzieren kann — kein Beweis, dass nichts übersehen wurde.

Also: Es ist ein Sorgfalts-Record, zeitgleich und zuordenbar und reproduzierbar. Es ist kein Korrektheits-Zertifikat. Es ist kein Bug-Finder. Und es ist nicht die Meinung eines weiteren Modells über den Code — der ganze Punkt ist, dass der Standard hergeleitet wurde, ohne ihn zu sehen.

Genau gesagt ist der Anspruch dreierlei Enges und nicht mehr: unabhängig vom Rumpf, nicht von Ihrer Absicht; Sorgfalt, nicht Korrektheit; reproduzierbar, nicht unfehlbar. Jedes der drei ist etwas, das eine zweite Partei nachprüfen kann. Nichts Weiteres wird behauptet.

Warum das jetzt zählt

Ab dem 9. Dezember 2026 behandelt die EU-Produkthaftungsrichtlinie Software als Produkt, und bei hinreichend komplexen Systemen kann sich die Beweislast zum Hersteller verschieben. „Wir waren sorgfältig" wird zu etwas, das man zeigen muss, nicht sagen. Und das zeigen gelingt am ehesten, wenn die Evidenz entstand, während der Code geschrieben wurde — zeitgleich, in der Schleife, in der er erzeugt wird — statt Monate später unter Vorladung rekonstruiert. Wie ein Sorgfalts-Record dazu passt — und was „legally defensible" bedeutet und was nicht — ist ein eigenes Thema, Legally Defensible Code (ein begleitendes Dossier, in Vorbereitung).

Scope & Status

agetra ist pre-launch. Die erste Version verifiziert pure, deterministische Python-Logik — der Ort, an dem „tut es, was gemeint war?" eine saubere Antwort hat. Wenn Sie KI-generierten Code auditieren oder ausliefern und das die Evidenz ist, die Sie sich wünschten — tragen Sie sich in die Waitlist ein. Der Rumpf Ihres Codes verlässt Ihre Maschine nie.

In die Waitlist eintragen →

Häufige Fragen

Wie auditiert man Code, den kein Mensch geschrieben hat?

Man auditiert ihn gegen einen unabhängigen Standard — hergeleitet aus der artikulierten Absicht (Signatur und Docstring), blind zum Code-Rumpf. Weil der Standard die Implementierung nie gesehen hat, erbt er ihren blinden Fleck nicht so, wie es die code-eigenen Tests tun. Das Ergebnis ist ein reproduzierbarer Record: wo der Code konform ist, wo er abweicht, und wo die Prüfung nicht entscheiden kann.

Prüft das nicht bloß Code gegen seine eigene generierte Spec?

Nur wenn Sie es zulassen — und der Record sagt es, wenn Sie es getan haben. Die Unabhängigkeit ist auf den Code-Rumpf umrissen: Der Standard wird hergeleitet, ohne die Implementierung zu lesen. Aber die Absicht, aus der er sich herleitet, hat eine Herkunft, und Herkünfte sind nicht gleich. Eine Absicht, die ein Mensch geschrieben hat, ist eine wirklich unabhängige Quelle. Eine Absicht, die das Modell neben dem Rumpf mit-generiert hat und die ein Mensch dann las und billigte, ist schwächer: Ratifikation beweist Zurechenbarkeit, nicht Unabhängigkeit — eine geteilte Fehllesart kann ein Nicken überleben. Und ein ungelesenes Nebenprodukt desselben Generierungslaufs kauft gar keine Unabhängigkeit; dort degradiert die Prüfung ehrlich zu einem Konsistenz-Check (passt der Rumpf zu seinem eigenen Docstring?) plus einer Messung, wie unterspezifiziert dieser Docstring ist. Der Record trägt die Provenienz der Absicht — authored, ratified oder unknown — die Stärke des Anspruchs steht damit im Record, statt behauptet zu werden. Und die Schleife biegt mit der Zeit Richtung Autorenschaft: Wo die Prüfung nicht entscheiden kann, hält sie an und lässt eine benannte Person die Mehrdeutigkeit auflösen — jede Auflösung injiziert menschliche Absicht, die dem ersten Durchgang womöglich fehlte.

Was ist ein Software-Sorgfalts-Record?

Ein zeitgleicher, zuordenbarer, reproduzierbarer Record einer Korrektheits-Prüfung: die eingefrorene Absicht, gegen die geprüft wurde, der daraus hergeleitete Standard, ein Verdikt pro Klausel (konform / abweichend / nicht entscheidbar), der explorierte Eingabe-Raum mit seinen Daten-Versionen und eine ausdrückliche Angabe, was nicht gedeckt wurde. Er zeigt Sorgfalt — dass Sie hingesehen haben, sorgfältig, reproduzierbar — keine Korrektheits-Garantie.

Ist ein LLM-Code-Review ein Audit?

Nein. Ein LLM-Review leitet seine Meinung aus dem Code ab und erbt damit dessen blinden Fleck — hat das Modell die Absicht beim Schreiben missverstanden, missversteht es sie beim Prüfen gleich. Das ist KI, die KI prüft. Ein Audit braucht eine unabhängige Referenz; ein aus der Absicht hergeleiteter, code-blinder Standard ist eine.

Beweist das, dass mein Code korrekt ist?

Nein — und es behauptet es nicht. Es findet Abweichungen im explorierten Eingabe-Raum; ihre Abwesenheit behauptet es nicht. Der erfüllte Maßstab ist Sorgfalt, nicht Perfektion: Beleg, dass Sie geprüft haben, auf eine Weise, die eine andere Partei reproduzieren kann.

Welchen Code kann es prüfen?

Die erste Version prüft pure, deterministische Logik — Funktionen, deren Ausgabe allein von ihren Eingaben abhängt, mit Seiteneffekten (I/O, Uhr, Zufall, globaler State) außen vor. agetra erkennt diese Grenze selbst und markiert alles andere als out-of-scope, statt vorzugeben, es zu decken — es gibt kein falsches Grün-für-alles. Dieselbe Grenze, die Code prüfbar macht — Entscheidungslogik getrennt von Effekten — ist die, die ihn testbar und wartbar macht.

Was, wenn die Absicht, die ich bestätige, falsch ist?

agetra hält Ihren Code an die Absicht, die Sie angeben oder ratifizieren — nicht an eine Grundwahrheit, die es nicht sehen kann. Bestätigen Sie eine falsche Absicht, wird der Code dagegen geprüft. Was agetra nicht tut: still raten. Wo die Absicht mehrdeutig ist, hält es an und lässt eine benannte Person entscheiden, und es hält fest, wer welche Lesart ratifiziert hat, und wann. Eine falsch-aber-ratifizierte Absicht ist immer noch eine zurechenbare, aktenkundige Entscheidung — genau wofür ein Sorgfalts-Record da ist. Er zeigt, wer „richtig" definiert hat und dass der Code daran gehalten wurde; er behauptet nicht, dass diese Definition unfehlbar war.