In part 1 of this series, we set the stage for how the Autonomous Enterprise reframes the work of change management. Classic transports and the changes they deliver now live in a world where intelligent agents are the downstream consumers. Change management didn’t shrink. It got more interesting.
What does the SAP Business AI platform imply for this evolving landscape? In part 2, I analyze the expanded change surface itself. It is no longer just the environment where intelligent agents operate; it represents a substantial expansion of the territory governance must cover.
Bundling BTP, Business Data Cloud, and Business AI under a single platform doesn’t just give organizations new capability. It extends the scope of governance, traceability, and change control well beyond the traditional ERP boundary; and likely far beyond where many SAP change management practices are operating today.
Why SAP agent governance starts with ERP change control
SAP has thought hard about agent governance, but the complete story of change must include the systems underneath.
Reading SAP’s announcement, one can see the effort given to governing agent activities. The core framework is architecturally sound on its own terms:
- The Knowledge Graph: Gives agents structured business context
- Joule Studio: Versions agent definitions
- NVIDIA’s OpenShell: Provides a “trusted secure runtime”
- Full action traceability: An audit trail of every agent action
The next step is bringing the same level of governance to the everyday ERP systems that the agent depends on to do work. Agents do not invent capability; they invoke it. A Joule Assistant placing orders still lives in VA01 or uses custom Z-programs someone wrote back in 2014 (or 2004!).
The AI agent’s competence is bound to the capabilities of the core system beneath. And that system is changing all the time. That is, after all, why we have transport management and a release calendar in the first place.
So, the question is this: when a Basis team ships a transport on Friday that modifies the behavior of a Z transaction, what happens on Monday when the agent that depends on that transaction tries to do its job? Now that the human employees who used to perform these activities have been elevated to higher-level work, who is minding production?
The expanding SAP change surface: 5 new change vectors
The SAP Business AI Platform expands the scope of change in ways that are not always obvious. Several of the new change vectors land outside what most teams think of as “SAP change management” today. Here is where we see the surface expanding.
- The Knowledge Graph
A cost center reorganization, a new company code – the Knowledge Graph reflects all of it. Agents read from the Knowledge Graph to know what to do. A configuration change previously treated as “low impact, just a customizing entry” now alters agent behavior in ways that may not surface until runtime. Customizing has always had impact; what’s new is that the impact area is larger, and the consequences are sometimes only visible after the fact.
2. The data layer
Business Data Cloud collapses what used to be many separate data conversations into a single platform conversation. That is good news for getting data to agents. It is more complicated news for governance. Data product definitions, sharing agreements, refresh schedules, lineage assertions – these are all changes that affect agent behavior, and most of them sit outside the traditional ABAP transport boundary. If your change practice ends at the SAP system boundary, you may have a gap.
3. SAP BTP Development
ABAP Cloud, side-by-side extensions, Integration Suite, custom tools registered into Joule Studio – none of this is “in S/4HANA” in the classical sense, but all of it sits on the same change-criticality scale. A misbehaving BTP extension affects an agent just as surely as a broken Z-program does. The Business AI Platform pushes more business logic into this layer, too.
Truly modernizing your transport management strategy requires a single solution across classic ABAP and cTMS, with full orchestration and dependency management for loosely coupled components. Without this, you risk an inevitable return to living in Excel and relying on manual oversight.
4. Dynamic agent definitions
Agent definitions remain changes. We touched on this in part 1, but it bears restating in platform context: prompts, guardrails, tool permissions and grounding configurations versioned inside Joule Studio are audit-worthy changes in every sense. SAP gives you native versioning, but it’s up to SAP managers to ensure change is managed using the same controls and discipline as the rest of the SAP estate.
5. Autonomous migration tooling
Migration tooling is now a change-making agent itself. SAP announced agent-led transformation tooling for automating system analysis, code remediation, configuration, and testing. That is autonomous code change. The migration agent is itself a change-making entity, operating across landscape boundaries, and it needs the same governance the rest of the system gets.
The hybrid reality: Managing change across Cloud, AI, and on-premises
Hybrid is still the status quo, only more so. SAP was explicit at Sapphire that ECC and S/4HANA on-premises customers get select AI scenarios if they commit to transitioning to Cloud ERP. What is also clear is that most large customers are going to run hybrid for years.
Agentic executions living on Cloud ERP will reach across systems still governed by traditional Basis discipline. Change management practices that only see one side of that fence are incomplete
AI governance starts with agents but doesn't end there
Agent governance is getting most of the attention right now, and understandably so – agents are the new and unfamiliar piece of the picture. But governing the agents themselves is only one of the change vectors that needs attention in an Autonomous Enterprise.
If you take only one thing from this post, let it be this: the agents inherit the discipline (or absence of it) applied to everything they touch. Governing the prompt and not governing the underlying systems is half the job. Governing the Joule Studio configuration and not governing the BTP integration that feeds it is half the job. Governing the agent’s identity and not governing the master data it acts on is half the job.
The SAP Business AI Platform extended the surface. The change management practice has to extend with it.
The scope of change management just got bigger
The SAP Business AI Platform is the architectural piece that makes the Autonomous Enterprise real. What it also does is extend the scope of change management beyond where many practices are operating today. That is not a reason to abandon what works – the transport, the approval gate, the regression test, the audit log all become more important, not less. What changes is the surface they apply to.
SAP CEO Christian Klein said it from the stage: “Moving to the Autonomous Enterprise requires serious change management.” Part of taking that seriously is recognizing the platform expansion is itself a change management expansion. The agents are not the only thing being governed in this new world. They might not even be the most important.
Next, in part 3, we look at practical best practices, why a durable, clean core still matters as much as ever, and why ensuring success in the clouds begins on the ground.