KI-Agent oder Workflow: Wann welches System passt

„KI-Agent“ steht inzwischen auf Angeboten, die technisch ein Formular mit einem Sprachmodell dahinter sind – und auf Systemen, die eigenständig in produktive Datenbanken schreiben. Der Begriff allein sagt nichts darüber aus, was ein System tun darf.

Eine einzige Frage trägt die gesamte Unterscheidung: Wer legt fest, welcher Schritt als Nächstes ausgeführt wird – ein Entwickler beim Bau oder das Modell zur Laufzeit?

Aus dieser Frage folgt alles Weitere. Sie entscheidet, ob sich ein Ergebnis vollständig testen lässt, ob ein Fehler reproduzierbar ist, wer für eine Fehlentscheidung einsteht und an welcher Stelle ein Mensch zustimmen muss. Sie ist auch die Frage, die im ersten Gespräch geklärt gehört, nicht die letzte.

Die folgende Übersicht fasst zusammen, was aus dieser einen Frage folgt. Jede Zeile wird weiter unten begründet:

	Workflow	KI-Agent
Wer wählt den nächsten Schritt	ein Entwickler beim Bau	das Modell zur Laufzeit
Zahl möglicher Abläufe	endlich und vorher bekannt	vorher nicht bekannt
Prüfung vor dem Start	Regressionstest je Zweig	Evaluation über eine feste Fallmenge
„Der Test ist grün“ heißt	bleibt grün, solange der Code gleich bleibt	bei diesen Fällen hat es funktioniert
Ergebnis der Prüfung	Ja oder Nein	eine Erfolgsquote gegen eine vorher gesetzte Schwelle
Erneut zu prüfen bei	Änderung am Code	Wechsel von Modell, Modellversion, Prompt oder Werkzeugsatz
Verhalten im Fehlerfall	der Fehler bleibt, wo er entsteht	der Fehler wird in den Folgeschritten als Tatsache weiterverwendet
Wichtigste Entwurfsgröße	Vollständigkeit der Pfade	Länge der Kette
Protokollierung	Betriebsdetail	Voraussetzung, um einen Fehler überhaupt rekonstruieren zu können
Freigabe durch einen Menschen	oft entbehrlich	vor jeder nicht umkehrbaren Aktion

Die Tabelle ist keine Empfehlung für eine der beiden Spalten. Sie zeigt, welche Pflichten mit welcher Bauform mitkommen — und die rechte Spalte ist deutlich länger.

Ein Workflow folgt einem Pfad, den jemand vorher aufgeschrieben hat

Die brauchbarste Abgrenzung stammt nicht aus der Werbung, sondern aus der technischen Literatur. Anthropic unterscheidet in seiner Entwicklerdokumentation zwei Bauformen: Workflows sind Systeme, „in denen Sprachmodelle und Werkzeuge über vorgegebene Code-Pfade orchestriert werden“. Agenten sind Systeme, „in denen Sprachmodelle ihren eigenen Ablauf und ihre Werkzeugnutzung dynamisch steuern“.

Der Unterschied liegt also nicht darin, ob ein Sprachmodell beteiligt ist. Er liegt darin, wo die Ablaufsteuerung liegt.

Ein Workflow für den Rechnungseingang sieht zum Beispiel so aus:

Ein PDF trifft im Posteingang ein.
Eine Texterkennung liest den Inhalt aus.
Ein Modellschritt extrahiert Lieferant, Rechnungsnummer, Betrag und Datum in ein festes Datenformat.
Eine Regel prüft, ob eine passende Bestellung existiert und der Betrag innerhalb der Toleranz liegt.
Bei Übereinstimmung wird der Vorgang angelegt, sonst landet er in einer Prüfliste.

Dieser Pfad ist für jede Rechnung derselbe. Er enthält ein Sprachmodell an genau einer Stelle – und bleibt trotzdem ein Workflow, weil die Reihenfolge der Schritte im Code steht.

Ein Agent bekäme stattdessen die Aufgabe „Verarbeite diese Rechnung“, dazu Kontext und eine Auswahl an Werkzeugen: Posteingang lesen, Bestellsystem abfragen, Vorgang anlegen, Rückfrage senden. Welches Werkzeug er in welcher Reihenfolge und wie oft verwendet, entscheidet er selbst.

Der Modellschritt im Workflow ist der Fall, der am häufigsten gemeint ist

Wenn ein Unternehmen sagt „das müsste doch ein KI-Agent können“, beschreibt es meistens diesen Zwischenfall: einen ansonsten festen Ablauf, der an ein oder zwei Stellen an unstrukturierten Eingaben scheitert. Jemand muss lesen, worum es geht, bevor die Regel greifen kann.

Genau dafür ist ein begrenzter Modellschritt gedacht. Er bekommt einen klar umrissenen Auftrag – einordnen, extrahieren, zusammenfassen, entwerfen –, liefert ein festgelegtes Ausgabeformat zurück, das technisch geprüft wird, und gibt bei unklaren Fällen an einen Menschen ab. Die Ablaufsteuerung bleibt im Code.

Diese Bauform ist in fast jeder Hinsicht angenehmer: Sie ist günstiger im Betrieb, schneller, sie lässt sich testen, und wenn das Modell einmal Unsinn liefert, begrenzt die nachgelagerte Prüfung den Schaden auf genau einen Feldwert. Wer sie übergeht und direkt einen Agenten baut, kauft sich Freiheitsgrade, die er für die Aufgabe nicht braucht.

Testbarkeit ist der Punkt, an dem sich die beiden Bauformen wirklich trennen

Ein Workflow hat eine endliche Zahl von Pfaden. Man kann jeden Zweig mit Testfällen belegen, und ein bestandener Test bleibt bestanden, solange sich der Code nicht ändert. Das ist der übliche Regressionstest: Vorher grün, nachher rot, also hat die letzte Änderung etwas kaputt gemacht.

Bei einem Agenten ist die Menge der möglichen Abläufe vorher nicht bekannt. Ein Testlauf prüft daher keinen Pfad, sondern eine Stichprobe aus einer Verteilung von Verhalten. „Der Test ist grün“ bedeutet dann: Bei diesen fünfzig Fällen hat es funktioniert. Es bedeutet nicht: Es funktioniert.

Praktisch heißt das, dass an die Stelle des Tests eine Evaluation tritt:

eine feste Menge realistischer Fälle, einschließlich unvollständiger, widersprüchlicher und böswilliger Eingaben
mehrere Durchläufe pro Fall, weil derselbe Fall unterschiedliche Abläufe erzeugen kann
eine Erfolgsquote als Kennzahl statt eines Ja/Nein-Ergebnisses
eine Schwelle, die vor dem Lauf festgelegt wurde, nicht danach
eine Wiederholung bei jedem Wechsel von Modell, Modellversion, Prompt oder Werkzeugsatz

Der letzte Punkt wird regelmäßig unterschätzt. Ein Modellwechsel beim Anbieter ist kein Deployment im eigenen Haus, verändert aber das Verhalten des Systems. Wer keine feste Evaluationsmenge hat, merkt eine Verschlechterung erst an den Beschwerden.

Aus der Nicht-Reproduzierbarkeit folgt außerdem etwas Unbequemes für den Betrieb: Ohne vollständiges Protokoll jedes Werkzeugaufrufs lässt sich ein gemeldeter Fehler oft nicht rekonstruieren. Protokollierung ist bei einem Agenten kein Betriebsdetail, das man später ergänzt. Sie ist die Voraussetzung dafür, überhaupt Fehler suchen zu können.

Fehler summieren sich nicht, sie multiplizieren sich

Das folgende Rechenbeispiel ist reine Arithmetik und keine Messung an einem konkreten System. Es erklärt aber, warum die Schrittzahl die wichtigste Entwurfsgröße eines Agenten ist.

Wenn ein einzelner Schritt mit 95 Prozent Wahrscheinlichkeit korrekt ist und zehn Schritte nacheinander alle korrekt sein müssen, liegt die Wahrscheinlichkeit eines fehlerfreien Durchlaufs bei 0,95 hoch 10, also rund 60 Prozent. Bei 99 Prozent pro Schritt sind es rund 90 Prozent. Die Verlässlichkeit eines einzelnen Schritts sagt für sich genommen wenig aus; entscheidend ist die Länge der Kette.

Dazu kommt ein zweiter Effekt, den Anthropic in derselben Dokumentation als „compounding errors“ beschreibt: Ein Fehler im dritten Schritt verschwindet nicht, sondern wird in den Schritten vier bis zehn als Tatsache weiterverwendet. Der Agent baut auf seinem eigenen falschen Zwischenergebnis auf und liefert am Ende ein in sich schlüssiges Resultat. Das ist der unangenehme Teil: Das Ergebnis sieht nicht falsch aus.

Wirksam dagegen sind nur wenige Dinge, und alle betreffen den Entwurf, nicht das Modell:

kurze Ketten statt langer Aufträge
unabhängige Prüfschritte zwischendurch, die ein Zwischenergebnis gegen eine verlässliche Quelle abgleichen
eine harte Obergrenze für Schritte und Werkzeugaufrufe, nach deren Erreichen abgebrochen wird
ein definiertes Verhalten bei Unsicherheit, das „abbrechen und übergeben“ lautet und nicht „weitermachen“

Ein Agent erweitert seinen Auftrag, ohne dass es jemand entschieden hat

Der Nebeneffekt der freien Werkzeugwahl ist, dass niemand den Weg vorgibt. Der Agent nimmt den, der aus Sicht des Modells am kürzesten zum Ziel führt. Das erzeugt drei Muster, die es bei einem Workflow nicht gibt.

Der Werkzeugkasten wächst. Ein Agent startet mit drei Werkzeugen und hat nach einem halben Jahr acht, weil bei jeder Erweiterung die Frage „kann er das nicht auch gleich?“ mit Ja beantwortet wurde. Mit den Werkzeugen wachsen die Berechtigungen, und zurückgenommen wird selten etwas.

Lesen wird zu Schreiben. Eine Aufgabe, die als „nachschlagen und zusammenfassen“ gedacht war, wird gelöst, indem der Agent einen Datensatz anlegt – weil das Werkzeug vorhanden war und der Weg plausibel schien. Verboten hatte es niemand ausdrücklich.

Eingaben enthalten Anweisungen. Ein Agent, der eingehende E-Mails, PDFs oder Webseiten verarbeitet, liest Text, den Dritte geschrieben haben. Steht darin eine Anweisung, kann das Modell sie als Auftrag behandeln. Ein deterministischer Workflow ignoriert solchen Text, weil er ihn nur als Daten kennt.

Der Schutz dagegen liegt nicht im Prompt. Ein Prompt ist eine Bitte an ein statistisches System; eine Berechtigung ist eine Zusicherung. Praktisch bedeutet das: eine eigene technische Identität für den Agenten mit eigenen, minimalen Rechten statt eines geliehenen Administratorkontos, Schreibzugriffe ausschließlich über eng gefasste Werkzeuge mit fest verdrahteten Grenzen – etwa „Vorgang anlegen bis 500 Euro“ – statt über generischen Datenbankzugriff, und ein regelmäßiger Blick darauf, welche Werkzeuge der Agent inzwischen hat und welche davon noch gebraucht werden.

Wer den Pfad wählt, muss ihn auch verantworten können

Bei einem Workflow ist jede ausgeführte Aktion auf eine Entscheidung im Code zurückführbar. Ein Fehler ist ein Bug: benennbar, reproduzierbar, korrigierbar, mit Datum und Verursacher. Diese Rückverfolgbarkeit ist keine Formalität, sondern die Grundlage jeder Aufarbeitung gegenüber Kunden, Versicherern oder Prüfern.

Bei einem Agenten kann eine Aktion ausgeführt worden sein, die niemand vorgesehen und niemand ausdrücklich ausgeschlossen hat. Der Nachweis, dass sie nicht erlaubt war, muss dann aus der Konfiguration und dem Protokoll kommen – aus Berechtigungen, Werkzeuggrenzen, Freigabepunkten und einer lückenlosen Aufzeichnung dessen, was tatsächlich passiert ist. Aus der Anweisung im Prompt kommt er nicht.

Das verschiebt den Aufwand: Was beim Workflow in Tests steckt, steckt beim Agenten in Berechtigungskonzept, Protokollierung und Freigabelogik. Wer diesen Aufwand nicht einplant, hat kein günstigeres System gebaut, sondern nur ein schlechter dokumentiertes.

TakFlow setzt diese technischen Maßnahmen um und dokumentiert sie. Die rechtliche Bewertung eines konkreten Einsatzes – Haftung, Vertragsgestaltung, datenschutzrechtliche Einordnung – gehört zur Rechtsberatung des Unternehmens und wird hier nicht ersetzt.

Eine Freigabe ist ein Bauteil, kein guter Vorsatz

„Human in the Loop“ steht in vielen Angeboten, meint aber oft nur, dass irgendwo ein Mensch beteiligt ist. Eine Freigabe, die tatsächlich schützt, hat konkrete Eigenschaften:

Sie sitzt vor der ersten nicht umkehrbaren Aktion, nicht am Ende des Ablaufs. Nach dem Versand einer E-Mail ist eine Freigabe eine Benachrichtigung.
Sie zeigt die Aktion im Wortlaut, nicht als Zusammenfassung: Empfänger, Betrag, Text, geänderte Felder – genau das, was ausgeführt wird.
Sie zeigt, worauf die Entscheidung beruht: verwendete Quellen und Werkzeugaufrufe, mindestens verlinkt. Ohne diese Angaben bestätigt der Mensch ein Ergebnis, das er nicht prüfen kann.
Der Standardzustand ist „nicht ausgeführt“. Läuft eine Frist ab, passiert nichts. Ein System, das nach 24 Stunden ohne Antwort trotzdem handelt, hat keine Freigabe, sondern eine Verzögerung.
Ablehnen ist so einfach wie Zustimmen und verlangt ein Feld für den Grund. Ohne dieses Feld lernt niemand etwas aus den Ablehnungen.
Sie wird selten genug ausgelöst, dass sie gelesen wird. Eine Freigabe, die vierzigmal am Tag erscheint, wird zur Klickstrecke. Dann ist entweder die Schwelle falsch gesetzt oder der Prozess noch nicht reif für den produktiven Einsatz.
Es gibt einen Stopp, der ohne Entwickler funktioniert – ein Schalter, der den Agenten anhält, bedienbar von der Person, die den Prozess verantwortet.
Freigaben werden protokolliert: wer wann was freigegeben oder abgelehnt hat.

Der Einwand, eine Freigabe mache die Automatisierung zunichte, geht am Punkt vorbei. Wenn ein System die gesamte Vorarbeit erledigt – Daten aus fünf Quellen zusammenführen, prüfen, entwerfen, aufbereiten – und der Mitarbeiter statt zwanzig Einzelschritten in mehreren Systemen eine Zusammenfassung mit einer begrenzten Entscheidung vor sich hat, ist der Aufwand nicht um null Prozent gesunken. Er ist nur nicht auf null gesunken. Das ist bei jeder Aufgabe, deren Fehler Geld kosten, die richtige Zielgröße.

Die Faustregel: Lässt sich der Pfad aufschreiben, gehört er in Code

Vier Schritte, die sich in einem Termin durchführen lassen:

Schreiben Sie den Ablauf als nummerierte Liste auf. Gelingt das für die überwiegende Mehrheit der Fälle vollständig, bauen Sie einen deterministischen Workflow. Kein Agent.
Scheitert die Liste nur an einer Stelle – „hier muss jemand lesen, worum es geht“ –, setzen Sie an genau dieser Stelle einen begrenzten Modellschritt ein. Die Steuerung bleibt im Code.
Scheitert sie daran, dass die Reihenfolge der Schritte vom jeweiligen Zwischenergebnis abhängt und die Zahl der Varianten nicht überschaubar ist, kommt ein Agent in Frage – mit engem Werkzeugsatz, harter Schrittgrenze und Freigabe vor jeder nicht umkehrbaren Aktion.
Ist ein einzelner Fehldurchlauf teuer, rechtlich heikel oder nicht rückgängig zu machen und lässt sich das nicht durch eine Freigabe abfangen, automatisieren Sie diese Entscheidung nicht. Die Vorbereitung der Entscheidung dürfen Sie automatisieren.

Die zweite Frage nach der Bauform lautet immer: Wie viele Schritte darf das System ohne Zwischenprüfung ausführen? Je größer diese Zahl, desto stärker wirkt die Fehlerkette – und desto weniger sagt eine gute Demonstration über den Betrieb aus.

Ein ehrlicher Hinweis in eigener Sache: Die meisten Aufgaben, die Unternehmen als Agentenfall beschreiben, lassen sich als Workflow mit ein oder zwei Modellschritten lösen. Das ist günstiger, schneller und prüfbar. Wenn Ihr Fall so aussieht, brauchen Sie keinen Agenten – und für die Umsetzung reicht eine saubere Prozessautomatisierung mit klar abgegrenzten KI-Schritten oder, wenn die Logik tief in Ihrem eigenen Fachbereich liegt, eine individuell entwickelte Anwendung.

Der EU AI Act betrifft die Freigabe, nicht nur das Modell

Für Unternehmen in der EU kommt zur technischen eine organisatorische Seite hinzu. Der zeitliche Rahmen (Stand März 2026):

Seit dem 2. Februar 2025 gelten die Verbote bestimmter KI-Praktiken sowie die Pflicht zur KI-Kompetenz nach Artikel 4.
Seit dem 2. August 2025 gelten die Governance-Regeln und die Pflichten für Anbieter von Modellen mit allgemeinem Verwendungszweck.
Zum 2. August 2026 wird der AI Act allgemein anwendbar. Dazu werden die Transparenzpflichten nach Artikel 50 gehören, die unter anderem die Kennzeichnung KI-generierter Inhalte in maschinenlesbarer Form und die Offenlegung gegenüber Personen betreffen, die mit einem KI-System interagieren.

Nicht jeder interne Agent ist deswegen ein Hochrisikosystem – die Einstufung hängt vom konkreten Anwendungsbereich ab und gehört bei sensiblen Anwendungen fachkundig geprüft. Unabhängig davon lohnt sich die Vorarbeit, weil sie ohnehin gebraucht wird: ein Verzeichnis der eingesetzten KI-Systeme mit Zweck, verantwortlicher Person, verarbeiteten Daten und beteiligtem Anbieter, dazu die Frage, an welchen Stellen Menschen über den KI-Einsatz informiert werden. Wer die im vorigen Abschnitt beschriebenen Protokolle und Freigaben ohnehin baut, hat den größeren Teil dieser Dokumentation bereits.

Update vom 3. August 2026: Die Transparenzpflichten nach Artikel 50 gelten seit dem 2. August 2026; die Europäische Kommission hat an diesem Tag mit der Durchsetzung der allgemeinen AI-Act-Regeln und der Transparenzanforderungen begonnen. Der finale „Code of Practice on Transparency of AI-generated Content“ wurde am 10. Juni 2026 veröffentlicht; bis Ende Juli 2026 hatten ihn rund 190 Organisationen unterzeichnet. Der sogenannte AI Omnibus ist am 27. Juli 2026 in Kraft getreten und hat die Pflichten für Hochrisiko-Systeme nach Anhang III auf den 2. Dezember 2027 verschoben. Artikel 50 war von dieser Verschiebung nicht betroffen.

Der beste Agent ist der, den Sie nicht gebaut haben

Ein Agent ist kein besserer Workflow. Er ist eine andere Bauform mit einem anderen Kostenprofil: mehr Anpassungsfähigkeit gegen weniger Vorhersagbarkeit, weniger Testbarkeit und mehr Aufwand für Berechtigungen, Protokolle und Freigaben.

Diesen Tausch einzugehen lohnt sich, wenn die Aufgabe ihn erzwingt – wenn der nächste sinnvolle Schritt wirklich vom Inhalt abhängt und sich die Varianten nicht aufzählen lassen. Er lohnt sich nicht, weil „Agent“ moderner klingt als „Workflow“.

Handlungsaufruf

Ob Ihr Fall ein Workflow, ein Workflow mit Modellschritt oder tatsächlich ein Agent ist, entscheidet sich am Ablauf – nicht an der Technologie. Wir nehmen den Prozess mit den Personen auf, die ihn täglich ausführen, schreiben ihn als Schrittfolge auf und sagen Ihnen, an welchen Stellen ein Modell nötig ist und an welchen nicht.

Anwendungsfall besprechen

Weiterführend: Automatisierung und KI-Lösungen von TakFlow · Drei KI-Agenten-Anwendungsfälle und ihre Grenzen · Warum ein schlechter Prozess durch KI nur schneller schlecht wird

KI-Agent oder Workflow: Der Unterschied liegt darin, wer den nächsten Schritt auswählt