Inhalt

• Drei Arten, wie KI im Unternehmen wirkt
• Was der Mittelstand heute nutzt, und wo es aufhört
• Wo es anfängt zu reiben
• Azure AI Foundry: Portal oder Engineering
• Die Foundation, auf der Use Cases skalieren
• Wo Sie jetzt ansetzen können

Rund jedes dritte Unternehmen in Deutschland setzt inzwischen KI ein, 2024 waren es erst 20 Prozent (Bitkom KI 2025). Weitere 47 Prozent planen oder diskutieren den Einsatz. Die Lücke liegt also nicht mehr im Interesse an KI, sondern in der skalierbaren, produktiven Umsetzung.

Der Mittelstand hat seine KI-Investitionen 2025 trotzdem nicht erhöht, sondern gesenkt: Auf 30 Prozent unter dem Marktdurchschnitt (Horváth-Studie, Januar 2026). Das passiert nicht, weil Unternehmen keine KI adoptieren wollen. Es passiert, weil die Projekte nicht liefern.

Was wir im Markt immer wieder beobachten: KI-Piloten erreichen den Produktivbetrieb nicht. Prozesse werden teilautomatisiert, nicht durchautomatisiert. Und selbst die Use Cases, die laufen, laufen isoliert, ohne Governance, ohne Compliance und ohne Wiederverwendbarkeit für den nächsten Use Case.

Das Problem ist nicht das Modell. Es ist nicht der Anbieter. Es ist die fehlende Foundation. Solange jeder Use Case bei Null startet, ist Skalierung eine Illusion.

Drei Arten, wie KI im Unternehmen wirkt

Nicht alle KI-Initiativen stellen dieselben Anforderungen. Die Einordnung, ob es sich um einen persönlichen Assistenten, einen automatisierten Prozess oder ein agentisches System handelt, entscheidet direkt darüber, welcher Stack der passende ist und welche Governance-Anforderungen entstehen.

Persönliche Co-Pilots sind chat-basierte Assistenten für eine einzelne Person. Der Hebel ist individuelle Produktivität, und das Entscheidende daran ist oft nicht der Schreibassistent, sondern der direkte Zugang zu Unternehmensdaten über natürlichsprachliche Abfragen: Ein Mitarbeiter befragt das Produkthandbuch, statt es zu durchsuchen, fragt nach einer spezifischen Klausel in der Vertragsdatenbank, ruft die relevante Kundenhistorie vor einem Meeting ab. Um nur einige Beispiele zu nennen.

Flow- und Prozessautomatisierung geht einen Schritt weiter. Definierter Workflow, mehrere Schritte, integrierte Systeme. KI übernimmt die Teile, die regelbasierte Automatisierung nicht sauber lösen kann: Klassifikation, Validierung, Anreicherung. Eingangsbeleg-Validierung und Abgleich gegen Stammdaten, Ticket-Triage nach Priorität, Angebotsprüfung gegen Lieferanten-SLA.

Agentische AI-Systeme sind die dritte Klasse. Der Agent entscheidet im Rahmen eines Ziels selbst, was als Nächstes passiert, über mehrere Tools, mehrere Datenquellen, ohne explizite Schritt-für-Schritt-Anweisung. Das bedeutet nicht vollautomatische Systeme ohne menschliche Kontrolle, sondern Autonomie innerhalb eines definierten Scopes, oft mit Human-in-the-Loop-Gates an kritischen Entscheidungspunkten. Vollständige Sales-Vorbereitung über CRM, Web-Recherche, Mail-Historie und Kalender. Compliance-Check gegen Policy-Datenbank und aktuellen Regulierungstext. Ein Monitoring-Agent, der auf Anomalien in Produktionsdaten selbständig reagiert.

Diese drei Klassen sind keine Reifegradstufen. Sie sind unterschiedliche Antworten auf unterschiedliche Probleme. Aber je komplexer die Anforderungen werden, desto früher stoßen die heute gängigen Tools an ihre Grenzen.

Was der Mittelstand heute nutzt, und wo es aufhört

Diese drei Klassen korrespondieren direkt mit dem Tool-Spektrum, das wir im Mittelstand vorfinden.

M365 Copilot und andere In-App-AI-Tools sind der natürliche Einstieg für alle, die M365 oder andere Software bereits lizenziert haben. Copilot läuft dort, wo Mitarbeiter ohnehin arbeiten, in Word, Teams, Outlook. Kein Setup-Aufwand, kein neues UI, sofortige erste Ergebnisse. Dabei gilt als neutraler Fakt: M365 Copilot ist zunächst auf den Microsoft-365-Datenraum optimiert. Externe Systeme wie SAP, CRM oder eigene Datenbanken können über Copilot- und Graph-Connectors eingebunden werden, sind aber kein automatisch vorhandener Bestandteil des Datenraums. Genau dort beginnt der Architektur- und Governance-Aufwand.

Copilot Studio ist die Erweiterung in Richtung eigener Agents und strukturierter Flows auf Low-Code-Basis: Ein Visual Designer für die Anbindung an externe Systeme über Connectors. Gut für klar umrissene conversational Use Cases mit SharePoint als Wissensbasis. Für viele Mittelstandsteams ist es der erste Schritt über den reinen Chat hinaus.

Power Platform und n8n adressieren Workflow-Automatisierung mit KI. Power Automate, Teil der Power Platform, ist tief ins Microsoft-Ökosystem integriert und richtet sich an Citizen Developer mit einem breiten Connector-Katalog. n8n ist eine quelloffene Alternative für technisch affinere Teams, die Self-Hosting und Vendor-Neutralität priorisieren und dabei Infrastructure-as-Code-nahe arbeiten wollen. In beiden Fällen kommt KI als Baustein in einen definierten Workflow: Klassifikation, Extraktion, Textgenerierung. Keine eigenständig agierenden Agenten-Systeme.

Wir empfehlen, diese Tools nicht zu unterschätzen. Sie liefern echten Mehrwert in ihrem jeweiligen Sweet Spot. Das Problem entsteht nicht beim ersten Use Case. Es entsteht, wenn Use Cases anspruchsvoller werden oder mehrere parallel laufen sollen. Über etwaige Datensilos und Systeme hinweg.

Wo es anfängt zu reiben

Solange ein oder zwei Use Cases auf demselben Stack laufen, gibt es kein Problem. Es wird spannend, wenn Use Cases skalieren sollen oder ein produktiver Use Case auf ein System zugreifen muss, das außerhalb des jeweiligen Tool-Stacks liegt.

Copilot Studio: wenn die KI-Qualität nicht steuerbar ist

Die Plattform bietet RAG out-of-the-box: Wissensquellen konfigurieren, Fragen stellen, Antworten erhalten. Das Problem beginnt, wenn die Qualität nicht ausreicht und man nicht weiß, warum. Copilot Studio liefert für jede Anfrage die Top-3-Ergebnisse pro Wissensquelle; Chunk-Größe, Embedding-Strategie und Retrieval-Parameter sind nicht konfigurierbar. Dazu kommen harte Skalierungsgrenzen: Pro Knowledge Source sind maximal 1.000 Dateien möglich, die praktische Grenze für verlässliche Ergebnisse liegt bei 500. Für Unternehmen mit mehreren tausend internen Dokumenten ist das eine Architekturgrenze, kein Konfigurationsproblem.

Hinzu kommen strukturelle Limitierungen, die in der Praxis häufig unterschätzt werden:

• Application Lifecycle Management (ALM) ist möglich, wird aber selten genutzt: Copilot Studio unterstützt Solutions, Pipelines und Git-Integration, viele Teams arbeiten jedoch in einer einzigen Umgebung ohne konsequenten Review-Prozess, mit den bekannten Folgen.
• Keine Modell-Versions-Pinnung: Die Modell-Familie ist wählbar (GPT-4.1, GPT-5 etc.), ein spezifisches Deployment lässt sich nicht fixieren. Ändert Microsoft den Modell-Default, ändert sich das Verhalten des Agents, ohne dass das System den Wechsel protokolliert.
• Token-Akkumulation ohne Management: Bei langen agentischen Konversationen akkumuliert sich der Verbrauch aus Conversation History, System Prompt und Knowledge Context bis zum Modell-Limit, ohne dass Copilot Studio natives Token-Management bietet.
• Multi-Agent nur über Workaround: Agentische Szenarien mit mehreren Agents sind heute nur über einen Parent-Proxy-Workaround realisierbar.

Das Resultat spricht für sich: Gartner hat Copilot-Enterprise-Kunden befragt und kommt zum Ergebnis, dass deutlich weniger als 10 Prozent der Piloten den Sprung in den produktiven Betrieb schaffen.

Power Platform und n8n: Wenn KI in Flows unsichtbar wird

Schnell gebaute Flows sind schnell vergessen: Wer hat sie deployed, welche Systeme sind angebunden, welche Credentials sind hinterlegt? Das kennt man aus klassischer Automatisierung. Bei KI-bestückten Flows kommt eine neue Schicht dazu. Ein Prompt, der direkt in einem Power-Automate-Step oder n8n-Node eingebettet ist, hat keine Versionshistorie. Wird er geändert, auch nur ein Satz umformuliert, verändert sich das Verhalten des Agents, ohne dass irgendjemand das protokolliert hat. Dasselbe gilt, wenn das Modell oder die Modell-Version durch den Anbieter geändert wird: Auch das hat keine Versionshistorie, keinen Audit-Trail, keinen Rollback. Hinzu kommt ein konkretes Kostenrisiko: Die seeded AI Builder Credits, die in vielen Power-Apps-Premium-Lizenzen enthalten sind, laufen zum 1. November 2026 aus. Danach sind separate Copilot Credits oder AI Builder Add-ons erforderlich. Wer heute auf diesem Modell aufbaut, ohne die Kostenstruktur zu kennen, baut auf einem ablaufenden Fundament.

Regulatorik, die Engineering-Kontrolle erzwingt

Der EU AI Act ist seit dem 1. August 2024 in Kraft. Die ursprünglich für August 2026 erwarteten Hochrisiko-KI-Pflichten stehen durch das laufende Digital-Omnibus-Verfahren aktuell unter Anpassung und könnten für bestimmte Systeme auf Dezember 2027 oder später verschoben werden. Für Unternehmen ändert das wenig an der praktischen Aufgabe. §203 StGB betrifft alle regulierten Berufe: Steuerberater, Rechtsanwälte, Healthcare-Dienstleister. Ein konkretes Szenario: Ein Mitarbeiter einer Kanzlei nutzt einen Copilot-Studio-Agenten, der Mandantenanfragen beantwortet. Das Modell zieht den Kontext aus einem SharePoint, der Fallakten enthält. §203 StGB schützt das Mandantengeheimnis, und ein Agent ohne nachvollziehbaren Datenfluss und Audit-Trail ist mit dieser Anforderung nicht vereinbar, egal wie gut die Antworten klingen. Dasselbe gilt für DORA in der Finanzbranche: Wer nicht nachweisen kann, welches Modell wann welche Daten verarbeitet hat, hat ein Compliance-Problem. Was compliance-relevante Use Cases zwingend brauchen: Einen vollständigen Audit-Trail, dokumentierte Datenflüsse, nachvollziehbare Modell-Auswahl.

OpenClaw und die Grenzen der Autonomie

Was wir aktuell bei den Innovation-Units mittelständischer Kunden sehen: Experimente mit lokal laufenden autonomen Agents, bei denen diese einen LLM-Modellzugang und einen Systemzugriff bekommen und selbst entscheiden, was sie tun. Das bekannteste Beispiel ist OpenClaw, ein quelloffenes Framework, das genau dieses Prinzip verkörpert. Die Demos sind faszinierend. Im produktiven Einsatz hat noch kein einziger Fall in unserer Kundenbasis ein Security-Review überlebt. Der Grund ist einfach: Jede Systemaktion braucht in einer regulierten Umgebung einen nachvollziehbaren, vorher definierten Scope. Ein autonomer Agent ohne Scope-Definition, Human-Approval-Gates und Audit-Trail ist keine Production-KI. Autonomie ohne Struktur ist keine Skalierung. Es ist ein gut gemeintes Experiment.

Die folgende Tabelle fasst zusammen, wo diese Grenzen liegen:

Use-Case-Klasse	Gängige Tools heute	Natürliche Grenze
Persönliche Co-Pilots	M365 Copilot, In-App-AI	Externe Systeme erfordern Connector-Aufwand und Governance
Flow / Prozessautomatisierung	Copilot Studio, Power Platform, n8n	Fehlende Steuerbarkeit, Governance-Schulden, keine Auditierbarkeit bei Skalierung
Agentische Systeme	Open Source SDKs, Azure AI Foundry	Für regulierte, auditierbare Enterprise-Szenarien reichen reine Low-Code-Setups nicht aus

Agentische Systeme lassen sich technisch mit verschiedenen Plattformen bauen. Für regulierte, auditierbare und wiederverwendbare Enterprise-Szenarien reichen reine Low-Code-Setups jedoch selten aus, um integrierte KI-Agenten-Systeme zu skalieren. Und die angesprochenen Schwierigkeiten sind nicht Schwächen einzelner Produkte. Sie sind das Ergebnis davon, wie No-Code- und Low-Code-Tools typischerweise eingesetzt werden. Low-Code-Tools lösen das erste Problem. Die nächsten fünf selten.

Azure AI Foundry: Portal oder Engineering

Wenn Copilot-Studio- oder Power-Platform-Teams an diese Limits stoßen, lautet die aktuelle Antwort am Markt: Migrieren Sie nach Azure AI Foundry. Das ist richtig. Aber was das in der Praxis bedeutet, ist entscheidend.

Azure AI Foundry ist Microsofts zentrale Azure-PaaS-Plattform für die Entwicklung, Evaluierung und den Betrieb von KI-Anwendungen und Agenten. Der Modellkatalog umfasst über 1.900 kuratierte Modelle – darunter Azure OpenAI, Claude von Anthropic und Mistral – ergänzt durch zehntausende Open-Source-Modelle über Hugging Face. Dazu kommen der Foundry Agent Service als managed Runtime für autonome Agenten, Foundry IQ als agentic RAG-Engine auf Basis von Azure AI Search mit Multi-Source-Grounding, Hybrid Retrieval und berechtigungsgesteuertem Datenzugriff. Dieselbe Plattform, aber zwei sehr unterschiedliche Nutzungsarten.

Der Portal-Modus: Wertvoll für Exploration, Modellvergleich und schnelle Prototypen. Der natürliche Übergang aus Copilot Studio: Mehr Modelle, mehr Konfigurationsmöglichkeiten, schneller Einstieg. Er ersetzt aber keine Engineering-Disziplin. Ohne IaC, CI/CD und reproduzierbare Deployments entsteht kein plattformfähiges Setup, sondern ein weiteres isoliertes Projekt. Was ohne Engineering-Disziplin typischerweise fehlt:

• Reproduzierbare Deployments: Konfiguration lebt im Portal, nicht in Source Control
• Automatisierte Evaluation Gates in der Deployment-Pipeline
• Netzwerkisolation: Endpunkte sind standardmäßig öffentlich erreichbar
• Durchsetzbares Token-Budget und Kosten-Enforcement
• Auditierbare Betriebshistorie

Der Engineering-Modus: Dieselbe Plattform, aber über SDKs, Open-Source-Agent-Frameworks wie Microsoft Agent Framework, LangGraph oder Flock sowie Terraform und GitHub Actions betrieben. Was damit verfügbar wird:

• Evaluation Pipelines für Modelle, RAG-Pipelines und Agenten-Workflows als automatisierter CI/CD-Gate
• Private Endpoints, VNET-Integration und Managed Identity: Keine öffentlichen Endpunkte, kein API-Key-Management
• Deployment auf ACA oder AKS mit horizontalem Scaling und Blue/Green-Rollouts
• Multi-Agent-Architekturen via Foundry Agent Service und A2A-Protokoll programmatisch steuerbar
• Alles in Source Control, alles versionierbar, alles auditierbar

Der Shift, den migrierende Teams oft übersehen: Wer von Copilot Studio in den Portal-Modus von Foundry wechselt, nimmt die Governance-Schulden mit. Der Schritt nach Foundry zahlt sich erst aus, wenn der Modus konsequent gewechselt wird.

Ein häufig optimales Muster aus der Praxis: Der Wechsel zu Foundry bedeutet nicht zwingend, Copilot Studio vollständig abzulösen. AI Foundry und Azure übernehmen das KI-Backend, RAG, Modell-Management, Observability und das Deployment. Copilot Studio bleibt als Frontend für M365-native Workflows und Teams-Integration bestehen. Das Copilot Studio endet dort, wo AI Foundry und Azure-AI-Architektur beginnen, und beide Ebenen können bewusst zusammenspielen. Entscheidend ist, dass Foundry in diesem Setup als Engineering-Plattform betrieben wird, nicht als weiteres Portal.

Der Schritt von Copilot Studio zu Azure AI Foundry ist richtig. Er zahlt sich erst aus, wenn die Plattform mit Engineering-Tiefe betrieben wird.

Die Foundation, auf der Use Cases skalieren

Eine KI-Plattform für den Mittelstand ist kein Produkt, das man kauft. Aber bevor wir beschreiben, was sie ist, lohnt ein Blick auf das, was ohne diese passiert.

Was wir am Markt beobachten: Use Case 1 baut eine Datenanbindung an das interne Wiki auf. Use Case 2 braucht dieselbe Daten-Pipeline und baut sie noch einmal, weil das erste Team keinen wiederverwendbaren Layer hinterlassen hat. Use Case 3 hat ein eigenes Identity-Modell. Use Case 4 hat kein Logging. Use Case 5 weist einen Compliance-Blocker auf, da der Audit-Trail fehlt. Die Kosten sind nicht linear: Sie wachsen, weil jede neue Isolation eine neue Schuld erzeugt. Token-basierte Abrechnung macht das transparent: Wer kein Cost Center pro Use Case hat, keine Limits pro Team, wird die Kostenfrage nicht beantworten können, wenn sie kommt.

Die Schlussfolgerung: Eine geteilte Foundation, nicht aus architektonischer Eleganz, sondern um zu skalieren. Schnell und kosteneffizient.

Eine solche Plattform entsteht nicht in einem Projekt. Sie wächst mit jedem Use Case, der auf ihr aufbaut, und genau darin liegt ihr Wert: Jeder neue Use Case macht die Foundation besser, nicht teurer.

Wir strukturieren diese Plattform in drei Schichten:

Schicht 1: Interface und Integration

Alle chat-basierten AI Use Cases laufen durch eine zentrale Oberfläche. Bei unseren Kunden stellen wir das als PrivateGPT bereit: Eine eigene Web-Applikation als Frontend für alle conversational Use Cases, mit Entra-ID-Anmeldung, Use-Case-Dashboard und einheitlicher User Experience, optional als Teams-Integration über Bot Framework. Nicht für jeden neuen Use Case ein neues UI. Ein Frontend, viele Backends.

Die Anbindung der Use Cases erfolgt einheitlich über MCP, das Model Context Protocol, einen breit unterstützten offenen Standard im KI-Ökosystem. MCP entkoppelt Use-Case-Logik von der Frontend-Schicht. Häufig genutzte Fähigkeiten werden als Skills abstrahiert und wiederverwendbar gemacht: Eine RAG-Anbindung, eine Systemintegration, einmal gebaut, für mehrere Use Cases verfügbar. Das ist der konkrete Mechanismus, über den Use Case 3 günstiger wird als Use Case 1: Nicht, weil das Team schneller ist, sondern weil es auf Bestehendem aufbaut, statt neu zu beginnen.

Schicht 2: Engineering und Runtime

Alles lebt in Code und Source Control. Keine click-konfigurierten Zustände, die nicht versionierbar sind. Was in Code lebt, kann getestet, deployed und auditiert werden. Was im Portal lebt, nicht.

Compute läuft containerisiert auf Azure Container Apps für leichte Workloads und Azure Kubernetes Service für komplexere Szenarien. Portabilität, Skalierbarkeit, echte Observability über Application Insights und OpenTelemetry. Produktiv- und Testsysteme sind konsequent getrennt: Prompt-Änderungen, Modell-Wechsel und neue Datenquellen werden über Evaluation-Pipelines in Azure AI Foundry vor dem Produktivbetrieb validiert. Das löst direkt das Problem, das in Copilot Studio nicht lösbar war.

Alle Use Cases teilen einen gemeinsamen Data-Layer: Zentral aufbereitete Datenquellen, Wikis, Ticketsysteme, Handbücher, ERP-Daten, einmal aufgebaut, für alle verfügbar. Blueprints und Templates stellen sicher, dass Use Case N+1 auf bewährter Architektur aufsetzt, statt bei Null zu beginnen.

Auf dieser Schicht entstehen komplexe Multi-Agent-Systeme: Ein Orchestrator-Agent zerlegt Aufgaben, delegiert sie an spezialisierte Sub-Agenten, die parallel über MCP auf Unternehmenssysteme zugreifen, und konsolidiert die Ergebnisse. Das Microsoft Agent Framework, LangGraph oder unser eigenes Open-Source-Framework Flock liefern dafür die Orchestrierungslogik. Jeder Agent läuft als containerisierter Service mit eigener Entra-Identität: Replizierbar, auditierbar und vollständig unter Engineering-Kontrolle. Genau das unterscheidet produktive Agentic AI von einem gut gemeinten Experiment.

Schicht 3: Governance, FinOps und Souveränität

Das ist die Schicht, die in KI-Projekten als “nice to have” behandelt wird und in der Produktion zur existenziellen Frage wird.

Governance bedeutet zentrales Logging und Audit-Trail aller KI-Interaktionen. Jede Anfrage, jede Modell-Response, jeder Tool-Aufruf, jede Datenquelle, vollständig nachvollziehbar. EU AI Act, §203 StGB und DORA-Anforderungen sind damit direkt erfüllbar. Modell-Freigaben und Access Control sind granular pro Use Case konfigurierbar, nicht auf Tenant-Ebene. Was kein Click-Path leisten kann, löst nur eine Engineering-Schicht, die von Anfang an Teil der Plattform ist. Wer diese Schicht heute sauber aufbaut, kann morgen Modelle wechseln, neue Regulierungsvorgaben erfüllen und Use Cases auf neue Systeme ausweiten, ohne von vorne zu beginnen. Das ist keine Compliance-Pflicht. Das ist ein Wettbewerbsvorteil.

FinOps bedeutet Cost Center pro Use Case, Token-Limits pro Team, Echtzeit-Transparenz über KI-Kosten, bevor die Azure-Rechnung kommt. Das erfordert eine zentrale Ebene quer über alle Use Cases. Wir adressieren das mit Token Control. Der Grundsatz gilt unabhängig vom Werkzeug: Diese Ebene muss Bestandteil der Plattform sein.

Souveränität ist für den deutschen Mittelstand keine ideologische Position, sondern eine sachliche Risikoabwägung. Die Frage ist nicht, ob man US-Hyperscaler nutzt; Azure ist eine legitime und leistungsstarke Wahl. Die Frage ist, ob man so baut, dass man Optionen behält. Wer Agents, Datenflüsse und Geschäftslogik in proprietäre Plattform-Strukturen einbettet, die sich einseitig ändern können, verliert diese Optionen. Eine KI-Plattform auf Azure mit Open-Source-Frameworks und offenen Standards erhält sie: Daten und Modelle im eigenen Azure-Tenant, unter voller Kontrolle des Unternehmens. Agent-Frameworks wählbar und wechselbar. Souverän zu bauen bedeutet nicht, auf Leistung zu verzichten. Es bedeutet, nicht in einer Situation aufzuwachen, in der ein Plattform-Update oder eine Lizenzänderung den eigenen KI-Stack grundlegend verändert, ohne dass man selbst die Wahl hatte.

Diese drei Schichten sind auch die Voraussetzung dafür, dass agentische AI-Systeme – die anspruchsvollste der drei Use-Case-Klassen – zuverlässig in Produktion laufen. Multi-Agent-Orchestrierung, Tool-Use über klar definierte MCP-Scopes, Human-in-the-Loop-Gates an kritischen Entscheidungspunkten, Entra Agent ID für jede Agent-Aktion: All das setzt voraus, dass Ausführungsumgebung, Datenanbindung, Identity und Audit-Trail als gemeinsame Foundation existieren.

Der Maßstab für eine KI-Plattform ist nicht, wie gut Use Case 1 läuft. Es ist, wie schnell und sicher Use Case 20 entwickelt und betrieben wird.

Wo Sie jetzt ansetzen können

Wer heute mehr als einen AI Use Case produktiv betreibt oder ernsthaft plant, sollte die Plattform-Frage jetzt stellen. Nicht beim fünften Piloten, der an derselben Stelle stecken bleibt wie der Zweite.

Ob Plattformaufbau oder der Bau konkreter agentischer Use Cases auf dieser Foundation: Unser Angebot Cloud Native Entwicklung mit KI deckt beides ab. Sprechen Sie uns an.