14. Juni 2026 · 1.759 Wörter · 9 Min. Lesezeit

Die Lücke zwischen Agentic AI und Unternehmensrealität

Rund 40 Werkzeuge in fünf Monaten. Allein gebaut.

Einige davon nutze ich täglich, andere laufen still als Dienst im Hintergrund. Manche sind Experimente geblieben, andere sind inzwischen echte Arbeitswerkzeuge. Entstanden sind sie nicht als Sammlung von Demos, sondern über sehr unterschiedliche Arbeitsbereiche hinweg: Mail-Automation, Dokumenten-RAG, Wissensmanagement, native Apps, Server-Dienste, Orchestrierung und Observability.

Vor zwei Jahren hätte diese Bandbreite nach einem kleinen Produktteam geklungen: Produktverständnis, Backend, Frontend, Infrastruktur, Testing, Dokumentation, Betrieb. Heute fallen diese Rollen nicht einfach weg, aber ihre Grenzen verschieben sich. Product Owner bauen Prototypen, Entwickler schreiben PRDs, Testfälle und Dokumentation, Fachbereiche testen Ideen direkt am System, und Infrastruktur, Betrieb und Monitoring werden Teil desselben Workflows.

Der Punkt ist nicht, dass eine Person plötzlich ein ganzes Produktteam ersetzt. Der Punkt ist, dass sich die Schleife zwischen Problem, Lösung, Test und Betrieb massiv verkürzt hat. Agentische Workflows helfen dabei, Aufgaben zu planen, umzusetzen, zu prüfen und nachzubessern, nicht einmalig, sondern in Schleifen, bis ein brauchbares Ergebnis entsteht. Was früher Wochen oder Monate gedauert hätte, entsteht heute oft in Tagen oder Wochen als erste belastbare Version.

Das ist keine Heldengeschichte. Es ist ein Signal dafür, wie groß die Lücke inzwischen geworden ist.

Was heute möglich ist

Viele der Tools, die dabei entstanden sind, sehen Aufgaben verdächtig ähnlich, die Unternehmen heute noch manuell erledigen.

E-Mail-Triage und Eingangsbearbeitung

Ein Werkzeug liest meinen Posteingang, erkennt relevante Nachrichten und übersetzt das Wichtige in konkrete Aufgaben. Es extrahiert den Kontext und legt die Aufgaben per API in meiner Task-App an, die ich anschließend abarbeite.

Genau hier trennt sich eine Demo von einem System, dem man trauen kann. Eine E-Mail ist nie vertrauenswürdiger Input, sie kann eine Prompt Injection enthalten, also versteckte Anweisungen an die KI. Deshalb wird ihr Inhalt als Daten behandelt und nicht als Befehl. Das Werkzeug darf genau eine Sache: einen Aufgabenvorschlag in meiner eigenen Liste anlegen. Es kann keine Mails versenden, nichts löschen, nichts bezahlen, nichts nach außen auslösen. Der schlimmste Fall einer manipulierten Mail ist damit ein überflüssiger Eintrag, den ich wegklicke. Die Entscheidung bleibt beim Menschen, automatisiert wird nur das Sortieren.

Dokumenten-Self-Service und Wissensmanagement

RAG über Projekt- und Wissensdokumente: Fragen in natürlicher Sprache, Antworten mit Quellenangaben. Statt dass Wissen in Ordnern, Wikis oder Postfächern versauert, wird es abfragbar.

Automatische Dokumentation und Anleitungen

Aus Stichpunkten, Code oder Notizen entstehen Wiki-Seiten, Tutorials und technische Dokumentation. Also genau die Dokumentation, von der alle wissen, dass sie wichtig ist, und die trotzdem oft niemand schreibt.

Agentische Pipelines

Workflows, die Quellen scannen, Informationen bewerten, Inhalte generieren und Ergebnisse tracken. Sie geben nicht nur Antworten, sondern koordinieren Arbeitsschritte.

Attention-Filtering und Zusammenfassungen

Aus Hunderten Artikeln, E-Mails und Quellen entsteht eine kurze, relevante Übersicht: Was ist wichtig? Was betrifft mich? Was kann ich ignorieren?

Server- und Infrastruktur-Automatisierung

Setup, Betrieb, Dokumentation, Monitoring und wiederkehrende Wartungsschritte, also Dinge, die sonst viel manuelle Arbeit erzeugen.

Und darunter liegt die eigentlich spannende Schicht: ein Orchestrator, der mehrere Agenten koordiniert, bis eine Aufgabe erledigt ist. Das Ganze läuft auf eigener Infrastruktur, erreichbar über eine gesicherte Oberfläche, über die ich viele persönliche Workflows automatisiere. Eine Art persönliches “Life OS”, aber unter eigener Kontrolle: eigene Infrastruktur, authentifizierter Zugang, eigene Datenhaltung. Dazu kommt eine Observability-Schicht, die Token-Verbrauch und Kosten sichtbar macht.

Das ist nicht einfach “ich nutze ein KI-Tool”, sondern eine Steuerungsebene für Arbeit. Und genau an dieser Ebene hängt in Unternehmen die eigentliche Adoption.

Die Lücke ist selten die Technologie

Das ist die eine Welt: was heute möglich ist. Die andere Welt ist das, was in vielen Unternehmen tatsächlich ankommt. Und dazwischen liegt meistens kein Technologie-Gap.

Die Modelle werden besser, die Tools zugänglicher, die Infrastruktur verfügbarer. APIs, RAG, Agenten, lokale Modelle, Cloud-Angebote, Orchestrierung, Observability: vieles davon ist heute schon real einsetzbar. Trotzdem bleibt KI in vielen Organisationen ein Pilotprojekt am Rand. Ein Workshop, ein Chatbot, ein interner Demo-Case, ein “Wir sollten mal ChatGPT einführen”. Aber der Sprung in echte, produktive, messbare Workflows bleibt oft aus.

Warum? Weil die eigentlichen Hürden früher beginnen.

KI ist kein Startpunkt

Der wichtigste Punkt kommt noch vor Technologie, Governance oder Kosten: KI ist kein Startpunkt, sondern ein möglicher Lösungsbaustein. Der Startpunkt ist ein scharf verstandenes Problem. Wer mit “Wir brauchen KI” anfängt, ist eigentlich schon einen Schritt zu spät.

Die bessere Frage lautet: Welches Problem wollen wir lösen? Daran hängen viele weitere Fragen.

• Wie arbeitet der Bereich wirklich?
• Wo entstehen Wartezeiten?
• Wo entstehen Medienbrüche?
• Wo wird doppelt gearbeitet?
• Welche Entscheidungen sind kritisch?
• Welche Daten sind verlässlich?
• Wo ist Automatisierung sinnvoll, und wo gefährlich?
• Was sollte ein System vorbereiten, was entscheiden, was nur sichtbar machen?

Das habe ich selbst erlebt, als ich eine GenAI-Plattform für eine Fachabteilung aufgebaut habe. Der lange Teil war nicht die technische Umsetzung, sondern die Domäne tief genug zu verstehen, um überhaupt zu wissen, welches Problem sich lohnt.

Erst wenn man die Arbeit wirklich versteht, kann man entscheiden, ob KI überhaupt die richtige Lösung ist, und falls ja, welche Art von KI: ein Chatbot, ein RAG-System, ein Agent, eine Workflow-Automatisierung, ein Assistenzsystem mit Human-in-the-loop, oder vielleicht erst einmal gar keine KI, sondern bessere Daten, bessere Prozesse oder klarere Verantwortlichkeiten.

KI löst kein unscharf verstandenes Problem. Im schlimmsten Fall skaliert sie nur die Unschärfe.

Technologieverständnis im Management

Der zweite Engpass ist Technologieverständnis. Viele Entscheider kennen KI vor allem als Chatbot, und das ist verständlich: Für viele Menschen war ChatGPT der erste echte Kontakt mit generativer KI. Aber agentische Systeme sind keine bessere Suchmaschine. Sie können Arbeit vorbereiten, strukturieren, ausführen, prüfen und koordinieren, sie können Tools aufrufen, Daten verarbeiten, Aufgabenketten planen, Zwischenergebnisse bewerten und mit Feedbackschleifen weiterarbeiten.

Wer KI nur als Chatfenster versteht, sieht diese Use Cases nicht. Dann bleibt die Strategie auf der Ebene “Wir sollten ChatGPT einführen”, und das ist zu wenig. Nicht, weil ChatGPT unwichtig wäre, sondern weil der eigentliche Hebel nicht darin liegt, jedem Mitarbeitenden ein weiteres Tool zu geben. Der Hebel liegt darin, echte Arbeitsabläufe neu zu denken.

• Welche wiederkehrenden Entscheidungen können vorbereitet werden?
• Welche Dokumente können automatisch erschlossen werden?
• Welche Supportfälle können vorqualifiziert werden?
• Welche Reports müssen nicht mehr manuell entstehen?
• Welche Fachprozesse könnten durch Agenten unterstützt, aber kontrolliert bleiben?

Dafür braucht Management kein Detailwissen über jedes Modell. Aber es braucht ein mentales Modell davon, was diese Systeme können, wo ihre Grenzen liegen und wie sich Arbeit dadurch verändert.

Verantwortung für Adoption

Der dritte Punkt ist Verantwortung. In vielen Unternehmen ist niemand wirklich zuständig für KI-Adoption. IT stellt vielleicht Tools bereit, Fachbereiche haben Ideen, Legal und Compliance haben berechtigte Bedenken, Management will Innovation sehen, einzelne Teams bauen Piloten. Aber wer trägt das Mandat, daraus echte Nutzung zu machen?

Ohne diese Verantwortung bleibt KI ein Dauer-Pilot. Es gibt Begeisterung im Workshop, ein paar gute Demos und vielleicht einzelne Produktivitätsgewinne bei Power-Usern, aber keine breite Veränderung. Adoption bedeutet nicht, ein Tool freizuschalten. Adoption bedeutet, Arbeitsweisen zu verändern, und das braucht Enablement, klare Use Cases, Training, Support, Erfolgsmessung, Governance und jemanden, der die Umsetzung wirklich treibt.

Governance ist kein Verbotsproblem

Governance ist real, besonders in regulierten Umfeldern. Dort stellen sich konkrete Fragen.

• Welche Daten dürfen verwendet werden?
• Welche Quellen sind belastbar?
• Welche Aktionen darf ein Agent ausführen?
• Was muss protokolliert werden?
• Wo braucht es Freigaben?
• Wo bleibt der Mensch in der Schleife?
• Was darf lokal laufen, was in der Cloud?
• Welche Ergebnisse müssen nachvollziehbar sein?

Aber Governance darf nicht bedeuten “Wir verbieten alles, bis jedes Risiko verschwunden ist”, denn dann passiert gar nichts. Governance muss heißen “Wir gestalten Systeme so, dass sie sicher nutzbar sind”. Das ist ein Design- und Engineering-Problem. RAG-Systeme brauchen Quellenangaben, Agenten brauchen Berechtigungsgrenzen, produktive Systeme brauchen Logs und Monitoring, kritische Aktionen brauchen Freigaben, Datenflüsse müssen nachvollziehbar sein, und Nutzer müssen verstehen, was ein System kann und was nicht.

Gerade im regulierten Umfeld lautet die entscheidende Frage nicht, ob KI-Agenten Workflows übernehmen, sondern wie man sie lokal, compliant, nachvollziehbar und vertrauenswürdig macht. Das ist die eigentliche Arbeit.

Messbarkeit entscheidet über Adoption

Adoption passiert nicht, weil ein Tool verfügbar ist. Adoption passiert, wenn Teams merken: Diese Arbeit läuft jetzt spürbar besser. Also braucht es Messbarkeit.

• Wie stark sinkt die Durchlaufzeit?
• Wie viele Tickets werden schneller gelöst?
• Wie viel Dokumentationsaufwand fällt weg?
• Wie viele Aufgaben schafft ein Team mehr bei gleicher Qualität?
• Wie schnell werden neue Mitarbeitende produktiv?
• Wie stark steigt die Konsistenz der Ergebnisse?
• Wie viel Zeit gewinnen Experten zurück?

Ohne Messbarkeit bleibt KI ein Experiment. Mit Messbarkeit wird sie ein Steuerungsinstrument. Dabei geht es nicht darum, unrealistische Produktivitätsversprechen in den Raum zu stellen. Nicht jede Tätigkeit wird plötzlich 50 Prozent schneller, nicht jeder Prozess eignet sich gleich gut, nicht jeder Mensch arbeitet auf dieselbe Weise. Aber genau deshalb muss man messen. Ein guter KI-Use-Case sollte nicht nur technisch funktionieren, er sollte zeigen, ob er Arbeit wirklich verbessert.

Cost Control kommt später, aber sie kommt

Cost Control ist wichtig, aber sie ist oft nicht das erste Problem. Viele Unternehmen sind noch gar nicht an dem Punkt, an dem Tokenomics wirklich schmerzt. Nicht, weil Kosten egal wären, sondern weil Agenten noch nicht breit produktiv laufen. Sobald das passiert, ändert sich das, denn fast jeder Schritt erzeugt Kosten: Agenten in Schleifen, mehr Kontext, Tool-Aufrufe, fehlgeschlagene Iterationen, unkontrollierte Automatisierung.

Deshalb braucht es Observability, Usage-Tracking und klare Grenzen.

• Welche Workflows verbrauchen wie viele Tokens?
• Welche Agenten laufen zu lange?
• Welche Aufgaben sind zu teuer für den Nutzen?
• Wo lohnt sich ein kleineres Modell?
• Wo braucht es Caching, bessere Prompts oder klarere Abbruchbedingungen?

Ohne Messung keine Steuerung. Tokenomics klingt abstrakt, bis ein Agent in einer Schleife läuft und niemand sieht, was passiert. Dann wird Observability plötzlich kein Nice-to-have mehr, sondern Voraussetzung.

Der Vorsprung entsteht nicht durch das Modell

Der Vorsprung entsteht nicht durch das beste Modell, denn das haben bald alle. Die Modelle werden stärker, günstiger und austauschbarer, und der eigentliche Wettbewerbsvorteil liegt nicht darin, Zugriff auf KI zu haben. Er liegt darin, echte Fachprobleme zu verstehen und agentische Workflows produktiv, kontrolliert und messbar in diese Prozesse zu bringen.

Das ist der Unterschied zwischen KI als Spielerei und KI als Betriebssystem für Arbeit: nicht ein einzelner Chatbot, nicht ein Pilotprojekt, nicht ein Innovationsworkshop, sondern eine neue Steuerungsebene für Wissen, Entscheidungen und Workflows.

Die Unternehmen, die diese Lücke zuerst schließen, sind nicht ein Feature voraus. Sie sind einen ganzen Zyklus voraus.

Nicht irgendwann. Jetzt.