DSAG's 3% Joule number is not an adoption problem

What DSAG actually found

The DSAG Investitionsreport surveys German-speaking SAP customers — DACH Mittelstand, the people who run the installed base. The 2026 edition produced three figures worth holding together:

• 3% use SAP Joule productively today.
• 77% of SAP customers running AI in production are using Microsoft Copilot.
• 78% of respondents run hybrid landscapes (on-prem plus cloud); only 5–7% run core operations exclusively on public cloud.

The first number is the one SAP critics seized on. The second is the one that explains it. The third is the one that explains the second.

Why the routing decision goes to Microsoft

The Microsoft Copilot licence is, in most German Mittelstand companies, already on the desk. M365 covers most knowledge-worker seats. Adding Copilot is a tier change inside an existing Enterprise Agreement. The procurement path is known. The cost is predictable. The data-residency story is workable for most use cases.

Joule is a different procurement story. To use Joule productively today, a customer typically needs one of:

• A RISE with SAP contract — committing to SAP-managed S/4HANA on hyperscaler infrastructure.
• A GROW with SAP contract — for greenfield S/4HANA Public Cloud.
• An entitlement bought through the SAP Business AI Platform consumption model — typically opaque until quoted.

For a Mittelstand company running on-prem ERP — which is the 78% — none of these match the existing procurement pattern. The on-prem stack is locked out of most Joule features. Pricing is not transparent. Roadmap timing is not under customer control.

Faced with a button they already have on a tier they already pay for, versus a button they would have to buy a new contract structure to reach, the Mittelstand IT director picks the button they have. Hence Copilot. The 3% number is the visible artefact of that rational choice.

What this means for SAP's AI narrative

SAP's Sapphire 2026 narrative was Autonomous Enterprise — Joule as the agentic surface across the portfolio. The narrative requires customers to concentrate AI workload on SAP. The DSAG numbers say they're doing the opposite.

This matters for two reasons. First, every Copilot interaction that reaches across SAP and non-SAP data trains the customer's mental model on a Microsoft AI surface, not a SAP AI surface. That model becomes the default. Second, every iteration of the customer's automation roadmap adds tooling that doesn't depend on Joule — n8n flows, LangChain agents, Power Automate steps, custom Python wrappers. Each addition makes the "concentrate on SAP" narrative harder to walk back to.

SAP's recent API Policy v4/2026 is partly a response to this drift — an attempt to close the API surface to third-party agents. The DSAG numbers tell us why SAP felt the need: the customers had already left.

The integration consequence

If AI workload routes around SAP into Microsoft (and other surfaces), the integration architecture follows the routing decision. The questions stop being "how do we surface SAP data inside Joule?" and start being:

• How do we replicate the SAP business objects the agents need into a working data plane?
• How do we keep that plane consistent with the SAP system of record?
• How do we govern the agent access to that plane independently of SAP licensing?
• How do we provide provenance, lineage, and audit on the agent's reasoning trail?

These are the same questions we covered in the companion paper on PI/PO to Cloud Integration. The integration layer becomes the foundation for both the SAP transparency gap and the agentic-AI escape hatch — because it is the same layer.

Sources

• DSAG Investitionsreport 2026 (press release, primary source)
• Börse-Express — 3% Joule productive use coverage
• rz10.de — DSAG Technologietage 2026 recap
• Eubuleus — DSAG-TT 2026 analysis