(Dr. Philipp Herzig, CTO, SAP SE)<\/p>\n
Around April 23, I knew something was up: I started getting deluged with pings about SAP’s API policy changes. I don’t know about you, but when I hear about changes to fine print in data access, my bells always go off.\u00a0<\/p>\n
A flurry of posts came out, including enough attention-seeking flotsam on LinkedIn to completely fog the windshield (many of the viral posts were from AI “influencers” outside the SAP community, but some thoughtful posts did spring up, which I called out at the time<\/a>).<\/p>\n Fast-forward to SAP Sapphire Orlando: by then, SAP had officially updated its SAP API Policy FAQ<\/a>, based on input from user group leadership, specifically DSAG and also ASUG, and possibly more.\u00a0<\/p>\n Immediately prior to SAP Sapphire, I heard from SAP offering an on-the-record interview with Philipp Herzig, CTO of SAP SE. I agreed; Herzig has been candid with me in past on-the-record discussions, including SAP’s AI cloud priorities.\u00a0<\/p>\n My interview with Herzig took place at the end of the final day of the show. Right before the Herzig interview, I taped a podcast with UKISUG Chair Conor Riordan<\/a>, where Riordan also addressed the topic. What follows is Herzig’s take on these issues in Orlando, as well as some quick thoughts on organizational memory, one of the more interesting enterprise AI initiatives I heard from the keynote stage this spring. Then I will give you my current views on APIs – and some user group reactions.<\/p>\n SAP’s API policy: Herzig on what customers need to know<\/p>\n So, Dr. Herzig, let’s cut to the chase: what do you really want customers to understand about SAP’s API policy? Herzig says one crucial issue is that bots of all kinds increase data traffic across APIs:\u00a0\u00a0<\/p>\n Our API policy, in a nutshell, is three things we are targeting. We have fair use limits on APIs, or rate limits for decades in SuccessFactors, in Ariba and so on. What we wanted to make sure is that we have consistency all across the portfolio, as we’re bringing all the platforms now together with the autonomous suite as well as, \u00a0of course, \u00a0the platform, because we haven’t had this in place in some of our application assets so far.\u00a0<\/p>\n Herzig spoke to the situation of existing customers:\u00a0<\/p>\n As long as it’s within fair use limits, everything is good, right? At the same time we acknowledge, of course, and appreciate existing contracts with customers. So we take workloads all across the customers, like for the SuccessFactors application, and we take the 99th percentile of that distribution to determine what that fair use limit would be. Of course, with existing customers, we would not block or take anything away, because we appreciate existing contracts.<\/p>\n Herzig says SAP is not trying to keep AI agents out:\u00a0<\/p>\n The second is people saying we keep the agents out. But the reality is: we’re not keeping the agents out. We are letting them in if it’s defined, via, for example, A2A. It makes no sense to block Cloud Code or Codex or Replit or whichever other coding system, for example, if they are part of the strategy, right?<\/p>\n Security is a major motivation here. Herzig calls out “bad agents”:<\/p>\n But on the other side, \u00a0there are not just good agents out there. There are a lot of bad agents out there as well, that try to sniff around and try to extract data from the system and so on. Nobody, not even the customer, has a clue what they’re doing there, right? They don’t identify themselves, so we have no clarity as to this.\u00a0<\/p>\n This is why, as part of our API gateways, that expose the APIs… Technically, we’re of course, partnering with vendors such as CloudFlare, for example, to harden it from a security perspective, which is good for the customer as much as a requirement, simply towards us, to actually do that.<\/p>\n Herzig’s third reason? The difference between SaaS and on-premise\/private cloud:<\/p>\n In the SaaS world, this is really now a private cloud\/on-premise issue with the API policy, not a SaaS issue at all… In every SaaS application, you have some private functions, some private methods as to how the application is managed, and maybe our data is being transferred between applications and so on. You would never know, right? Because you would never see the code. That’s obviously different in on-prem and private cloud, where you can see all the code, and there are, of course, interfaces in that code.<\/p>\n Where do we go from here – is the SAP API FAQ complete?\u00a0<\/p>\n This brings us to ODP-RFC, a means of SAP to SAP communication that SAP is specifically concerned about, in terms of turning it into a defacto API.\u00a0<\/p>\n There’s actually a private API, like ODP,-RFC, for example, was only done for SAP-to-SAP communication. And of course, some partners, some customers, started to use that [as an external API],, and it was never designed for that purpose. And the audit logs are full of, ‘Oh, SAP did this? SAP did that,’ right?’ There is no clear auditability. It was not designed for that purpose. So for me, just the people used it in an unintended way.\u00a0<\/p>\n Herzig sees a difference with customer builds: “all the C code, everything the clients build, the customers build, with respect to the customer; that all remains untouched.” [Author’s note: Herzig is primarily referring here, as I understand it, to the so-called “customer Z Namespace” – these customer-specific customizations are not impacted by these policy changes. SAP has issued a comprehensive FAQ on these ODP changes<\/a> as well. I also thought this piece by Theobald Software<\/a> was very useful as a primer, focusing on Note 3255746, and listing all the ways customers can access\/process SAP data that are not impacted by this June 2026 change – though customers should obviously validate this with SAP].<\/p>\n Now that user group input has been incorporated into the FAQ, does SAP stand by the API Policy FAQ<\/a> as it is now? Herzig:\u00a0<\/p>\n There are still some questions in the details, which we’re then working through with customers individually. But overall, I think so far, this FAQ has now been perceived very positively. In my mind also, if I look across social media or other channels, I think the sentiment also has changed towards ‘What SAP is doing is just industry standard,’ also, to a large extent, expected and actually a good thing overall.<\/p>\n Note: SAP has also published its go-to-architectural validation guidelines<\/a>, as well as its so-called AI Golden Path<\/a>, which SAP refers to as the “starting point for developing AI applications across the SAP ecosystem.”<\/p>\n A brief detour: why SAP’s organizational memory announcement is an announcement to watch<\/p>\n With all the API drama, I didn’t get the chance to delve into an underrated SAP keynote announcement: “organizational memory.” At the end of my Sapphire podcast with Greenbaum<\/a>, I explained why I see SAP’s organizational memory pursuits as a crucial part of the real-time organizational truth AI agents will need. Herzig calls this “tribal knowledge.” This topic may be under the radar for now, but it’s the sum of these structured\/unstructured data sources, along with so-called “decision traces,” that will inform the best AI agents.\u00a0<\/p>\n As Herzig explains it, SAP’s ambitions for the context layer extend beyond SAP BDC, bolstered by the Reltio acquisition<\/a>:<\/p>\n That’s, of course, great for the structured data, right? But there’s so much data that does not sit in any information system today, but it sits in people’s heads that you want to capture, right? Because otherwise, higher levels of agency and autonomy of these agents will never be created, because they need these decision traces.<\/p>\n The way SAP views organizational memory, it must be constantly updated and validated, to avoid fleeting misdirections. Herzig explains:<\/p>\n Steve Jobs always called this business folklore. Business is done because it was done so yesterday, and the day before. We want to capture that, and then study: is this actually how I want to run my company… Maybe you find improvements from there, because you identify people have taken decisions, and it’s this tribal folklore knowledge, because people have learned that from each other, which you actually would like to optimize. And you now, we have an opportunity to tap into this and yet, actually put the company towards a totally new kind of transformation from that.\u00a0<\/p>\n A promising topic I will return to, as I engage further with SAP (and other) vendors on this….<\/p>\n SAP’s API Policy – user group reactions from Orlando<\/p>\n Overall, SAP’s API Policy is heading into a well-documented direction, but fast-moving, emerging standards like MCP raise a slew of open questions. I’ll get to MCP, but first: how have user groups responded? Prior to SAP’s FAQ updates, ASUG issued an update for members; DSAG, the German Speaking User Group, shared a public response in German<\/a>.<\/p>\n Since DSAG’s initial position on API policy changes, they met with SAP; SAP’s updated FAQ includes some of their input. I had an off-the-record meeting with DSAG leadership in Orlando, hopefully with more on-the-record to follow. But for now, I can say this: \u00a0<\/p>\n After my meeting with DSAG leadership in Orlando, I get the impression that DSAG now finds the published FAQ API policy acceptable, though it will likely need further clarification from SAP for individual customer situations and granular questions. However DSAG will also clearly be monitoring this carefully, to make sure that diligence around API\/data security does not cross over into areas their members would not support, such as: monetizing basic access to their own data, or limitations on their ability to use third party vendors to further analyze or utilize their data beyond SAP.\u00a0<\/p>\n During my podcast with UKISUG’s Conor Riordan, <\/a>I asked him: How did this API policy change impact your members and your organization? Riordan responded:<\/p>\n We were in Waldorf last week. I think, based on the conversations there, the genuine feedback from SAP was, ‘Look, it was just genuinely poor communication’… My understanding is that there was one specific API that was available to transfer data from between two SAP systems. [Author’s note: Riordan is referring to ODP-RFC]. And maybe over the years, organizations were using that API to transfer data out of SAP into other systems.\u00a0<\/p>\n The primary concern is the resilience of that API and the security around the API is not resilient enough, and therefore companies potentially could be opening themselves up to new threats. And so what they’re recommending is the other APIs to do the same work. And so the conversation was around: you cannot use this API, but you can use other APIs, and somehow, in their communication, it came out different.<\/p>\n Riordan tied this to SAP CEO Christian Kiein’s comments prior to SAP Sapphire, and also in Orlando:<\/p>\n The other thing Christian [Klein] said last week, and I think he re-iterated this week was: SAP are never going to be charging customers again to get access to their own data. So, you know, they kind of reinforced the message that they won’t restrict customers using their own data in other places, like we had years ago with the [indirect] usage policies. And you know, they’re not going to go back there.\u00a0<\/p>\n Riordan added:\u00a0<\/p>\n It didn’t seem to come up as a major topic this week around around the hall, so hopefully they’ve put it to bed. But yeah, sometimes these things, just poor communication can cause a whirlwind.<\/p>\n So is Riordan satisfied with what he heard in Walldorf, and Orlando?<\/p>\n I think so, once we got the clarification… When you think about [SAP’s] intent – the intent, they said, is not to prevent customers using their data in other ways. So that wasn’t the intent. The other intent is to make sure that when they are exporting data, you’re doing it in a secure way, right? Which seemed reasonable.<\/p>\n My take – instant reactions, and looking ahead: MCP as a test case<\/p>\n I’ve been asked the burning question: has this issue been resolved? My short answer: we’ll know it’s resolved when SAP’s partners are posting enthusiastically about the agents they have built, both using SAP’s preferred architecture but also, in some cases, non-SAP platforms that are also validated (and appropriately monitored) by SAP.\u00a0<\/p>\n No partner, or customer for that matter, wants to cross a line that would cause audits and delays, but: they also want the choice on when and how to build AI with their data.\u00a0<\/p>\n In my SAP Sapphire podcast review with Josh Greenbaum<\/a>, I gave my own take, based on what I learned on the ground. Here is a near-verbatim excerpt:<\/p>\n \u00a0I think listeners are aware that I’ve been critical of all vendors that set up even what appears to be the appearance of data toll roads connected to AI, because I think customers should own their data. But I do think there’s a point in time where if you transform that data enough for customers, then you can start making the case that you’re providing a value.\u00a0<\/p>\n But I think customers should be really free to experiment, even if, as SAP sometimes has said this week, that doing API calls to external systems or MCP servers results in a less context-rich, less valuable form of AI. I think customers should still be free to find that out for themselves, and I think SAP should try to win this game in the market of presenting the best solutions, rather than the appearance of restrictions.\u00a0<\/p>\n But I also agree with SAP’s general point that the circumstances around how you make data calls into SAP systems has absolutely changed, because of agentic systems, bots and all of that, and new rules are going to be needed, including the security and controls that customers expect.\u00a0<\/p>\n However: I recognize that when you start making that argument too heavily, if you are able to control and audit everything, that also implies that you could monetize it. So there is a potential monetization bottleneck that makes people very distrustful…<\/p>\n The issue of data toll roads isn’t going away, and that’s for every vendor to look at and figure out. How do we protect from a security perspective, but avoid the temptation to over-monetize the wrong channel, because the right channel is monetizing innovation, not regulating data anyway?<\/p>\n Which brings me to MCP. Emerging standards like MCP, moving at speed, put the most pressure on SAP’s policies. For example, one partner told me about their MCP-based solution, already live on customer projects, that doesn’t use the MCP Gateway inside of SAP’s Integration Suite (This partner has built their MCP solution on SAP BTP Cloud Foundry, using SAP\u2019s security and authentication methods). While Herzig told me that this partner’s solution is valid and not impacted by these changes, it does illustrate the many questions partners have. And all partners, even this one, will likely want to make sure they are on the “Golden AI Path,” and not a problematic one.<\/p>\n SAP’s user groups, which do a good job of advocating for customer needs and influencing SAP’s data policies, may struggle to address areas involving standards like MCP and A2A, which quickly get into ice-cream-headache architectural complexities. (Example: a partner told me that they think SAP’s current MCP Gateway approach is likely to generate too many individual agentic tool calls, which in turn diminishes agentic accuracy and performance.).\u00a0<\/p>\n