Around one in three companies in Germany now uses AI; in 2024, it was only 20 percent (Bitkom AI 2025). A further 47 percent are planning or discussing its use. The gap, therefore, no longer lies in interest in AI, but in scalable, productive implementation.
Nevertheless, SMEs did not increase their AI investments in 2025, but decreased them: To 30 percent below the market average (Horváth Study, January 2026). This does not happen because companies do not want to adopt AI. It happens because projects do not deliver.
What we observe repeatedly in the market: AI pilots do not reach production. Processes are partially automated, not fully automated. And even the use cases that do run, run in isolation, without governance, without compliance, and without reusability for the next use case.
The problem is not the model. It is not the provider. It is the lack of a foundation. As long as every use case starts from scratch, scaling is an illusion.
Three ways AI impacts the enterprise
Not all AI initiatives have the same requirements. Determining whether it is a personal assistant, an automated process, or an agentic system directly decides which stack is appropriate and which governance requirements arise.
Personal Co-pilots are chat-based assistants for a single person. The lever is individual productivity, and the decisive factor is often not the writing assistant, but direct access to company data via natural language queries: An employee queries the product manual instead of searching through it, asks about a specific clause in the contract database, or retrieves the relevant customer history before a meeting. To name just a few examples.
Flow and process automation goes one step further. Defined workflow, multiple steps, integrated systems. AI takes over the parts that rule-based automation cannot solve cleanly: classification, validation, enrichment. Incoming document validation and matching against master data, ticket triage by priority, offer verification against supplier SLAs.
Agentic AI systems are the third class. The agent decides for itself what happens next within the framework of a goal, across multiple tools and data sources, without explicit step-by-step instructions. This does not mean fully automatic systems without human control, but autonomy within a defined scope, often with human-in-the-loop gates at critical decision points. Complete sales preparation via CRM, web research, email history, and calendar. Compliance checks against policy databases and current regulatory texts. A monitoring agent that reacts independently to anomalies in production data.
These three classes are not maturity levels. They are different answers to different problems. However, as requirements become more complex, the tools commonly used today quickly reach their limits.
What SMEs use today, and where it ends
These three classes correspond directly to the tool spectrum we find in SMEs.
M365 Copilot and other in-app AI tools are the natural entry point for everyone who already has licenses for M365 or other software. Copilot runs where employees already work: in Word, Teams, and Outlook. No setup effort, no new UI, immediate initial results. A neutral fact remains: M365 Copilot is initially optimized for the Microsoft 365 data space. External systems such as SAP, CRM, or proprietary databases can be integrated via Copilot and Graph Connectors, but they are not an automatically included part of the data space. This is exactly where the architecture and governance effort begins.
Copilot Studio is the extension toward custom agents and structured flows on a low-code basis: A visual designer for connecting to external systems via connectors. Good for clearly defined conversational use cases with SharePoint as a knowledge base. For many SME teams, it is the first step beyond pure chat.
Power Platform and n8n address workflow automation with AI. Power Automate, part of the Power Platform, is deeply integrated into the Microsoft ecosystem and targets citizen developers with a broad connector catalog. n8n is an open-source alternative for more technically inclined teams that prioritize self-hosting and vendor neutrality while working close to infrastructure-as-code. In both cases, AI serves as a building block in a defined workflow: classification, extraction, text generation. These are not independently acting agent systems.
We recommend not underestimating these tools. They deliver real value in their respective sweet spots. The problem does not arise with the first use case. It arises when use cases become more demanding or when several are intended to run in parallel across various data silos and systems.
Where the friction begins
As long as one or two use cases run on the same stack, there is no problem. It becomes interesting when use cases need to scale or when a productive use case must access a system outside the respective tool stack.
Copilot Studio: When AI quality cannot be controlled
The platform offers RAG out-of-the-box: configure knowledge sources, ask questions, receive answers. The problem begins when the quality is insufficient and you don’t know why. Copilot Studio delivers the top 3 results per knowledge source for every query; chunk size, embedding strategy, and retrieval parameters are not configurable. Added to this are hard scaling limits: A maximum of 1,000 files are possible per knowledge source, while the practical limit for reliable results is 500. For companies with several thousand internal documents, this is an architectural limit, not a configuration problem.
Furthermore, there are structural limitations that are frequently underestimated in practice:
- Application Lifecycle Management (ALM) is possible but rarely used: Copilot Studio supports solutions, pipelines, and Git integration, yet many teams work in a single environment without a consistent review process, leading to the known consequences.
- No model version pinning: The model family is selectable (GPT-4.1, GPT-5, etc.), but a specific deployment cannot be fixed. If Microsoft changes the model default, the agent’s behavior changes without the system logging the switch.
- Token accumulation without management: In long agentic conversations, consumption from conversation history, system prompts, and knowledge context accumulates up to the model limit, without Copilot Studio offering native token management.
- Multi-agent only via workaround: Agentic scenarios with multiple agents can currently only be implemented via a parent-proxy workaround.
The result speaks for itself: Gartner surveyed Copilot Enterprise customers and concluded that significantly fewer than 10 percent of pilots make the leap into productive operation.
Power Platform and n8n: When AI becomes invisible in flows
Quickly built flows are quickly forgotten: Who deployed them, which systems are connected, which credentials are stored? This is familiar from classic automation. With AI-equipped flows, a new layer is added. A prompt embedded directly in a Power Automate step or n8n node has no version history. If it is changed, even if just one sentence is reformulated, the agent’s behavior changes without anyone logging it. The same applies if the model or model version is changed by the provider: this also has no version history, no audit trail, and no rollback. Additionally, there is a specific cost risk: the seeded AI Builder credits included in many Power Apps Premium licenses expire on November 1, 2026. After that, separate Copilot credits or AI Builder add-ons are required. Anyone building on this model today without knowing the cost structure is building on a vanishing foundation.
Regulation that forces engineering control
The EU AI Act has been in force since August 1, 2024. The high-risk AI obligations originally expected for August 2026 are currently being adjusted through the ongoing Digital Omnibus procedure and could be postponed to December 2027 or later for certain systems. For companies, this changes little regarding the practical task. §203 StGB (German Criminal Code) affects all regulated professions: tax consultants, lawyers, healthcare providers. A specific scenario: An employee at a law firm uses a Copilot Studio agent to answer client inquiries. The model draws context from a SharePoint containing case files. §203 StGB protects client confidentiality, and an agent without a traceable data flow and audit trail is incompatible with this requirement, no matter how good the answers sound. The same applies to DORA in the financial sector: anyone who cannot prove which model processed which data and when has a compliance problem. What compliance-relevant use cases urgently need: a complete audit trail, documented data flows, and traceable model selection.
OpenClaw and the limits of autonomy
What we are currently seeing in the innovation units of SME customers: experiments with locally running autonomous agents, where they are given LLM model access and system access and decide for themselves what to do. The best-known example is OpenClaw, an open-source framework that embodies exactly this principle. The demos are fascinating. In productive use, not a single case in our customer base has survived a security review. The reason is simple: every system action in a regulated environment needs a traceable, pre-defined scope. An autonomous agent without scope definition, human approval gates, and an audit trail is not production AI. Autonomy without structure is not scaling. It is a well-intentioned experiment.
The following table summarizes where these limits lie:
| Use Case Class | Common Tools Today | Natural Limit |
|---|---|---|
| Personal Co-pilots | M365 Copilot, In-App AI | External systems require connector effort and governance |
| Flow / Process Automation | Copilot Studio, Power Platform, n8n | Lack of controllability, governance debt, no auditability at scale |
| Agentic Systems | Open Source SDKs, Azure AI Foundry | Pure low-code setups are insufficient for regulated, auditable enterprise scenarios |
Agentic systems can be built technically with various platforms. However, for regulated, auditable, and reusable enterprise scenarios, pure low-code setups are rarely sufficient to scale integrated AI agent systems. And the difficulties mentioned are not weaknesses of individual products. They are the result of how no-code and low-code tools are typically used. Low-code tools solve the first problem. Rarely the next five.
Azure AI Foundry: Portal or Engineering
When Copilot Studio or Power Platform teams reach these limits, the current market response is: Migrate to Azure AI Foundry. This is correct. But what this means in practice is crucial.
Azure AI Foundry is Microsoft’s central Azure PaaS platform for the development, evaluation, and operation of AI applications and agents. The model catalog includes over 1,900 curated models – including Azure OpenAI, Claude from Anthropic, and Mistral – supplemented by tens of thousands of open-source models via Hugging Face. Added to this are the Foundry Agent Service as a managed runtime for autonomous agents, and Foundry IQ as an agentic RAG engine based on Azure AI Search with multi-source grounding, hybrid retrieval, and permission-controlled data access. The same platform, but two very different ways of using it.
Portal Mode: Valuable for exploration, model comparison, and rapid prototyping. The natural transition from Copilot Studio: more models, more configuration options, quick entry. However, it does not replace engineering discipline. Without IaC, CI/CD, and reproducible deployments, no platform-ready setup is created, but rather another isolated project. What is typically missing without engineering discipline:
- Reproducible deployments: Configuration lives in the portal, not in source control
- Automated evaluation gates in the deployment pipeline
- Network isolation: Endpoints are publicly accessible by default
- Enforceable token budget and cost enforcement
- Auditable operational history
Engineering Mode: The same platform, but operated via SDKs, open-source agent frameworks such as Microsoft Agent Framework, LangGraph, or Flock, as well as Terraform and GitHub Actions. What becomes available with this:
- Evaluation pipelines for models, RAG pipelines, and agent workflows as an automated CI/CD gate
- Private endpoints, VNET integration, and Managed Identity: No public endpoints, no API key management
- Deployment on ACA or AKS with horizontal scaling and blue/green rollouts
- Multi-agent architectures programmatically controllable via Foundry Agent Service and A2A protocol
- Everything in source control, everything versionable, everything auditable
The shift that migrating teams often overlook: Anyone switching from Copilot Studio to the portal mode of Foundry takes the governance debt with them. The step to Foundry only pays off when the mode is consistently changed.
A frequently optimal pattern from practice: Switching to Foundry does not necessarily mean completely replacing Copilot Studio. AI Foundry and Azure take over the AI backend, RAG, model management, observability, and deployment. Copilot Studio remains as the frontend for M365-native workflows and Teams integration. Copilot Studio ends where AI Foundry and Azure AI architecture begin, and both levels can deliberately interact. The key is that Foundry is operated as an engineering platform in this setup, not as another portal.
The step from Copilot Studio to Azure AI Foundry is correct. It only pays off when the platform is operated with engineering depth.
The foundation on which use cases scale
An AI platform for SMEs is not a product you buy. But before we describe what it is, it is worth looking at what happens without it.
What we observe in the market: Use Case 1 builds a data connection to the internal wiki. Use Case 2 needs the same data pipeline and builds it again because the first team did not leave a reusable layer. Use Case 3 has its own identity model. Use Case 4 has no logging. Use Case 5 shows a compliance blocker because the audit trail is missing. The costs are not linear: they grow because every new isolation creates a new debt. Token-based billing makes this transparent: anyone who does not have a cost center per use case and no limits per team will not be able to answer the cost question when it comes.
The conclusion: A shared foundation, not for architectural elegance, but to scale. Quickly and cost-effectively.
Such a platform does not emerge in a single project. It grows with every use case built upon it, and that is exactly where its value lies: every new use case makes the foundation better, not more expensive.
We structure this platform into three layers:
Layer 1: Interface and Integration
All chat-based AI use cases run through a central interface. For our customers, we provide this as PrivateGPT: A dedicated web application as a frontend for all conversational use cases, with Entra ID login, use case dashboard, and a unified user experience, optionally as a Teams integration via Bot Framework. Not a new UI for every new use case. One frontend, many backends.
The connection of use cases is carried out uniformly via MCP, the Model Context Protocol, a widely supported open standard in the AI ecosystem. MCP decouples use case logic from the frontend layer. Frequently used capabilities are abstracted as skills and made reusable: A RAG connection or a system integration, once built, is available for multiple use cases. This is the specific mechanism through which Use Case 3 becomes cheaper than Use Case 1: not because the team is faster, but because it builds on existing elements instead of starting anew.
Layer 2: Engineering and Runtime
Everything lives in code and source control. No click-configured states that are not versionable. What lives in code can be tested, deployed, and audited. What lives in the portal cannot.
Compute runs containerized on Azure Container Apps for light workloads and Azure Kubernetes Service for more complex scenarios. Portability, scalability, and true observability via Application Insights and OpenTelemetry. Production and test systems are strictly separated: prompt changes, model switches, and new data sources are validated via evaluation pipelines in Azure AI Foundry before production operation. This directly solves the problem that was not solvable in Copilot Studio.
All use cases share a common data layer: centrally prepared data sources, wikis, ticket systems, manuals, and ERP data, once established, are available to everyone. Blueprints and templates ensure that Use Case N+1 is based on proven architecture instead of starting from scratch.
Complex multi-agent systems are created on this layer: An orchestrator agent breaks down tasks and delegates them to specialized sub-agents that access company systems in parallel via MCP and consolidate the results. The Microsoft Agent Framework, LangGraph, or our own open-source framework Flock provide the orchestration logic for this. Each agent runs as a containerized service with its own Entra identity: replicable, auditable, and fully under engineering control. This is exactly what distinguishes productive agentic AI from a well-intentioned experiment.
Layer 3: Governance, FinOps, and Sovereignty
This is the layer that is treated as “nice to have” in AI projects and becomes an existential question in production.
Governance means central logging and an audit trail of all AI interactions. Every query, every model response, every tool call, and every data source is fully traceable. EU AI Act, §203 StGB, and DORA requirements are thus directly fulfillable. Model approvals and access control are granularly configurable per use case, not at the tenant level. What no click-path can achieve is only solved by an engineering layer that is part of the platform from the start. Anyone who builds this layer cleanly today can switch models tomorrow, meet new regulatory requirements, and extend use cases to new systems without starting from scratch. This is not a compliance obligation. It is a competitive advantage.
FinOps means a cost center per use case, token limits per team, and real-time transparency regarding AI costs before the Azure bill arrives. This requires a central level across all use cases. We address this with Token Control. The principle applies regardless of the tool: this level must be part of the platform.
For German SMEs, sovereignty is not an ideological position, but a factual risk assessment. The question is not whether one uses US hyperscalers; Azure is a legitimate and powerful choice. The question is whether one builds in a way that retains options. Anyone who embeds agents, data flows, and business logic into proprietary platform structures that can change unilaterally loses these options. An AI platform on Azure with open-source frameworks and open standards preserves them: data and models in your own Azure tenant, under the full control of the company. Agent frameworks are selectable and exchangeable. Building sovereignly does not mean sacrificing performance. It means not waking up in a situation where a platform update or a license change fundamentally alters your own AI stack without you having a choice.
These three layers are also the prerequisite for agentic AI systems – the most demanding of the three use case classes – to run reliably in production. Multi-agent orchestration, tool use via clearly defined MCP scopes, human-in-the-loop gates at critical decision points, and Entra Agent ID for every agent action: all of this requires that the execution environment, data connection, identity, and audit trail exist as a common foundation.
The benchmark for an AI platform is not how well Use Case 1 runs. It is how quickly and securely Use Case 20 is developed and operated.
