Max Schreiber 
IBM hat gerade eine Studie unter 2.900 Führungskräften veröffentlicht – und die Zahlen sind eindeutig: KI-Agenten sind kein Experiment mehr, sondern wandern in die Kernprozesse. 70 % der Befragten halten agentische KI für entscheidend. Für CIOs bedeutet das: Ihre Developer-Teams brauchen neue Skills, neue Rollen und eine andere Architektur-Denkweise. Sofort.
Klartext: Aktuell laufen lediglich 3 % aller Enterprise-Workflows KI-gestützt. Bis Ende 2025 erwarten die befragten Führungskräfte einen Sprung auf 25 %. Das sind keine graduellen Anpassungen – das ist ein Systemwechsel. Die IBM-Studie „AI Projects to Profits“ des Institute for Business Value, die 2.900 Führungskräfte weltweit befragte, spricht eine klare Sprache.
70 % der Befragten stufen agentische KI als entscheidend für die Zukunft ihres Unternehmens ein. 83 % erwarten, dass KI-Agenten bis 2026 die Prozesseffizienz deutlich verbessern. 64 % der KI-Budgets fließen bereits in Kernbereiche des Geschäfts – nicht in Sandbox-Projekte. Seien wir ehrlich: Wer das als „interessante Statistik“ abtut und weiter abwartet, hat das Spielfeld schon verlassen.
Wichtig zu verstehen: IBM befragte hier Führungskräfte, keine Developer direkt. Das ist kein Manko – es zeigt, dass die Investitionsentscheidungen von oben kommen und Developer-Teams damit umgehen müssen, ob sie wollen oder nicht. Der Druck kommt von der Führungsebene. Die Umsetzung landet auf dem Schreibtisch der Entwicklerinnen und Entwickler.
Und die Hürden? Sind real. 49 % nennen Datenqualität als Hauptproblem, 46 % zweifeln an der Technologie-Reife, 42 % klagen über Fachkräftemangel. Die harte Wahrheit: Diese drei Probleme löst man nicht mit einem weiteren Workshop. Man löst sie mit strukturellen Entscheidungen.
Ein einzelner LLM-Chatbot ist keine Multi-Agenten-Architektur. Das klingt banal. Ist es aber nicht, weil genau diese Verwechslung in Unternehmen gerade massenhaft passiert. Ein Chat-Interface mit GPT dahinter ist ein Werkzeug. Eine Multi-Agenten-Architektur ist ein Betriebssystem für autonome Prozesse.
Was unterscheidet die beiden? In einer Multi-Agenten-Architektur übernehmen spezialisierte Agenten jeweils klar abgegrenzte Aufgaben: Data-Analytics-Agenten bereiten Daten auf, Tool-Agenten steuern externe Systeme wie SAP, Salesforce oder ServiceNow an, Monitoring-Agenten überwachen Prozesse und Compliance-Agenten prüfen Ergebnisse gegen regulatorische Vorgaben. Ein Orchestrator koordiniert das Zusammenspiel – entscheidet, welcher Agent wann welche Aufgabe übernimmt, und sorgt dafür, dass Ergebnisse korrekt weitergegeben werden.
IBM illustriert dieses Konzept etwa im Fertigungskontext, wo agentische KI gleichzeitig Produktionsplanung, Qualitätssicherung und Wartungsmanagement koordiniert – nicht als monolithischer Superagent, sondern als vernetztes System spezialisierter Einheiten. Die Orchestrierung ist dabei die eigentliche Ingenieursleistung. Schluss damit, Orchestrierung als „nice to have“ zu behandeln. Sie ist der kritische Engpass.
Das bedeutet konkret: Die Systemarchitektur muss von Anfang an event-getrieben gedacht werden. Agenten kommunizieren über klar definierte Schnittstellen, nicht über lose String-Übergaben. Fehlerbehandlung, Retry-Logik und Rollback-Strategien müssen eingebaut sein – nicht nachgerüstet werden, wenn ein Agent zum ersten Mal einen Produktionsbefehl falsch interpretiert.
Die harte Wahrheit für Engineering-Teams: Klassisches Backend-Development reicht nicht mehr aus, um sinnvolle KI-Agenten zu bauen. Wer nur REST-APIs schreibt und Datenbanken modelliert, kann Agenten integrieren. Aber wer Agenten-Systeme designt, braucht ein anderes Skill-Profil.
Erstens: LLM-Know-how. Nicht im Sinne von „Ich kenne ChatGPT“, sondern im Sinne von Modellauswahl (proprietär vs. Open Source), Prompt-Engineering mit Guardrails, Halluzinationsreduktion und Token-Management. Ein Agent, der in einem Bestellprozess halluziniert, kostet echtes Geld.
Zweitens: Tool-Integration und API-Sicherheit. Agenten müssen ERP-, CRM- und Datenplattformen sicher ansteuern. Das bedeutet Kenntnisse in OAuth2, OIDC, Event-getriebener Architektur und sauberem Fehler-Handling. Ein Agent mit zu weiten Zugriffsrechten ist kein Effizienzgewinn – er ist ein Sicherheitsrisiko.
Drittens: MLOps-Grundlagen. Agenten müssen überwacht werden. Latenz, Fehlerrate, Kosten pro Anfrage, Modell-Drift – das sind operative Kennzahlen, die Developer verstehen und steuern müssen. Wer Agenten baut und nicht überwacht, baut auf Sand.
Viertens, und das wird am häufigsten unterschätzt: Domänenwissen. Ein Entwickler, der den Geschäftsprozess nicht versteht, kann keinen sinnvollen Agenten spezifizieren. Welche Entscheidung darf ein Agent autonom treffen? Wo muss ein Mensch eingreifen? Diese Fragen sind keine IT-Fragen. Sie sind Business-Fragen – und Developer müssen sie gemeinsam mit den Fachbereichen beantworten.
Seien wir ehrlich: Die wenigsten Enterprise-Teams sind heute bereit für Multi-Agenten-Architekturen. Laut IBM-Studie nennen 42 % der Befragten Fachkräftemangel als Haupthürde. Die Lösung ist keine Recruiting-Offensive allein. Sie ist eine strukturierte Skill-Transformation in Phasen.
Phase 1 – Bestandsaufnahme (0–3 Monate): Welche Developer-Skills sind vorhanden? Wo sind die Lücken bei LLM-Integration, Orchestrierung und MLOps? Welche bestehenden Systeme müssen Agenten ansprechen können – und wie gut sind deren APIs? Unternehmen, die hier schummeln und überschätzen, was ihr Team kann, werden bei der ersten echten Agentenintegration brutal ausgebremst.
Phase 2 – Plattform und Standards setzen (3–6 Monate): Ein zentrales AI-Platform-Team – call it Center of Excellence oder wie auch immer – definiert die Spielregeln. Welche Agenten-Frameworks werden unterstützt? Wie sehen Logging- und Monitoring-Standards aus? Welche Governance-Anforderungen gelten? Ohne diese Leitplanken entstehen Dutzende inkompatible Agenten-Inseln. Das ist das Shadow-AI-Problem, das niemand will.
Phase 3 – Dezentrale Umsetzung mit zentralen Guardrails (6–12 Monate): Fachbereichs-Developer bauen domänenspezifische Agenten auf der gemeinsamen Plattform. Sie nutzen bereitgestellte APIs, SDKs und Monitoring-Tools. Business-Analysten werden geschult, Agenten-Anforderungen korrekt zu spezifizieren. Die Orchestrierung koordiniert das Zusammenspiel. Und der Compliance-Rahmen – EU AI Act inklusive – ist von Anfang an eingebaut, nicht nachträglich draufgeklebt.
Zahlen lügen selten. Laut IBM-Auswertung flossen 2024 rund 12 % der gesamten IT-Budgets in KI – bis 2026 wird ein Anstieg auf 20 % erwartet. 64 % dieser Mittel landen bereits in Kernprozessen, nicht in Forschungs-Sandboxen. Jedes vierte befragte Unternehmen verfolgt bereits einen AI-first-Ansatz – und diese Unternehmen führen mehr als die Hälfte ihres jüngsten Umsatzwachstums direkt auf KI-Initiativen zurück.
Das bedeutet: Wer jetzt in Developer-Skills, Orchestrierungs-Plattformen und Agenten-Governance investiert, hat in 18 Monaten einen strukturellen Vorsprung. Wer wartet, bis der Business Case „wasserdicht“ ist, wartet zu lang. Die 67 % der Befragten, die Kostensenkung als Haupttreiber nennen, haben das bereits verstanden.
Meine Einschätzung dazu: Die Budget-Verschiebung Richtung Kernprozesse ist das stärkste Signal. Unternehmen experimentieren nicht mehr – sie integrieren. Wer seine Developer-Teams in dieser Phase nicht transformiert, wird nicht nur technisch zurückfallen, sondern auch strategisch.
Hier liegt ein verbreitetes Missverständnis. Orchestrierung klingt nach einem Infrastrukturproblem, das die Architekten lösen. Falsch. Orchestrierung ist eine strategische Entscheidung, die bestimmt, wie autonom Prozesse laufen dürfen, wo Menschen eingreifen müssen und wie Fehler eskaliert werden.
Ein konkretes Beispiel: In einem Supply-Chain-Szenario übernimmt ein Data-Analytics-Agent die Nachfrageprognose, ein Bestell-Agent löst automatisch Bestellungen aus, und ein Compliance-Agent prüft Lieferanten gegen aktuelle Sanktionslisten. Der Orchestrator entscheidet: Läuft alles automatisch durch – oder gibt es Schwellenwerte, ab denen ein Mensch bestätigen muss? Diese Entscheidung ist keine technische. Sie ist eine Governance-Entscheidung. Und sie muss CIO und Business gemeinsam treffen.
Die IBM-Studie zeigt, dass 46 % der Befragten Vertrauen als Kernproblem nennen. Kein Unternehmen vertraut einem Agenten, der intransparent entscheidet. Orchestrierung, die Entscheidungslogik sichtbar macht und Eingriffspunkte für Menschen vorsieht, ist deshalb kein Komfort-Feature – sie ist die Voraussetzung für Akzeptanz.
In der Praxis wiederholen sich bestimmte Fehler bei der Orchestrierung von Multi-Agenten-Systemen mit auffälliger Regelmäßigkeit. Der erste und häufigste: zu viele Agenten, zu wenig Struktur. Teams bauen schnell viele spezialisierte Agenten, vergessen aber, den Orchestrator klar zu definieren. Das Ergebnis sind konkurrierende Zuständigkeiten und Race Conditions – zwei Agenten versuchen gleichzeitig, denselben Datensatz zu schreiben.
Der zweite typische Fehler: fehlende Human-in-the-Loop-Punkte. Agenten werden mit maximaler Autonomie ausgestattet, weil das schneller klingt. In der Realität führt das dazu, dass Fehler unbemerkt kaskadieren, bis ein Prozess in einem inkonsistenten Zustand steckt, den niemand schnell reparieren kann. Sinnvoll ist es, für jeden Agenten explizit zu definieren: Welche Aktionen darf er ohne Bestätigung ausführen – und ab welchem Schwellenwert muss ein Mensch freigeben?
Der dritte Fehler: Logging als Nachgedanke. Wenn ein Multi-Agenten-System einen falschen Output produziert, ist die erste Frage: Welcher Agent hat wann welche Entscheidung auf Basis welcher Daten getroffen? Ohne strukturiertes, nachvollziehbares Logging ist diese Frage nicht beantwortbar – und damit ist auch jede Fehlerkorrektur Raterei.
Klartext: Multi-Agenten-Architekturen multiplizieren auch Risiken. Ein einzelner Agent mit falschem Tool-Zugriff kann Schaden anrichten. Ein Netzwerk von Agenten, die sich gegenseitig triggern und falsche Daten weitergeben, kann Schaden im großen Maßstab anrichten – innerhalb von Sekunden, bevor ein Mensch eingreifen kann.
Prompt Injection – also der Versuch, Agenten über manipulierte Eingaben zu steuern – ist in komplexen Multi-Agenten-Setups schwerer zu erkennen als bei einem einzelnen Chatbot. Wenn Agent A die Eingabe von einem externen System erhält und diese ungeprüft an Agent B weitergibt, entsteht eine Angriffsfläche, die klassische Security-Konzepte nicht abdecken. Das ist kein hypothetisches Problem.
Wie BigData-Insider die IBM-Studienergebnisse einordnet: 49 % der Befragten nennen Datenqualität als größte Hürde. Das ist nicht nur ein Datenproblem. Es ist ein Vertrauensproblem in die Grundlage, auf der Agenten entscheiden. Schlechte Daten führen zu falschen Agentenentscheidungen – und in autonomen Prozessen gibt es keinen manuellen Filter mehr, der das abfängt.
Ich sage das mit Nachdruck: Security und Datenqualität sind keine Themen, die man nach der Pilotphase angeht. Sie müssen in die Architektur eingebaut sein, bevor der erste Agent produktiv geht. Nicht danach.
Die Unternehmen, die laut IBM zu den AI-first-Vorreitern zählen – rund ein Viertel der Befragten – haben eines gemeinsam: Sie haben nicht auf den perfekten Use Case gewartet. Sie haben früh angefangen, haben Teams mit gemischten Skills aufgebaut und Governance-Strukturen etabliert, bevor die Agenten skaliert wurden.
Was das konkret bedeutet: gemischte Teams aus Developer, Business-Analyst und Domain-Experten arbeiten gemeinsam an Agenten-Spezifikationen. Developer-Skills in LLM-Integration und MLOps werden durch gezielte Weiterbildung aufgebaut, nicht durch externe Berater ersetzt. Und Orchestrierungs-Entscheidungen werden im Führungskreis getroffen – nicht delegiert.
Laut IBM führen AI-first-Unternehmen mehr als die Hälfte ihres jüngsten Umsatzwachstums und ihrer Margenverbesserung direkt auf KI-Initiativen zurück. Das ist kein Marketing. Das ist die Benchmark, an der sich der Rest des Marktes messen lassen muss.
Ein häufiges Gegenargument aus der Praxis lautet: Warum jetzt eine vollständige Transformation anstoßen? Reicht nicht ein gut abgegrenztes Pilotprojekt, um Erfahrung zu sammeln und dann schrittweise zu skalieren?
Die Antwort ist differenziert. Pilotprojekte sind sinnvoll – aber nur, wenn sie von Anfang an auf skalierbarer Infrastruktur aufbauen und die Governance-Fragen mitdenken. Das Problem der meisten Pilot-Ansätze ist nicht der Pilot selbst, sondern die Lücke zwischen Pilot und Produktion. Teams bauen in einer isolierten Umgebung, ohne Anbindung an echte Unternehmens-APIs, ohne Monitoring-Standards, ohne Security-Review. Wenn das Pilotprojekt dann skaliert werden soll, muss es faktisch neu gebaut werden.
Ein Pilot-first-Ansatz funktioniert dann, wenn er als architektonisches Experiment angelegt ist – mit dem expliziten Ziel, Entscheidungen zu treffen, die auf das Gesamtsystem übertragbar sind. Wer den Pilot als Proof of Concept für den Business Case baut, ohne die technische Skalierbarkeit mitzudenken, schiebt die eigentliche Arbeit nur auf.
Die IBM-Studie liefert keine Überraschungen für alle, die den Markt beobachten. Aber sie quantifiziert, was viele nur ahnen: Der Wechsel von Einzel-Chatbots zu orchestrierten Multi-Agenten-Systemen passiert gerade – in Kernprozessen, mit echtem Budget und mit realem Druck auf Developer-Teams. 70 % der Führungskräfte halten agentische KI für entscheidend. 64 % der KI-Budgets landen bereits im Kerngeschäft. Die Prognose: 25 % aller Workflows sollen bis Ende 2025 KI-gestützt sein.
Für CIOs ist die Frage nicht mehr, ob sie ihre Teams umrüsten müssen. Die Frage ist: Wie viele Monate wollen Sie noch verlieren – und welchen Rückstand nehmen Sie dafür in Kauf?
