An Approve button is unsafe when the reviewer can see only an AI recommendation and a confidence score. Before an SAP DRC change is authorized, the interface must expose the system evidence, exact action, affected scope, verification test and recovery path.
The model may help assemble the proposal, but the approval must remain tied to verifiable SAP facts and a customer-controlled change process. In this article, you will learn what an SAP DRC AI agent must show, which missing facts must block approval and how to prevent an approved proposal from expanding during execution.
Show the observed problem before the proposed solution
The approval view should begin with the requirement and failure that triggered the proposal. The reviewer must be able to open the original evidence, not only read the model’s summary.
- Target SID and client
- Country process and document direction
- Company code or other approved business scope
- Source document and electronic-document identifier
- Exact error, application log or failed test result
- Installed product, release and relevant component level
- Locally observed Note, object or configuration state
If the evidence is unavailable, stale or collected from another system, the item is not ready for approval. The agent should mark the missing fact explicitly and request a new evidence run.
Explain why the proposed change applies
A plausible SAP Note, configuration value or mapping change is not enough. The agent must connect the proposal to the exact product, release, process and observed failure.
- Current SAP instruction or approved design basis
- Release and component applicability
- Every prerequisite and manual activity
- Affected repository, configuration or integration objects
- Customer modifications in the affected path
- Why alternatives were rejected or deferred
- Known uncertainty that remains after the evidence review
The agent must distinguish “proved” from “inferred.” An inference can guide investigation, but it cannot silently become the basis for a production change.
Display the exact before and after state
The reviewer should see the concrete change, not a label such as “apply remediation.” For configuration, show the object, key, current value and proposed value. For a Note, show the local status, prerequisites and affected objects. For a mapping, show the approved version and the fields or rules that change.
Mask credentials, private keys, tokens and unnecessary business data. Evidence should be sufficient for the decision without exposing secrets or broad invoice payloads.
Bind approval to one immutable action package
When approval is recorded, freeze the action package. It should contain the target, scope, before state, proposed change, prerequisites, test case, recovery instruction and evidence versions.
- Target system and client
- Change type and exact object
- Approved company-code or process scope
- Before-state fingerprint
- Proposed payload or instruction hash
- Required transport or implementation route
- Verification test and expected result
- Recovery action and authorized owner
If the agent later changes the Note, value, object list, company-code scope or test, the previous approval is invalid. The new version must return to review with a clear difference summary.
Keep execution outside the model’s own authority
The agent can prepare a proposal and collect evidence. Execution should pass to a customer-controlled service or authorized SAP user that verifies the requested action against the approved package.
- Use an execution identity separate from the model service
- Check the target system and client again at execution time
- Reject any payload that differs from the approved hash or values
- Stop when a prerequisite remains unresolved or an affected object has changed
- Attach the transport, implementation or configuration log to the same record
- Keep production release inside the customer’s change process
Approval authorizes only the frozen package. It is not permission for the agent to discover and execute additional corrective actions.
Define recovery for the specific change type
“Rollback available” is not an adequate recovery instruction. The method depends on what changes and on the customer’s supported procedures.
- Configuration: approved compensating change with the previous value and transport route
- Custom ABAP: prior repository version and corrective transport
- External mapping: redeployment of the last approved version
- SAP Note: deimplementation only when supported for that correction and after dependency review
- Master data: controlled restoration or correction with affected-population reassessment
The recovery action may itself change the system. It therefore needs an authorized owner, evidence and verification.
Verify from SAP and the business process
A second model opinion does not prove that execution succeeded. Re-read the changed object or configuration from SAP, confirm the transport or Note state and rerun the named business test.
- Approved action matches the execution log
- Post-change SAP state matches the intended value or object version
- Representative electronic document follows the expected lifecycle
- Payload or report output matches the approved test expectation
- Adjacent unaffected scenario still passes
- Reviewer records pass, fail or recovery decision
Failed verification must reopen the item. Preserve the failed result, invoke only the approved recovery path and return the finding to technical review. Do not allow the agent to improvise a second production change.
Use hard blockers, not confidence thresholds
A high confidence score cannot compensate for missing release evidence or an undefined recovery action. Configure the workflow so that approval is unavailable when a required control is missing.
- Original SAP evidence cannot be opened
- Target system or client is ambiguous
- Applicability to the installed release is unresolved
- Prerequisite or manual activity remains open
- Affected object has an unexplained modification
- Before and after state is not explicit
- Verification test or expected result is missing
- Recovery instruction has no authorized owner
- Execution package differs from the reviewed package
Approval rule: allow the reviewer to approve only a specific, evidenced and recoverable action package. Any change to its target, scope, objects or values requires a new review.
Governance reference: The NIST AI Risk Management Framework is a voluntary framework for managing AI risk and emphasizes defined roles, contextual risk assessment, documentation and oversight. The SAP DRC controls in this article are S4FN’s operational interpretation for customer-controlled change approval.