SAPPHIRE 2026 — Three Readings of a Keynote
What the Orlando announcements really mean — and why the most interesting questions weren’t answered on stage.
Introduction: A Keynote Is Not a Whitepaper
A SAPPHIRE keynote follows its own dramaturgy. It’s not about complete information. It’s about staging. Christian Klein stands on stage, behind him a display the size of a mid-sized industrial building, and over ninety minutes, messages are placed that will shape the next year. Anyone who reads a keynote like product documentation misunderstands the genre.
The 2026 keynote in Orlando was a masterclass in this regard. Three major messages were set: the “Autonomous Enterprise” as a vision, the Agent-to-Agent pact with Microsoft as a strategic alliance, and “Sovereign AI by Design” as the answer to the European sovereignty debate. Each message was delivered with confidence, backed by customer references, and made plausible through roadmap slides.
And yet: the really interesting questions weren’t answered. Not because SAP wanted to hide them, but because a keynote structurally cannot answer them. A keynote sets narratives. It doesn’t resolve architecture questions. It doesn’t resolve governance questions. It doesn’t resolve economic questions.
But those questions need to be asked in the coming weeks — in board meetings, IT steering committees, and strategy workshops. Anyone who delegates or postpones them will be overtaken in twelve months by realities that today still look like marketing slides.
This article offers three readings of the keynote — three analytical cuts through the same material. Each reading illuminates a different aspect, each asks different questions, and all three together produce a picture that is considerably sharper than the sum of the marketing messages.
First Reading — Maturity: What Is Real Today?
Let’s start with the most obvious question: of everything announced, what actually works today? What is pilot, what is vision, what is pure slideware?
Anyone who has followed SAP keynotes over several years knows the pattern. On stage, solutions are demonstrated that work impressively in a controlled demo environment. Twelve months later, General Availability arrives. Another twelve months later, the first customer references go productive. And another twelve months later, the feature is broadly deployable.
This timeline is not an accusation against SAP. It is the reality of enterprise software. But it has consequences for how a CIO or CDO should respond to the announcements today.
For such assessments, I use a simple heuristic I call the 20/30/50 rule. In every major platform keynote, roughly 20 percent of the announced functions are actually productive today — with reference customers, documented results, and calculable effort. Another 30 percent are in advanced pilot phase, often with selected customers in limited scope. And the remaining 50 percent are strategic vision: there is a roadmap, there is an architectural idea, perhaps there are early prototypes — but there is no path to productive deployment within the next twelve to eighteen months.
Applied to the Orlando keynote: the “Joule agents for procurement” — automatically generating supplier inquiries, comparing quotes, flagging contract deviations — likely belong in the first 20 percent. This functionality exists, it has been tested, and it delivers measurable value in clearly defined use cases. The announced “autonomous production agents,” which coordinate shift planning, machine scheduling, and material disposition, belong more in the 30 percent pilot zone. Early customers are testing, but we are far from a mature, scalable solution. And the “Autonomous Enterprise” as an overall picture — self-steering value chains that autonomously execute strategic decisions under human supervision — that is the 50 percent vision. Right direction, but not an operational program for 2026.
The strategic consequence for CIOs and CDOs is not to ignore the vision. It is to separate the vision from the reality. Anyone allocating budget today should prioritize the first 20 percent: where the technology is mature, the use case clearly definable, and the business case calculable. The 30 percent deserves pilot budgets — controlled, with clear abort criteria. The 50 percent belongs in the strategy roadmap, but not in the investment plan.
A second observation matters. Maturity is not maturity. A Joule agent that works in a Tier-1 corporation with a mature data foundation and a dedicated AI team is not automatically a Joule agent that works in mid-market industrial companies. The demo environments shown in Orlando are built on cleansed master data, clean processes, and curated example scenarios. The reality in most industrial companies looks different. Bills of materials are incomplete, supplier master data is heterogeneous, contract documents sit as scanned PDFs in SharePoint folders. No AI agent operates reliably on this foundation.
This is not SAP’s problem. It is the problem of the user companies. But it determines which level of maturity is achievable in your own organization. The honest question, therefore, is not: what can Joule do? It is: what can Joule do with our data and in our processes?
This question can only be answered through a structured assessment matrix. In my consulting practice, I work with three dimensions: data maturity (is the master data in a state that permits AI application?), process maturity (are the business processes documented and stable enough that an agent can operate on them?), and governance maturity (are there clear rules about what an agent may do, who supervises it, who is liable?). Only when all three dimensions reach at least level three out of five does productive deployment make sense. Below that, every pilot is an expensive learning project — which can be legitimate, but must be treated as such.
The first reading ends with a sober recommendation. Don’t let the vision keep you from checking the maturity. But don’t let the current maturity keep you from taking the vision seriously.
Second Reading — Architecture: Who Controls the Layer?
The second reading goes deeper. It shifts the view from individual functions to architecture — and to the strategic question of who will control the intelligence layer of enterprise applications in the coming years.
The most important announcement of the keynote, in this regard, was not “Autonomous Enterprise.” It was a sentence that disappeared in most summaries: Joule now speaks natively with Microsoft 365 Copilot. Agent-to-Agent interoperability. Sounds like a feature. Is a strategic landslide.
To understand the significance, you need to know the backstory. For two years, SAP tried to position Joule as the place where knowledge workers spend their day. Joule was supposed to become the interface through which buyers query their suppliers, planners check their inventories, controllers pull their reports. This strategy had a clear logic: whoever controls the interface controls the value creation. Microsoft has known this logic for decades — it’s the reason Office continues to dominate the market despite all alternatives.
But Microsoft rolled out Copilot in the meantime. To 400 million Microsoft 365 users. With native integration into Outlook, Teams, Word, Excel. Anyone who has once understood how Copilot analyzes a spreadsheet or drafts an email reply will not switch to a separate application to perform a similar task. The battle for the AI workspace is decided, and SAP did not win it.
The decision to make Joule interoperable with Copilot is therefore not a cooperation among equals. It is the sober acknowledgment of a changed power dynamic. SAP gives up the interface — and tries instead to remain the system of record. The user works in Outlook and Teams, but the processes triggered run in S/4HANA. The intelligence Joule contributes becomes a service layer between Microsoft workspace and SAP backbone.
Architecturally, this is the right answer. Economically, it gets interesting.
Three consequences deserve board-level attention.
The first concerns license economics. Anyone licensing Microsoft 365 Copilot and in parallel consuming Joule through SAP pays twice for the intelligence layer. Once to Microsoft per user per month, once to SAP on a consumption model. The question is not whether this adds up — the question is how high the markup will be in three years. For a mid-market industrial company with 2,000 knowledge workers and intensive SAP usage, we are talking about additional seven-figure annual budgets that are not calculated in any current IT plan.
The second consequence concerns governance. When a Copilot agent triggers a Joule agent via the A2A interface that initiates a purchase order in S/4HANA — who is responsible if that order should not have been initiated? The Microsoft compliance rules defining what Copilot may do are not identical to the SAP authorization concepts defining which transactions a user may execute. At the interface, a governance vacuum emerges that is not addressed in most organizations today. Whoever is responsible for SOX compliance should be talking to internal audit by now.
The third consequence concerns lock-in. Lock-in on a platform is a known quantity — most organizations have learned to manage it. Lock-in on the connection between two platforms is a new category. If business processes depend on Copilot and Joule communicating with each other, then organizations are no longer dependent on a single vendor but on a specific vendor combination. A migration away from Microsoft then affects not just the workspace, but also the SAP integration. A migration away from SAP affects not just the ERP, but also the Microsoft integration. Exit costs double, without being reflected in today’s TCO models.
Architecturally, this can be thought of in a three-layer model. The bottom layer is the system of record: SAP, holding master data, transactions, and business processes. The middle layer is intelligence: Joule on the SAP side, Copilot on the Microsoft side, with the A2A bridge between them. The top layer is the interface: where the user actually works, which is primarily the Microsoft environment. The strategic question is who will define the middle layer in the coming years. Whoever controls the routing logic — which agent takes on which task — holds the value creation. Today, this question is open. In three years, it will be decided — and anyone who doesn’t ask it will live with the answer without having influenced it.
The second reading ends with a question that must not be missing from any IT strategy in the next twelve months: which architecture decisions do we make consciously, and which do the vendors make for us?
Third Reading — Sovereignty: What’s Really in the Engine Room?
The third reading addresses the term that was born in Orlando and has not let go of me since: “Sovereign AI by Design.”
Sounds good. Sounds European. Sounds like an answer to a legitimate concern. Let’s look more closely.
What does “Sovereign AI by Design” mean concretely? SAP promises: AI functions running in sovereign cloud environments. Data residency in the EU. Compliance with the AI Act. On the slides, this looks like digital self-determination. In reality, three questions matter that are not answered on the slides.
The first question concerns the foundation models. Which models are in the engine room of Joule? The answer is not fully transparent today, but the key components are known: GPT-4 from OpenAI and Claude from Anthropic. Both U.S. companies, both under U.S. jurisdiction, both fundamentally subject to the CLOUD Act. A model running on European servers is not sovereign if the model weights, the training, and the roadmap are decided in San Francisco. The data may not leave the EU — but the intelligence operating on the data is American.
The second question concerns the infrastructure. SAP does not operate its cloud in its own data centers — the SAP cloud runs on AWS, Microsoft Azure, and Google Cloud. Three U.S. hyperscalers. “Sovereign” is achieved through contractual constructs: data residency guarantees, encryption keys under customer control, legally defined access restrictions. These constructs are not worthless — but they are contractual, not technical. In a serious case — and serious cases are defined by geopolitical tensions that are not foreseeable today — jurisdiction decides over contract law, not the other way around.
The third question concerns agent logic. Joule decides which prompt goes to which model. This routing logic is proprietary. The customer sees the result, but not the decision path. Which model answered a question? Which data was loaded into the context? Which safety filters were applied? These questions are not auditable today — and this is not a temporary state that will resolve itself through maturity, but a deliberate architectural decision. SAP will not disclose the routing logic, because it belongs to the core of the value proposition.
Let me be clear: this is not an accusation against SAP. SAP is doing the economically right thing. Training proprietary foundation models costs tens of billions and produces models that lag behind the state of the art. The partnership with OpenAI and Anthropic is the rational decision — it gives customers access to the best available technology without the investment risk. If I were on SAP’s board, I would make the same decision.
But: “Sovereign AI by Design” is marketing, not architecture. Real sovereignty would be something else. It would be foundation models under European control — which today means Mistral, perhaps later Aleph Alpha or a state-backed consortium. It would be infrastructure under European jurisdiction — not just data residency, but ownership and control of the data centers. It would be transparent, auditable agent logic — with the option for customers and regulators to understand how decisions come about.
We are far from all of this. And it will not change in the next three years. Mistral is technologically impressive, but compared to OpenAI and Anthropic, it is a dwarf. Aleph Alpha has largely withdrawn from the foundation model business. A state-backed European AI consortium exists in Sunday speeches, but not in industrial policy. Anyone waiting for European sovereignty waits in vain.
What does this mean for CIOs and CDOs? It does not mean sovereignty is irrelevant — on the contrary. It means sovereignty must not be treated as a checkbox. Honest engagement requires three decisions every organization must make for itself.
The first decision is a data classification. Which data must under no circumstances go into a U.S. model? Engineering data? Negotiation strategies with Chinese suppliers? Personnel files of employees in regulated functions? This classification must be in writing, must be backed by the board, and must be implemented in technical controls — not in training sessions.
The second decision is a process assignment. Which business processes can be consciously assigned to the U.S. stack because the risk is manageable? Marketing copy, code generation, translations, general research — here sensitivity is low and productivity gains are high. This pragmatic separation between “can use U.S. stack” and “must not use U.S. stack” is the operational answer to a strategic question that ideally will never be answerable with a single yes or no.
The third decision is an exit architecture. Which components must be built such that they can be swapped for European alternatives within twelve months, should the geopolitical situation require it? This question forces modularity — and modularity is more expensive than monolithic integration. But it is the only technical answer to a strategic uncertainty that cannot be resolved.
The third reading ends not with resignation, but with a precise demand. Sovereignty is not a marketing term. Sovereignty is an architectural discipline. And it belongs on the board agenda — not in IT steering.
Synthesis — The One Question That Matters
When you put the three readings together, a pattern emerges. The maturity question leads to the architecture question, the architecture question leads to the sovereignty question, and all three are connected by a common movement: the shift of the AI discussion from the feature level to the strategy level.
For the past three years, AI was treated in most companies as a feature topic. Which functions exist? How many use cases can we identify? How high is the productivity gain? These questions are not wrong, but they are insufficient. They treat AI like a new software version — like something you buy, install, and use.
The Orlando keynote makes clear that this view no longer holds. AI is no longer a feature. AI is the layer in which the business processes of the future are defined. Whoever controls the layer controls the value creation. Whoever does not control it is controlled.
This shift has consequences for who decides on AI in companies. As long as AI was a feature, it was an IT topic. The CIO released budget, the IT department set up pilot projects, individual business units identified use cases. That works for features. It does not work for a layer that will define the operational business architecture over the next five years.
The maturity question is a question of investment focus — and belongs on the board agenda, not in IT steering. The architecture question is a question of vendor dependency and exit costs — and belongs on the supervisory board, not in business unit leadership. The sovereignty question is a question of geopolitical resilience — and belongs at executive level, not in the compliance department.
That this shift is difficult is known to anyone who has accompanied similar movements over the past twenty years. Cloud migration was a comparable shift — from “new servers” to “new business architecture.” It took about ten years before it reached board level. With AI, we don’t have that time. The strategic decisions made today define the competitive position for the next five years.
This is why I have been speaking about “Adult Supervision” for two years. The term is deliberately provocative. It says: this technology is too important to be left exclusively to specialists who think in tokens and embeddings. It needs experienced people with process knowledge, business acumen, and strategic judgment. It needs adult supervision — not in the sense of distrust toward technologists, but in the sense of responsibility toward the organization.
The SAPPHIRE 2026 keynote did not change the playing field. It made visible what has been emerging for months. The question is no longer whether AI will be integrated into operational value creation. The question is who steers the integration — the vendors, the consultants, or the companies themselves.
Closing: Three Questions for the Next Board Meeting
If this article has one purpose, it is to bring three questions into board meetings where they are often not asked today.
First: which level of maturity is realistically achievable in our organization — given our data foundation, our processes, and our governance structures? The answer will be uncomfortable, because it usually turns out lower than the vendor slides suggest. But it is the only sound basis for investment decisions.
Second: which architecture decisions do we make consciously, and which do the vendors make for us? If the answer is that we leave the decisions to the vendors today, that is a conscious decision with foreseeable consequences. If the answer is that we want to make the decisions ourselves, that requires an architectural competence that is not sufficiently built up in most organizations today.
Third: how do we operationalize sovereignty without letting it become a slogan? A data classification, a process assignment, an exit architecture — these are the building blocks. They cost money, they cost time, and they produce no quick wins. But they produce strategic agency.
Three readings of a keynote. Three questions for the next board meeting. One insight: AI in industry is no longer an IT task. It is a leadership task. And it demands adult supervision — not tomorrow, but today.
E-Mail: sven.vollmer@business-quotient.com
Sven Vollmer is “The Industrial Translator.” He bridges the gap between industrial operational reality (SAP, supply chain) and the possibilities of generative AI. His focus is on value-creating applications—beyond the hype.
Transparency Note: This article was created with editorial support from AI (Gemini/Claude). The ideas, technical validation, use case selection, and adult supervision were 100% authored by Sven Vollmer.
LinkedIn: www.linkedin.com/in/sven-vollmer-bq
