Welcome to Tech Zone TV. Welcome to Tech Zone TV. We're at SAP Sapphire in Orlando and we're talking to Thomas Saueressig. He's chief customer officer and member of the executive board of SAP. Um today you launched the autonomous enterprise, a new word. Absolutely. As you just mentioned to me in the before talks. Um and you call yourself an open platform, which um to me raised a couple questions because I've seen some announcements and some choices you made in the architecture. And I wonder how open it really is because one of the things you did last month for example, you released a new API policy in which you said external AI agents are not allowed to call our APIs anymore.
That's not entirely correct, but we can we can lift the the reason what we did and why we did it. Okay. But I think first and foremost what you mentioned, I think that's the exciting piece. What we did today, we basically showed the world the next generation of enterprise software. Like how the autonomous suite with the business AI platform is driving real AI value in the enterprise. And here for sure, we need to talk about business context. The combination of business data, business processes, and the governance around it because even in a world where thousands of agents are running around, you still need to be SOX compliant. And we as a company with 54 years of experience in the various industries know exactly how in this business critical context what is required to deliver these AI scenarios. That's what you see what we showed today. And what you've seen today is the openness. And now I come to the question on the API policy because I think that's where where where you're interested how this fits together.
SAP is in my perspective one of the most open company on this planet. If we start from the infrastructure, we give choice to our customers. If they want to go to Microsoft Azure, GCP, AWS, customer choice. If you think about our data partnerships with Databricks which we which we launched, Databricks, Snowflake, um Google BigQuery and the likes. We are open on the data platform side. If you think about the LLMs, all of the LLMs on a global scale are available as part of our business AI platform. So, we give full choice again on the LLMs. So, what you see is a huge excitement on the ecosystem. We we are pride ourselves with more than 25,000 partners, which are part of our community, which are coming together. Now, specifically to the AI policy, because it is an open platform, because we run in the cloud, for us it's important that we are very clear with the governance around it.
Think about the SaaS and PaaS environment of SAP. These are also shared environments. So, other customers in the multi-tenant environment share the same capacity and and and cloud capacity, as you know. So, for sure in that case we need to be clear that if the one customer is using thousands of APIs, that they don't hurt the reliability or performance or quality aspects, because otherwise they could hurt another customer. And we feel the responsibility for all of our customers to keep that in in in in sync. That's the reason why we followed the market best practice and industry standard with all SaaS players, that we for sure govern the access to the respective public APIs. In the SaaS world, I think it's a no-brainer. For us specifically, and that's the nuance where we need to be more differentiated, and if you allow give me 1 minute, is the private cloud scenario. Because in the private cloud scenario, basically our system also here is open. All of our partners and customers have access to the full SAP source code as part of the BTP system, and they do the respective extensions.
What we said with the API policy, for sure absolutely use our public APIs. That's exactly what they are intended for, to use public APIs. For sure, if you use um custom code, custom extension as part of the code in in technical terms in the BTP world is called Z code, for sure, if it's a custom extension, you also can use this API for sure as well. Now, what we want to be very prescriptive, that if you use in SAP internal only APIs, that this is certainly something where we need to be careful because that's something where we also have continuous upgrades and we don't want to break any of these things. And that's the reason why we guide our customers using public APIs which are available using for sure they can continue to use their own custom extensions and for sure our partners do the right level of integration according to our architecture. And this is important to guarantee the quality around it and that's the reason why we are absolutely open but also very prescriptive how the right architecture is to extend our solutions and for sure also then see how the access from from from from agents and the likes are going. Here specific to agents because you said agent integration. Therefore sure we use A2A as the standard protocol in the industry to do this.
>> we go there because you say your APIs are open but there was this policy document that said they weren't. So and today even Philip said in the Q&A APIs are the old technology, we're moving towards MCP and A2A. Yeah. >> So so are they open or are they closed? Because now it gets a bit blurry.
>> No, they are open but we need to differentiate. Is it an AI use case where for sure the the leading standard industry protocols are MCP and A2A where we are partnering and A2A is an open protocol to get agent to agent integration.
>> Okay, so if you take an example, Gemini AI agent cannot talk to your APIs. That's not allowed.
>> They do the A2A integration with our business AI platform to then access the full business context and get exactly the content which is required to fulfill the task. But still you need APIs because you still have not only AI workloads which address and extend systems and there you have public APIs which you use in the application context.
Yeah, but you're forcing your partners that want to use external AI agents to go to A2A and talk to Joule because there's no there's no different way to talk to SAP anymore. Because A2A is the standard industry protocol for agent to agent for interoperability between the systems exactly. Yeah, okay, but if we move then to what's industry standard now, if we look at what Salesforce launched and ServiceNow launched, they went headless. Salesforce came with headless 360, ServiceNow came with action fabric. Both give external agents direct deterministic headless access with full business context context included. SAP doesn't have a deterministic headless access point with full business context. SAP has made the architectural choice to require external agents to go to Joule every time. And that's non-deterministic. And there And there two aspects to that.
First of all, Salesforce has an API policy, which is interesting in that sense as well. So, they absolutely throttle and work against the APIs in that sense. And we absolutely took a very uh very um clear approach to say in this world which we see on on on rolling, for sure it's important to have an orchestration and governance layers to protect the security and reliability for all of our customers. And that's something where also what was mentioned today on stage, we also go to the world where we talk about no apps and appless experiences, especially with Joule, but I think this gives us for sure the right architecture also for the future to scale it in a different means. So, I think that's something where where we are very confident for our customers which run business critical systems, this is important. We could argue if an opportunity in pipeline management system is business critical in the moment. I can tell you if a company like Nvidia, which is a Rise with SAP customer, um and you saw Jens on stage, but again, full ERP, full supply chain, everything running with SAP. If that would stand for day, that would be different impact than a pipeline management system would be down. And that's the reason why we see this obligation to have the right governance, security, compliance around our systems, which for sure some market participants perhaps have a different approach on on quality expectations, but our systems also scale to a different level. Let's take the Nvidia example as a good one. Nvidia Jensen said on GTC that they that he thinks that that they are doing 1 trillion in revenue next year. That's a massive scale which they do with the ERP system of SAP. And for sure this is a scale which we enable in our systems where for sure we need to ensure that we have the right guardrails around the quality aspects to facilitate such a growth. And that's something which is also uniquely differentiating us that we have infinitive growth opportunities and scaling opportunities with our software systems.
Yeah, but but giving governance and compliance and the things you saw at scale doesn't mean you have to close your APIs for external AI agents because now you're missing out on a non now you're you're pushing towards Joule and you're not offering a non you're not offering a deterministic reasoning layer. It's all it's all non-deterministic which means if you want to run a very complex process the AI can take the wrong turn.
Why should an AI take a wrong turn? Because again coming back to what we saw today Mhm. with SAP in the business AI platform you get the full SAP knowledge graph how the entire enterprise runs all business entities how they are connected. Mhm. We also combine it with the company memory which we have how decisions are made which means for sure actually this is exactly the foundation that AI agents do the right reasoning because if an agent directly access just an a simple API I mean then the entire context is actually missing and we give that with the context with the with the knowledge graph to actually these systems that you really can take that. If you do a complex supply chain question
>> Yeah, I got a I got an example I was last week. Let me help you. Um let's say there's a credit card fraud dispute process which is a complicated process. Need to change different financial systems, something SAP is good at. Um Customers don't want AI to do that pro- uh non-deterministic. They want it not to hallucinate and it wants to take certain steps. 100%. Yeah. So, they want a government deterministic business process that runs the same way every time. Yes, for sure. >> Yes. If you call Joule, it's non-deterministic, so it can go either way.
No, Joule is the advantage and I know to to get clarity to the Joule is the access and that's the beauty of of our architecture. For sure, Joule is full access to the respective business systems. I mean, that's Joule and SAP, that's for sure once. That's the advantage we bring together public LLMs, we bring together our knowledge graph who knows every business entity which comes together. With that, we directly have access to the business system in itself. We have also this BDC, also the the possibility to do joins with non-SAP system data as well. And bring our capabilities together what we have with the with the company memory. So, by definition, we basically can access the specific right entity in the system and with that we have two data points and absolutely clear outcome. That's exactly the promise to have a really reliable, responsible AI opportunity in place what we do and that differentiates us, quite frankly, because we have this full knowledge graph across the enterprise. So, we know exactly if you have one question for this financial system change what you meant. How is that linked to another object, to another object, to another object to find the right outcome? And if you would have otherwise, you would need to Also, that's the interesting thing. If you build agents which are prospectively going to one specific um thing, why use an agent for that? Well, you shouldn't use an agent for that. That's what I'm saying. If you want
>> you use the usual automation, then again, coming back to my initial point with public available APIs where every application extension can use directly the APIs. Yeah, but an external AI agent can call those because you didn't allow them. But again, for this scenario again, you don't need agent.
You have a usual automation and that's actually what we also see with our customers because agent is not the answer for deterministic automation because the cost for for agentic AIs for sure higher with in future. That's reason why many of the customers you talk to here will tell you if it's a clear deterministic rule-based approach to to solve a problem, then you do that. And exactly for that reason we have open public APIs where you build an extension where you build an application accessing these APIs because they are open. And this is exactly where we need to be clear on the use case. So we have open public APIs for all of these deterministic things, you don't need the an agent for that. If you want to have a agent for that, then you have a different use case.
