Ein Agent ist kein besserer Chatbot
Bei generativer AI konnten Unternehmen lange relativ einfach experimentieren: Ein Mitarbeitender stellt eine Frage, die AI antwortet, der Mensch entscheidet, was er mit der Antwort macht.
Mit AI Agents verschiebt sich die Grenze.
Ein Agent kann – abhängig von seinen Werkzeugen und Berechtigungen – Daten suchen, Systeme abfragen, Tickets erstellen, Datensätze verändern, Nachrichten versenden oder Prozesse über mehrere Schritte hinweg ausführen.
Damit wird aus „AI unterstützt Arbeit“ zunehmend „AI führt Arbeit aus“.
Das ist leistungsfähig. Es bedeutet aber auch, dass schlechte Prozesslogik nicht nur schneller analysiert, sondern schneller ausgeführt werden kann.
Microsoft beschreibt in seinem 2026 aktualisierten Agentic-AI-Reifegradmodell einen zentralen Punkt: Agents schaffen Wert in gut gestalteten Prozessen. Ohne klares Process Mapping und Value Measurement besteht die Gefahr, einzelne Tätigkeiten zu automatisieren, ohne den End-to-End-Prozess tatsächlich zu verbessern.
Genau deshalb würde ich neben AI Readiness einen zweiten Begriff etablieren:
Agent Readiness: Ist ein Prozess so klar, kontrollierbar und messbar, dass ein Agent darin sicher handeln kann?
Fehler 1: Das Ziel des Prozesses ist nicht eindeutig
„Bearbeite Kundenanfragen“ ist kein gutes Agent-Ziel.
Was bedeutet erfolgreich bearbeitet?
- innerhalb von zwei Stunden beantwortet?
- richtig kategorisiert?
- vollständig gelöst?
- an die richtige Stelle eskaliert?
- dokumentiert?
- SLA eingehalten?
Ein Mensch gleicht unklare Ziele häufig mit Erfahrung aus. Ein Agent benötigt deutlich explizitere Kriterien.
Vor jeder Automatisierung sollte deshalb ein Outcome formuliert werden.
Nicht:
„Agent soll Rechnungen prüfen.“
Sondern:
„Agent soll eingehende Lieferantenrechnungen anhand definierter Pflichtfelder, Bestellbezug und Toleranzen vorklassifizieren, Abweichungen markieren und nur vollständig regelkonforme Fälle zur automatischen Weiterverarbeitung freigeben.“
Jetzt kann man testen, messen und Grenzen setzen.
Fehler 2: Der Prozess existiert nur in den Köpfen
Viele operative Prozesse wirken standardisiert, bis man fünf Mitarbeitende fragt, wie sie tatsächlich arbeiten.
Dann entstehen fünf Varianten.
Ein Agent braucht eine nachvollziehbare Prozessdefinition:
- Trigger
- Inputs
- Standardablauf
- Entscheidungen
- Ausnahmen
- Output
- Verantwortlichkeiten
Wenn das Unternehmen den Prozess nicht erklären kann, sollte der Agent ihn noch nicht autonom ausführen.
Fehler 3: Es gibt keine klare Source of Truth
Welches System hat Recht?
Das CRM sagt, der Kunde ist aktiv. Das ERP zeigt eine Sperre. Eine Excel-Datei enthält einen Sonderstatus. Im Teams-Chat wurde gestern eine Ausnahme vereinbart.
Ein Mensch fragt nach. Ein Agent benötigt Regeln.
Für relevante Datenobjekte muss definiert sein:
- führendes System
- Aktualität
- Datenqualität
- zulässige Alternativquellen
- Verhalten bei Widersprüchen
Agentic AI macht Daten-Governance damit noch wichtiger als klassische Automatisierung.
Fehler 4: Entscheidungsrechte sind nicht definiert
Ein Agent kann vielleicht erkennen, dass ein Kunde eine Zahlungsfrist überschritten hat.
Darf er selbst mahnen?
Darf er eine Mahnsperre entfernen?
Darf er eine Gutschrift erstellen?
Darf er einen Auftrag blockieren?
Technische Berechtigung und organisatorisches Entscheidungsrecht sind zwei verschiedene Dinge.
Ich würde Agent-Aktionen in drei Klassen einteilen:
Klasse A – Lesen und vorbereiten
Informationen sammeln, analysieren, zusammenfassen, Empfehlungen erstellen.
Klasse B – Niedrigrisiko-Aktion
Task erstellen, Datensatz kategorisieren, internen Entwurf erstellen, standardisierte Information versenden.
Klasse C – Geschäftskritische Aktion
Finanzbuchung, Vertragsänderung, personenbezogene Entscheidung, Löschung, externe verbindliche Kommunikation oder weitreichende Berechtigungsänderung.
Je höher die Klasse, desto stärker sollten Human Review, Freigaben und technische Kontrollen sein.
Fehler 5: Ausnahmefälle sind unsichtbar
Ein Standardprozess funktioniert in 90 Prozent der Fälle. Die restlichen zehn Prozent machen ihn schwierig.
Agent-Projekte scheitern schnell, wenn nur der Happy Path dokumentiert wird.
Relevante Fragen sind:
- Was passiert bei fehlenden Daten?
- Was passiert bei widersprüchlichen Informationen?
- Was passiert bei Timeout?
- Was passiert, wenn ein Drittsystem nicht verfügbar ist?
- Was passiert bei einem unbekannten Fall?
- Wann muss der Agent stoppen?
Ein guter Agent ist nicht derjenige, der alles selbst erledigt. Ein guter Agent erkennt zuverlässig, wann er nicht selbst entscheiden sollte.
Fehler 6: Es gibt keinen Rollback oder sicheren Stopp
Bei einer klassischen Empfehlung kann der Nutzer einfach nichts tun.
Bei einem Agent kann eine Aktion bereits ausgeführt sein.
Deshalb muss der Prozess vorab klären:
- Welche Aktionen sind reversibel?
- Wie wird ein Fehler erkannt?
- Wie wird gestoppt?
- Wer wird informiert?
- Wie wird der vorherige Zustand wiederhergestellt?
Gerade bei mehrstufigen Agents ist das entscheidend. Wenn Schritt fünf fehlschlägt, müssen die Auswirkungen der Schritte eins bis vier bekannt sein.
Fehler 7: Niemand misst den Business Value
„Wir haben einen Agent“ ist kein Erfolgskriterium.
Ein Agent sollte mindestens eine messbare Verbesserung liefern:
- kürzere Durchlaufzeit
- weniger manuelle Bearbeitung
- geringere Fehlerquote
- schnellere Reaktion
- höhere Datenqualität
- weniger Eskalationen
- bessere Transparenz
Ohne Baseline kann man später nicht sagen, ob die neue Lösung wirklich besser ist.
Microsoft betont in seinem Agentic-AI-Maturity-Modell ebenfalls die Verbindung von Prozessgestaltung und Value Measurement. Das ist aus meiner Sicht zentral: AI muss einen Geschäftsprozess verbessern, nicht nur einen beeindruckenden Demo-Moment erzeugen.

Der Agent Readiness Canvas
Bevor ein Agent gebaut wird, würde ich eine Seite mit acht Feldern ausfüllen.
1. Outcome
Welches messbare Ergebnis soll besser werden?
2. Trigger
Was startet den Prozess?
3. Daten
Welche Quellen werden benötigt und welche ist führend?
4. Tools und Aktionen
Was darf der Agent technisch tun?
5. Entscheidungsgrenzen
Was darf er selbst entscheiden und was nicht?
6. Human Gates
Wo ist eine Freigabe erforderlich?
7. Exception & Recovery
Wie werden unbekannte Fälle, Fehler und Rollbacks behandelt?
8. Monitoring & KPI
Wie erkennen wir Qualität, Kosten und Fehler?
Wenn diese acht Felder nicht beantwortet werden können, ist häufig nicht der Agent das Problem, sondern der Prozess.
Illustrativer Business Case: Agent für offene Kundenforderungen
Ein Unternehmen möchte den Aufwand für überfällige Forderungen reduzieren.
Die erste Idee lautet: „Ein Agent soll jeden Morgen offene Rechnungen prüfen und Kunden automatisch erinnern.“
Klingt einfach. In der Praxis entstehen sofort Fragen:
- Kunden mit laufender Reklamation?
- strategische Key Accounts?
- bereits vereinbarte Zahlungspläne?
- falsche Rechnungen?
- Mahnsperren?
- unterschiedliche Sprachen?
- verschiedene rechtliche Einheiten?
Ein agent-ready Design könnte deshalb so aussehen:
Stufe 1 – Agent analysiert
Offene Posten, Kundenstatus, Sperren, CRM-Aktivitäten und bekannte Ausnahmen zusammenführen.
Stufe 2 – Agent klassifiziert
„Standard-Erinnerung möglich“, „manuelle Prüfung“, „keine Aktion“.
Stufe 3 – Human Gate
Zu Beginn werden alle externen Nachrichten freigegeben.
Stufe 4 – kontrollierte Automatisierung
Nach einer Lernphase werden nur Fälle mit sehr klaren Regeln automatisch versendet.
Stufe 5 – Monitoring
Antwortquote, Fehlklassifikationen, manuelle Overrides und Durchlaufzeit werden gemessen.
So wächst Autonomie mit nachgewiesener Qualität – nicht mit Begeisterung für Technologie.
Agent Governance darf nicht parallel zur normalen Governance entstehen
Eine weitere Gefahr ist ein separates „AI Governance Universe“.
Dabei gelten viele bekannte Prinzipien weiterhin:
- Identity & Access Management
- Least Privilege
- Segregation of Duties
- Logging
- Change Management
- Datenklassifizierung
- Incident Management
- Lifecycle Management
Agents sind neue technische Akteure, aber sie müssen in bestehende Kontrollmodelle integriert werden.
Microsoft empfiehlt beispielsweise ein Agent Registry, in dem Zweck, Owner, Plattform und Zugriffsbereich dokumentiert werden. Das halte ich auch ausserhalb der Microsoft-Welt für ein starkes Prinzip.
Die Reihenfolge macht den Unterschied
Ich würde Agent-Projekte in dieser Reihenfolge angehen:
- Prozess sichtbar machen.
- Prozess vereinfachen.
- Business Outcome definieren.
- Daten und Systeme klären.
- Entscheidungsgrenzen definieren.
- Agent zuerst als Assistent einsetzen.
- Qualität messen.
- Autonomie schrittweise erhöhen.
Nicht umgekehrt.
Welche Prozesse sich zuerst für Agents eignen
Ich würde nicht mit dem komplexesten End-to-End-Prozess starten. Gute erste Kandidaten haben mehrere dieser Eigenschaften:
- hoher Wiederholungsgrad
- klarer Trigger
- digitale Datenquellen
- wenige irreversible Aktionen
- eindeutige Eskalationslogik
- messbare Baseline
- heute spürbarer manueller Aufwand
- relativ stabile Business-Regeln
Beispiele können interne Triage, Informationssammlung, Vorbereitung von Freigaben, Datenqualitätschecks oder Follow-up-Prozesse sein.
Schlechtere Startkandidaten sind Prozesse mit starkem Ermessensspielraum, vielen rechtlichen Sonderfällen, unklaren Datenquellen oder hoher externer Wirkung.
Der Unterschied zwischen Task Automation und End-to-End-Verbesserung
Ein Agent kann einen einzelnen Task um 80 Prozent beschleunigen und trotzdem den Gesamtprozess kaum verbessern.
Beispiel: Das Erstellen einer Antwort dauert statt zehn Minuten nur noch zwei. Wenn die Anfrage danach zwei Tage auf eine Freigabe wartet, ist der eigentliche Engpass nicht gelöst.
Operational Excellence betrachtet deshalb:
- Gesamt-Durchlaufzeit
- Wartezeiten
- Übergaben
- Fehler und Rework
- Entscheidungspunkte
- Kundenwirkung
Erst danach wird entschieden, wo ein Agent den grössten Hebel hat.
Ein Kontrollmodell für wachsende Autonomie
Ich würde Autonomie in Stufen freigeben:
Observe
Agent liest und analysiert, führt aber nichts aus.
Recommend
Agent schlägt eine Aktion vor.
Draft
Agent bereitet die Aktion vollständig vor; Mensch bestätigt.
Execute with Guardrails
Agent führt klar definierte Niedrigrisiko-Fälle selbst aus.
Exception-based Supervision
Menschen sehen primär Ausnahmen und Stichproben.
Der Sprung zur nächsten Stufe erfolgt erst, wenn Qualität und Fehlerrate akzeptabel sind. Damit wird Autonomie evidenzbasiert statt ideologisch.
Fazit: Autonomie muss verdient werden
AI Agents werden viele operative Prozesse verändern. Aber Autonomie ist keine Checkbox.
Ein Agent sollte nicht deshalb mehr dürfen, weil das technisch möglich ist. Er sollte mehr dürfen, wenn der Prozess klar ist, die Daten stimmen, Risiken kontrolliert sind und die Qualität nachweisbar ist.
Das ist Operational Excellence im Agent-Zeitalter:
Erst Prozessklarheit. Dann Automatisierung. Dann kontrollierte Autonomie.

