KI-Agenten erfolgreich implementieren

Die Geschichte wiederholt sich seit 2023 in vielen deutschen Unternehmen: Ein Bereich startet mit großer Euphorie ein KI-Pilotprojekt, baut in wenigen Wochen einen beeindruckenden Demo-Agenten, präsentiert ihn der Geschäftsführung – und versandet danach. Die Pilotumgebung wird nie produktiv. Use-Cases werden nicht skaliert. Investitionen versickern in Excel-Sheets mit dem Vermerk „Innovationsbudget“.

Die Ursachen sind in den meisten Fällen erstaunlich ähnlich: Es fehlt eine klare Entscheidung darüber, ob das Programm strategisch, organisatorisch und technologisch aufgesetzt wird. Es wird auf Tool-Ebene gestartet, aber nicht auf Architektur-Ebene gedacht. Es fehlt die Brücke zwischen Innovationsabteilung und operativer Linie. Und die schwierigsten Themen – Governance, Datenqualität, Change Management – werden nach hinten verschoben.

Die gute Nachricht: Die Erfolgsfaktoren sind erlernbar. Wer einen klaren Plan hat, beginnt mit den richtigen zwei oder drei Use-Cases, baut eine tragfähige Architektur und investiert in Verankerung, kommt in 60 bis 120 Tagen zu einem produktiven Agenten – und in 12 bis 18 Monaten zu einem skalierten Programm.

Wir haben aus Dutzenden Programmen ein Vorgehensmodell destilliert, das sich in der Praxis bewährt hat. Es teilt das Projekt in drei Schichten: Discovery, MVP und Skalierung. Jede Schicht hat eigene Phasen, Ergebnisse und Beteiligte. Die folgenden 12 Phasen sollten Sie planen, dokumentieren und mit klaren Übergaben verknüpfen.

Die häufigste Fehlentscheidung am Anfang ist die Wahl des falschen Use-Cases. Was sich gut präsentiert, ist nicht automatisch wirtschaftlich. Was wirtschaftlich aussieht, ist nicht automatisch technisch tragfähig. Und was technisch tragfähig ist, hat möglicherweise zu wenig Volumen, um den ROI zu rechtfertigen.

Wir empfehlen ein Bewertungsraster mit fünf Achsen: Geschäftswert (Volumen × Wirkung), technische Machbarkeit (Datenverfügbarkeit, Tool-Reife), Risikoprofil (regulatorisch, reputativ), organisatorische Bereitschaft (Sponsor, Linienverankerung) und strategischer Hebel (Plattform-Effekt, Lerneffekt).

In der Praxis sind die wertvollsten Einstiegs-Use-Cases meist im Service- und Support-Bereich, in der Sachbearbeitung mit hohem Routineanteil oder im Vertriebs-Funnel mit hoher Anfrage-Frequenz. Wer mit einem komplexen, geschäftskritischen Use-Case startet (z.B. automatisierte Kreditentscheidung), riskiert lange Projektlaufzeiten und enttäuschte Erwartungen.

Wer den ersten Agenten als isolierte Punktlösung baut, zahlt beim zweiten und dritten Agenten doppelt. Architektur entscheidet über Skalierbarkeit, Wirtschaftlichkeit und Sicherheit. Eine Plattform-Architektur ist die Investition, die sich in jeder Phase auszahlt.

Drei zentrale Bausteine bestimmen die Plattform: Erstens das Modell-Gateway als zentrale Anlaufstelle für alle LLM-Aufrufe – mit Routing, Caching, Cost-Control, Observability und Policy-Enforcement. Zweitens die Tool-Layer als zentrale Bibliothek für alle externen Aufrufe (CRM, ERP, DMS, Datenbanken) – mit einheitlichen Berechtigungen, Audit-Trails und Wiederverwendbarkeit. Drittens die Memory-Schicht für Kurz- und Langzeitkontext, RAG-Integration und Wissensquellen.

Daneben gehören Beobachtbarkeit, Trace-Logging, Auswertungs-Pipeline und Sicherheits-Scanner zur Grundausstattung. Diese Bausteine müssen nicht alle in den ersten 60 Tagen perfekt sein – sie müssen nur architektonisch vorgesehen sein und schrittweise wachsen.

Die größte Überraschung in praktisch jedem KI-Agenten-Projekt: Das LLM selbst ist die einfachste Komponente. Der Aufwand steckt in den Schnittstellen, Adaptern, Berechtigungen und Datenflüssen, die der Agent braucht, um wirklich nützlich zu sein. 60 bis 70 Prozent des Implementierungsaufwands entfallen auf den Tool-Layer.

Konkret: Anbindung an CRM (Salesforce, HubSpot, Dynamics), ERP (SAP, Microsoft Dynamics, Aareon), Service-Plattformen (ServiceNow, Zendesk, Freshdesk), Dokumentenmanagement (DMS, SharePoint), interne Datenbanken, Mailsysteme, Telefonie. Jede dieser Schnittstellen braucht definierte Endpunkte, Authentifizierung, Rate-Limits, Fehlerbehandlung und Berechtigungs-Mapping.

Wir empfehlen eine Tool-Bibliothek mit klaren Schemas (z.B. OpenAPI), die der Agent aufrufen kann, statt direkter Punkt-zu-Punkt-Verbindungen. So bleiben Wartung, Sicherheit und Wiederverwendung beherrschbar. Jedes neue Tool wird einmal in die Bibliothek aufgenommen und steht dann allen Agenten zur Verfügung.

Ein gutes MVP ist nicht ein abgespecktes Produkt, sondern eine vollständige End-to-End-Strecke für einen klar abgegrenzten Use-Case. Es enthält den Agenten, alle relevanten Tool-Anbindungen, einen Validierungsdatensatz, Eskalationspfade und ein erstes Monitoring.

Die Mindest-Komponenten eines MVP: Ein Agent mit klar definiertem Aufgabenbereich (z.B. Mieter-Stammdatenänderung), Anbindung an die relevanten 2–4 Quellsysteme, ein Validierungsdatensatz mit 50–200 realen Vorgängen, eine Eval-Pipeline (Erfolgsquote, Eskalationsrate, Genauigkeit), ein Schatten-Modus-Setup für die spätere Migration, ein Eskalationspfad mit klarem Übergabe-Protokoll an Menschen.

Vier Wochen sind ein realistischer Zeitrahmen für ein MVP, wenn Use-Case und Architekturentscheidung sauber getroffen wurden. Wer länger braucht, hat in der Regel den Use-Case zu groß geschnitten oder die Architekturschicht überspringt.

Bevor ein Agent mit echten Kunden, Mietern, Patienten oder Mitarbeitenden interagiert, muss er im Schatten-Modus laufen. Das bedeutet: Der Agent verarbeitet reale Vorgänge parallel zum bestehenden Prozess, seine Antworten werden aber nicht ausgespielt, sondern verglichen und ausgewertet.

Der Schatten-Modus liefert drei wichtige Einsichten: Erstens die Genauigkeit (wo weicht der Agent vom Goldstandard ab?), zweitens die Eskalationsquote (wie viele Vorgänge müssen menschlich entschieden werden?), drittens die Wirtschaftlichkeit (wie viel Bearbeitungszeit spart der Agent tatsächlich?). Erst wenn diese Kennzahlen eine festgelegte Schwelle erreichen, geht der Agent in die Pilot-Produktion.

Der Schatten-Modus dauert typischerweise 2 bis 6 Wochen, je nach Volumen und Komplexität. Er ist unbequem, weil er Wartezeit erzeugt. Aber er ist die wirksamste Maßnahme gegen blamable Live-Fehler und gegen einen Vertrauensverlust beim Sponsor.

Die Pilot-Produktivnahme erfolgt nicht für alle Vorgänge auf einmal, sondern entlang klar definierter Limit-Kriterien. Typische Limits: nur einfache Vorgänge mit hoher Sicherheit, nur ein Kanal (z.B. Web-Chat), nur in Geschäftszeiten mit menschlicher Aufsicht, nur ein Geschäftsbereich oder ein Standort.

Diese Limits werden in den ersten Wochen schrittweise gelockert, sobald die Kennzahlen aus dem Schatten-Modus auch in der Live-Produktion stabil bleiben. Jede Lockerung wird dokumentiert, beobachtet und im Bedarfsfall zurückgenommen.

Wichtig ist die Eskalationskette: Was passiert, wenn der Agent unsicher ist? Was passiert bei einem Sicherheitsvorfall? Wer wird benachrichtigt, wer entscheidet, wer kommuniziert mit dem Kunden? Diese Fragen müssen vor der Produktivnahme geklärt und mit allen Beteiligten geübt sein.

Ein KI-Agent verändert Arbeitsabläufe – auch wenn er nur Routine übernimmt. Mitarbeitende müssen verstehen, was der Agent tut, was er nicht tut, wie sie ihn nutzen und wie sie ihn verbessern. Schulung ist deshalb keine Option, sondern integraler Bestandteil der Implementierung.

Wir empfehlen drei Schulungs-Ebenen: Erstens eine Grundschulung für alle Beteiligten (was ist ein KI-Agent, was darf er, was nicht). Zweitens eine Anwender-Schulung für die Mitarbeitenden, die täglich mit dem Agenten arbeiten (Übergabe-Protokolle, Eskalation, Feedback-Schleife). Drittens eine Power-User-Schulung für die Personen, die den Agenten weiterentwickeln (Prompt-Engineering, Eval-Auswertung, Tool-Anbindung).

Linienverankerung bedeutet: Der Agent gehört nach der Pilot-Phase nicht mehr dem Innovationsteam, sondern der operativen Linie. Es muss klare Eigentümerschaft geben (Product Owner), klare Eskalations- und Verbesserungspfade, klare Budgets für Betrieb und Weiterentwicklung. Programme, die diese Übergabe nicht sauber machen, sterben in der Innovation Lab.

Der zweite Use-Case sollte 30–50 Prozent schneller umzusetzen sein als der erste – wenn die Plattform stimmt. Das ist die wichtigste Kennzahl für die Skalierungsphase. Wer den zweiten Use-Case ähnlich lang braucht wie den ersten, hat den Plattform-Gedanken nicht umgesetzt.

Wiederverwendbar müssen sein: Modell-Gateway-Infrastruktur, Tool-Adapter, Memory-Schicht, RAG-Pipeline, Observability, Eval-Pipeline, Sicherheits- und Compliance-Bausteine. Was für den ersten Use-Case gebaut wurde, muss für den zweiten nur konfiguriert oder erweitert werden.

Auf organisatorischer Ebene zahlt sich ein zentrales Plattform-Team aus, das die gemeinsame Infrastruktur betreibt und weiterentwickelt, während dezentrale Squads die einzelnen Use-Cases verantworten. Das Plattform-Team ist der Garant für Architektur, Sicherheit und Wirtschaftlichkeit – die Squads sind nah an den Geschäftsprozessen.

Governance ist kein Bremsklotz, sondern ein Beschleuniger: Wer von Anfang an klare Regeln, Rollen und Verantwortlichkeiten definiert, kommt schneller in die produktive Skalierung als wer Governance nachträglich aufpfropft.

Mindest-Bausteine: Datenschutz-Folgenabschätzung (DSFA) pro Use-Case, klare Auftragsverarbeitungsverträge mit allen Modell- und Cloud-Anbietern, dokumentierte Datenflüsse, Audit-Trails über alle Agent-Entscheidungen, regelmäßige Sicherheits- und Halluzinations-Tests, klare Ansprechpartner für Compliance und Datenschutz.

Mit dem EU AI Act kommen für viele Use-Cases zusätzliche Pflichten hinzu (Risikoeinstufung, Transparenz, Mensch-in-der-Schleife, Logging). Wir empfehlen, diese Pflichten frühzeitig in die Architektur einzuziehen und nicht als Zusatzprojekt zu führen.

Aus Hunderten von Implementierungen kennen wir wiederkehrende Muster, an denen Programme scheitern. Wer sie kennt, kann sie vermeiden:

Ein Kern-Team von 3–5 Personen reicht für die ersten zwei Use-Cases. Es besteht aus: Product Owner (Geschäftsseite), AI Engineer (LLM, Prompts, Eval), Software Engineer (Tool-Anbindung, Backend), Data Engineer (RAG, Datenflüsse), optional UX/Conversation Designer.

Daneben braucht es einen klaren Sponsor auf C-Level oder VP-Ebene, der Budget, Eskalation und politische Rückendeckung sicherstellt. Ohne Sponsor wird ein KI-Agenten-Programm nicht über die ersten Hindernisse kommen.

Mit dem zweiten und dritten Use-Case wächst das Team auf 8–12 Personen, oft strukturiert in ein zentrales Plattform-Team und mehrere dezentrale Use-Case-Squads. Outsourcing-Modelle sind möglich, sollten aber das interne Team nicht ersetzen, sondern verstärken.