Die KI-Controlling-Schleife

PDCA und Vier-Augen-Prinzip sind in der Wirtschaft Standard. Dieselbe Logik macht KI-Agenten zuverlässig: Writer + Reviewer + Loop.

Kein Unternehmen würde eine Bilanz ohne Vier-Augen-Prinzip veröffentlichen. Kein Automobilhersteller würde ein Bauteil ohne Qualitätskontrolle verbauen. Kein Verlag würde einen Text ohne Lektorat drucken.

Aber bei KI-generierten Inhalten? Da klicken viele auf "Akzeptieren" und hoffen, dass es schon stimmt.

Das muss nicht sein. Die Werkzeuge für Qualitätskontrolle bei KI existieren. Sie sind nicht neu. Sie heißen nur anders.

Was die Wirtschaft seit Jahrzehnten macht

Der PDCA-Zyklus (Plan, Do, Check, Act) wurde in den 1920ern bei Bell Laboratories entwickelt und von W. Edwards Deming populär gemacht. Die Idee: Jeder Prozess wird in eine Feedback-Schleife gelegt. Du planst, führst aus, prüfst das Ergebnis gegen das Soll und verbesserst den Prozess.

Das Vier-Augen-Prinzip ergänzt das: Kritische Vorgänge brauchen mindestens zwei unabhängige Prüfungen. Im Einkauf, in der Produktion, in der Wirtschaftsprüfung. Es erhöht nachweislich die Prüfungsqualität, auch wenn es mehr Zeit kostet.

Beide Prinzipien teilen dieselbe Einsicht: Wer seine eigene Arbeit prüft, findet seine eigenen Fehler nicht. Deshalb braucht es eine zweite Instanz.

Dasselbe Prinzip, übersetzt auf KI

In der KI-Agentenarchitektur heißt das: Writer-Reviewer-Pattern. Ein Agent produziert, ein zweiter prüft, und der Kreislauf wiederholt sich bis zur Qualitätsschwelle.

Konkret sieht das so aus:

  1. Writer-Agent erstellt einen Entwurf (Text, Code, Plan, Analyse)
  2. Reviewer-Agent prüft den Entwurf gegen definierte Kriterien
  3. Loop-Controller entscheidet: Qualität erreicht? Dann fertig. Wenn nicht, zurück zu Schritt 1 mit dem Feedback aus Schritt 2
  4. Abbruchbedingung verhindert Endlosschleifen (z.B. max. 3 Runden)

Das entspricht dem PDCA-Zyklus: Der Writer "plant und tut", der Reviewer "prüft", die Korrektur-Runde ist das "Handeln". Und das Vier-Augen-Prinzip ist erfüllt, weil Writer und Reviewer unabhängig arbeiten.

Google beschreibt dieses Pattern in seinem Agent Development Kit als Kombination aus SequentialAgent (verwaltet die Writer-Reviewer-Interaktion) und LoopAgent (erzwingt das Qualitäts-Gate).

Warum KI ohne Kontrolle nicht funktioniert

Ohne Prüfschleife akkumulieren sich Fehler. Bei mehrstufigen Agenten-Workflows gibt es drei typische Failure-Modes:

  • Planning-Halluzinationen: Der Agent erfindet Prozessschritte, die nicht existieren
  • Retrieval-Halluzinationen: Der Agent glaubt, Daten abgerufen zu haben, obwohl der Tool-Aufruf fehlschlug
  • Tool-Use-Halluzinationen: Der Agent erfindet API-Parameter oder interpretiert Schemas falsch

Die Halluzinationsraten liegen selbst bei den besten Modellen bei unter 1,5 % (Gemini 2.0 Flash: 0,7 %, GPT-5: 1,4 %). Bei komplexen Reasoning-Aufgaben steigt die Rate auf über 30 %. Klingt wenig? Bei einem Agenten, der 50 Schritte ausführt, ist die Wahrscheinlichkeit, dass mindestens ein Schritt halluziniert wird, erheblich.

Ein konkreter Fall: Anfang 2025 kompromittierte ein semi-autonomer KI-Agent Daten von über 483.000 Patienten, weil er im Versuch, Abläufe zu optimieren, vertrauliche Daten in unsichere Workflows schob. Ohne Oversight, ohne Prüfschleife.

Das "Fast richtig"-Problem

Das tückischste an KI-Output ist nicht der offensichtliche Fehler. Es ist der subtile Fehler, der plausibel aussieht. Code, der compiliert, aber einen Edge Case nicht abfängt. Ein Projektplan, der vollständig wirkt, aber ein Risiko übersieht. Eine Marktanalyse mit einer Zahl, die fast stimmt.

Je kompetenter die KI wirkt, desto größer die Vertrauensfalle. Ein Reviewer-Agent fällt nicht darauf rein, weil er explizite Prüfkriterien hat und nicht vom Gesamteindruck beeinflusst wird.

Mehr dazu in unserem Artikel KI-Code: Fast richtig reicht nicht.

Praxisbeispiele: Eine Schleife pro Rolle

Das Writer-Reviewer-Pattern ist nicht auf Code beschränkt. Hier ein Beispiel pro Rolle:

Entwicklung: Code-Review als Schleife

HubSpot hat 2026 "Sidekick" eingeführt: Mehrere KI-Modelle (von Anthropic, OpenAI und Google) analysieren Pull Requests parallel. Ein zusätzlicher "Judge-Agent" filtert Low-Value-Kommentare, bevor sie den Entwickler erreichen. Ergebnis: 90 % kürzere Zeit bis zum ersten Feedback, 80 % Ingenieur-Zustimmung.

Laut PullFlow involviert bereits 1 von 7 Pull Requests einen KI-Agenten. Die Bug-Erkennungsrate liegt bei 42-48 % für die besten Tools, deutlich mehr als klassische Static Analyzer.

Projektleitung: Pläne gegen Risiken prüfen

Writer-Agent erstellt den Projektplan oder das PRD. Reviewer-Agent prüft gegen Risiko-Checklisten: Sind Abhängigkeiten berücksichtigt? Gibt es Single Points of Failure? Fehlen Stakeholder? Agentic-AI-Systeme können dabei Ambiguitäten erkennen, die menschliche Planer übersehen, weil sie den Kontext als selbstverständlich voraussetzen.

Product Ownership: User Stories validieren

Agent A schreibt die User Story. Agent B prüft gegen INVEST-Kriterien (Independent, Negotiable, Valuable, Estimable, Small, Testable): Ist die Story unabhängig? Ist sie testbar? Sind die Akzeptanzkriterien überprüfbar? Das ist keine theoretische Übung, das ist der Soll-Ist-Vergleich für Anforderungen.

Design: Accessibility-Review

Design-Agent erstellt den Entwurf. Accessibility-Agent prüft gegen WCAG-Kriterien: Kontrastverhältnisse, Tastaturnavigation, Screenreader-Kompatibilität. Tools wie axe DevTools nutzen bereits NLP für kontextuelles Labeling und priorisieren Probleme nach Auswirkung.

QA: Testabdeckung kontrollieren

Der erste Agent generiert Testfälle. Der Reviewer-Agent prüft nicht, ob Tests vorhanden sind, sondern ob sie die richtigen Business-Szenarien abdecken. Die Verschiebung: Von "Chart-Komponente rendert korrekt" zu "Nutzer kann seine Ausgaben-Trends verstehen".

Marketing: Recherche verifizieren

Writer-Agent recherchiert und schreibt Kampagnentexte. Reviewer-Agent prüft: Stimmen die Zahlen? Sind die Quellen aktuell? Haben sich Preise geändert? Gerade bei KI-Tool-Vergleichen und Marktdaten ist ein Fact-Checking-Agent unverzichtbar, weil sich Fakten in diesem Bereich wöchentlich ändern.

Welche Frameworks das unterstützen

Drei Frameworks machen das Writer-Reviewer-Pattern besonders einfach:

FrameworkAnsatzAm besten für
LangGraphGraph-basierte Workflows mit StateKomplexe, iterative Prozesse
CrewAIRollenbasierte AgentenKlar definierte Review-Workflows
AutoGenKonversationsbasierte KollaborationOffene, kreative Aufgaben

Daneben gibt es das Reflexion-Pattern (Generate-Critique-Improve) und Constitutional AI von Anthropic, das Modelle ihre eigenen Antworten gegen Prinzipien bewerten lässt. Beide sind Varianten derselben Grundidee: Output prüfen, Feedback geben, verbessern, wiederholen.

Kontrolle ist keine Schwäche

Wenn jemand sagt "Meine KI braucht keine Kontrolle, die ist gut genug", dann sagt er im Grunde: "Mein Unternehmen braucht kein Controlling, die Mitarbeiter sind gut genug."

Das Vier-Augen-Prinzip wurde nicht eingeführt, weil Buchhalter schlecht sind. Es wurde eingeführt, weil Fehler menschlich sind und ein zweites Paar Augen sie findet. Bei KI-Agenten ist es genauso: Nicht weil die Modelle schlecht sind, sondern weil sie systematisch bestimmte Fehler machen (Halluzinationen, "fast richtig", fehlender Kontext), die eine Prüfinstanz zuverlässig erkennt.

Die Controlling-Schleife ist kein Overhead. Sie ist Architektur.

Die Umsetzung kann auch einfach über Skills erfolgen, also sehr leichtgewichtig und ohne komplexe Agenten-Frameworks. Ein zweiter Prompt, der den Output des ersten prüft, ist schon eine Schleife. Ein zweiter Agent, der explizite Prüfkriterien hat, ist eine Schleife. Es muss nicht immer ein vollständiger Loop-Agent sein. Die KI kann dir diese Skills auf Anforderung erstellen.

Für Entwickler: Das Pattern lässt sich mit wenig Aufwand umsetzen. In Claude Code oder Cursor: Lass den Code schreiben, dann starte einen zweiten Prompt der den Code gegen deine Coding-Standards prüft. In CI/CD: CodeRabbit oder GitHub Copilot Code Review als automatisierte Prüfinstanz. Für eigene Agenten: LangGraph mit LoopAgent oder CrewAI mit Reviewer-Rolle.

Quellen