Die meisten Teams, die heute AI-Systeme ausliefern, folgen einem Muster: bauen, deployen, justieren, erneut deployen. Das fühlt sich wie Iteration an. Das ist es nicht.
Sie nennen es Agile. Sie nennen es kontinuierliche Verbesserung. Aber ohne eine ehrliche Check-Phase — eine echte Überprüfung, was im System tatsächlich passiert — ist Iteration etwas anderes: Redeployment mit besseren Release Notes.
Das Problem liegt nicht daran, dass AI-Modelle schwach sind. Moderne Modelle sind bemerkenswert leistungsfähig. Das Problem ist, dass die Feedback-Schleife um sie herum kaputt ist. Und eine kaputte Feedback-Schleife verlangsamt das Lernen nicht — sie stoppt es komplett.
Ohne Check: Blindflug
Der Fehler liegt hier: Accuracy ist eine Modell-Metrik. Nützlichkeit ist eine System-Metrik. Das ist nicht dasselbe.
Ein Modell kann 94% Accuracy melden, während Nutzer das System komplett umgehen. Der Classifier funktioniert. Der Workflow funktioniert nicht. Aber wenn man nur das Modell misst, wird man das nicht sehen, bis drei Monate Telemetrie es unmöglich machen zu ignorieren — bis dahin ist der Workaround bereits in jedermanns Muscle Memory eingebettet.
Hier lebt die Check-Phase. Nicht als Ritual. Als Disziplin.
Der Deming-Zyklus — Plan, Do, Check, Act — wurde für die Fertigung entwickelt. Dasselbe Prinzip gilt für AI-Systeme, aber die Check-Phase muss für etwas Konto leisten, das die Fertigung kaum kennt: menschliche Entscheidungen an den Reibungspunkten.
Der vierteilige Kreislauf. Die Check-Phase ist dort, wo Lernen geschieht — oder eben nicht.
Wenn ein Mensch in ein AI-System eingreifen muss, ist dieser Eingriff kein Fehler. Er ist ein Signal. Er sagt dir, dass die Systemarchitektur Annahmen hatte, die die echte Welt verletzt hat. Ein Team, das diese Eingriffe kontrolliert, lernt. Ein Team, das das nicht tut, sieht sie einfach als Ausnahmen, die man im nächsten Sprint bearbeitet.
Die Kosten des Check-Ausfalls
Die meisten AI-Teams überspringen Check nicht, weil es schwer ist. Sie überspringen es, weil Kontrollieren Disziplin erfordert. Es bedeutet, über deine Dashboard-Metriken hinauszuschauen. Es heißt:
- Beobachten, wo Nutzer dem System nicht trauen
- Zählen, wie oft Menschen eine Entscheidung überschrieben haben
- Nachverfolgung, welche Workarounds entstanden sind, bevor irgendein Alert feuerte
- Messen der Reibung zwischen dem, was das System empfahl, und dem, was Leute tatsächlich taten
Nichts davon passt sauber in eine CI/CD-Pipeline. Es erfordert Beobachtung, Gespräche und Anpassungszyklen, die nicht in Sprint-Rhythmen passen.
Aber hier ist, was passiert, wenn du das überspringst: deine Deployment-Geschwindigkeit steigt, und deine Lern-Geschwindigkeit fällt auf null. Du änderst das System, aber das System verbessert sich tatsächlich nicht — du verschiebst den Fehler nur in eine andere Form.
Ein Team, mit dem ich arbeitete, lieferte einen AI-Agent aus, der „nach den Metriken funktioniert“. Nutzer ignorierten seine Empfehlungen 60% der Zeit. Das Team dachte, es wäre ein Trainings-Problem. Sie deployte neu mit einem anderen Prompt. Immer noch ignoriert. Ein anderer Prompt. Ignoriert. Noch einer. Vier Monate Iteration. Null Lernen.
Warum? Weil niemand überprüft hatte, warum Nutzer ihm nicht vertrauten. Ein einziger Nachmittag, Nutzer bei ihrer Arbeit zu beobachten, hätte gezeigt: Das System war zu 94% richtig, aber die 6%, wo es falsch war, kosteten etwas. Nutzer hatten gelernt, es jedes Mal zu verifizieren, was bedeutete, der Empfehlung zu folgen, sparte ihnen null Zeit. Das System war nicht schwach — der Use Case war es. Diese Diagnose entsteht aber nur mit Check.
Warum PDCA in AI immer noch zählt
PDCA ist fast ein Jahrhundert alt. Deming lehrte es japanischen Herstellern in den 1950ern. Es ist nicht neu. Es ist nicht cool. Es hat keine API.
Aber es ist auch nicht überholt. Was PDCA mächtig macht, ist, dass es den Akt, ein System zu ändern, von dem Akt trennt, von dieser Änderung zu lernen. Plan ist Hypothese. Do ist Experiment. Check ist Beobachtung. Act ist Anpassung. Überspringen Sie eines, und der Zyklus wird zu Rauschen.
In AI zählt das mehr, nicht weniger.
AI-Systeme sitzen an der Schnittstelle zwischen Machine Learning und menschlichem Workflow. Sie sind nicht reine Algorithmen — sie sind sozio-technische Systeme. Eine Änderung, die das Modell verbessert, kann das System verschlechtern. Ein Prompt, der Accuracy erhöht, kann Nutzer-Reibung erhöhen. Du kannst diese Trade-offs ohne Kontrolle des ganzen Systems nicht sehen, nicht nur der Komponente.
Und „Checken“ heißt nicht, eine Test Suite laufen zu lassen. Es bedeutet zu fragen: Hat sich das Systemverhalten in die Richtung geändert, die wir vorhergesagt haben? Können Menschen immer noch eingreifen, wenn nötig? Ist ein Workaround entstanden, den wir nicht erwartet haben? Lernen wir, oder deployen wir einfach neu?
Das echte Problem: Feedback-Schleifen, die langsamer sind als Release-Zyklen
Hier ist die Diagnose: Wenn deine Feedback-Schleife langsamer ist als dein Release-Zyklus, hast du keine Feedback-Schleife. Du hast ein Spray-and-Pray-System.
Ein Sprint ist zwei Wochen. Eine Feedback-Schleife sollte mindestens so schnell sein. Wenn du alle zwei Wochen deployst, aber erst drei Monate später überprüfst, was passiert ist, gibt es keine Verbindung zwischen Änderung und Beobachtung. Das System hat sich 20 Mal geändert. Welche Änderung verursachte die Drift? Du wirst es nie wissen.
Das ist, warum PDCA überlebt: Es erzwingt Synchronisation. Plan und Do können schnell sein. Check und Act müssen Schritt halten, oder Lernen kollabiert.
Die meisten Teams beschleunigen Plan und Do durch Automation. CI/CD ist wunderbar dafür. Aber dann finden Check und Act in einer quarterly Retrospektive statt (falls überhaupt), und der Kreis bricht. Das System lernt nicht. Es häuft nur Änderungen an, die sich zum damaligen Zeitpunkt richtig anfühlten.
Wie man tatsächlich checkt
Das Überprüfen eines AI-Systems erfordert mehr als Metrics Dashboards. Es erfordert:
- Observability in menschliche Reibung. Wo greifen Menschen ein? Wo zögern sie? Wo wechseln sie zu einem manuellen Workaround? Das sollten First-Class-Signale in deinem System sein, nicht Randgedanken.
- Trennung von Signal-Schichten. Die Modell-Ausgabe ist ein Signal. Die menschliche Entscheidung ist ein anderes. Das System-Outcome ist ein drittes. Wenn du nur das Modell misst, bist du blind für den Rest.
- Geschlossene Schleifen für Wiederholung. Wenn derselbe Fehler sich wiederholt, ist das kein Pech — es ist ein System-Signal. Wenn derselbe Eingriff fünfmal pro Woche passiert, sagt dir das System etwas über sein Design, nicht über Edge Cases.
- Geschwindigkeit des Feedbacks. Wenn deine Feedback-Schleife monatlich ist, ist dein Lern-Zyklus monatlich. Wenn Teams nur jeden Monat auf Feedback reagieren können, behandle Entscheidungen als strategisch, nicht taktisch — denn alles zu ändern wird länger dauern als es zu bauen.
Das ist, wo sich AI Engineering von typischem Model Tuning unterscheidet. Model Tuning optimiert eine Komponente. Systemkontrolle optimiert die ganze Schleife — und offenbart, ob das Problem überhaupt im Modell liegt.
Die unbequeme Wahrheit
Du kannst AI schnell deployen. Du kannst Modelle optimieren. Du kannst kontinuierlich ausliefern. Aber wenn die Check-Phase fehlt, zählt nichts davon als Verbesserung. Es ist nur schnelleres Scheitern in neuen Formen.
Der Deming-Zyklus ist nicht alte Weisheit, die sich relevant anfühlt. Es ist alte Weisheit, die relevant ist — weil es etwas anspricht, das sich nicht ändert: Der Unterschied zwischen Aktivität und Lernen.
Redeployment ist Aktivität. Checken ist Lernen. Ohne Checken wählst du das erste über das zweite.
Und wenn dieser Zyklus zusammenbricht, verbessert sich das System nicht — es scheitert nur in neuen Wegen.
