KI-Agenten für Unternehmen: Architektur, Use Cases und Einführung 2026

Was ein KI-Agent wirklich ist — und was nicht

Der Begriff KI-Agent wird gerade so inflationär verwendet, dass er kaum noch trennscharf ist. Nüchtern technisch: ein KI-Agent ist ein System, das auf Basis eines Sprachmodells eigenständig Ziele in mehreren Schritten verfolgt, dabei externe Werkzeuge aufruft und seine Schritte an Zwischenergebnissen anpasst.

Drei Eigenschaften sind dabei entscheidend: Tool Use (der Agent kann APIs, Datenbanken, Dateisysteme aufrufen), Mehrschritt-Planung (er zerlegt eine Aufgabe in Subschritte) und Feedback-Loop (er bewertet Zwischenergebnisse und korrigiert).

Ein Chatbot, der nur eine Antwort generiert, ist kein Agent. Ein RAG-System, das Dokumente sucht und zusammenfasst, ist auch keiner — solange es einen festen Ablauf hat. Erst wenn das System selbst entscheidet, welche Werkzeuge in welcher Reihenfolge aufgerufen werden, wird daraus ein Agent.

• Tool Use — Aufruf externer Funktionen (CRM-Lookup, E-Mail senden, Datenbank-Update, Code-Ausführung)
• Multi-Step Planning — Zerlegung eines Ziels in Subschritte, dynamisch statt vorprogrammiert
• Feedback-Loop — Bewertung von Zwischenergebnissen, Korrektur des Plans
• Optional: Memory — Zwischenstände persistieren, an Nutzer- oder Sitzungsverlauf andocken

Chatbot, RAG, Workflow, Agent — die Abgrenzung

Diese Konzepte werden oft vermischt. Praktisch macht es einen großen Unterschied, was Sie bauen — Aufwand, Kosten und Risiko unterscheiden sich um Größenordnungen.

• Chatbot — Frage rein, Antwort raus. Kein Tool Use, kein Plan. Aufwand: niedrig. Risiko: Halluzination.
• RAG-System — Frage → Dokumente suchen → Antwort generieren. Linearer Ablauf. Aufwand: mittel. Risiko: schlechte Suche, fehlende Quellen.
• Workflow-KI — vordefinierter Ablauf mit KI an einzelnen Stellen (z. B. n8n + LLM-Knoten). Aufwand: mittel. Risiko: Brüche bei Edge Cases.
• Agent — KI entscheidet selbst, welche Schritte und Werkzeuge. Aufwand: hoch. Risiko: nicht-deterministisch, schwer testbar, schwer monitorbar.

Wo KI-Agenten 2026 wirklich produktiv laufen

Die ehrliche Antwort: noch nicht so viele Stellen, wie Marketing suggeriert. Die produktiven Use Cases haben drei Eigenschaften gemeinsam — gut definierte Werkzeuge, klare Erfolgsmessung, akzeptable Fehlerraten.

• Software-Engineering — Code-Agents wie Claude Code oder Cursor: Code schreiben, Tests laufen lassen, Fehler iterativ beheben
• Customer Support Triage — eingehende Tickets klassifizieren, Stammdaten anreichern, in CRM einsortieren, Routine-Antworten vorbereiten
• Research und Briefings — strukturierte Recherche zu Marktthemen, Wettbewerbern, regulatorischen Updates
• Procurement und Beschaffung — Anfragen an Lieferanten, Angebotsvergleich, Bestellauslösung mit Human-in-the-Loop
• Datenextraktion und ETL — komplexe Dokumente lesen, in strukturierte Felder überführen, in Zielsysteme schreiben

Architektur: was unter der Haube läuft

Ein produktionsfähiger KI-Agent besteht aus vier Bausteinen: dem LLM als Steuerungseinheit, einer Tool-Schicht mit klar definierten Funktionen, einem Orchestrator, der den Loop koordiniert, und einem Beobachtungs-Layer für Logging, Tracing und Cost Control.

Die meisten Frameworks (LangGraph, OpenAI Agents SDK, Anthropic Tool Use, Microsoft AutoGen) liefern Variationen dieser Struktur. Der wichtigste Unterschied liegt nicht im Framework, sondern in der Disziplin bei der Tool-Definition und im Cost-Cap pro Run.

• LLM-Schicht — Foundation Model mit Tool-Calling-Fähigkeit (GPT-4, Claude, Gemini)
• Tool-Schicht — typisierte Funktionen mit klarer Beschreibung, Validierung, Fehlerbehandlung
• Orchestrator — Loop-Steuerung, Stop-Bedingungen, Max-Iteration-Cap, Re-Planning
• Memory — Sitzungs-, Kurzzeit- und Langzeitspeicher (Vector DB, Key-Value, strukturierte Tabellen)
• Observability — Tracing pro Run, Token-Kosten pro Schritt, Tool-Erfolgsraten, Halluzinations-Detektion
• Guardrails — PII-Filter, Output-Validierung, harte Stop-Regeln (z. B. nie ohne Bestätigung Geld bewegen)

Wo Agenten in der Praxis scheitern

Die meisten gescheiterten Agenten-Projekte scheitern nicht am Modell, sondern an einem von vier Punkten. Es lohnt sich, vor dem ersten Sprint diese Punkte aktiv zu adressieren.

• Tool-Definitionen sind unscharf — der Agent ruft Funktionen falsch auf, weil Beschreibung und Schema nicht eindeutig sind
• Fehlende Stop-Bedingungen — Agenten loopen, weil keine harte Iterations-Grenze gesetzt ist, Cost explodiert
• Nicht-deterministische Pfade — derselbe Input führt zu unterschiedlichen Antworten; Tests werden flaky
• Keine Eskalation an Menschen — Edge Cases laufen still in falsche Aktionen statt einen Menschen zu involvieren
• Keine Erfolgsmetrik — niemand kann sagen, ob der Agent gut funktioniert; Optimierung wird Bauchgefühl

Sicherheit, Compliance, EU AI Act

Agenten verschärfen die typischen LLM-Risiken: sie können Werkzeuge aufrufen, also Daten verändern, Mails senden, Geld bewegen. Ein klassischer Prompt-Injection-Angriff wird in einer Agentenumgebung schnell zu einer echten Datenpanne.

Drei Themen müssen in Agentenprojekten von Tag eins behandelt werden: Berechtigungen pro Tool, Trennung zwischen Lese- und Schreib-Aktionen, und Confirmation-Gates für irreversible Schritte. Im Kontext des EU AI Acts fallen viele Agentenanwendungen — abhängig vom Use Case — unter die Hochrisiko-Klassifizierung.

• Least Privilege — pro Tool nur die minimal nötigen Rechte
• Read vs. Write Separation — schreibende Tools brauchen explizite Bestätigung
• Prompt Injection Defense — Eingaben aus externen Quellen (E-Mails, PDFs, Webseiten) sind nicht vertrauenswürdig
• Audit Trail — jeder Tool-Call mit Trace-ID, Input, Output, Zeitstempel
• EU AI Act Klassifizierung — Agenten in HR, Kredit, kritischer Infrastruktur sind Hochrisiko

Einführung im Unternehmen: ein realistischer Pfad

Wer Agenten produktiv einführen will, sollte nicht mit dem ehrgeizigsten Use Case starten. Bewährt hat sich ein dreistufiger Pfad.

• Phase 1 — Read-only Agent — der Agent darf nur lesen, nie schreiben. Z. B. Daten aus drei Quellen zusammenfügen und zusammenfassen. Risiko gering, Lerneffekt hoch.
• Phase 2 — Write mit Human-in-the-Loop — der Agent darf Aktionen vorschlagen, ein Mensch bestätigt vor Ausführung. Erste echte Produktivität.
• Phase 3 — Autonom mit Guardrails — der Agent darf für klar abgegrenzte Aktionen autonom handeln, mit harten Limits und Eskalation an Menschen für alles außerhalb des Korridors.
• Querschnittsthema — Eval-Framework — vor jeder Phase ein Set von Beispiel-Inputs mit erwartetem Verhalten. Ohne Evals kein Fortschritt messbar.

Build vs. Buy: agentische Plattformen 2026

Der Markt für agentische Plattformen ist 2026 noch jung, aber wächst schnell. SAP Joule, Salesforce Agentforce, Microsoft Copilot Studio, ServiceNow Now Assist — alle großen Suiten bauen Agenten in ihre Plattformen ein. Für Standard-Workflows in diesen Ökosystemen lohnt sich ein Eigenbau selten.

Eigenbau lohnt sich, wenn Ihr Use Case spezifisch für Ihr Produkt oder Ihre Domäne ist, wenn Sie eigene Daten und Tools tief integrieren oder wenn die Plattform-Lösung wesentliche Kontrollpunkte (Logging, Modell-Wahl, Cost-Cap) nicht zulässt.