Teil 6 von 6

Governance: Menschen, Freigabe und das Ziel

Menschliche Freigabe vor irreversiblen Aktionen, ein vollständig deklarierter Prompt-Loop und das Ziel: spezifikationsgetriebenes probabilistisches Software Engineering.

Andrej Albrecht Von Andrej Albrecht Veröffentlicht 29.07.2026 8 Min. Lesezeit
Abschnitte 19–21
19 · Menschliche Governance

Menschliche Freigabe vor irreversiblen Aktionen

KI schlägt vor System zeigt die Auswirkung Mensch prüft Freigeben / Ablehnen / Ändern System führt aus
Aktionen, die eine Freigabe erfordern
Website veröffentlichen In Produktion deployen E-Mail senden Kampagne starten Domain registrieren / übertragen Kunden belasten Geld ausgeben Daten löschen DNS ändern Rechtliche Inhalte ändern Öffentliche Inhalte erstellen Berechtigungen erteilen Externes Konto verbinden
Freigabe erforderlich: Website veröffentlichen IRREVERSIBEL NACH CDN-PROPAGATION
Was passiertRevision #418 ersetzt die Live-Site
Betroffene SystemeCDN · DNS-Cache · Sitemap · Suchindex
Erzeugte Einträge1 Deployment · 1 Audit-Log-Eintrag
Umkehrbar?Ja, vorherige Revision in ~2 Min. wiederherstellbar
Erwartete Kosten€0,00
Öffentliche AusgabeVorschau von Revision #418 ↗
Rollback-PlanAutomatische Wiederherstellung von Revision #417
Freigeben und veröffentlichen Plan ändern Ablehnen
Was das für das Geschäft bedeutet
Freigabe-Gates sind die Kontrolle, und sie müssen selektiv sein

Menschliche Freigabe vor irreversiblen Aktionen ist zugleich Ihre Risikokontrolle und, in vielen Märkten, Ihr Compliance-Nachweis. Die beiden naheliegenden Fehler sind gleichermaßen schädlich: Alles freizugeben zerstört die Effizienz, für die das System gebaut wurde, und nichts freizugeben setzt das Geschäft Aktionen aus, die es nicht rückgängig machen kann. Der praktikable Mittelweg ist eine kurze, explizite Liste irreversibler Aktionen, jede mit einer Vorschau der Auswirkung und einer namentlich verantwortlichen Person für die Entscheidung.

Entscheidung Die Liste der irreversiblen Aktionen festlegen und für jede eine Vorschau der Auswirkung sowie einen namentlich benannten Freigebenden verlangen.
20 · Das Programm, deklariert

Ein Prompt-Loop lässt sich wie ein Programm deklarieren

Alles, was dieser Leitfaden behandelt hat, in einer Programmdefinition. Natürliche Sprache bleibt Teil des Systems, aber das umgebende Verhalten wird deklariert, validiert und durchgesetzt.

program: website_change Programmdefinition · v12
input:
user_request: string
tenant_id: uuid
output:
website_revision: VerifiedRevision
stages:
classify_intent → create_spec →
select_design_direction →
create_plan → request_approval →
implement → verify → repair →
mark_ready
routing:
first_build: build_workflow
ongoing_edit: edit_workflow
redesign: redesign_workflow
module_configuration: module_workflow
question: answer_only
permissions:
planner: repository read
builder: repository write
crawler: restricted_read
publisher: approval_required
invariants:
- tenant_isolation
- preserve_user_content
- no_publish_without_approval
- no_unverified_ready_state
- no_secret_exposure
- no_unapproved_side_effect
verification:
schema · architecture · browser ·
accessibility · visual_regression ·
requirement_coverage · security
repair_loop:
success: all_required_checks_pass
max_iterations: 5
max_cost_eur: 2.00
stop_on_no_progress: 2
rollback_on_regression: true
checkpoint:
after_each_stage: true
before_irreversible_action: true
observability:
record prompts · tool_calls ·
state_transitions · costs · evaluations
Jeder Block verbindet sich mit…
Typisierte Inputs & Outputs §08
State Machine & Routing §05 · §11
Permissions & Effekte §10
Contracts & Invarianten §09
Externe Verifikation §13
Repair-Loop & Stoppregeln §16
Checkpointing §17
Observability §06
Was das für das Geschäft bedeutet
Eine Spezifikation, die auch Nicht-Engineers prüfen können

Wenn der gesamte Loop deklariert ist, einschließlich Ziel, Inputs, erlaubter Tools, Grenzen, Stoppbedingungen und Verifikation, wird das System für Menschen prüfbar, die keinen Code lesen. Das ist in der Praxis wichtig, denn Legal, Compliance, Security und die Geschäftsverantwortlichen haben alle berechtigte Fragen zum autonomen Verhalten, und eine Spezifikation ist das einzige Artefakt, das sie ohne den Quellcode beantwortet. Außerdem wird die Übergabe zwischen Teams zu einem Dokumentenaustausch statt zu einem aufwendigen Wissenstransfer.

Entscheidung Ein einheitliches Spezifikationsformat über alle Features einführen, damit Review, Audit und Handover wiederholbar statt maßgeschneidert werden.
21 · Das Ziel

Spezifikationsgetriebenes probabilistisches Software Engineering

Die reife Form der Disziplin: Jede Schicht über und unter dem Modell ist deklariert, und die Freiheit des Modells lebt in ihnen.

Menschliches Ziel
Typisierte Spezifikation
Deterministische Orchestrierung
Eingeschränkte Modellentscheidungen
Kontrollierte Tool-Effekte
Externe Verifikation
Menschliche Governance
Verifiziertes Ergebnis
Die tragende Formel
Zuverlässiges KI-System =
  typisierte Spezifikationen
+ deterministische Orchestrierung
+ eingeschränkte Modellentscheidungen
+ kontrollierte Seiteneffekte
+ externe Verifikation
+ beobachtbare Ausführung
+ menschliche Governance

Der Prompt wird vergleichbar mit einem Funktionsrumpf: ein Implementierungsdetail. Das dauerhafte System ist die Architektur darum herum.

Was das für das Geschäft bedeutet
Die Architektur ist der Wert, die Prompts sind es nicht

Spezifikationen, Evaluation-Sets, Contracts, Capability-Grenzen und Governance behalten ihren Wert über Modellgenerationen hinweg. Sammlungen von Prompts, die auf ein bestimmtes Modell abgestimmt sind, tun das nicht, weil genau dieses Modell ersetzt werden wird. Deshalb ist das nützliche Maß für Fortschritt nicht, wie viele Prompts oder Agents in Produktion sind, sondern wie viel des Systems deklariert und verifiziert ist. Teams, die das verinnerlichen, hören auf, ihre KI-Features bei jedem Wechsel des zugrunde liegenden Modells neu zu schreiben.

Entscheidung Fortschritt an der deklarierten und verifizierten Fläche messen und Ihre KI-Roadmap daran ausrichten statt an der Anzahl der Features.
Serie

Weiter im Engineering-Leitfaden

Das ist ein Teil eines sechsteiligen Leitfadens dazu, Prompts in spezifikationsgetriebene, probabilistische Software zu verwandeln.

Zur Serienübersicht →

App- & Cloud-Architektur · Strategiegespräch buchen

Weitere Artikel