KI-Regression ist ein Softwareproblem

9 Min. Lesezeit

Der Arbeitsablauf schert sich nicht um KI-Mythen

Das Lustigste an vielen KI-Regressionen ist nicht der Fehler selbst.

Es ist das Vokabular rund um den Fehler.

Ein Agent, der letzte Woche Rechnungsmails fehlerfrei verarbeitet hat, benimmt sich plötzlich wie ein verwirrter Praktikant mit Bildschirmfoto-Tick – und erwachsene Menschen beginnen ernsthaft zu diskutieren, ob das Modell gerade eine emotionale Phase durchlebt. Diese Sprache ist menschlich verständlich. Sie ist aber auch eine kleine Katastrophe. In dem Moment, in dem die Diskussion ins Mystische abdriftet, verlässt die echte Verantwortungsfrage den Raum.

Ein KI-Workflow ist nicht mit dem falschen Fuß aufgestanden.

Es hat sich etwas in einem System geändert.

Der KI-Workshop liefert keine Software, weil der Workshop nicht das System ist und das Modell nicht die Steuerungsebene.

Ein regredierender Ablauf ist bereits ein Softwaresystem

Das ist die Denkfalle für viele Produktmanager, Betriebsleiter, Gründer und Prozessoptimierer. Sie beschreiben die Arbeit in Geschäftsbegriffen: Rechnungsverarbeitung automatisieren, manuellen Aufwand reduzieren, Werkzeuge verbinden, dem Team helfen schneller zu werden, KI-Unterstützung einführen. Alles vernünftige Formulierungen.

Dann wird der Ablauf geschäftskritisch.

Jetzt zählt das Postfach. Anhänge zählen. Dateitypen zählen. Das E-Mail-Layout zählt. Berechtigungen zählen. Hersteller-APIs zählen. Wiederholungslogik zählt. Der Unterschied zwischen dem Herunterladen eines Dokuments und einem Screenshot davon ist plötzlich immens – denn das eine füttert den nächsten Schritt in einem kontrollierten Prozess, und das andere ist eine Clownsmaske, die eine Dokumenten-Pipeline vortäuscht.

Das ist Software.

Nicht weil das Unternehmen Software verkauft.

Sondern weil das Unternehmen von Softwareverhalten abhängt, um einen Geschäftsprozess am Laufen zu halten.

Genau deshalb geraten scheinbar „nicht-technische“ KI-Initiativen immer wieder in technische Schmerzen. Die Organisation glaubt, sie hätte reine Cleverness eingekauft. Was sie tatsächlich eingekauft hat, ist eine neue betriebliche Abhängigkeit mit beweglichen Teilen, Randfällen, Integrationsannahmen und Fehlermodi.

Und diese Abhängigkeit muss sauber getrennt werden.

Nutzen Sie das LLM dort, wo echte Unschärfe herrscht: Zusammenfassen, Formulieren, unstrukturierte Eingaben klassifizieren, Optionen vorschlagen, einem Menschen helfen, eine vage Situation einzuschätzen.

Nutzen Sie das LLM nicht als Kontrollsystem für einen Schritt, der verlässlich und vorhersehbar ablaufen muss.

Wenn die Aufgabe lautet: „Anhang herunterladen, Datei speichern, Metadaten erhalten und das richtige Objekt an den nächsten Schritt übergeben“, dann ist das gewöhnliche Software. Sie sollte von deterministischen Werkzeugen und Code abgewickelt werden. Diese Verantwortung einem probabilistischen Modell zu überlassen, ist keine Innovation. Es ist ein Kategorienfehler.

„Script First“ ist keine Spezifikation

Teams reagieren auf Regressionen oft genauso wie auf den enttäuschenden ersten Entwurf eines menschlichen Assistenten: mehr Feedback geben, die Anweisungen wiederholen, eine weitere Einschränkung hinzufügen, den Skill erweitern, die Formulierung schärfen, den Agenten daran erinnern, was er hätte tun sollen.

Manchmal hilft das. Gut. Nutzen Sie es.

Aber verwechseln Sie „Wir haben den Prompt verbessert“ nicht mit „Wir haben die Kontrolle über den Workflow zurückgewonnen“.

Kontrolle entsteht durch explizite Erwartungen, die Gedächtnislücken, Personalwechsel, Anpassungen des Anbieters und die nächste begeisterte Optimierungsrunde überstehen. Wenn das gewünschte Verhalten lautet: „Anhang herunterladen, am richtigen Ort speichern, Metadaten erhalten und die Datei an den nächsten Schritt übergeben“, dann braucht dieses Verhalten mehr als eine geschliffene Anweisung. Es braucht Prüfungen.

Kann das System den Unterschied zwischen einem Download und einem Bildschirmfoto erkennen?

Kann es feststellen, dass der falsche Artefakttyp erzeugt wurde?

Kann es den Fehler sichtbar machen, bevor der nächste Schritt stillschweigend Müll akzeptiert?

Kann jemand den Ablauf nachvollziehen und sehen, an welcher Stelle das Verhalten abwich?

Kann der Workflow sicher auf einen Fallback zurückgreifen, statt mit dekorativem Unsinn fortzufahren?

Wenn die Antwort auf diese Fragen Nein lautet, ist die Regression nicht überraschend. Das einzig Überraschende ist, dass der Workflow überhaupt so lange funktioniert hat.

Das ist der Punkt, den Nicht-Entwickler immer wieder missverstehen.

Sie sehen, wie ein LLM einmal etwas Beeindruckendes leistet, und nehmen an, das Modell sei ein allgemeiner Ersatz für Software. Das ist es nicht. Es ist eine probabilistische Komponente, die innerhalb eines Systems nützlich sein kann – vorausgesetzt, das System wurde von Menschen entworfen, die verstehen, wo Wahrscheinlichkeiten akzeptabel sind und wo nicht.

Normale Software ist nicht überflüssig geworden, nur weil ein Modell seine eigenen Schätzungen mit Selbstbewusstsein vortragen kann.

Agentic Coding ist nicht ‘Mach mir X’. Derselbe Fehler zeigt sich auch dort: Man verwechselt einen nützlichen probabilistischen Kollaborateur mit einer deterministischen Ausführungsmaschine und tut dann überrascht, wenn der Workflow abdriftet.

Launengerede kaschiert meist eine Verantwortungslücke

Ja, Anbieter ändern Modelle. Ja, APIs verschieben sich. Ja, externe Abhängigkeiten regredieren gelegentlich. Nichts davon befreit die kaufende Organisation aus der Verantwortung.

Wenn Ihr Geschäftsprozess von einem Herstellermodell abhängt, dann ist die Modell-Drift des Herstellers Teil Ihres Systemdesigns. So zu tun, als wäre es anders, ist Management-Aberglaube.

Die Frage ist nicht, ob der Anbieter etwas geändert hat. Die Frage ist, was Ihre Organisation um diese Möglichkeit herum aufgebaut hat.

Hat jemand den betrieblichen Vertrag definiert?

Hat jemand festgelegt, was sich niemals stillschweigend ändern darf?

Hat jemand Monitoring um die kritischen Ergebnisse gelegt?

Hat jemand Raum geschaffen für Rollback, Fallback, manuelle Übersteuerung oder Freigabeschranken?

Hat jemand Produktabsicht, Prozesswissen und Software-Urteilsvermögen im selben Raum zusammengebracht?

Dieser letzte Punkt wiegt schwerer, als die meisten Teams zugeben wollen. Viele KI-Initiativen werden von Leuten geleitet, die den geschäftlichen Wert sehen, von Leuten beraten, die souverän über Tools sprechen können, und von irgendjemandem tief im Stack umgesetzt, von dem erwartet wird, dass er es zum Laufen bringt. Was fehlt, ist die erfahrene Kraft an der Schnittstelle, die all das in ein dauerhaftes System übersetzen kann – statt in eine Serie von Glückstreffern.

Glückstreffer sind keine Zuverlässigkeit.

Sie sind geborgte Zeit.

Die falsche Frage klingt etwa fünf Minuten lang schlau

Die falsche Frage lautet:

„Ist das Modell schlechter geworden?“

Diese Frage ist nicht nutzlos. Sie greift nur viel zu kurz.

Sie hält die Aufmerksamkeit auf der modischsten Komponente im Stack fest und ignoriert alles andere, was hätte stimmen müssen, damit sich der Workflow verlässlich verhält.

Die besseren Fragen sind unbequemer und genau deshalb nützlicher:

• Welches genaue Ergebnis wurde erwartet?
• Wo wurde diese Erwartung definiert?
• Welcher Schritt hätte das falsche Artefakt sofort erkennen können?
• Was hat sich im umliegenden System verändert?
• Welche Fehler sind hinnehmbar und welche sind geschäftliche Vorfälle?
• Wer verantwortet den Fix, wenn die Ursache die Grenzen von Prompt, Tool, Workflow und Integration überschreitet?

Das sind Softwarefragen im Gewand von Workflowfragen.

Genau darum geht es. Ein Großteil moderner KI-Einführung ist Softwarearbeit im Business-Gewand. Die Kleidung verwirrt die Einkäufer. Der Schaden im Ernstfall tut es nicht.

Und eine der Softwarefragen ist brutal einfach:

Sollte dieser Schritt überhaupt von einem LLM ausgeführt werden?

Für deterministische Steuerungsschritte lautet die Antwort oft Nein.

Nutzen Sie das Modell zur Interpretation. Nutzen Sie Software zur Ausführung.

Produktstrategie braucht weiterhin Entwicklungsdisziplin

Es gibt einen Grund, warum dieses Muster mittlerweile in Produktkreisen und nicht mehr nur bei Entwicklern auftaucht. Produkt- und Betriebsverantwortliche sind heute viel näher an den echten Reibungspunkten. Sie sehen Ineffizienzen früher. Sie erkennen wertvolle Automatisierungsziele, bevor ein technisches Team überhaupt eingeladen wird.

Das ist eine gute Nachricht.

Die schlechte Nachricht ist, dass die Nähe zum Prozess falsche Sicherheit erzeugen kann. Weil der Schmerz sichtbar ist, fühlt sich das System verständlich an. Weil KI schnell eine beeindruckende Demo liefern kann, fühlt sich die Umsetzung leicht an. Weil die Beteiligten klug und engagiert sind, wirkt die fehlende Disziplin wie ein Detail, das man später nachholen kann.

Dieses „Später“ ist der Ort, an dem Regressionen entstehen.

Ein guter Produktstratege erkennt, wo Automatisierung hilft. Ein guter Entwickler sorgt dafür, dass ein System den Kontakt mit der Realität überlebt. Der Markt tut weiterhin so, als ließen sich diese Aufgaben trennen, sobald die KI-Werkzeuge nur gut genug sind.

Das ist Unfug.

Je kritischer der Ablauf wird, desto dringender braucht das Unternehmen beide Perspektiven – verbunden durch jemanden, der die Nahtstelle beherrscht.

An dieser Nahtstelle scheitern die meisten KI-Projekte still und leise. Produktleute sehen die Reibung. Entwickler sehen die Fehlermodi. Nur Nicht-Entwickler neigen zu dem Glauben, das Modell selbst mache gewöhnliches Softwaredesign überflüssig. Das tut es nicht. Es sorgt nur dafür, dass dieses Missverständnis schneller viel teurer wird.

Was ernsthafte Teams stattdessen tun

Sie hören auf zu fragen, ob das Modell launisch ist, und fangen an, für Drift zu entwerfen.

Sie definieren kritische Ergebnisse in konkreten Begriffen.

Sie bauen kleine, unnachgiebige Prüfungen um die Schritte, auf die es ankommt.

Sie verlagern deterministisches Verhalten aus dem Modell in gewöhnliche Software, wo immer es geht.

Sie protokollieren genug, um Fehler ohne Folklore nachstellen zu können.

Sie entscheiden, welches Verhalten in Prompts gehört und welches in Code oder Werkzeuge.

Sie behandeln Änderungen des Anbieters als normales Betriebsrisiko, nicht als persönliche Beleidigung durch das Universum.

Sie geben jemandem die Autorität zu sagen: „Nein, dieser Ablauf ist noch nicht stabil genug, um ihm Geld, Kunden oder Compliance anzuvertrauen.“

Und sie hören auf, Probleme bei der KI-Bereitstellung unter Motivationskategorien wie Einführung, Befähigung oder Experimentieren abzuhegen, sobald der Workflow in der betrieblichen Realität angekommen ist.

Dieser Schritt kann sich nach der Begeisterung der ersten funktionierenden Testläufe ernüchternd nüchtern anfühlen.

Gut so.

Nüchternheit ist meistens genau das, was eine beeindruckende Demo von einem System unterscheidet, das die Finanzabteilung überlebt.