Die Build-vs.-Buy-Entscheidung für Enterprise-KI hat für die meisten Organisationen eine geklärte Antwort: Modelle kaufen, Integration bauen. Aber diese Antwort wirft sofort die nächste Frage auf — die Integration bauen womit? Einer Low-Code-Plattform, die in Tagen liefert, oder einem Pro-Code-Framework, das Monate braucht, aber Fähigkeiten ermöglicht, die die Plattform nicht erreichen kann?
Das ist keine Frage der Technologiepräferenz. Es ist eine Architekturentscheidung mit direkten finanziellen Konsequenzen. Organisationen, die richtig wählen, deployen schneller, potenzieren Wert über Funktionen hinweg und vermeiden die kostspielige Plattformmigration mitten im Projekt, die passiert, wenn ein Low-Code-System achtzehn Monate nach Beginn einer strategischen Initiative an seine Obergrenze stößt. Organisationen, die falsch wählen, über-engineeren entweder einfache Use Cases (geben €200.000 für etwas aus, das Copilot Studio in einer Woche liefern könnte) oder unter-engineeren komplexe (entdecken, dass ihr Low-Code-Agent keinen Speicher teilen, nicht autonom operieren oder nicht systemübergreifend integrieren kann — nachdem die Organisation Workflows um seine Limitierungen herum gebaut hat).
Die Forschung ist in einem Punkt konsistent: Die Plattformentscheidung ist sekundär gegenüber dem Workflow-Redesign, das den Wert schafft. Aber die Plattform beschränkt, welches Redesign möglich ist. Man kann einen Workflow nicht um geteilten Agent-Speicher herum umgestalten, wenn die Plattform geteilten Speicher nicht unterstützt. Man kann einen Prozess nicht um autonomes Monitoring herum umgestalten, wenn die Agenten nur auf Benutzerkonversationen reagieren. Die Plattform schafft nicht den Wert — aber sie definiert die Obergrenze des Werts, den man schaffen kann.
Der Kern-Trade-off
Low-Code-Plattformen — Copilot Studio, Power Platform AI Builder und ähnliche Tools — tauschen Kontrolle und architektonische Flexibilität gegen Geschwindigkeit und Zugänglichkeit. Pro-Code-Frameworks — AutoGen, LangGraph, CrewAI, das Claude Agent SDK — tauschen Geschwindigkeit gegen architektonische Tiefe und Ownership. Keine Seite dieses Trade-offs ist per se überlegen. Die richtige Wahl hängt vom spezifischen Use Case ab, von der KI-Reife der Organisation und von der strategischen Ambition für das System, das gebaut wird.
Low-Code optimiert für Time-to-First-Value. Ein Knowledge-Bot, der Fragen zu Unternehmensrichtlinien beantwortet, kann in zwei bis drei Tagen betriebsbereit sein. Ein Routing-Agent, der Kundenanfragen auf Basis von Intent-Klassifikation an spezialisierte Sub-Agenten verteilt, lässt sich in einer Woche konfigurieren. Ein Beschaffungsassistent, der Mitarbeitern hilft, Bestellungen per natürlicher Sprache zu erstellen, kann in zwei Wochen deployt werden. Diese Zeitrahmen sind real, keine Marketing-Claims, und sie sind möglich, weil die Plattform die Infrastruktur abstrahiert — Retrieval-Pipelines, Modell-Hosting, Authentifizierung, Logging und Monitoring werden automatisch bereitgestellt.
Pro-Code optimiert für architektonische Obergrenze. Ein Finanz-Monitoring-System, in dem Research-Agenten, Analysten-Agenten, Portfolio-Agenten, Risiko-Agenten und Compliance-Agenten Speicher teilen, Erkenntnisse über Interaktionen akkumulieren und autonom Probleme flaggen — das lässt sich in keiner heute verfügbaren Low-Code-Plattform bauen. Eine Product-Signal-Pipeline, in der Marktüberwachungsagenten Verbrauchersignale scannen, Validierungsagenten die kommerzielle Tragfähigkeit bewerten und Marketing-Agenten die Positionierung testen, in einem End-to-End-autonomen Workflow — das erfordert den geteilten Speicher, das iterative Reasoning und die Custom Governance, die nur Pro-Code-Frameworks bieten. Diese Systeme brauchen Monate, um gebaut zu werden. Sie erzeugen aber auch die 10 bis 25 Prozent EBITDA-Verbesserung, die Bain bei technologieorientierten Unternehmen dokumentiert, die von Einzelaufgaben-KI zu Workflow-Level-Agent-Deployment übergegangen sind.
Wann Low-Code gewinnt
Es gibt eine substanzielle Kategorie von Enterprise-KI-Use-Cases — konservativ 60 bis 70 Prozent dessen, was die meisten Organisationen in ihren ersten zwei Jahren versuchen —, in der Low-Code nicht nur ausreichend, sondern optimal ist. Ein Pro-Code-Framework für diese Use Cases zu verwenden, ist wie einen Statiker zu engagieren, um ein Regal aufzuhängen.
Interne Wissensagenten. Unternehmensrichtlinien-Q&A, HR-FAQs, IT-Helpdesk-Assistenten, Produktdokumentationssuche, Compliance-Verfahrens-Lookup. Das sind hochwertige, hochfrequente Use Cases, bei denen die Daten strukturiert sind, die Fragen begrenzt und die Qualität des eingebauten RAG ausreichend ist. Die Copilot-Studio-Bewertung beschreibt im Detail, wie der Knowledge-Tab der Plattform Retrieval und Grounding ohne eigene Pipeline handhabt.
Einfache Routing-Orchestrierung. Ein Master-Agent, der Kundenanfragen empfängt und sie auf Basis von Intent-Klassifikation an fünf bis zehn spezialisierte Sub-Agenten verteilt — Billing, technischer Support, Terminplanung, Retouren, Account-Management. Das Muster ist Hub-and-Spoke, die Routing-Logik ist deterministisch, und die einzelnen Sub-Agenten bearbeiten begrenzte Aufgaben mit klaren Erfolgskriterien. Das ist das Multi-Agent-Pattern, für das Low-Code-Plattformen konzipiert wurden.
M365-native Workflows. Alles, was in SharePoint, Teams, Outlook oder Azure SQL lebt, profitiert von den vorgefertigten Connectors, die Low-Code-Plattformen bieten. Agenten, die Meeting-Notizen aus Teams zusammenfassen, Action Items aus E-Mail-Threads extrahieren oder überfällige Aufgaben in SharePoint flaggen, lassen sich mit Copilot Studio schneller bauen als mit jedem Framework, weil die Integrationsarbeit bereits erledigt ist.
Citizen-Developer-Enablement. Business-User, die Agenten ohne Beteiligung des Engineering-Teams bauen und iterieren können. Das ist kein marginaler Vorteil — es bedeutet, dass das Marketing-Team seinen eigenen Kampagnenanalyse-Agenten bauen kann, das Finance-Team seinen eigenen Reportgenerierungs-Agenten und das Operations-Team seinen eigenen Qualitätsmonitoring-Agenten, ohne in einer Engineering-Warteschlange warten zu müssen. In Organisationen, in denen KI-Engineering-Talent knapp ist (was laut Deloittes 2026-Daten mit 20 Prozent Talentbereitschaft die meisten Organisationen bedeutet), ist Citizen-Developer-Fähigkeit ein Kraftmultiplikator.
Governance-first-Umgebungen. DLP-Policies, Admin-Kontrollen, Connector-Berechtigungen und Audit-Trails sind in Low-Code-Plattformen eingebaut. Für Organisationen, die in regulierten Branchen operieren, in denen jedes KI-System dokumentierte Governance benötigt, sparen die eingebauten Kontrollen Monate an Custom-Governance-Entwicklung. Dieser Vorteil potenziert sich — jeder neue Agent, der auf der Plattform deployt wird, erbt automatisch das bestehende Governance-Framework.
Wann Pro-Code erforderlich ist
Die verbleibenden 30 bis 40 Prozent der Use Cases — die mit dem höchsten Wert und der größten strategischen Differenzierung — erfordern Pro-Code. Nicht weil Pro-Code im Abstrakten besser ist, sondern weil spezifische architektonische Anforderungen von keiner aktuellen Low-Code-Plattform erfüllt werden können.
Geteilter Speicher und Lernsysteme. Agenten, die Wissen akkumulieren, Erkenntnisse über Abteilungen hinweg teilen und Lernerfahrungen über die Zeit potenzieren. Ein Customer-Intelligence-System, in dem jede Support-Interaktion, jedes Verkaufsgespräch und jedes Produktfeedback eine geteilte Wissensbasis bereichert, aus der alle Agenten schöpfen — in dem das System mit jeder Interaktion intelligenter wird, statt jedes Mal von vorne zu beginnen. Das ist die Kernthese des AI Operating System-Konzepts, und es ist architektonisch unmöglich in Plattformen, in denen Agenten nativ keinen Zustand teilen.
Autonome Entscheidungsfindung. Agenten, die Datenquellen überwachen, Muster identifizieren, Probleme flaggen, Maßnahmen vorschlagen und innerhalb von Governance-Grenzen ausführen — ohne eine menschliche Konversation als Auslöser. Ein Supply-Chain-Agent, der Lagerbestände überwacht, Nachfrageanomalien erkennt, Nachbestellvorschläge generiert, diese gegen Budgetbeschränkungen und Lieferantenverträge prüft und Bestellungen innerhalb vorab genehmigter Parameter ausführt, während er Ausnahmen eskaliert. Das ist kein Chatbot. Es ist ein autonomes System, das 24/7 mit menschlicher Aufsicht an definierten Entscheidungspunkten operiert. Low-Code-Plattformen basieren auf dem Konversationsparadigma — ein Benutzer fragt, der Agent antwortet. Autonomer Betrieb erfordert eine fundamental andere Architektur.
Cross-System-Orchestrierung. Agenten, die Microsoft, AWS, selbst gehostete Modelle und Drittanbieter-APIs in einem einzigen Workflow umspannen. Ein DACH-Mittelstandsunternehmen, das SAP für ERP, Salesforce für CRM, ein selbst gehostetes Modell für Dokumentenverarbeitung (aufgrund von Datensouveränitätsanforderungen) und Azure für Cloud-Infrastruktur betreibt, braucht Agenten, die über alle vier Umgebungen hinweg orchestrieren. Plattformgekoppelte Lösungen handhaben eine Umgebung gut und die anderen schlecht oder gar nicht.
Self-Hosting und Air-Gapped Deployments. Unternehmen — insbesondere in regulierten DACH-Branchen —, die erfordern, dass alle Daten und Modelle On-Premises oder im eigenen Cloud-Tenant verbleiben. Copilot Studio verarbeitet Daten über Microsofts Infrastruktur. Manche Use Cases, insbesondere solche mit personenbezogenen Daten, Finanzdaten oder klassifizierten Industriedaten, erfordern Verarbeitung innerhalb des Unternehmensperimeters. Pro-Code-Frameworks laufen überall dort, wo man sie deployt — im eigenen Rechenzentrum, im eigenen Cloud-Tenant, im eigenen Air-Gapped-Netzwerk.
Iteratives Reasoning. Multi-Agent-Debatte, Verifikationsketten, Research-Synthese-Validierungs-Loops. Ein Due-Diligence-System, in dem ein Agent ein Zielunternehmen recherchiert, ein anderer die Ergebnisse gegen öffentliche Aufzeichnungen validiert, ein dritter Diskrepanzen identifiziert und das System iteriert, bis die Ergebnisse verifiziert sind — Hin und Her zwischen Agenten, bis Konsens erreicht ist. Dieses iterative Verfeinerungsmuster ist Standard in Pro-Code-Frameworks und fehlt in Low-Code-Plattformen.
Custom Governance jenseits von DLP. Governance-Regeln, die über Data-Loss-Prevention-Policies hinaus in geschäftsspezifische Entscheidungsframeworks gehen. Ein Agentensystem, in dem der Compliance-Agent die Empfehlungen des Operations-Agenten überstimmen kann, in dem Eskalationspfade nach Deal-Größe und Kundensegment definiert sind, in dem Governance-Regeln sich je nach regulatorischer Jurisdiktion ändern — dieses Maß an Governance-Customization erfordert Code.
Die hybride Architektur
Die stärkste Position ist nicht Entweder-Oder. Es ist eine geschichtete Architektur, die jeden Ansatz dort einsetzt, wo er am effektivsten ist.
Copilot Studio als geschäftsseitige Schicht. Citizen Developer bauen und iterieren an Agenten, die die 60 bis 70 Prozent der Use Cases abdecken, die Low-Code gut bewältigt. Governance ist eingebaut. Das M365-Ökosystem ist verbunden. Time-to-Value wird in Tagen gemessen. Diese Schicht handhabt Knowledge-Bots, Routing-Agenten, Dokumentenassistenten und einfache Workflow-Automatisierung. Sie ist die sichtbare Schicht — diejenige, mit der Mitarbeiter täglich interagieren, die die Geschäftsführung in Demos sieht, die Quick Wins und organisatorisches Buy-in generiert.
Azure AI Foundry als Brücke. Wenn ein Use Case mehr Modellflexibilität benötigt, als Copilot Studio bietet — eine Aufgabe, die Claude für tiefes Reasoning erfordert, oder Llama für kosteneffiziente Klassifikation, oder ein eigenes Fine-Tuned-Modell für domänenspezifische Extraktion —, bietet Foundry den Microsoft-gehosteten Mittelweg. Pro-Code in der Fähigkeit, aber Microsoft-gesteuert in der Infrastruktur. Das richtige Tool, wenn der Engpass die Modellauswahl ist, nicht die architektonische Tiefe.
Pro-Code-Framework darunter für die harten Probleme. Geteilte Speichersysteme, autonome Monitoring-Agenten, Cross-System-Orchestrierung, iterative Reasoning-Loops — die hochwertigen, hochkomplexen Fähigkeiten, die Level 2 und Level 3 Integration definieren. Diese Schicht ist für die meisten Benutzer unsichtbar. Sie ist der Motor, der den sich potenzierenden Wert antreibt: das Wissen, das über Interaktionen wächst, die autonomen Prozesse, die ohne menschliche Initiierung laufen, die funktionsübergreifende Koordination, die kein einzelner Agent leisten kann.
Die Integrationspunkte sind entscheidend. Die hybride Architektur funktioniert nur, wenn die Schichten kommunizieren. Die Pro-Code-Schicht bezieht Daten aus denselben Quellen, auf die die Copilot-Studio-Schicht zugreift. Die Erkenntnisse des autonomen Monitoring-Agenten tauchen in der Copilot-Studio-Oberfläche auf, in der Mitarbeiter mit ihnen interagieren. Das geteilte Speichersystem speist Kontext in die Low-Code-Agenten ein, sodass diese vom akkumulierten Wissen profitieren, ohne Custom-Code zu benötigen. Das Design dieser Integrationspunkte — die API-Verträge, die Datenflüsse, die Event-Trigger — ist die kritische architektonische Arbeit, die bestimmt, ob das Hybridmodell als einheitliches System oder als zwei entkoppelte Stacks funktioniert.
Das Entscheidungsframework
Vier Fragen bestimmen den richtigen Ansatz für jede gegebene KI-Agent-Initiative.
Was ist die architektonische Obergrenze des Use Case? Wenn der Agent geteilten Speicher, autonomen Betrieb, Cross-System-Orchestrierung oder iteratives Reasoning benötigt — beginnen Sie mit Pro-Code. Wenn er nichts davon benötigt — beginnen Sie mit Low-Code. Wenn Sie unsicher sind, beginnen Sie mit Low-Code und akzeptieren Sie, dass Sie möglicherweise später migrieren. Die Kosten der Migration eines einzelnen Agenten sind weitaus geringer als die Kosten, jeden Agenten von Tag eins an zu über-engineeren.
Wie ist die KI-Reife der Organisation? Eine Organisation auf Level 1 — die ihre KI-Reise mit Chatbots und Copilots beginnt — sollte mit Low-Code starten. Die Quick Wins bauen organisatorische Fähigkeit auf, das Governance-Framework wird etabliert, und das Team lernt, was KI im eigenen spezifischen Kontext kann und nicht kann. Zu Pro-Code zu springen, bevor die Organisation ihre eigenen Workflows, Datenqualität und Governance-Anforderungen versteht, produziert teure Fehlschläge. Die BCG-Reifegraddaten sind eindeutig: Agentenwert konzentriert sich in Organisationen, die bereits grundlegende Fähigkeiten aufgebaut haben.
Wer wird das System bauen und warten? Wenn die Erbauer Business-Analysten und Citizen Developer sind, ist Low-Code die einzige praktikable Option. Wenn die Erbauer Software-Engineers mit KI-Erfahrung sind, erschließt Pro-Code Fähigkeiten, die Low-Code nicht erreichen kann. Wenn die Antwort lautet „Wir haben einen Entwickler, der mit LangChain experimentiert hat", sind Sie nicht bereit für ein Pro-Code-Multi-Agent-System. Talentbereitschaft bestimmt die Plattformwahl stärker als jede technische Evaluation.
Was ist der strategische Zeithorizont? Wenn die Initiative in 30 Tagen Wert demonstrieren muss, gewinnt Low-Code. Wenn das System Wert über drei Jahre potenzieren muss, ist Pro-Code erforderlich — weil die architektonischen Investitionen in geteilten Speicher, autonomen Betrieb und Cross-System-Integration sich über die Zeit auszahlen, nicht sofort. Die kumulierenden Kosten der Untätigkeit gelten auch hier: Organisationen, die auf Level 1 verbleiben, weil Low-Code einfacher ist, fallen weiter hinter Organisationen zurück, die in Level-2-Fähigkeiten investieren, selbst wenn die Level-2-Investition länger braucht, um Renditen zu zeigen.
Der Fehler, den die meisten Organisationen machen
Der häufigste Fehler ist nicht, die falsche Plattform zu wählen. Es ist, irgendeine Plattform zu wählen, ohne zuvor den Workflow zu verstehen, in dem sie operieren wird. Eine Organisation, die Copilot Studio oder AutoGen auswählt, bevor sie den tatsächlichen Workflow abgebildet hat — den realen Prozess, nicht die idealisierte Version —, wird das Falsche optimieren. Die Plattform verstärkt jeden Workflow, in den man sie deployt. Wird sie in einen kaputten Prozess deployt, erhält man einen schnelleren kaputten Prozess. Wird sie in einen neu gestalteten Workflow deployt, erhält man die Transformation, die die Big Three der Strategieberatungen als primären Treiber des KI-Unternehmenswerts identifizieren.
Die Reihenfolge ist entscheidend: den Workflow verstehen, den Zielzustand gestalten, dann die Plattform wählen, die den Zielzustand ermöglicht. Nicht: die Plattform wählen, dann herausfinden, ob sie den Zielzustand erreichen kann.
Ein Fit Call beginnt bei Ihren Workflows, bildet sie auf die drei Level ab und identifiziert, ob Ihre aktuelle oder geplante Plattform das Integrationslevel unterstützt, das echten Wert schafft — bevor die Architekturentscheidung Sie festlegt.
Referenzen: McKinsey & Company, „The State of AI: How Organizations Are Rewiring to Capture Value", 2025; Bain & Company, „Technology Report 2025", 2025; BCG, „AI Radar 2025: From Potential to Profit", 2025; Deloitte, „State of AI in the Enterprise", Ausgabe 2026; Microsoft Copilot Blog und Microsoft Learn Dokumentation, 2026.