KI-Agenten: 3 Anwendungsfälle und ihre Grenzen

Die begriffliche Frage ist beantwortbar: Ein Workflow folgt festgelegten Regeln, ein Agent bekommt ein Ziel, Kontext und eine Auswahl an Werkzeugen und entscheidet selbst über die Reihenfolge. Wer diese Unterscheidung noch braucht, findet sie in KI-Agenten und Workflows im Vergleich.

Die schwierigere Frage kommt danach. Wofür genau setzt man so etwas ein? Und an welcher Stelle hört der Agent auf und übernimmt ein Mensch?

Dieser Beitrag beschreibt drei Zuschnitte, die sich in kleineren und mittleren Unternehmen regelmäßig anbieten. Es sind Muster, keine Fallstudien: keine Kundennamen, keine Branchen, keine Kennzahlen. Jeder Zuschnitt ist so beschrieben, dass er sich gegen den eigenen Betrieb prüfen lässt.

Ein Anwendungsfall ist erst dann einer, wenn fünf Angaben feststehen

Ein Satz wie „Wir wollen einen Agenten für den Posteingang” beschreibt noch keinen Anwendungsfall. Beschreibbar wird er über fünf Angaben, die in jedem der folgenden Beispiele beantwortet sind:

Aufgabe – was der Agent tut, in einem Satz und ohne „und”.
Systemgrenze – welche Systeme er liest und in welche er schreibt.
Freigabepunkt – an welcher Stelle ein Mensch bestätigt, bevor etwas wirksam wird.
Fehlererkennung – woran auffällt, dass er falsch gearbeitet hat, und zwar bevor jemand sich beschwert.
Ausschluss – was er ausdrücklich nicht tut, auch wenn er es technisch könnte.

Fehlt Punkt 3 oder Punkt 4, ist das Vorhaben nicht klein genug beschrieben. Fehlt Punkt 5, wächst der Agent im Betrieb in Aufgaben hinein, für die ihn niemand geprüft hat.

Fall 1: Aus eingehenden Dokumenten werden geprüfte Datensätze, keine gebuchten Vorgänge

Aufgabe. Ein Postfach nimmt Rechnungen, Lieferscheine, Bestellbestätigungen und Auftragsbestätigungen entgegen – als PDF, als Foto, als eingescannte Anlage, gelegentlich als Text direkt in der Mail. Der Agent bestimmt den Dokumenttyp, liest die relevanten Felder aus, ordnet das Dokument einem vorhandenen Vorgang oder Lieferanten zu und legt einen Entwurf im Zielsystem an.

Systemgrenze. Lesend: das Postfach, ein Ablageverzeichnis, die Stammdaten aus dem Warenwirtschafts- oder Buchhaltungssystem. Schreibend: ausschließlich ein Entwurfsbereich – ein Vorgang im Status „zu prüfen”, nicht ein gebuchter Beleg. Der Agent bekommt kein Konto mit Buchungsrecht. Diese Trennung ist der eigentliche Entwurf des Falls, nicht ein nachgelagertes Sicherheitsdetail.

Freigabepunkt. Ein Mensch sieht Dokument und extrahierte Felder nebeneinander und bestätigt. Sinnvoll ist eine Zweiteilung: Dokumente, bei denen jedes Pflichtfeld gefunden wurde, die Rechnungssumme zur Positionssumme passt und der Lieferant eindeutig zugeordnet ist, gehen als Sammelliste zur Sichtprüfung. Alles andere geht einzeln in die Prüfung, mit der Angabe, welches Feld unsicher war.

Fehlererkennung. Verlassen Sie sich hier nicht auf Stichproben. Belastbar sind drei Kontrollen: rechnerische Prüfungen, die unabhängig vom Modell laufen (Summen, Datumsplausibilität, gültige Steuersätze, Format der Bankverbindung); ein Abgleich gegen Stammdaten, bei dem eine unbekannte Bankverbindung eines bekannten Lieferanten immer in die manuelle Prüfung geht; und eine Quote, die Sie regelmäßig ansehen, nämlich der Anteil der Entwürfe, die bei der Freigabe korrigiert werden mussten. Steigt diese Quote, hat sich etwas verändert – ein Dokumentformat, ein Modell, eine Vorlage beim Absender.

Ausschluss. Der Agent bucht nicht, zahlt nicht, ändert keine Stammdaten und legt keine neuen Lieferanten an. Er antwortet auch nicht auf die eingegangene E-Mail. Die Änderung einer Bankverbindung durch eine eingehende Nachricht ist ein klassisches Betrugsmuster; ein Automatismus, der das erledigt, ist kein Fortschritt.

Fall 2: Eingehende Anfragen werden eingeordnet, aber nicht beantwortet

Aufgabe. Anfragen kommen über Formular, Telefonnotiz und mehrere Postfächer. Der Agent bestimmt Thema, Dringlichkeit und Zuständigkeit, erkennt fehlende Angaben, hängt die drei ähnlichsten früheren Vorgänge an und legt ein Ticket mit einer kurzen Zusammenfassung an.

Systemgrenze. Lesend: Postfächer, Formulareingänge, die Historie des Ticketsystems, eine freigegebene Wissensbasis. Schreibend: das Ticketsystem – Anlage, Kategorie, Zuweisung, interne Notiz. Ausdrücklich nicht: der Versand an den Absender.

Freigabepunkt. Hier liegt die Freigabe nicht vor der Zuweisung, sondern vor jeder Kommunikation nach außen. Eine falsch einsortierte Anfrage kostet Minuten und fällt in der Warteschlange auf. Eine automatisch versendete falsche Antwort kostet Vertrauen und lässt sich nicht zurückholen. Wenn Antwortentwürfe erzeugt werden, dann als Vorschlag im Ticket, den ein Mitarbeiter absendet.

Fehlererkennung. Messbar ist die Umsortierquote: Wie oft verschiebt ein Mensch das Ticket nach der automatischen Zuweisung in eine andere Kategorie? Diese Zahl entsteht ohnehin im Ticketsystem und muss nur ausgewertet werden. Ergänzend sollten Anfragen, die der Agent nicht sicher einordnen konnte, in einer eigenen Warteschlange landen statt mit einer Standardkategorie zu verschwinden – ein Agent, der bei Unsicherheit rät, produziert eine Statistik, die besser aussieht als der Betrieb.

Ausschluss. Kein Versand nach außen ohne Freigabe. Keine Zusagen zu Terminen, Preisen oder Gewährleistung, auch nicht im Entwurf. Keine Bearbeitung von Anfragen, die erkennbar personenbezogene Gesundheits-, Bewerbungs- oder Beschwerdedaten enthalten – diese Kategorien gehören direkt an einen Menschen, ohne dass ein Modell den Inhalt zusammenfasst.

Fall 3: Ein wiederkehrender Bericht entsteht automatisch – der agentische Teil ist der kleinste

Aufgabe. Ein Bericht, der heute jemand am Monatsanfang aus vier Quellen zusammenkopiert: Kennzahlen aus dem ERP, offene Vorgänge aus dem Ticketsystem, Verfügbarkeitswerte aus dem Monitoring, Ist-Zahlen aus einer Tabelle. Der Ablauf holt die Daten, prüft sie auf Vollständigkeit, erzeugt das Dokument und legt es zur Durchsicht ab.

Systemgrenze. Lesend: vier Systeme über Schnittstellen oder Exporte, jeweils mit eigenem technischen Konto und Leserecht. Schreibend: ein Ablageort. Sonst nichts.

Freigabepunkt. Vor der Verteilung. Ein Bericht, der ohne Sichtprüfung an die Geschäftsführung oder an Kunden geht, ist die teuerste Art, einen Schnittstellenfehler zu entdecken.

Und hier die unbequeme Einordnung: Der überwiegende Teil dieses Falls ist überhaupt kein Agent. Daten abrufen, zusammenführen, formatieren und ablegen ist ein deterministischer Workflow – günstiger, schneller, exakt wiederholbar und wesentlich leichter zu prüfen. Ein Sprachmodell wird erst an zwei Stellen sinnvoll: bei der Einordnung von Abweichungen in Worte („dieser Wert liegt außerhalb der letzten zwölf Monate”) und beim Umgang mit Quellen, deren Struktur sich ändert, etwa einer Tabelle, in der Spalten umbenannt werden.

Wenn Ihnen jemand für diesen Fall einen vollständig agentischen Aufbau anbietet, lohnt die Rückfrage, welcher Teil davon nicht als feste Regel schreibbar wäre. Häufig ist die Antwort: nur ein kleiner. Der Rest gehört in eine klassische Prozessautomatisierung, und die kostet weniger und fällt seltener aus.

Ausschluss. Kein automatischer Versand an Empfängerlisten. Kein stiller Umgang mit fehlenden Daten – wenn eine Quelle nicht erreichbar war, steht das im Bericht, statt dass die Zeile leer bleibt.

Der gefährlichste Text ist der, den der Agent selbst geholt hat

Alle drei Fälle haben eine Eigenschaft gemeinsam: Der Agent verarbeitet Inhalte, die von außen kommen und die niemand vorher gelesen hat. Genau daraus entsteht ein Risiko, das bei einem Chatbot noch keine Rolle spielt.

Das BSI beschreibt es in seiner Veröffentlichung zu generativen KI-Modellen als Indirect Prompt Injection: Angreifende verstecken Anweisungen „auf Webseiten, in E-Mails oder in Dokumenten, die das LLM auswertet”. Das Modell unterscheidet nicht zuverlässig zwischen dem Text, den es zusammenfassen soll, und einer Anweisung, die in diesem Text steht. Das BSI benennt auch die Folge, wenn eine solche Anwendung handeln darf: „unautorisierte Aktionen, wie das automatische Durchführen von unerwünschten Käufen oder das Versenden und Löschen von E-Mails”. Die Empfehlung daraus ist unspektakulär und wirksam – die Rechte der Anwendung einschränken, um die Auswirkungen zu begrenzen.

In den OWASP Top 10 für LLM-Anwendungen tragen die beiden zugehörigen Einträge die Nummern LLM01 (Prompt Injection) und LLM06 (Excessive Agency). Der zweite beschreibt genau den Fehler, den die Ausschlusslisten oben verhindern sollen: einem Agenten mehr Funktionen, mehr Berechtigungen oder mehr Autonomie zu geben, als seine Aufgabe erfordert.

Praktisch heißt das: Das Leserecht des Agenten darf nicht größer sein als das des Mitarbeiters, dem er zuarbeitet. Und ein Werkzeug, das er in fünf Prozent der Fälle braucht, sollte nicht dauerhaft in seinem Werkzeugkasten liegen.

Ab dem 2. August 2026 kommen Transparenzpflichten aus dem AI Act hinzu

Der zeitliche Rahmen ist absehbar und sollte in die Planung eines Agenten einfließen, der jetzt gebaut wird.

In Geltung sind bereits die Verbote bestimmter KI-Praktiken und die Pflicht zur KI-Kompetenz nach Artikel 4 – beides seit dem 2. Februar 2025. Seit dem 2. August 2025 gelten die Governance-Regeln und die Pflichten für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck.

Ab dem 2. August 2026 greifen die Transparenzpflichten nach Artikel 50. Sie betreffen die Kennzeichnung KI-generierter Inhalte in maschinenlesbarer Form sowie Offenlegungspflichten für Anbieter und Betreiber. Die Europäische Kommission hat am 10. Juni 2026 dazu einen freiwilligen Code of Practice on Transparency of AI-generated Content veröffentlicht.

Für die drei beschriebenen Fälle ist die Konsequenz überschaubar, aber nicht null. Wer künftig Antwortentwürfe an Kunden versendet, sollte jetzt klären, ob und wie gekennzeichnet wird. Wer Berichte verteilt, die ein Modell mitformuliert hat, sollte dasselbe für den internen Verteiler klären. Und in allen Fällen hilft dieselbe Dokumentation, die auch technisch sinnvoll ist: welches System eingesetzt wird, wer verantwortlich ist, welche Daten verarbeitet werden und an welcher Stelle Menschen eingebunden sind.

Was daraus im Einzelfall rechtlich folgt, hängt vom konkreten Einsatz ab. TakFlow setzt technische Maßnahmen wie Kennzeichnung, Protokollierung, Rollen und Freigaben um und dokumentiert sie. Die verbindliche rechtliche Einordnung gehört zur Rechtsberatung, nicht zur technischen Umsetzung.

Wann Sie für Ihren Fall keinen Agenten brauchen

Drei Prüfungen, die vor jedem Angebot stehen sollten:

Lässt sich der Ablauf als Regel schreiben? Wenn ein Mitarbeiter die Entscheidung in zwei Sätzen erklären kann und diese Sätze für alle Fälle gelten, bauen Sie einen Workflow. Er ist billiger, prüfbarer und fällt nicht wegen eines Modellwechsels aus.

Sind die Daten in dem Zustand, den der Fall voraussetzt? Fall 1 setzt gepflegte Lieferantenstammdaten voraus, Fall 2 eine Ticket-Historie, die nicht aus fünf Jahren „Sonstiges” besteht. Ein Agent gleicht schlechte Datenqualität nicht aus, er wird von ihr begrenzt.

Wer sieht die Freigaben durch? Ein Freigabepunkt ohne benannte Person ist ein Postfach, das nach drei Wochen niemand mehr öffnet. Dann läuft entweder der Prozess nicht mehr, oder jemand klickt die Sammelliste ungelesen durch – und die zweite Variante ist die schlechtere.

Bleiben nach diesen drei Prüfungen tragfähige Antworten übrig, ist der nächste Schritt klein: ein Fall, ein Freigabepunkt, ein messbarer Fehlerindikator, drei Monate Beobachtung. Erst danach der zweite Fall.

Handlungsaufruf

Welcher der drei Zuschnitte kommt Ihrem Posteingang am nächsten? TakFlow prüft, welcher Teil davon eine feste Regel bleiben sollte, wo ein Modell tatsächlich etwas beiträgt und an welcher Stelle die Freigabe sitzt – und sagt auch, wenn eine klassische Automatisierung die bessere Wahl ist.

KI-Anwendungsfall besprechen

Weiterführend: Automatisierung und KI-Lösungen von TakFlow · KI-Agenten und Workflows im Vergleich · RAG-Systeme für Unternehmenswissen