Reproduzierbare KI-Projekte

Ein gutes KI-Ergebnis kann überzeugend aussehen und trotzdem methodisch wertlos sein.

Es kann niemand mehr erklären, welche Quellen verwendet wurden. Der entscheidende Prompt wurde mehrfach überschrieben. Ein Modellwechsel fand mitten im Projekt statt. Ein Agent hat ein Tool aufgerufen, aber die Nebenwirkung wurde nicht dokumentiert. Eine Architekturentscheidung steht im aktuellen Code, doch niemand weiß, warum die Alternative verworfen wurde. Ein Reviewer hat eine Version freigegeben, die später noch verändert wurde.

Am Ende existiert ein Ergebnis – aber keine belastbare Geschichte seiner Entstehung.

Genau dort beginnt das Problem der Reproduzierbarkeit.

Bei klassischen Softwareprojekten helfen Versionskontrolle, Build-Logs, Tests und Tickets. Bei agentischen KI-Projekten reicht das allein nicht mehr. Zusätzlich entstehen Prompt-Versionen, Modellaufrufe, Tool-Interaktionen, Handoffs, dynamische Entscheidungen, Retrieval-Ergebnisse, Bewertungen und teilweise nicht deterministische Outputs.

Die professionelle Frage lautet deshalb nicht nur:

Funktioniert das Ergebnis?

Sondern:

Können wir später beweisen, wie dieser Projektzustand entstanden ist, auf welcher Evidenz er beruht und welche Entscheidungen ihn geprägt haben?

Reproduzierbarkeit beginnt dort, wo Erinnerung endet

Solange ein Projekt klein ist, funktioniert Erinnerung erstaunlich gut.

Man weiß noch, warum eine Variante verworfen wurde. Man erinnert sich an den entscheidenden Prompt. Der Chat ist offen. Die Quelldateien liegen sichtbar daneben. Änderungen sind frisch.

Mit wachsender Projektdauer bricht dieses Modell zusammen.

Menschen vergessen. Chats werden gewechselt. Modelle werden aktualisiert. Dateien erhalten neue Versionen. Agenten erzeugen Zwischenergebnisse, die später nicht mehr sichtbar sind. Ein Teammitglied tritt hinzu und kennt die Gründe hinter einer bestehenden Entscheidung nicht.

Dann entsteht eine gefährliche Illusion: Der aktuelle Zustand sieht eindeutig aus, obwohl seine Herkunft nicht mehr eindeutig ist.

Reproduzierbarkeit ist deshalb nicht primär ein Archivproblem.

Sie ist eine Eigenschaft der Projektarchitektur.

Ein Ergebnis ist kein Beweis seiner Entstehung

Eine fertige Präsentation beweist nicht, wie sie entstanden ist.

Ein funktionierender Prototyp beweist nicht, welche Annahmen getestet wurden.

Ein finaler Prompt beweist nicht, welche früheren Varianten gescheitert sind.

Ein Git-Commit beweist nicht automatisch, warum eine Entscheidung getroffen wurde.

Und ein Chatverlauf beweist nicht, welche Dateien, Toolzustände und externen Daten zum Zeitpunkt einer Antwort tatsächlich relevant waren.

Darum braucht ein reproduzierbares KI-Projekt mehrere miteinander verknüpfte Evidenzebenen.

Erst zusammen bilden diese Ebenen eine belastbare Projektgeschichte.

Prompt-Historie ist notwendig – aber nicht ausreichend

In KI-Projekten wird Reproduzierbarkeit häufig mit „Prompt speichern“ gleichgesetzt.

Das ist ein guter Anfang. Aber es reicht nicht.

Ein Prompt kann identisch sein und trotzdem unterschiedliche Ergebnisse erzeugen, wenn sich mindestens eine der folgenden Bedingungen ändert: Modell oder Modellversion, Systeminstruktionen, Temperatur oder andere Sampling-Parameter, Retrieval-Inhalte, Toolversionen, externe API-Antworten, Reihenfolge paralleler Schritte, vorheriger Sessionzustand, Dateien oder Datenquellen, oder zeitabhängige Webinhalte.

Der Prompt ist also nur ein Teil des Versuchaufbaus.

Wer nur Prompts archiviert, archiviert die Frage – aber nicht zwingend die Bedingungen, unter denen die Antwort entstand.

Ein Chatverlauf ist kein Audit Trail

Ein Chat ist hervorragend für Exploration.

Als alleiniger Nachweis ist er schwach.

Warum?

Er vermischt Auftrag, Diskussion, Korrektur, Entscheidung und Ergebnis. Er enthält möglicherweise nicht alle Toolzustände. Manche Systeme komprimieren ältere Inhalte. Dateien können ersetzt werden. Externe Webseiten verändern sich. Ein Agent kann Nebenwirkungen außerhalb des Chats erzeugen. Plattformen zeigen nicht immer jede interne Instruktionsschicht.

Ein Audit Trail braucht dagegen strukturierte Ereignisse.

Zum Beispiel: RUN-028-014 startete am 28.08. um 14:32, nutzte Prompt-Version P-12.3, arbeitete mit Quellensnapshot SRC-07, verwendete Modellkonfiguration M-04, erzeugte Artefakt A-19.2, wurde von Review R-44 beanstandet, führte zur Entscheidung D-31 und wurde durch RUN-028-016 ersetzt.

Damit wird aus Chronologie Provenienz.

Observability ist nicht dasselbe wie Provenienz

Observability beantwortet vor allem die Betriebsfrage: Was tut das System gerade oder was hat es technisch getan?

Provenienz beantwortet die Herkunftsfrage: Warum existiert dieser Zustand – und welche Inputs, Entscheidungen und Prüfungen haben ihn hervorgebracht?

Ein Trace kann zeigen, dass ein Agent drei Tools aufgerufen und zwei Dateien erzeugt hat. Ohne Decision Record ist aber weiterhin unklar, warum Variante A akzeptiert und Variante B verworfen wurde. Umgekehrt kann ein sauberer Decision Record existieren, ohne dass die tatsächliche Ausführung technisch nachvollziehbar ist.

Professionelle Projekte brauchen deshalb beides:

Observability für Laufzeitereignisse, Fehler, Tool Calls und Systemverhalten.

Provenance für Herkunft, Begründung, Versionen und Evidenzbeziehungen.

Diese Trennung verhindert ein verbreitetes Missverständnis: Viele Logs machen ein Projekt noch nicht reproduzierbar. Sie machen nur mehr Ereignisse sichtbar. Erst wenn relevante Ereignisse mit Quellen, Entscheidungen und Artefakten verbunden werden, entsteht eine beweisfähige Projektgeschichte.

Projektgeschichte ist ein Graph, keine Erzählung

Menschen erzählen Projekte linear:

Erst recherchierten wir. Dann bauten wir einen Entwurf. Danach änderten wir die Architektur. Schließlich kam Version 3.

Technisch ist die Geschichte jedoch selten linear.

Ein Artefakt kann aus mehreren Quellen entstehen. Eine Entscheidung kann drei Runs beeinflussen. Ein Review kann eine frühere Entscheidung wieder öffnen. Zwei parallele Agenten können konkurrierende Varianten liefern. Ein späterer Test kann zeigen, dass eine frühere Annahme falsch war.

Deshalb ist ein Provenienzgraph hilfreicher als eine reine Timeline.

Seine wichtigsten Knotentypen sind:

Source – Quelle, Datensatz, Referenz.

Instruction – Prompt, Systemregel, Task Contract.

Run – konkrete Ausführung.

Artifact – erzeugte Datei, Code, Analyse oder Output.

Finding – Test- oder Reviewbefund.

Decision – akzeptierte, verworfene oder ersetzte Entscheidung.

Checkpoint – bestätigter Projektzustand.

Kanten beschreiben Beziehungen wie USES, PRODUCES, REVIEWS, SUPPORTS, REJECTS, SUPERSEDES und DERIVES_FROM.

Die zentrale Frage lautet dann nicht mehr nur „Was geschah wann?“, sondern:

Welche Evidenz trägt welche Entscheidung – und welche Artefakte hängen davon ab?

Der Minimal Run Record

Nicht jedes Projekt braucht eine komplexe Observability-Plattform.

Aber jeder relevante KI-Lauf sollte einen minimalen Datensatz hinterlassen.

Dieser Record muss nicht alle Rohdaten duplizieren.

Er muss sie eindeutig referenzieren.

Modellidentität gehört zur Evidenz

„Wir haben GPT verwendet“ ist keine reproduzierbare Angabe.

Auch „wir haben Modell X verwendet“ kann zu grob sein, wenn sich ein Anbieter im Hintergrund verändert.

Für relevante Runs sollte deshalb – soweit verfügbar und zulässig – festgehalten werden: Provider, Modellbezeichnung, Modell- oder API-Version, Datum, relevante Sampling-Einstellungen, Toolkonfiguration, aktivierte Retrievalquellen, strukturierte Output-Schemata und besondere Laufzeitoptionen.

Nicht jeder Anbieter macht alle Details sichtbar.

Gerade deshalb ist es wichtig zu dokumentieren, was bekannt war und was nicht.

Unsichtbare Modellveränderungen sind kein Grund, auf Reproduzierbarkeit zu verzichten. Sie sind ein Grund, Unsicherheit explizit zu markieren.

Reproduzierbarkeit bedeutet bei generativer KI nicht Byte-Identität

Ein häufiger Denkfehler ist die Erwartung, derselbe Prompt müsse später exakt denselben Text erzeugen.

Das ist bei generativen Systemen oft weder realistisch noch notwendig.

Je nach Modell und Infrastruktur können Sampling, nicht deterministische Hardwareoperationen, veränderte Retrievalresultate oder Providerupdates Abweichungen verursachen.

Darum hilft eine Dreiteilung:

Replay

Können dieselben gespeicherten Inputs, Instruktionen und Toolschritte erneut ausgeführt werden?

Rebuild

Kann ein neuer Lauf denselben fachlichen Projektzustand oder dieselbe Funktion aus den dokumentierten Voraussetzungen wieder herstellen?

Re-evaluation

Kann ein unabhängiger Prüfer nachvollziehen, ob die damalige Entscheidung unter den dokumentierten Bedingungen vertretbar war?

Für viele KI-Projekte ist Re-evaluation wichtiger als identische Textreproduktion.

Entscheidungen brauchen einen eigenen Datentyp

Eine Entscheidung darf nicht nur als Satz in einem Chat existieren.

Sie sollte ein eigenes Objekt sein.

Ein brauchbarer Decision Record enthält mindestens:

Das verhindert verwaiste Entscheidungen: Projektzustände, deren Ursprung nicht mehr auffindbar ist.

Activity Log und Decision Log sind nicht dasselbe

Ein Activity Log sagt: Agent hat Datei geöffnet. Tool wurde aufgerufen. Test wurde ausgeführt. Entwurf wurde gespeichert.

Ein Decision Log sagt: Variante B wird verworfen, weil Test T-14 eine zentrale Anforderung verletzt. Architektur A wird akzeptiert, obwohl sie teurer ist, weil Reversibilität und Datenkontrolle höher sind. Version 3.1 wird nicht veröffentlicht, bis Finding F-22 geschlossen ist.

Beide Logs sind wertvoll.

Aber sie beantworten unterschiedliche Fragen.

Aktivität erklärt Bewegung. Entscheidung erklärt Richtung.

Der wichtigste Link lautet: Entscheidung → Evidenz

Ein Projekt kann sehr gut dokumentiert aussehen und trotzdem schwach sein.

Das passiert, wenn Entscheidungen zwar erfasst werden, aber ihre Grundlage fehlt.

„Wir haben Variante A gewählt“ ist Dokumentation.

„Wir haben Variante A gewählt, weil Test T-07 und T-09 die Akzeptanzkriterien erfüllten, Quelle S-03 die regulatorische Annahme stützte und Variante B im Kosten-Stresstest scheiterte“ ist Evidenzführung.

Damit wird der Decision Record prüfbar.

Die Entscheidung steht nicht nur im Projekt.

Sie zeigt auf ihren Beweisraum.

Evidenzdichte ist wichtiger als Logmenge

Ein Projekt kann Millionen Logzeilen besitzen und trotzdem kaum nachvollziehbar sein.

Entscheidend ist nicht die Menge gespeicherter Ereignisse, sondern die Dichte relevanter Verknüpfungen. Ein guter Evidenzsatz beantwortet mit wenigen Objekten eine konkrete Frage: Welche Annahme wurde geprüft? Welcher Test lief? Welches Ergebnis entstand? Welche Entscheidung folgte? Welches Artefakt änderte sich dadurch?

Das führt zu einem hilfreichen Designprinzip:

Speichere nicht alles gleichwertig. Markiere projektwirksame Ereignisse.

Dazu gehören insbesondere Zustandsänderungen, Freigaben, Ablehnungen, Tool-Side-Effects, neue Quellenstände, geschlossene oder wiedereröffnete Findings und Entscheidungen, die spätere Arbeit beeinflussen. Reine Debugdetails können weiterhin existieren, müssen aber nicht dieselbe Retentions- oder Reviewpriorität besitzen.

So bleibt Provenienz lesbar, ohne Observability zu amputieren.

Quellen brauchen Snapshots oder zumindest Identität

Webquellen verändern sich.

Dokumente werden aktualisiert. Webseiten verschwinden. API-Dokumentation erhält neue Versionen. Tabellen werden korrigiert.

Wer später nur eine URL besitzt, weiß nicht zwingend, welchen Inhalt der ursprüngliche Lauf gesehen hat.

Für kritische Quellen helfen deshalb: Abrufdatum, Titel und Herausgeber, Versionsnummer falls vorhanden, archivierter Snapshot sofern rechtlich zulässig, Hash lokaler Quelldateien oder zumindest ein extrahierter relevanter Abschnitt mit Herkunftsreferenz.

Die Regel lautet:

Eine Quelle ist erst dann reproduzierbar referenziert, wenn ihre damalige Identität hinreichend bestimmt ist.

Artefakte brauchen Lineage

Ein Verzeichnis voller Dateien ist noch keine Versionierung.

final.docx, final_neu.docx und final_v2_neu_final.docx erzeugen Dateinamen – aber keine Provenienz.

Ein Artefakt sollte mindestens wissen, welche Version es ist, aus welchem Run es stammt, welche Inputs verwendet wurden, welche Entscheidung seine Freigabe erlaubt, welche frühere Version es ersetzt und ob es draft, reviewed, approved oder superseded ist.

Bei maschinenlesbaren Artefakten kann zusätzlich ein Hash helfen, die konkrete Datei eindeutig zu identifizieren.

So wird aus „die Datei“ ein adressierbarer Zustand.

Hashes beweisen Identität – nicht Qualität

Ein kryptographischer Hash ist nützlich, weil schon kleine Dateiänderungen einen anderen Wert erzeugen.

Damit kann später geprüft werden, ob exakt dieselbe Datei vorliegt.

Aber ein Hash sagt nicht, ob die Datei korrekt ist, ob die Quelle vertrauenswürdig war, ob der Prompt gut war oder ob die Entscheidung sinnvoll war.

Hashes lösen also das Identitätsproblem, nicht das Qualitätsproblem.

Das ist eine wichtige Trennung.

Checkpoints frieren keinen Prozess ein – sie stabilisieren ihn

Lange KI-Projekte brauchen Momente, in denen ein Zustand bewusst bestätigt wird.

Ein Checkpoint kann beispielsweise enthalten: aktuelle Project Baseline, aktive Decision Records, freigegebene Artefaktversionen, offene Findings, relevante Quellenstände, aktuelle Runtime- und Toolversionen und den nächsten erlaubten Arbeitsbereich.

Der Checkpoint sagt nicht: „Ab jetzt darf nichts mehr geändert werden.“

Er sagt:

Wenn wir später rekonstruieren müssen, wo das Projekt zu diesem Zeitpunkt stand, ist dies die bestätigte Referenz.

Ein Checkpoint braucht einen Fingerabdruck

Ein robuster Checkpoint sollte eindeutig referenzierbar sein.

Das kann über eine Versionsnummer, einen Commit, ein Manifest oder eine Kombination aus Hashes geschehen.

Beispiel: CP-28-04 verweist auf Charter v5, Decision Register v8, Source Manifest v6, Artifact Set v12, Open Findings v3, Runtime Manifest v4 und einen konkreten Git-Commit.

Damit entsteht eine kompakte Zustandsadresse.

Prompt-Diffs sind wertvoller als Prompt-Sammlungen

Eine Promptbibliothek zeigt, welche Prompts existieren.

Ein Prompt-Diff zeigt, warum sich ein Prompt verändert hat.

Das ist für reproduzierbare Projekte wesentlich interessanter.

Beispiel: Version 4 führte zu Quellenvermischung, Version 5 ergänzte eine Trennung zwischen Primär- und Sekundärquellen, Version 6 führte ein hartes Ausgabe-Schema ein und Version 7 wurde nach einem Reviewer-Finding um eine Unsicherheitsmarkierung ergänzt.

So entsteht Prompt Engineering nicht als Sammlung cleverer Texte, sondern als versionierte Methodengeschichte.

Tool Calls gehören zur Projektgeschichte

Agentische Systeme verändern die Beweislage fundamental.

Ein Modell produziert nicht nur Text. Es kann Dateien schreiben, Datenbanken ändern, APIs aufrufen, Tickets erstellen, Code ausführen, externe Systeme verändern, andere Agenten delegieren oder menschliche Freigaben anfordern.

Darum muss ein relevanter Trace nicht jede interne Tokenbewegung speichern.

Er muss die projektwirksamen Ereignisse sichtbar machen.