Ein Unternehmen will einen Kundenservice-Agenten einführen. Das KI ist ausgewählt, der Prompt ist geschrieben, die ersten einfach Tests mit Demodaten sehen gut aus. Dann die Ernüchterung: Der Agent kann nicht auf das Ticketsystem zugreifen, weil es keine passende API gibt. Die benötigten Kundendaten liegen verschiedenen Systemen, die nicht miteinander sprechen können und manche aktuelle Infos sind nur in Excel-Dateien auf Mitarbeiterdesktops zu finden. Die DSGVO-Konformität der automatisierten Datenverarbeitung ist ungeklärt. Und niemand hat definiert, was der Agent tun darf, wenn ein Kunde kündigen will und was er unbedingt nicht tun darf.

Die KI wäre bereit loszulegen. Die Organisation nicht.

Dieses Szenario ist kein Einzelfall. In Teil 1 dieser Reihe haben wir gesehen, was Agentic AI ist und warum sie technisch funktioniert: Werkzeuge, Planung und Gedächtnis – die drei Säulen, die LLMs von Chatbots zu Agenten machen. Aber diese drei Säulen brauchen ein Fundament. Und genau dieses Fundament fehlt in vielen Unternehmen.

Was ist Agent-Readiness?

Agent-Readiness beschreibt den Grad, in dem ein Unternehmen technisch und organisatorisch so aufgestellt ist, dass KI-Agenten produktiv arbeiten können.

Die Analogie ist naheliegend: Man würde auch keinen neuen Mitarbeiter in ein Unternehmen setzen, ohne ihm einen Laptop, Zugang zu den Systemen, eine Aufgabenbeschreibung und einen Ansprechpartner zu geben. Bei Agenten ist es nicht anders – nur dass die meisten Unternehmen genau das tun. Sie setzen die Fähigkeiten der KI voraus und vergessen die Arbeitsbedingungen.

Die sechs Dimensionen der Agent-Readiness:

1 Tool-Infrastruktur → Kann der Agent überhaupt handeln?
2 Datenzugänglichkeit → Kommt der Agent an die richtigen Daten?
3 Zugriffskontrolle → Darf der Agent das, was er tun soll?
4 Observability → Weiß man, was der Agent tut?
5 Verantwortung → Wer ist verantwortlich, wenn etwas schiefgeht?
6 Team & Prozesse → Wer baut, betreut und verbessert den Agenten

Keine dieser Dimensionen ist optional. Jede einzelne kann der Flaschenhals sein, der einen Agenten theoretisch mächtig, praktisch aber nutzlos macht.

Dimension 1: Tool-Infrastruktur – Kann der Agent überhaupt handeln?

Agenten handeln über Werkzeuge (Function Calling). Ein Agent ohne Werkzeuge ist ein Chatbot. Aber Werkzeuge gibt es nicht einfach so – sie müssen gebaut, dokumentiert und bereitgestellt werden.

APIs als Lebensader

Agenten greifen auf Systeme über APIs zu. Das ist keine Neuigkeit – aber die Qualität der API-Landschaft entscheidet darüber, ob ein Agent arbeiten kann oder nicht.

AGENT READY	NICHT AGENT-READY
RESTful APIs mit klarer Dokumentation	Keine APIs, nur manuelle Oberflächen
Konsistente Authentifizierung	Verschiedene Auth-Methoden pro System
Versionierte APIs mit Abwärtskompatibilität	Undokumentierte Änderungen, Breaking Changes
Strukturierte Fehlermeldungen	Kryptische Fehler oder stilles Scheitern

Wie viele der unternehmensinternen Systeme haben eine maschinenlesbare API? Wenn die Antwort „die Hälfte“ oder „weniger“ ist, kann ein Agent nicht die Hälfte der Aufgaben erledigen – und bricht bei Aufgaben, die mehrere Systeme verknüpfen, komplett zusammen.

Tool-Beschreibungen als Schnittstelle Mensch-Maschine

Die KI wählt Werkzeuge anhand ihrer Beschreibung in natürlicher Sprache. Das bedeutet: Jedes Werkzeug braucht eine präzise Beschreibung. Vage Beschreibungen führen zu falschen Aufrufen oder dazu, dass Werkzeuge gar nicht genutzt werden. Parameter müssen klar definiert sein – welche Werte erwartet werden, welche Pflicht sind, welche Formate gültig sind. Und Fehlerfälle müssen beschrieben sein, damit das LLM darauf reagieren kann, wenn ein Aufruf scheitert.

Ein konkretes Beispiel:

Schlechte Tool-Beschreibung:

Name: suche_kunde
Beschreibung: Sucht Kunden
Parameter: query (string)

Gute Tool-Beschreibung:

Name: suche_kunde
Beschreibung: Sucht einen Kunden anhand von Name, E-Mail oder
Kundennummer. Gibt Kundendaten inkl. Vertragsstatus und letzter Interaktion zurück. Verwende dies, wenn du spezifische Kundendaten brauchst.
Parameter:
-suchbegriff (string, Pflicht): Name, E-Mail oder 8-stellige Kundennummer
feld_typ (string, optional): „name“, „email“ oder „kundennummer“ – verbessert die Suchgenauigkeit
Fehler:
„kein_treffer“: Kein Kunde gefunden. Frag den Nutzer nach mehr Details.
„mehrere_treffer“: Mehrere Kunden passen. Liste die Ergebnisse auf und frag nach Klärung.

Der Unterschied ist nicht kosmetisch. Er ist funktional. Die KI (das LLM) wird mit der ersten Beschreibung Kunden suchen, aber oft falsche Parameter übergeben, bei Fehlern nicht wissen, wie es reagieren soll, und bei Mehrdeutigkeiten raten statt nachfragen. Mit der zweiten Beschreibung arbeitet es präzise, offensiv und fehlerresilient.

Tool-Design für Agenten ist ein neues Handwerkszeug. Es ist API-Design plus UX-Design – nur dass der Nutzer eine KI ist.

Dimension 2: Datenzugänglichkeit – Kommt der Agent an die richtigen Daten?

Der klügste Agent ist nutzlos, wenn die Daten in Silos liegen, die er nicht erreichen kann.

Typische Daten-Hürden

HINDERNIS	AUSWIRKUNG AUF DEN AGENTEN
Daten liegen in Excel-Dateien auf Netzlaufwerken	Daten liegen in Excel-Dateien auf Netzlaufwerken
Kundendaten in drei verschiedenen Systemen	Agent findet keine einheitliche Antwort
Dokumente als gescannte PDFs	Agent kann den Text nicht direkt lesen
Alte Systeme ohne API (Legacy)	Agent kann nur über Umwege zugreifen
Datenqualität ist schlecht (Duplikate, Inkonsistenzen)	Agent arbeitet mit falschen Daten – Ergebnisse sind unzuverlässig

Was Agent-Readiness hier bedeutet:

Daten müssen maschinenlesbar zugreifbar sein. Das klingt banal, ist aber in vielen Unternehmen der größte Flaschenhals. Nicht jedes System braucht eine API – aber die Daten, die ein Agent braucht, müssen irgendwie strukturiert erreichbar sein. Sei es über eine API, über eine Datenbankabfrage oder über eine Dateischnittstelle.

RAG als Brücke. Retrieval-Augmented Generation erlaubt Agenten den Zugriff auf unstrukturierte Daten – Dokumente, Handbücher, interne Wikis. RAG ist kein Hexenwerk, braucht aber: eine funktionierende Vektor-Datenbank, aktuelle Dokumente, saubere Aufbereitung und Metadaten. RAG löst aber nicht das Problem schlechter Daten – es macht schlechte Daten nur schneller auffindbar.

Datenqualität ist Agentenqualität. Ein Agent, der auf veraltete oder widersprüchliche Daten zugreift, produziert veraltete oder widersprüchliche Ergebnisse. Datenpflege wird durch Agenten nicht obsolet – sie wird wichtiger. Wer sich damit beschäftigt, wie KI mit schlechten Daten umgeht, findet mehr dazu im Artikel über KI-Halluzinationen in dieser Reihe.

Wenn ein Mensch 10 Minuten braucht, um eine bestimmte Information zu finden – wie lange braucht der Agent? Wenn die Antwort „länger“ oder „gar nicht“ lautet, liegt das Problem nicht beim Agenten.

Dimension 3: Zugriffskontrolle – Darf der Agent das, was er tun soll?

Ein Agent braucht Zugriffe – aber nicht auf alles. Und nicht mit den gleichen Rechten wie ein Administrator. Das Prinzip der minimalen Rechte (Least Privilege) gilt besonders für Agenten.

Berechtigungsmodelle für Agenten

Drei Rollen, die jedes Agenten-Projekt braucht

Rolle	Verantwortung	Typisches Profil
Agent-Developer	Baut den Agenten, schreibt Prompts, integriert Werkzeuge	Software-Entwickler/in mit LLM-Erfahrung
Agent-Operator	Überwacht den Betrieb, analysiert Logs, greift bei Fehlern ein	IT-Operations mit Verständnis für KI-Besonderheiten
Domain-Expert	Definiert Aufgaben, bewertet Ergebnisse, gibt Fachwissen	Fachbereichsmitarbeiter/in, die den Prozess kennt

Service-Accounts für Agenten

Agenten sollten eigene Identitäten haben – nicht die eines menschlichen Mitarbeiters. Das ermöglicht Auditing, weil jede Aktion nachvollziehbar dem Agenten zugeordnet ist. Es ermöglicht Rechte-Scoping, weil der Agent nur die Rechte bekommt, die er für seine Aufgabe braucht. Es ermöglicht Abschaltung, weil ein Agent deaktiviert werden kann, ohne menschliche Nutzer zu beeinflussen. Und es ermöglicht datenschutzrechtliche Klarheit, weil offensichtlich ist, dass eine Maschine auf Daten zugreift.

Human-in-the-Loop als Geschäftsanforderung

Nicht jede Aktion sollte ein Agent selbstständig ausführen. Die Entscheidung, welche Aktionen autonom sind und welche menschliche Freigabe brauchen, ist eine Geschäftsanforderung, keine technische:

Aktion	Autonom?	Begründung
Kundendaten abrufen	✅ Ja	Nur-Lese-Zugriff, geringes Risiko
Standard-E-Mail senden	✅ Ja	Vordefinierte Vorlagen, geprüft
Kundenerstattung veranlassen	❌ Freigabe nötig	Finanzielle Auswirkung
Vertragskonditionen ändern	❌ Freigabe nötig	Rechtliche Relevanz
Incident an Eskalation weiterleiten	✅ Ja	Zeitkritisch, klarer Prozess

Diese Einteilung kann kein Technik-Team allein treffen. Sie braucht den Fachbereich, der definiert: Wo ist das Risiko akzeptabel? Wo brauchen wir menschliche Kontrolle? Und was passiert, wenn der Agent in einem Graubereich landet?

Dimension 4: Observability – Weiß man, was der Agent tut?

Ein Agent führt möglicherweise Hunderte oder sogar viele Tausende von Aktionen pro Tag aus. Ohne Nachvollziehbarkeit ist das ein Black-Box-Betrieb – und das ist inakzeptabel. Wie man KI-Ausgaben grundsätzlich kontrolliert, haben wir im Artikel über LLM-Guardrails behandelt. Für Agenten kommt eine weitere Ebene hinzu: Nicht nur die Ausgabe muss überwacht werden, sondern jeder einzelne Handlungsschritt.

Drei Ebenen der Nachvollziehbarkeit

Ebene 1: Logging – Was ist passiert?
Jeder Werkzeug-Aufruf wird protokolliert: Welches Werkzeug, welche Parameter, welches Ergebnis. Jeder Denkschritt wird gespeichert: Was hat der Agent überlegt, bevor er gehandelt hat? Dazu Zeitstempel, Dauer und Token-Verbrauch pro Schritt.

Ebene 2: Monitoring – Läuft alles normal?
Erfolgsquote der Werkzeug-Aufrufe, durchschnittliche Aufgabendauer, Fehlerraten nach Werkzeug und Aufgabentyp, Kosten pro Aufgabe und Eskalationsrate – wie oft muss ein Mensch eingreifen? Diese Metriken erlauben es, Probleme früh zu erkennen: Wenn ein Werkzeug plötzlich häufiger fehlschlägt, ist das ein Signal.

Ebene 3: Auditing – Warum ist etwas passiert?
Vollständige Entscheidungsketten für jede Aufgabe. Rückverfolgbarkeit: Welche Eingabe führte zu welcher Aktion? Und der Vergleich: Hat der Agent die Aufgabe gelöst? Entspricht das Ergebnis den Erwartungen?

Was gutes Agent-Logging ausmacht

Der Unterschied zwischen „Der Agent hat eine E-Mail gesendet“ und „Der Agent hat am 15.05.2026 um 14:32 Uhr eine E-Mail an kunde@example.com gesendet mit dem Betreff ‚Ihre Rückfrage zum Auftrag #4821‘ – weil in Schritt 3 des ReAct-Zyklus das Werkzeug lade_auftrag den Status ‚in Bearbeitung‘ zurückgegeben hat und der Agent entschied, dass der Kunde darüber informiert werden muss.“

Erst diese Tiefe macht ein Auditing sinnvoll. Ohne sie bleibt der Agent eine Black Box – und Black Boxes sind in produktiven Systemen nicht akzeptabel.

Dimension 5: Verantwortung – Wer ist verantwortlich, wenn etwas schiefgeht?

Agenten treffen Entscheidungen und führen Aktionen aus. Wenn etwas schiefgeht, ist die Frage: Wer ist verantwortlich? Die Antwort ist klarer, als viele glauben – und unbequemer, als viele hoffen.

Das Drei-Ebenen-Modell

Ebene 1: Der Modellanbieter (OpenAI, Anthropic, Google) ist verantwortlich für die Qualität und Sicherheit des Basismodells. Aber: Die Modellanbieter kennen nicht die Unternehmenskontexte. Sie garantieren nicht, dass ihr Modell in jeder Anwendung korrekt handelt.

Ebene 2: Das Plattform-Team ist verantwortlich für Werkzeug-Design, Guardrails, Berechtigungen und Monitoring. Das ist das Bindeglied zwischen dem, was das Modell kann, und dem, was der Agent im Unternehmenskontext tun darf.

Ebene 3: Der Fachbereich ist verantwortlich für die Definition der Aufgabe, die Freigabe von Aktionen und die Überprüfung der Ergebnisse. Das Modell liefert, der Fachbereich entscheidet.

Die unbequeme Wahrheit

Ein Agent ist kein eigenständiger Akteur. Er ist ein Werkzeug, das von Menschen gebaut, konfiguriert und überwacht wird. Die Verantwortung liegt immer bei den Menschen, die ihn einsetzen – nicht bei der KI.

Auch regulatorisch wird das klar: Der EU AI Act definiert Verantwortlichkeiten für den Einsatz von KI-Systemen. Der Agent hat keine eigene Rechtspersönlichkeit. Die Haftung bleibt beim Unternehmen. Wer heute keine nachvollziehbare Strategie für Agenten-Einsatz dokumentiert, schafft sich später Compliance-Arbeit.

Dimension 6: Team & Prozesse – Wer baut, betreut und verbessert den Agenten?

Agenten sind keine Einmal-Entwicklung. Sie brauchen kontinuierliche Pflege, Verbesserung und Anpassung. Die meisten Unternehmen unterschätzen diesen Aufwand massiv.

Drei Rollen, die jedes Agenten-Projekt braucht

Rolle	Verantwortung	Typisches Profil
Agent-Developer	Baut den Agenten, schreibt Prompts, integriert Werkzeuge	Software-Entwickler/in mit LLM-Erfahrung
Agent-Operator	Überwacht den Betrieb, analysiert Logs, greift bei Fehlern ein	IT-Operations mit Verständnis für KI-Besonderheiten
Domain-Expert	Definiert Aufgaben, bewertet Ergebnisse, gibt Fachwissen	Fachbereichsmitarbeiter/in, die den Prozess kennt

Der häufigste Fehler: Entwickler bauen einen Agenten ohne tiefes Verständnis des Fachprozesses. Das Ergebnis funktioniert technisch, aber inhaltlich nicht. Die Zusammenarbeit zwischen Developer und Domain-Expert ist kritisch – und sie braucht Zeit, die in Projektplänen oft fehlt.

Prozesse, die etabliert werden müssen

Agent-Lifecycle-Management: Von der Definition über Entwicklung, Test, Staging, Deployment bis zum Monitoring – Agenten brauchen einen strukturierten Prozess wie jedes andere Software-Produkt.

Prompt-Review: Prompts sind Code. Sie müssen versioniert, getestet und reviewed werden. Ein geänderter Prompt kann das Verhalten eines Agenten radikal verändern – und nicht immer zum Besseren.

Werkzeug-Review: Jedes neue Werkzeug, das ein Agent erhält, ändert seinen Handlungsspielraum. Neue Werkzeuge müssen geprüft werden: Was kann schiefgehen? Welche Guardrails braucht es? Was passiert, wenn das Werkzeug unerwartet reagiert?

Regelmäßige Evaluierung: Agenten-Performance verändert sich – durch Modell-Updates, sich ändernde Daten, neue Anforderungen. Regelmäßige Tests mit realen Aufgaben sind notwendig, nicht optional.

Der Agent-Readiness-Check

Ein pragmatischer Selbsttest für Unternehmen:

Dimension	✅ Agent-Ready	⚠️ Auf dem Weg	❌ Nicht bereit
Tool-Infrastruktur	Die meisten Systeme haben gut dokumentierte APIs	Einige Systeme haben APIs, aber unzureichend dokumentiert	Die meisten Systeme haben keine APIs
Datenzugänglichkeit	Daten sind strukturiert und maschinenlesbar zugreifbar	Einige Daten sind zugreifbar, andere nicht	Daten liegen in Silos, gescannten PDFs, Excel-Dateien
Zugriffskontrolle	Service-Accounts mit Least Privilege sind etabliert	Es gibt Berechtigungskonzepte, aber nicht für Agenten	Alle Nutzer teilen sich Admin-Zugänge
Observability	Agenten-Aktionen werden vollständig geloggt und überwacht	Es gibt Logging, aber keine Agenten-spezifische Auswertung	Es gibt kein systematisches Logging
Verantwortung	Rollen und Verantwortlichkeiten sind klar definiert	Es gibt Ansprechpartner, aber keine formalen Prozesse	Niemand ist explizit verantwortlich
Team & Prozesse	Dediziertes Team, strukturierte Prozesse	Einige Personen befassen sich damit, aber nebenbei	Keine personelle Zuständigkeit

Faustregel: Wenn weniger als drei Dimensionen „✅ Agent-Ready“ sind, sollte der Fokus zuerst auf der Infrastruktur liegen – nicht auf dem Agenten. Ein Agent auf einem schwachen Fundament wird enttäuschen. Die Investition in die Infrastruktur zahlt sich aber nicht nur für den Agenten aus, sondern für die gesamte Digitalisierung.

Ausblick

Agent-Readiness ist kein Zustand, den man einmal erreicht und dann abhakt. Es ist ein Reifegrad, der schrittweise aufgebaut wird. Die gute Nachricht: Jede Verbesserung der Infrastruktur nützt nicht nur den Agenten, sondern dem gesamten Unternehmen. Bessere APIs, zugänglichere Daten, klarere Berechtigungen – das sind Investitionen, die sich auch ohne Agenten rechnen.

Stand: Mai 2026