What should an SAP change board review before approving an AI-drafted transport?
The agent drafts. The board decides. Here is the checklist that keeps those two roles honestly separate.
The short answer
An SAP change board should review an AI-drafted customizing transport exactly as it would one written by a consultant, plus a few checks specific to machine authorship. Confirm the business reason and the evidence behind it, read the transport contents object by object, check that the verified read-back matches the intended values, confirm it was applied in a development client only, and confirm the approval and audit record show who authorized the draft. Then decide on risk, not on novelty: a small, well-evidenced customizing change with a clean read-back deserves the same path through QA as any other. The agent proposes; your existing change process remains the control that decides whether anything moves toward production.
Why the board's job does not change
The instinct is to treat an AI-drafted transport as a new category that needs a new committee. It does not. A customizing transport is the same artifact whether a consultant or an agent produced it, and the Change and Transport System does not care who typed the settings. What changes is the volume and speed at which drafts can arrive, which makes a disciplined, repeatable review more important, not less.
Think of it like a junior analyst who can draft a hundred journal entries an hour. The controller does not stop reviewing journals; she gets a better-organized pile and a tighter checklist. The control is the review, not the author.
Which questions should the board ask first?
Start with intent before contents. A transport that is technically clean but solves the wrong problem is still a bad change.
- What business decision or process finding triggered this change, and where is the evidence? A draft should trace to something observable in the source system, not to a general recommendation.
- Which configuration objects does the transport touch, and are all of them expected? Unexpected objects in a transport are the single most useful warning sign.
- Is this change a retire, re-implement, or configure-to-standard decision, and does it match the fit-to-standard disposition the business already agreed?
What evidence should come attached to the draft?
A reviewable draft carries its own proof. The board should not have to reconstruct what happened from logs after the fact.
Look for a verified read-back, meaning the agent re-read the changed rows after applying the change and compared each field to the intended value. Look for confirmation that the change was applied in a development client only. Look for an approval record showing that a named human authorized the draft, using a single-use, time-limited authorization the agent could not issue to itself. And look for an audit entry that ties the approval, the operation, and the result together.
How should the board decide, and what stays out of scope?
Decide on risk. Low-risk customizing changes with clean evidence and a clean read-back can move through QA on the normal cadence. Anything touching pricing, credit, tax, or financial posting behavior deserves the same extra scrutiny it would get from any author, including regression testing in the quality system before release.
Be equally clear about boundaries. In our design the agent drafts a governed customizing transport; the customer's change board decides whether it lands; development systems only; it never touches production on its own. Our functional-testing agent, which would validate the reconfigured process end to end, is in build and design preview and is not shipped, so QA testing remains your team's responsibility today. An agent's draft is an input to your process, never a shortcut around it.
How do you keep the review from becoming a rubber stamp?
The failure mode of any approval gate is fatigue. If a board approves forty clean drafts in a row, the forty-first gets a glance. Counter it structurally: sample-check read-backs independently, track the rejection rate and investigate if it falls to zero, and rotate reviewers so the segregation of duties is real in practice and not only on the org chart.
SAP's own direction points the same way. SAP describes agent-led transformation with a claimed reduction of more than 35% in migration effort (SAP News, Sapphire 2026). That is SAP's figure, not ours, and any such gain is only worth keeping if the governance around it holds.
Frequently asked
Does an AI-drafted transport need a different approval process than a consultant's?
No. It should flow through the same Change and Transport System, QA gate, and change advisory process. What you add is a check for machine-specific evidence: a verified read-back, a development-only application, and an approval record showing a human authorized the draft.
What is the biggest red flag in an AI-drafted transport?
Unexpected objects. If the transport contains configuration the stated business reason does not explain, reject it or send it back for explanation. The same rule applies to human-authored transports, but machine-generated drafts make it easier to produce large bundles quickly.
Can the agent release a transport to production on its own?
No. The agent drafts a transport in a development client. Whether it is released onward is decided by your change board and your existing process, and the agent never touches production on its own.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading