For three parts of this series, we’ve been talking about the AI agent as the object of change management: the new downstream consumer of every transport you ship, the new reasons a low-impact customizing entry might not be low-impact at all, and the new stakeholder that doesn’t ask questions before acting on whatever state it finds.
That framing is accurate. But there’s more to the story.
The more consequential shift that most SAP organizations haven’t fully confronted yet is the agent as actor in the change process itself.
In part four, I reveal how to prepare for SAP’s Business AI Platform.
Key takeaways
- SAP agents are shifting from assisting with change to making change themselves, often unreviewed
- Agent logs and ERP records don’t talk to each other –that’s where audit risk lives
- Impact analysis now needs to cover agent execution paths, not just human ones
- Hybrid SAP landscapes are a permanent governance challenge, not a temporary gap
- The organizations preparing now will be positioned for the Autonomous Enterprise
Does SAP’s autonomous migration tooling make changes on its own?
SAP’s Autonomous Migration tooling, announced at Sapphire 2026, is the clearest current example. It is expanding to perform system analysis, code remediation, configuration work, and test generation autonomously. That is not a tool that assists with change; that is a tool that makes change, operating across landscape boundaries, and at a pace and scale no human change manager is reviewing in real time.
The Joule Assistants themselves are not far behind. Today, they orchestrate processes within defined guardrails. Tomorrow, agents that propose, route, and in some contexts execute configuration and workflow changes are in SAP’s roadmap.
The governance question that follows is one no existing change management framework was originally designed to answer: who approves an agent’s change?
When a Basis administrator ships a transport at 11pm Friday, there is a person, a ticket, an approval record, and an audit trail. When an autonomous migration agent remediates a Z-program at 2am, or a Joule Assistant re-routes a procurement workflow based on updated master data, the same question applies. The audit trail doesn’t care whether the initiating entity has a user ID or a service account. The auditor certainly doesn’t.
Does SAP’s AI governance cover ERP change records too?
SAP has built thoughtful governance into the Business AI Platform. Joule Studio versions agent definitions. The action traceability layer records what agents do. NVIDIA’s OpenShell provides a trusted runtime. These are the right investments.
What they don’t do is bridge the gap between what the agent did and why the system it was operating on permitted it to do that. The agent’s action log tells you the agent placed a purchase order. The ERP change record tells you what the pricing configuration looked like when it did. Both records are necessary. Neither record refers to the other by default.
The gap between agent-side governance and ERP-side governance is where liability lives. An agent that only performs work within the framework is merely a slightly smarter RPA. None of us are making these investments for a fragile screen-scraping robot to continue producing script maintenance chores. We want something better, but that better requires much more robust and insightful management.
Internal audit teams working under SOX, GxP, or GDPR regimes are going to ask for a defensible record linking agent action to system state to authorized change. “The agent did it” is not an acceptable response. Neither is “SE10 seems OK and we have the Joule audit trail” if those logs don’t speak to each other and correlate to defined agent authority for change.
Building the traceability across change → object → agent → process → business outcome requires more than native tooling on either side. It requires an integration point across the entire change lifecycle.
How does AI change SAP impact analysis?
The impact analysis problem also changes in an agentic environment. Today, impact analysis asks: given this change, which processes and users are affected? That question has always been under-answered in practice as static code technical analysis is imperfect at best and wildly incomplete at worst, but the target was at least well-defined.
When agents are in the picture, the target moves. A transport modifying a BAPI doesn’t just affect the human users and automated jobs that call it today. It affects every agent that might invoke it, every process those agents orchestrate, and every downstream system those processes touch. And because agents act at scale and outside business hours, the blast radius of a misconfiguration isn’t limited to the next business day’s UAT cycle.
The practical implication is that impact analysis needs to extend to the agent layer — not just what human processes does this change affect, but which agent execution paths does it intersect, what agent paths could it intersect, and how? That capability doesn’t exist as a standard feature in most SAP landscapes today. Building toward it is part of what it means to prepare for the Business AI Platform.
Do hybrid environments make agent governance harder?
The other variable that doesn’t go away is hybrid. SAP has been clear that full AI capability arrives with Cloud ERP. SAP has also accepted and acknowledged many large organizations will run hybrid landscapes for years. Cloud ERP customers will be running AI-assisted procurement workflows on S/4HANA Cloud while their connected legacy systems still live in on-premises ECC with a Basis team managing transports the traditional way.
In that environment, the change surface doesn’t divide cleanly between “AI side” and “classic side.” An agent executing on Cloud ERP will reach into a connected on-premises system for master data, pricing configuration, or legacy integration. Enterprise context means Joule is smart enough to know where to find needed data where it lives today, and probably through a BTP integration suite connector. A change made to that on-premises system — using the same transport process it’s always used — now has agent-facing consequences the Basis team has no way to see.
The change management practice governing only half the landscape is not prepared for this. And the organizations taking on the foundational work seriously before the agents arrive are the ones with the most defensible position when the AI layer lands on top.
What should SAP teams do now to prepare for agentic change management?
“Preparing for the SAP Business AI Platform” is not a single project. It is a continuous discipline that begins before any AI capability is deployed and continues through every agent onboarding, every landscape expansion, and every transport cycle that follows.
In practice, it means a few things:
Treat every change as potentially agent-facing by default. On the day the first Joule Assistant goes live in production, every impact analysis has a new consideration. The organizations that have already built that discipline — flagging agent-facing change vectors as part of standard release management — are ahead of the ones that plan to add it later.
Bring the agent layer inside the change control envelope. Agent definitions, BTP artifacts, data product configurations, and Joule Studio versions are changes in the same sense that ABAP transports are changes. The approval workflow, the regression testing, and the audit trail need to apply to the agent layer too, even when existing tooling doesn’t make it easy today.
Build for the audit conversation now. The audit teams that will review AI-era change records are already working in your organization. What they’ll ask for isn’t fundamentally different from what a SOX audit asks for today: a defensible, traceable record of who authorized what change, when, to what, and with what effect. The difference is that “who” now includes automated entities with service accounts and execution authority. The record needs to capture that.
Make hybrid first-class, not an edge case. The change practice that assumes a pure-cloud landscape is not the change practice the next five years require. The hybrid boundary is not a gap to close eventually — it is an active change surface to govern now.
Change governance is the foundation of the Autonomous Enterprise
Christian Klein said at Sapphire 2026: “Moving to the Autonomous Enterprise requires serious change management.”
We’ve spent four posts unpacking what that means in practice. The change surface has expanded. The agents are now downstream consumers of every change made. In some contexts, they are already change actors themselves, and the governance frameworks applied to human-initiated change apply to them too. The foundation beneath the agents including clean core, migration discipline, and structured release management now matter more because the agents will amplify whatever they find there.
None of this makes the Autonomous Enterprise less compelling. The direction is right. The capabilities are real. What it means is that the organizations best positioned to capture the value SAP is promising are the ones that treat change governance as a strategic capability, not an operational overhead.
Rev-Trac was built for exactly that: end-to-end visibility and control across the SAP change lifecycle, from development through production, across ABAP, BTP, and hybrid landscapes. As the change surface expands and the actors within it multiply, the capability to track, trace, and authorize change across the full scope becomes the foundation on which a trustworthy Autonomous Enterprise is built.
That foundation doesn’t build itself. But the organizations that build it now will be the ones the agents inherit from – and that’s exactly the right inheritance to leave.that build it now will be the ones the agents inherit from – and that’s exactly the right inheritance to leave.
