Nicht glauben, nachweisen.

9.1 Warum Nachvollziehbarkeit?

In klassischer Entwicklung beantwortet die Git-Historie viele Fragen: Wer hat was wann geändert? Bei agentischer Entwicklung reicht das nicht mehr. Der Commit-Autor ist ein Agent oder eine neutrale Identität, und die interessanten Fragen liegen davor: Wer hat den Auftrag erteilt? Welches Modell hat gearbeitet? Welche Regeln galten? Wurde der Code geprüft, und wer hat ihn freigegeben? Gegen welche Anforderung wurde gebaut?

Vier Gründe machen diese Fragen dringend:

• Verantwortung und Haftung: Ein Agent kann keine Verantwortung tragen. Verantwortlich bleiben Menschen und Organisationen. Damit Verantwortung zuordenbar ist, muss festgehalten sein, wer welche Entscheidung getroffen hat.
• Audit und Revision: Interne Revision, externe Prüfer und Kunden fragen nach Nachweisen. Eine Behauptung („unser Code wird immer geprüft“) ist kein Nachweis. Ein Nachweis ist ein Datensatz, den man unabhängig prüfen kann.
• Regulatorik: Verschiedene Regelwerke verlangen Aufzeichnungen, menschliche Aufsicht und die Beherrschung von IKT- und Drittparteienrisiken. Welche Pflichten konkret für deine Organisation gelten, ist eine rechtliche Frage. Technisch lässt sich aber vorbereiten, dass die nötigen Aufzeichnungen entstehen und belastbar sind.
• Reproduzierbarkeit und Fehleranalyse: Wenn ein Fehler auftaucht, willst du wissen, unter welchen Bedingungen der Code entstand: Modell, Kontext, Regeln, Prüfergebnisse. Erst dann kannst du die Ursache finden und den Prozess verbessern.

9.2 Hash-Ketten und Signaturen in fünf Minuten

Hashfunktionen

Eine kryptografische Hashfunktion wie SHA-256 bildet beliebige Daten auf einen Wert fester Länge ab. Ändert sich auch nur ein Zeichen der Eingabe, ändert sich der Hash vollständig. Und es ist praktisch unmöglich, zwei verschiedene Eingaben mit demselben Hash zu finden. Ein Hash ist damit ein Fingerabdruck des Inhalts.

Verkettung

In einer Hash-Kette enthält jeder Eintrag den Hash seines Vorgängers. Der Hash eines Eintrags wird über seinen Inhalt und den Vorgänger-Hash gebildet:

Grafik in voller Größe öffnenGrafik in voller Größe öffnen

Damit fällt jede Änderung, jedes Löschen, jedes Einfügen und jedes Umordnen innerhalb der Kette auf, zumindest für jemanden, der sie nachrechnet. Nicht erkennbar ist allein das Abschneiden der jüngsten Einträge am Ende; dagegen helfen ein signierter Ketten-Kopf und ein bekannter Vergleichsstand (Abschnitt 9.7). Eine fortlaufende Sequenznummer macht Lücken zusätzlich sichtbar.

Signaturen

Eine Hash-Kette allein schützt nicht gegen jemanden, der alle Hashes neu berechnet. Deshalb wird jeder Eintrag zusätzlich digital signiert: Mit einem privaten Schlüssel entsteht eine Signatur, die jeder mit dem zugehörigen öffentlichen Schlüssel prüfen kann. Ohne den privaten Schlüssel lässt sich keine gültige Signatur erzeugen. Ein verbreitetes, modernes Verfahren ist Ed25519.

Was das nicht leistet

• Wer den privaten Schlüssel besitzt, kann gültig signieren, auch Falsches. Schlüsselschutz ist deshalb Teil des Nachweises.
• Wer den öffentlichen Schlüssel aus derselben Quelle bezieht wie die Daten, prüft nichts: Ein Fälscher tauscht beides aus. Der Vertrauensanker muss auf einem zweiten Weg kommen.
• Eine Kette belegt, dass Einträge seit ihrer Entstehung unverändert sind. Sie belegt nicht, dass das System, das sie schrieb, die Wahrheit aufgeschrieben hat.

9.3 Was aufzeichnen? Entscheidungen, nicht nur Ergebnisse

Ein gutes Audit-Protokoll für agentische Entwicklung zeichnet nicht jeden Tastendruck auf, sondern die entscheidungsrelevanten Ereignisse: Auftrag, Regeln, Ressourcen, Prüfungen, Freigaben. Hilfreich ist die Frage, welche Information ein Prüfer in einem Jahr bräuchte, um einen konkreten Code-Stand zu erklären.

• Lebenszyklus: angelegt, gestartet, pausiert, abgebrochen.
• Konfiguration zur Laufzeit: welches Modell, aus welcher Quelle, welche Verhaltensregeln in welcher Version.
• Regeln: welche Policy angewendet wurde und welche Läufe abgelehnt wurden. Auch die Ablehnung ist ein Nachweis.
• Prüfungen: Gate-Ergebnis, SBOM, Signaturen von Artefakten.
• Menschliche Entscheidungen: Freigaben mit Person und Zeitpunkt.
• Anforderungsbezug: gegen welche Anforderung in welcher Fassung gebaut wurde.

Ein zweiter Grundsatz: Inhalte nur dort, wo nötig. Werkzeugargumente können vertrauliche Daten enthalten. Oft genügt ein Hash, um später zu beweisen, dass und was übergeben wurde, ohne den Inhalt im Protokoll zu speichern.

9.4 Policy-as-Code: Regeln als Dokument

Regeln wie „nur diese Anbieter“, „Quality Gate blockierend“ oder „Freigabe vor Ausführung“ lassen sich auf zwei Arten verwalten: als verstreute Einstellungen in einer Oberfläche oder als Policy-as-Code, also als ein strukturiertes Dokument, das versioniert, geprüft und nachgewiesen wird.

Die Vorteile des zweiten Wegs:

• Versioniert: Jede Änderung erzeugt eine neue Fassung; die alte bleibt erhalten. Man kann jederzeit sagen, welche Regeln zu einem Zeitpunkt galten.
• Signiert: Eine signierte Fassung lässt sich nicht unbemerkt ändern.
• Eindeutig wirksam: Es gibt genau eine aktive Fassung, keine Mischzustände.
• Durchgesetzt statt empfohlen: Das System prüft die Regeln an definierten Punkten und lehnt Verstöße ab.
• Schichtbar: Eine engere Ebene (etwa ein Mandant) darf Regeln verschärfen, aber nicht lockern.

Ein wichtiger Detailpunkt ist der Zeitpunkt der Durchsetzung. Prüft ein System nur beim Anlegen eines Auftrags, kann ein Auftrag, der vor einer Regeländerung angelegt wurde, die neue Regel umgehen. Robuster ist eine zweite Prüfung unmittelbar vor der Ausführung.

9.5 Menschliche Aufsicht und Segregation of Duties

Menschliche Aufsicht heißt nicht, dass ein Mensch jede Zeile tippt, sondern dass an den entscheidenden Stellen ein Mensch zustimmen muss und diese Zustimmung dokumentiert ist. Für agentische Entwicklung gibt es zwei natürliche Haltepunkte:

1. Vor der Ausführung: Darf der Agent mit diesem Auftrag, diesem Modell und diesen Rechten überhaupt loslegen?
2. Vor der Übernahme: Darf das geprüfte Ergebnis in den gemeinsamen Stand, also gemergt oder als Pull Request eröffnet werden?

Der zweite Punkt ist entscheidend. Fehlt er, landet der Code im Base-Branch, bevor jemand ihn gesehen hat. Eine nachträgliche „Freigabe“ wäre dann nur Fassade.

Segregation of Duties (Funktionstrennung) bedeutet, dass dieselbe Person nicht zugleich auslösen und freigeben darf. Das klassische Vier-Augen-Prinzip schützt vor Fehlern und vor Missbrauch. Bei Agenten gilt es zusätzlich in einer zweiten Form: Der schreibende Agent darf seine Arbeit nicht selbst freigeben. Diese Rolle übernehmen unabhängige, read-only Reviewer und ein Mensch.

Ein drittes Prinzip ist fail-closed: Wenn eine Prüfung nicht durchgeführt werden kann, etwa weil ein Reviewer abstürzt oder eine Policy nicht lesbar ist, darf das nie als Erfolg gelten.

9.6 Regulatorik: Was Technik leisten kann und was nicht

Viele Organisationen müssen nachweisen, dass sie Risiken beim Einsatz von Software und KI beherrschen. Einige Beispiele, ohne Anspruch auf Vollständigkeit und ohne Rechtsberatung:

• Die EU-KI-Verordnung (VO (EU) 2024/1689) enthält unter anderem Vorgaben zu Aufzeichnungen (Art. 12) und menschlicher Aufsicht (Art. 14) für bestimmte KI-Systeme.
• Im Finanzsektor beschreiben die MaRisk der BaFin, die BAIT (deren Anforderungen sich für DORA-pflichtige Institute mit DORA überschneiden; maßgeblich ist die jeweils aktuelle Aufsichtspraxis) und der Digital Operational Resilience Act (DORA, VO (EU) 2022/2554) Anforderungen an IKT-Risikomanagement, Drittparteienrisiken und Nachweisführung.
• Für die öffentliche Hand sind BSI IT-Grundschutz und die Regeln für Verschlusssachen (VS-NfD) relevant.

Ob und wie diese Regelwerke auf deinen Einsatz anwendbar sind, klären Fachleute für Recht und Compliance. Technik kann zweierlei beitragen: Sie kann die technisch erzwingbaren Anteile durchsetzen (Freigaben, Signaturpflicht, blockierende Prüfungen, Anbieterbeschränkung) und die nötigen Aufzeichnungen manipulationssicher erzeugen. Organisatorische Pflichten wie Verantwortlichkeiten, Schulungen, Risikoanalysen und Verträge mit Anbietern ersetzt sie nicht.

9.7 Unabhängige Prüfung: Nachweise nach außen geben

Ein Nachweis ist erst dann stark, wenn ihn jemand prüfen kann, der dem System nicht vertraut. Daraus folgen Anforderungen an einen Export:

• Deterministisch: Dieselben Daten ergeben dieselben Bytes, unabhängig von Bibliotheksversionen. Sonst lässt sich ein Hash nicht nachrechnen.
• Selbsttragend: Der Export enthält alles, was zur Prüfung nötig ist, ohne Zugriff auf das Ursprungssystem.
• Datensparsam: Einträge, die nicht zum Prüfgegenstand gehören, etwa andere Projekte oder Mandanten, erscheinen nur als Hash-Stellvertreter. Ihre Anzahl ist sichtbar, ihr Inhalt nicht.
• Unabhängig prüfbar: Das Prüfwerkzeug stammt nicht von der geprüften Installation, ist klein, quelloffen und reproduzierbar gebaut.
• Vertrauensanker auf zweitem Weg: Der Fingerabdruck des Signaturschlüssels kommt per Brief, Ticket oder signierter E-Mail, nicht im selben Paket wie die Daten.

9.8 Anforderungen unter Governance: Spec-Pflicht

Bis hierher beantwortet die Governance, wie Code entstanden ist. Eine Frage bleibt: Wurde das Richtige gebaut? Dafür braucht es freigegebene, versionierte Anforderungen. Das Konzept der Produkt-Spec mit Akzeptanzkriterien behandelt Kapitel 4. Hier geht es darum, wie Specs zum Teil der Governance werden.

Drei Bausteine greifen ineinander:

• Pflicht: Ein Build darf nur starten, wenn er sich auf eine freigegebene Anforderung bezieht.
• Abdeckung: Ein Ergebnis wird nur abgenommen, wenn ein Mindestanteil der gebundenen Akzeptanzkriterien durch Tests belegt ist.
• Nachweis: Der Export enthält die Anforderungsfassung selbst, signiert und mit Freigabe, sodass ein Prüfer unabhängig nachvollziehen kann, gegen welchen Text gebaut wurde.

Dazu kommen Kennzahlen, die zeigen, ob der Prozess wirkt: Wie viele Kriterien sind durch Tests belegt? Wie oft ändern sich freigegebene Anforderungen während der Umsetzung? Wie viele Starts hatten überhaupt eine freigegebene Anforderung?

9.9 Zusammenfassung

• Nachweise müssen vollständig, unverändert und zurechenbar sein. Hash-Ketten machen Änderungen sichtbar, Signaturen machen Einträge zurechenbar, und der Vertrauensanker kommt auf einem zweiten Weg.
• Policy-as-Code macht Regeln versioniert, signiert, eindeutig wirksam und doppelt durchgesetzt.
• Menschliche Aufsicht braucht zwei Haltepunkte (vor Ausführung, vor Merge) und Funktionstrennung.
• Compliance-Profile setzen technisch erzwingbare Anteile durch, keine organisatorischen Pflichten.
• Der Audit-Export mit dem Offline-Verifier erlaubt Dritten, ohne Vertrauen in die Fabrik zu prüfen.
• Mit der Spec-Pflicht wird auch nachweisbar, gegen welche freigegebene Anforderung gebaut wurde.

Wie Kosten, Budgets, Mandanten und Rollen den Betrieb steuern, folgt in Kapitel 10.

Kapitelfragen

1. Welche drei Eigenschaften braucht ein Nachweis, und welcher technische Baustein sorgt jeweils dafür?

   Musterantwort

   Vollständig (lückenlose Sequenz seq und Verkettung über prev_hash, im Export zusätzlich der signierte Kopf und das Run-Manifest), unverändert (entry_hash über Inhalt und Vorgänger) und zurechenbar (Ed25519-Signatur mit key_id, geprüft gegen einen auf zweitem Weg übermittelten Fingerabdruck).

2. Die Kettenprüfung meldet nach einem Restore CHAIN_BREAK. Was bedeutet das, und was ist eine wahrscheinliche Ursache?

   Musterantwort

   Ein Eintrag fehlt oder wurde eingefügt; die Verkettung stimmt an einer Stelle nicht. Nach einem Restore ist ein unvollständiges Backup eine naheliegende Ursache. Genau deshalb empfiehlt das Administrationshandbuch die Kettenprüfung nach jedem Restore: Sie ist zugleich eine Integritätsprüfung der Sicherung.

3. Warum genügt es nicht, dem Prüfer zusammen mit dem Export auch den öffentlichen Schlüssel zu schicken?

   Musterantwort

   Wer Einträge fälscht, kann auch den mitgelieferten Schlüssel austauschen und alles neu signieren. Der Vertrauensanker muss aus einer unabhängigen Quelle kommen. Deshalb übermittelt der Admin den Fingerabdruck von /attestierung auf einem zweiten Weg, und der Verifier liefert ohne --schluessel nie Exit 0.

4. Warum setzt die Fabrik eine Policy zweimal durch, beim Anlegen und bei der Ausführung eines Runs?

   Musterantwort

   Ein Run, der vor der Aktivierung einer neuen Policy angelegt wurde, könnte sie sonst umgehen. Außerdem soll der Warum-Trace bzw. Export die tatsächlich durchgesetzte Policy-Version ausweisen. Dasselbe Muster gilt für den Isolationsnachweis: Ein CLI-Update zwischen Anlage und Start wird so erkannt.

5. Ein Kollege schlägt vor, nur einen Freigabepunkt vor der Ausführung einzurichten, „das reicht doch“. Was entgegnest du?

   Musterantwort

   Ohne Freigabe vor dem Merge (Approval-Policy bzw. Pflichtfreigabe-Phase VALIDATION) landet der Code im Base-Branch oder im PR, bevor ein Mensch das validierte Ergebnis gesehen hat. Die Freigabe vor der Ausführung bewertet nur den Auftrag, nicht das Ergebnis. Für regulierte Profile ist der zweite Punkt entscheidend, sonst wäre die signierte Zusage Fassade.

6. Ein Mandanten-Admin will in seiner Policy das MCP-Standardverbot abschalten, das in der globalen Policy gesetzt ist. Geht das?

   Musterantwort

   Nein. Über mehrere wirksame Policies gilt das Strengere: Eine Mandanten-Policy kann die globale nur verschärfen, nicht unterlaufen (globaler Policy-Floor). Bei Plugins und MCP-Servern gilt entsprechend die Schnittmenge.

7. Deine Geschäftsführung fragt: „Wenn wir das Profil EU AI Act anwenden, sind wir dann konform?“ Wie antwortest du?

   Musterantwort

   Nein, nicht automatisch. Das Profil setzt die technisch erzwingbaren Anteile durch (blockierendes Gate, Pflichtfreigabe vor EXECUTION, Attestierung) und erzeugt manipulationssichere Aufzeichnungen. Es ersetzt keine Rechtsberatung und deckt keine organisatorischen Pflichten ab. Ob und welche Pflichten gelten, klären Recht und Compliance; die Fabrik liefert dafür belastbare technische Bausteine und Nachweise.

8. Der Offline-Verifier liefert Exit 2. Was heißt das, und wie kommst du zu Exit 0?

   Musterantwort

   Es wurde keine Verletzung gefunden, aber nicht alles ist beweisbar, typischerweise weil --schluessel fehlt oder Einträge unsigniert bzw. Legacy sind. Mit dem auf zweitem Weg bestätigten Fingerabdruck als --schluessel und aktiver Signatur für die betroffenen Einträge ist Exit 0 erreichbar. Legacy-Einträge vor der Attestierung bleiben nicht prüfbar.

9. Im Zielzustand nach SPEC-005: Eine Policy verlangt pflichtSpecFreigabe, das Projekt steht aber im Spec-Modus AUS. Was passiert beim Start eines Build-Runs?

   Musterantwort

   Die Policy gewinnt als strengere Regel. Der Start wird abgelehnt, mit verständlichem Grund und einem Eintrag RUN_POLICY_DENIED in der Audit-Kette. Abhilfe: Spec-Modus einschalten, eine Spec anlegen und freigeben lassen und den Build aus einem Backlog-Eintrag mit Spec-Bezug starten.

10. Transfer: Ein Kunde will sechs Monate nach Lieferung wissen, gegen welche Anforderung ein bestimmter Code-Stand gebaut wurde. Welche Spuren nutzt du, und was kann der Kunde selbst prüfen?

    Musterantwort

    Der Fabrik-Commit trägt die Trailer Spec: SPEC-<nnn> und Implements: AC-…. Über den Run findest du im Warum-Trace Spec-ID, gebundene Version, Inhalts-Hash und AC-IDs aus RUN_SPEC_GEBUNDEN, dazu SPEC_APPROVED mit der Freigabe. Selbst prüfen kann der Kunde den Run-Export mit dem Offline-Verifier; im Zielzustand nach SPEC-005 enthält der Export 2.1 die Spec-Fassung samt Signatur und Freigabe, und der Verifier gleicht die Bindung gegen die gelieferte Fassung ab.