Op Sapphire 2026 presenteert SAP de Autonomous Enterprise als de toekomst van enterprise software. De ambitie is groot. Maar achter de glanzende keynote schuilt een fundamentele strategiekeuze die rechtstreeks ingaat tegen de richting die de rest van de markt op gaat: waar andere open gaan en voor headless kiezen, kiest SAP voor een architectuur waarbij externe AI-agents buitenspel worden gezet en alles via Joule moet.
SAP’s centrale boodschap op Sapphire 2026 is helder: het bedrijf wil dat zijn software bedrijfsprocessen autonoom uitvoert in plaats van de uitkomsten van menselijk werk vastlegt. Meer dan 50 Joule-assistants sturen ruim 200 gespecialiseerde agents aan over finance, supply chain, HR, inkoop en customer experience. Het nieuwe SAP Business AI Platform voegt SAP Business Technology Platform, SAP Business Data Cloud en SAP Business AI samen in één beheerde omgeving. Centraal staat de SAP Knowledge Graph.
Dat klinkt indrukwekkend. De onderliggende data-ambitie is ook echt sterk, SAP heeft vijftig jaar aan bedrijfskritische procesdata in één geïntegreerd systeem. Geen andere vendor heeft finance, supply chain, inkoop, HR en productie zo diep met elkaar verbonden. Maar dan houdt het ook meteen op.
SAP gooit de deur dicht
Terwijl Salesforce en ServiceNow de afgelopen weken kozen voor volledige openheid, kiest SAP voor een andere koers. In april 2026 publiceerde het bedrijf stilletjes een bijgewerkt API-beleid. Sectie 2.2.2 van API Policy v4/2026 verbiedt expliciet het gebruik van SAP API’s door AI-systemen die zelfstandig calls plannen of uitvoeren. In gewone taal: externe AI-agents mogen geen SAP API’s meer gebruiken.
De API’s blijven vooralsnog dicht
CEO Christian Klein probeerde de gemoederen te sussen door te stellen dat klanten niet hoeven te betalen voor toegang tot hun eigen data. Maar mondelinge toezeggingen en contractuele verplichtingen zijn bij SAP twee verschillende zaken. Ondertussen is het beleid nog steeds hetzelfde, externe AI-agents mogen geen SAP API’s gebruiken.
Tijdens Sapphire 2026 spraken we hierover met Thomas Saueressig, Chief Customer Officer. Hij verdedigde het beleid als noodzakelijke governance voor het multi-tenant platform. Toch was zijn conclusie helder: voor agentic use cases is A2A via Joule de enige weg. De publieke API’s zijn er voor statische applicaties, niet voor de dynamische AI-agents van derden.
Wat Salesforce en ServiceNow anders doen
De timing maakt het contrast des te pijnlijker. In april kondigde Salesforce Headless 360 aan: een architectuur waarbij elke feature, denk aan data, workflows en acties, toegankelijk zijn als API, MCP-tool of CLI-commando. Meer dan 60 nieuwe MCP-tools direct bruikbaar vanuit Claude Code, Cursor of elke MCP-compatibele runtime. Geen proprietary AI-interface als verplichte doorgang. Een externe agent kan direct een vaststaande voorspelbare (deterministische) actie aanroepen en hiermee een flow starten, een record aanmaken, een rapport draaien en Salesforce voert het uit. Één inferentielaag. Voorspelbaar, auditeerbaar, testbaar.
Vorige week volgde ServiceNow op Knowledge 2026 met de Action Fabric: twintig jaar aan workflows, playbooks, approval chains en business rules, geopend voor elke AI-agent via REST APIs en MCP. Wederom kan dit zonder extra LLM-inferentie. Bij elke actie zit de intelligentielaag automatisch ingebakken. Voorspelbare vastgestelde processen, toegang met governance en een open architectuur.
Zowel Salesforce als ServiceNow kiezen expliciet voor het headless model: het platform als executielaag, de AI-keuze ligt bij de klant. Agents kunnen direct vastgestelde acties uitvoeren op hun platformen en krijgen een intelligent antwoord terug met knowledge graph en metadata. Geen dubbele inferentie tenzij je dat zelf kiest.
De architectuur van de gedwongen omweg
Bij SAP is dat anders. Tijdens de Q&A op Sapphire werden API’s door de CTO bestempeld als oude technologie, terwijl hij A2A (Agent 2 Agent) en MCP (Model Context Protocol) nieuw en modern noemde. SAP tolereert daarmee enkel A2A als manier om externe AI-agents met Joule te laten communiceren, terwijl de rest van de wereld vooral MCP als open standaard omarmt. SAP gebruikt MCP wel intern voor Joule en voor hun eigen gateway, maar beperkt de reikwijdte ervan naar buiten toe.
Het gevolg: bij SAP zijn externe agents welkom, maar enkel via A2A en Joule. Dit is een duurdere omweg en resulteert altijd in dubbele inferentie. Directe API-toegang is juridisch dichtgetimmerd. Daarmee ontstaat direct een probleem: de uitkomst staat niet vooraf vast en is open voor interpretatie door Joule.
Er is ook nog de nieuwe Integration Suite MCP Gateway die in Q2 verschijnt. Die biedt dezelfde API-toegang als voorheen, maar dan via MCP en met extra kosten per call. Het is eigenlijk een belasting voor het gebruik van externe AI-agents met SAP-data. SAP’s eigen Architecture Center is net als Saueressig echter duidelijk: wie de intelligentielaag wil, de Knowledge Graph, de business context, de proceslogica, moet A2A en Joule gebruiken. De MCP Gateway is niet die route. Het is een betaalde doorgang naar dezelfde data die klanten voorheen via directe API-calls konden benaderen, maar zonder de intelligentie die SAP als zijn grote differentiator positioneert.
Bij SAP is de intelligentie enkel mogelijk via Joule. Wie intelligentie wil, moet langs Joule en dat betekent extra inferentie om te snappen wat de vraag is, welke acties nodig zijn en welke data en intelligentie moeten worden toegevoegd. Dit terwijl de externe AI-agent al een eigen inferentie heeft uitgevoerd om tot die vraag te komen. Twee keer inferentie, twee keer latency, twee keer kosten. Dit is geen keuze maar een architectuurverplichting vanuit SAP.
Saueressig stelt dat A2A de nieuwe standaard is. Agents communiceren via A2A en dat betekent nou eenmaal dubbele inferentie. In de basis heeft hij gelijk, maar dat is enkel omdat SAP exclusief kiest voor A2A.
Het determinisme-probleem
We vroegen ook naar de mogelijkheid die Salesforce en ServiceNow bieden door vastgestelde acties uit te voeren op het platform via API’s. Als je te maken hebt met complexe processen, bijvoorbeeld het betwisten van een frauduleuze creditcardafschrijving, waarbij er acties moeten worden uitgevoerd in diverse financiële systemen, dan wil je zekerheid dat die acties altijd op dezelfde manier worden uitgevoerd. Op het moment dat je hier een LLM met inferentie in betrekt, is er de kans dat de uitkomst niet altijd hetzelfde is. Het AI-model gaat dan keer op keer opnieuw de stappen bepalen. Salesforce en ServiceNow stellen dat je die stappen beter kan vastleggen in een vaste workflow en die aanroepen. Je hebt niet altijd een LLM nodig.
Saueressig stelt dat als je een complexe taak hebt waarbij meerdere stappen nodig zijn, je Joule prima kan gebruiken, want Joule heeft via de Knowledge Graph en de metadata de context om die stappen correct en accuraat uit te voeren. Joule kan intern wel een deterministische workflow aanroepen. Het probleem blijft echter dat er een inferentie stap voor zit, waardoor die zekerheid nooit 100 procent is.
Saueressig zei daarover dat je voor duidelijke deterministische, rule-based processen geen agent moet gebruiken, maar gewone automatisering via de publieke APIs. Die zijn open, die kan je aanroepen. Het probleem is alleen dat als het betwisten van die frauduleuze creditcard afschrijving via een externe agent tot stand is gekomen, die van SAP geen API mag aanroepen.
SAP zal hier nog veel vragen over krijgen van organisaties die externe AI-platformen willen gebruiken én strenge compliance-eisen hebben.
SAP’s argument en waarom het niet overtuigt
SAP’s argument is dat Joule’s business context zo waardevol is dat de gedwongen weg via Joule gerechtvaardigd is. De Knowledge Graph levert correlaties tussen finance, supply chain, HR en inkoop die nergens anders bestaan. Dat rechtvaardigt een intelligente orchestratie-laag.
Dat argument heeft een kern van waarheid. De breedte van SAP’s bedrijfsdata is uniek. Voor complexe, domeinoverschrijdende processen kan Joule als intelligente orchestrator oprecht waardevol zijn.
Toch zien we twee problemen met dat argument.
Ten eerste: als Joule werkelijk beter is, hoef je het niet juridisch af te dwingen en de oude route duurder te maken. Klanten kiezen dan vanzelf voor Joule. Het feit dat SAP het dwingend maakt via API-beleid suggereert dat SAP zelf niet overtuigd is dat klanten snel voor Joule gaan kiezen.
Ten tweede: Salesforce en ServiceNow blokkeren directe API-toegang niet, ondanks dat ook zij een Knowledge Graph hebben en intelligentie in hun platform hebben gebouwd. Ze vertrouwen erop dat die intelligentielaag waardevol genoeg is om klanten aan te trekken zonder juridische dwang. Zij bieden beide de API’s om direct vastgestelde acties uit te voeren op het platform en de mogelijkheid om met hun agents te communiceren, waarbij ze de informatie teruggeven vanuit hun knowledge graphs zonder dat daar een extra LLM-laag voor nodig is. SAP had ook gewoon een governance-laag op zijn API’s kunnen zetten en de rate-limits kunnen aanscherpen, net zoals de rest van de industrie.
De cijfers bevestigen het
Uit de DSAG Investment Survey 2026 blijkt dat slechts 3 procent van alle SAP-klanten Joule in productie gebruikt. Tegelijkertijd gebruikt 77 procent van de AI-actieve SAP-enterprises wel Microsoft Copilot. SAP heeft hiermee de directe weg afgesneden voor de AI-tools die 97 procent van de klanten al gebruikt. Dat lijkt niet op een strategie om klanten naar Joule te trekken, maar een strategie om ze nergens anders heen te laten gaan.
Saueressig stelt dat dit geen kwalitatief onderzoek is, want minder dan 100 organisaties hebben meegedaan aan deze survey en de cijfers komen niet overeen met de werkelijkheid. Hij stelt dat 68 procent van de Fortune 500-klanten gebruikmaken van SAP AI, maar dit is niet specifiek Joule. SAP biedt al tien jaar AI-features in zijn software. Hoe hoog het werkelijke Joule-adoptiegetal ligt is dan ook onduidelijk. Een fonds van 100 miljoen euro dat SAP beschikbaar heeft gesteld voor SAP-partners om klanten te helpen met de adoptie en implementatie van Joule geeft een ander signaal.
Dit patroon is niet nieuw
In 2017 ontdekten grote SAP-klanten tot hun schrik dat het koppelen van externe systemen aan SAP zonder de juiste licenties hen miljoenen kon kosten. Een Britse rechter oordeelde dat Diageo ruim 54 miljoen Britse pond verschuldigd was aan SAP omdat Salesforce-gebruikers indirect SAP-data hadden benaderd. SAP achtervolgde ook AB InBev voor naar verluidt 600 miljoen dollar, dat geschil werd uiteindelijk geschikt. SAP introduceerde in 2018 het Digital Access-model als compromis. Nu, in 2026, lijkt hetzelfde patroon zich opnieuw af te spelen, maar dan met AI-agents in plaats van CRM-gebruikers.
SAP-partners: strategie niet houdbaar
Die analyse wordt gedeeld door SAP-partners die bij Sapphire aanwezig waren. Zij gaven aan verrast te zijn door de API-blokkade. Ze gebruikten termen als ‘lock-in’, ‘walled garden’ en ‘firewall’, want naar buiten connecteren mag wel, maar naar binnen via je eigen tools is beperkt. Op termijn verwachten deze partners dat deze strategie niet houdbaar is, omdat de industrie juist in de tegenovergestelde richting beweegt. Ze willen niet met naam geciteerd worden, want ze zijn op een SAP-conferentie.
Conclusie
Wat ons betreft is de Autonomous Enterprise helemaal geen slecht idee, maar de onderliggende gedwongen migratie naar SAP’s AI-stack is dat wel. Dit is geen volledig open platform, zoals de rest van de industrie, maar een meer gesloten platform. De vraag is of organisaties bereid zijn alles via Joule te laten lopen, en of SAP bereid is de consequenties te dragen als ze dat niet zijn.