Was ist Agentic AI? Vom Hype zum produktiven Agenten

Die Demo funktioniert. Der Agent liest das Ticket, findet den passenden Wissensartikel, formuliert eine Antwort. Alle im Raum nicken. Und dann steht die Frage im Raum, an der die meisten Vorhaben hängen bleiben: Was muss passieren, damit dieser Agent morgen früh auf echte Kundenanfragen losgelassen werden kann?

Zwischen einem funktionierenden Prototyp und einem verlässlichen Dienst liegen keine weiteren Modellfähigkeiten. Dort liegen Entscheidungsgrenzen, Berechtigungen, Freigabewege, Fehlerpfade, Monitoring und ein Betriebsmodell. Gartner prognostizierte im Juni 2025, dass über 40 Prozent der agentischen KI-Projekte bis Ende 2027 abgebrochen werden – wegen eskalierender Kosten, unklarem Geschäftswert oder unzureichender Risikokontrollen. Keiner dieser drei Gründe ist ein KI-Problem. Es sind Architektur-, Governance- und Betriebsprobleme.

Dieser Beitrag erklärt zuerst, was Agentic AI überhaupt ist und wie sie sich von Chatbots, Workflows und RPA unterscheidet. Danach geht es um das, was in der Praxis darüber entscheidet, ob ein Agent produktiv geht: Autonomiegrenzen, Human-in-the-Loop, Rechte, Betrieb und Compliance.

Was ist Agentic AI?

Agentic AI beschreibt KI-Systeme, die ein Ziel verfolgen und dafür eigenständig Schritte planen, Informationen beschaffen, Werkzeuge einsetzen und Handlungen vorbereiten oder ausführen. Der Agent bekommt also nicht mehr eine Anweisung pro Schritt, sondern ein Ergebnis, das er erreichen soll.

Im Unternehmenskontext heißt das ausdrücklich nicht vollständige Autonomie. Es heißt kontrollierte Autonomie innerhalb definierter Regeln, Rollen und Freigaben. Genau diese Unterscheidung entscheidet darüber, ob ein Vorhaben durch Security und Compliance kommt – und sie ist der Grund, warum Agentic AI im Enterprise etwas anderes ist als ein beeindruckender Assistent auf dem Laptop.

Der praktische Unterschied lässt sich in einem Satz sagen: Ein Chatbot liefert Text. Ein Agent liefert ein Ergebnis im Prozess.

Abgrenzung: Chatbot, Workflow, RPA und Agent

  • Chatbots beantworten Fragen und reagieren auf Prompts. Ein Agent erzeugt Arbeitspläne, ruft Systeme auf, reichert Kontext an und schließt eine Aufgabe ab.
  • Klassische Workflows sind deterministisch: Ein Schritt folgt dem nächsten. Agenten wählen bei Abweichungen alternative Wege, leiten Zwischenschritte ab und bereiten aus dem Kontext passende Entscheidungen vor – kontrollierbar über die Orchestrierung.
  • Robotic Process Automation automatisiert Klickpfade und Regeln und ist stark bei stabilen, wiederholbaren Aufgaben. Agenten sind stärker bei variantenreichen Fällen, unstrukturierten Inputs und Aufgaben, die Bewertung erfordern. RPA kann dabei Teil des Werkzeugkastens eines Agenten sein.

Ein verbreiteter Irrtum ist übrigens, Autonomie sei eine Eigenschaft des Modells. Sie ist eine Eigenschaft der Umgebung, in die du das Modell stellst.

Warum Agenten-Piloten den Sprung in Produktion nicht schaffen

Piloten scheitern selten daran, dass das Modell zu schwach wäre. Sie scheitern an vier wiederkehrenden Mustern.

Der Scope war nie abgegrenzt. Ein Pilot, der „mal schauen soll, was geht“, hat kein Abnahmekriterium. Ohne definierten Use Case gibt es keinen Baseline-Wert – und damit keine Grundlage für eine Investitionsentscheidung.

Der Agent hatte zu viele Rechte. Im Prototyp bekommt er einen Admin-Zugang, weil das schneller geht. In Produktion ist genau das der Grund, warum Security das Vorhaben stoppt. Rechte nachträglich zu beschneiden heißt, die halbe Integration neu zu bauen.

Niemand hat die Fehlerfälle modelliert. Was passiert, wenn das Zielsystem nicht antwortet? Wenn das Modell eine Bestellnummer erfindet? Wenn zwei Agenten denselben Vorgang anfassen? Ein Prototyp darf abstürzen. Ein Dienst muss kontrolliert degradieren.

Es gab keine Zahlen. Ohne Erfolgsquote, Kosten je Aufgabe und Bearbeitungszeit gegenüber der Baseline bleibt die Bewertung Geschmackssache. Und Geschmackssache verliert gegen jedes andere Budgetthema.

Alle vier Punkte lassen sich vorab adressieren. Sie kosten in der Konzeption Tage – und im Nachhinein Monate.

Kontrollierte Autonomie: Was ein Agent entscheiden darf

Es braucht eine explizite Entscheidung darüber, wo die Grenze verläuft. Bewährt hat sich, jede Aktion eines Agenten in eine von drei Klassen einzuordnen:

  • Frei ausführbar: lesende Zugriffe, Recherche, Klassifikation, Zusammenfassung, Entwürfe anlegen. Nichts davon verlässt das Haus, nichts davon ist irreversibel.
  • Freigabepflichtig: alles, was nach außen wirkt oder Geld bewegt – Versand an Kunden, Buchungen, Statuswechsel in führenden Systemen, Vertragsrelevantes. Der Agent bereitet vor, ein Mensch gibt frei.
  • Gesperrt: Löschungen, Rechtevergabe, Änderungen an Konfiguration und Stammdaten.

Diese Einteilung ist kein Dokument für die Ablage. Sie wird zur Struktur des Workflows: Jede Klasse entspricht einem anderen Pfad in der Orchestrierung. Damit wird aus einer Absichtserklärung eine technisch erzwungene Grenze. Der Agent plant und schlägt vor – die Orchestrierung kontrolliert die Ausführung.

Human-in-the-Loop sauber modellieren

„Ein Mensch schaut nochmal drüber“ ist keine Governance. Sobald ein Prozess Volumen bekommt, wird aus der Kontrolle ein Durchwinken. Damit Human-in-the-Loop trägt, brauchst du drei Festlegungen.

Wer freigibt. Nicht „das Team“, sondern eine Rolle mit fachlicher Zuständigkeit und der Befugnis, die konkrete Aktion zu verantworten. Bei allem, was Kunden oder Geld betrifft, gehört diese Rolle ins bestehende Berechtigungskonzept – nicht in eine Nebentabelle des Automatisierungstools.

Was der Freigebende sieht. Ein Vorschlag ohne Begründung ist nicht prüfbar. Brauchbar wird eine Freigabe erst, wenn der Agent mitliefert, worauf er sich stützt: verwendete Quellen, gezogene Datensätze, die Regel hinter der Entscheidung. Das ist gleichzeitig die Grundlage für den Audit-Trail.

Was passiert, wenn niemand reagiert. Jede Freigabe braucht eine Frist und einen definierten Ausgang, wenn die Frist verstreicht – Eskalation, Rückfall auf den manuellen Prozess oder Abbruch mit Benachrichtigung. Offene Vorgänge ohne Timeout sind der häufigste Grund dafür, dass ein Agenten-Workflow im Betrieb still stehenbleibt.

Zwei Personen prüfen gemeinsam Dokumente am Doppelmonitor – Human-in-the-Loop: Freigabe kritischer Schritte durch Menschen

Rechte und Tool-Zugriff: Least Privilege und MCP

Der Zugriff auf Systeme ist die Stelle, an der ein Agent gefährlich wird. Nicht weil er böswillig wäre, sondern weil er mit den Rechten handelt, die du ihm gibst – und weil er Inhalte verarbeitet, die von außen kommen.

Rechte pro Werkzeug, nicht pro Agent. Ein Agent bekommt keinen generischen Systemzugang, sondern definierte, im Workflow modellierte Werkzeuge: „Ticket lesen“, „Wissensartikel suchen“, „Antwortentwurf speichern“. Jedes Werkzeug hat eigene, minimale Rechte.

Identität durchreichen. Arbeitet der Agent im Auftrag eines Nutzers, sollte er dessen Rechte verwenden statt eines technischen Sammelkontos. Per-User-Token und OAuth begrenzen, was er überhaupt sehen kann. Das verhindert den klassischen Fall, in dem über die Automatisierung plötzlich Daten sichtbar werden, die der anfragende Mensch nie hätte sehen dürfen.

Prompt-Injection als Zugriffsrisiko behandeln. Ein Agent, der E-Mails, Tickets oder Dokumente liest, verarbeitet fremden Text. Steht dort eine Anweisung, darf sie nicht wie eine Anweisung des Nutzers behandelt werden. Inhalte aus externen Quellen sind Daten, keine Instruktionen.

Für die Anbindung selbst hat sich mit dem Model Context Protocol (MCP) ein offener Standard etabliert: ein Server, viele Clients, statt jede Integration je Modell neu zu bauen. MCP normt die Schnittstelle – die Ausführung bleibt orchestriert, etwa über n8n als kontrollierten Stromkreis.

Betrieb: messbar, begrenzt und bezahlbar

Ein Agent, dessen Verhalten niemand messen kann, lässt sich nicht verantworten. Vier Kennzahlen reichen als Minimum:

  • Erfolgsquote je Aufgabentyp – nicht „läuft der Workflow“, sondern wie viele Vorgänge vollständig und korrekt abgeschlossen wurden, getrennt nach Standard- und Randfällen.
  • Kosten je Aufgabe – Token, Laufzeit und Infrastruktur heruntergebrochen auf den einzelnen Vorgang. Die einzige Absicherung gegen Kostenüberraschungen bei steigendem Volumen.
  • Korrekturquote – wie oft musste ein Mensch den Vorschlag ändern, bevor er freigegeben wurde? Hohe Korrekturquote bei hoher Freigabequote ist das Warnsignal schlechthin.
  • Fehler- und Abbruchrate mit Ursache – nicht nur dass etwas schiefging, sondern wo: Zielsystem, Modell oder Datenlage.

Dazu gehören harte Limits: Token-Budgets je Workflow, Laufzeitbegrenzungen, Alarme bei Abweichungen. Und Fehlerpfade, damit ein scheiternder Agent nicht zum Betriebsrisiko wird – Retries mit Backoff, Fallbacks auf den manuellen Prozess, sauberes Degradieren statt stiller Fehler.

Vertrauen entsteht nicht durch Versprechen, sondern durch Belege: begrenzte Rechte, gemessene Ergebnisse und ein Betrieb, der jederzeit zeigt, was der Agent getan hat und was er gekostet hat.

DSGVO, EU AI Act und Datensouveränität

Aus der DSGVO ergeben sich drei bekannte Fragen: Welche personenbezogenen Daten verarbeitet der Workflow, zu welchem Zweck, und wer hat Zugriff? Für Agenten kommt eine vierte hinzu, die klassische Automatisierung nicht kennt: Welche Daten verlassen die Organisation, wenn ein externes Modell aufgerufen wird? Diese Frage gehört vor den ersten Prototyp, nicht vor den Go-Live.

Der EU AI Act adressiert Transparenz, menschliche Aufsicht und Nachvollziehbarkeit. Für Vorarbeit, Triage und Entwürfe bedeutet das keine dramatischen Zusatzanforderungen, sofern Freigaben, Protokollierung und Eingriffsmöglichkeit ohnehin modelliert sind. Anders wird es, sobald ein Agent Entscheidungen mit unmittelbarer Wirkung auf Personen vorbereitet – dann ist die Einordnung eine Aufgabe für Compliance, nicht für die Entwicklung.

Bei der Datenhaltung ist Souveränität kein Entweder-oder, sondern ein Weg mit vier Stufen: Cloud direkt für unkritische Daten und schnelle Wertnachweise, Cloud mit vorgelagerter Anonymisierung, eine gehostete Plattform mit EU-Datenhaltung als pragmatischer Mittelweg und self-hosted mit lokalen Modellen, wenn keine Daten das Haus verlassen dürfen. Du steigst dort ein, wo Daten, Reife und Risiko es erlauben – häufig mit unterschiedlichen Stufen für unterschiedliche Use Cases.

Das ist eine praxisorientierte Einordnung und keine Rechtsberatung. Die konkrete Bewertung eines Anwendungsfalls gehört in die Hände der zuständigen Stellen im Unternehmen.

Wo der Nutzen in der Praxis entsteht

Agentische Automatisierung lohnt sich dort, wo Vorgänge wiederkehren, mehrere Systeme beteiligt sind und die eigentliche Entscheidung klein, die Vorarbeit aber groß ist.

  • Service und Support: Der Agent liest die Anfrage, holt passende Wissensartikel und formuliert einen Antwortentwurf inklusive Quellenangaben. Der Mitarbeitende prüft und sendet. Eine Feldstudie von Brynjolfsson, Li und Raymond mit 5.172 Support-Mitarbeitenden (QJE 2025) weist für KI-Unterstützung rund 15 Prozent mehr gelöste Anfragen pro Stunde aus.
  • Eingangsrechnungen: Lieferant, Betrag, Bestellnummer, Leistungszeitraum und Zahlungsziel extrahieren, mit ERP und Freigabelogik abgleichen, Standardfälle direkt in die richtige Freigabestrecke, Abweichungen in die Prüfung.
  • Ticket-Triage: Thema, Dringlichkeit, Kundentyp und Eskalationssignale erkennen, nach definierten Regeln priorisieren und an das passende Team leiten.
  • On- und Offboarding: HR-Events lösen anhand von Rolle, Standort und Team die passenden Workflows aus – und beim Austritt den systematischen Entzug der Zugänge mit vollständigem Nachweis.

Das gemeinsame Muster: Der Agent übernimmt Recherche, Vorarbeit und Routine. Die kritische Entscheidung bleibt beim Menschen. So entstehen Geschwindigkeit und Qualität, ohne dass die Nachvollziehbarkeit verloren geht.

Die ersten 90 Tage

Ein phasenweises Vorgehen führt von der Idee zum belastbaren Betrieb, ohne den Umweg über ein Großprojekt.

Tag 0 bis 30 – Discovery und Architektur. Kernteam aus IT, Fachbereich, Data und Security bilden. Use Cases identifizieren und priorisieren, je Fall Risiko und Machbarkeit bewerten, Datenquellen und Werkzeuge inventarisieren. Ergebnis: eine bewertete Use-Case-Liste, eine Architekturskizze und ein abgestimmtes Security- und Compliance-Review.

Tag 31 bis 60 – Pilot. Einen einzigen Use Case kontrolliert umsetzen, Werkzeuge anbinden, Logging und Freigabepunkte von Anfang an mitbauen, iterativ nachschärfen. Ergebnis: ein laufender Workflow auf Testdaten, eine dokumentierte Konfiguration und erste Kennzahlen gegen die Baseline.

Tag 61 bis 90 – Härtung und Skalierung. Schwachstellen beheben, Betriebsmodell aufsetzen – Dashboards, Alarme, Rollen –, Governance abnehmen. Ergebnis: ein produktiv geschalteter Agent mit Runbook, Monitoring und einer belastbaren Entscheidung darüber, was als Nächstes kommt.

Der Rahmen ist anpassbar. Entscheidend ist nicht die Kalenderlogik, sondern dass innerhalb eines Quartals ein greifbares Resultat vorliegt, das die weitere Investition trägt oder ehrlich widerlegt.

Den eigenen Reifegrad einschätzen

Ob ein Unternehmen bereit für produktive Agenten ist, entscheidet sich an sechs Dimensionen: Datenqualität, Prozessreife, Integrationsgrad, Security- und Compliance-Readiness, Betriebs- und Monitoring-Fähigkeit sowie Change-Management. Aufschlussreich ist weniger das Gesamtergebnis als die Streuung – meist ist die IT bereit und der Fachbereich zögert, oder die Datenlage ist gut und die Policy-Frage ungeklärt.

➤ Den vollständigen Self-Readiness-Check mit Auswertungshilfe und 90-Tage-Roadmap findest du in unserem Workbook Agentic AI mit n8n im Enterprise.

Was jetzt sinnvoll ist

  • Grenz den ersten Use Case so eng ab, dass du ein Abnahmekriterium formulieren kannst.
  • Leg früh fest, welche Aktionen frei laufen, welche Freigabe brauchen und welche gesperrt sind.
  • Vergib Rechte pro Werkzeug, nicht pro Agent – und reiche die Identität des Nutzers durch.
  • Bau Logging, Freigabepunkte und Fehlerpfade beim Piloten mit ein, nicht danach.
  • Miss Erfolgsquote und Kosten je Aufgabe ab Tag eins, sonst bleibt die Bewertung Geschmackssache.
  • Klär die Frage, welche Daten das Haus verlassen dürfen, vor dem ersten Prototyp.

Agentic AI ist im Unternehmenseinsatz kein Hype mehr, sondern machbar – aber nur dort, wo Architektur, Governance und Betrieb von Anfang an zusammen gedacht werden.

Häufige Fragen zu Agentic AI

Agentic AI beschreibt KI-Systeme, die ein Ziel verfolgen und dafür eigenständig Schritte planen, Informationen beschaffen, Werkzeuge einsetzen und Handlungen vorbereiten oder ausführen. Im Unternehmenskontext bedeutet das keine vollständige Autonomie, sondern kontrollierte Autonomie innerhalb definierter Regeln, Rollen und Freigaben.
Ein Chatbot beantwortet Fragen und liefert Text. Ein Agent erzeugt einen Arbeitsplan, ruft Systeme auf, reichert Kontext an und schließt eine Aufgabe ab – er liefert ein Ergebnis im Prozess statt einer Antwort im Chatfenster.
Klassische Workflows sind deterministisch: Ein Schritt folgt dem nächsten. Agenten wählen bei Abweichungen alternative Wege und bereiten aus dem Kontext passende Entscheidungen vor. RPA automatisiert Klickpfade und ist stark bei stabilen, wiederholbaren Aufgaben; Agenten sind stärker bei variantenreichen Fällen und unstrukturierten Inputs. RPA kann Teil des Werkzeugkastens eines Agenten sein.
Vorgänge, die wiederkehren, mehrere Systeme berühren und viel Vorarbeit bei kleiner eigentlicher Entscheidung erfordern – etwa Service-Anfragen, Ticket-Triage, Rechnungsverarbeitung oder Onboarding. Ungeeignet sind Prozesse ohne dokumentierte Regeln und ohne belastbare Datenlage.
Rechte werden pro Werkzeug vergeben, nicht pro Agent. Jedes Werkzeug ist im Workflow definiert und hat minimale Rechte. Arbeitet der Agent im Auftrag eines Nutzers, verwendet er dessen Berechtigungen statt eines technischen Sammelkontos. Jeder Aufruf wird protokolliert.
Als Minimum: Erfolgsquote je Aufgabentyp, Kosten je Aufgabe, Korrekturquote bei Freigaben sowie Fehler- und Abbruchrate mit Ursache. Dazu harte Limits für Token-Verbrauch und Laufzeit sowie Alarme bei Abweichungen vom Normalverhalten.
Nein. Es gibt vier Zugangswege mit unterschiedlicher Datenexposition: Cloud direkt, Cloud mit vorgelagerter Anonymisierung, eine gehostete Plattform mit EU-Datenhaltung und vollständig self-hosted mit lokalen Modellen. Die Wahl kann je Use Case unterschiedlich ausfallen.
Ein realistischer Rahmen sind 90 Tage: Discovery und Architektur in den ersten 30 Tagen, Pilotumsetzung bis Tag 60, anschließend Härtung, Governance-Abnahme und die Entscheidung über die Skalierung.

Hinweis: Dieser Beitrag wurde mit Unterstützung von KI erstellt oder überarbeitet. Inhalte, Struktur und fachliche Bewertung stammen aus der Projektpraxis von cimt; redaktionelle Prüfung und Freigabe erfolgen durch die Autorinnen und Autoren.

Kontakt

Rouven Homann, Vorstand in der cimt Gruppe
Rouven HomannVorstand in der cimt Gruppe

Heimspiel KI in Frankfurt – live erleben

Am 25. November zeigen wir im Stadion von Eintracht Frankfurt, wie aus KI-Piloten produktive Prozesse werden – mit echten Projekten, Praxisberichten und Networking. Gemeinsam mit Camunda. Teilnahme kostenfrei, Plätze begrenzt.

Zum Heimspiel KI Frankfurt

Das könnte Sie auch interessieren

Nach oben scrollen