Before an AI agent drafts a single configuration, data mapping, or test on your program, put four controls in the contract. Require a named human approver for every agent-generated artifact. Require an audit log that records the artifact, the approver, and the date, and that survives into the first weeks after go-live. Limit the data the agent can read. And transfer ownership of the agent's output, its trained model instance, and its prompts to you at go-live. The reason is narrow. Your auditors will ask who approved a configuration an agent wrote, and under SOX a configuration no one can trace to a named approver is a control gap. Oracle's own implementation agents already route designs for human review and approval. Require the same discipline on any platform.
This article is about the controls, not the savings. For the question of whether AI actually lowers the implementation bill and how to hold an SI to it, see our review of what AI changes in an ERP program. Here the subject is governance: what a program needs when agents draft configuration, map data, or design tests.
Four controls belong in the contract before agents touch configuration
The controls below are not a governance program in the abstract. Each one answers a specific question an auditor, a regulator, or your own successor will ask after go-live, and each has a concrete thing to write into the statement of work. Agent output is a draft until a person owns it, and the record of that ownership is the control.
| Control | Why it matters | What to require |
|---|---|---|
| Named human approver for every agent-generated artifact | Agent output is a draft, not a decision. A configuration with no named owner cannot be defended to an auditor, and a mapping no one signed cannot be traced when a balance is wrong. | A named individual, on your side as well as the SI's, approves every agent-drafted configuration, mapping, and test before it is built or run. The name sits in the record, not a team mailbox. |
| Audit log of the artifact, the approver, and the date | SOX and most financial-controls regimes require evidence of who changed what and when. An agent that drafts quietly leaves none. | A log naming every agent-generated artifact, the person who approved it, and the date, in a form your team holds, retained through the first weeks after go-live and into the first close. |
| Limit on agent access to master and transactional data | An agent prompted or trained on live data can carry it into a model instance the SI keeps. A mapping agent needs structure, not the records. | Agents read the least data the task needs: schema and samples for mapping, masked or synthetic data for testing. Access to full master and transactional data is granted set by set and logged. |
| Ownership of output, model instance, and prompts transfers to you | Vendors and SIs build a trained model instance on your data and methods. Test scripts, mapping rules, and prompts built on your program can otherwise stay with the SI. | All agent output, the trained model instance, and the prompts transfer to you at go-live, in a form your team can rerun without the SI. |
Agent output is a draft until a named person approves it
The vendors building these agents agree on this point, which makes it easy to enforce. Oracle's AI Success Navigator, announced October 26, 2026, sends draft designs "for review and approval," and Oracle's release describes expert reviewers who examine the configuration, request changes, and approve it. Sage and PwC, working on Sage Intacct rollouts, told ERP Today in April 2026 that consultants validate every AI proposal. No vendor is claiming an agent configures without a person in the loop.
The weak version of this control is a sentence in the proposal saying agents "operate within our quality process." That is the SI's process, not yours, and it names no one. The strong version names an approver on each side and makes the approval a gate the artifact cannot pass without.
The gate matters most on the artifacts that carry financial logic. A chart of accounts mapping, a tax configuration, a posting rule, or an approval-workflow design is a control in the finished system. Gartner expects more than 70% of recently implemented ERP initiatives to fall short of their original business case by 2027, and configuration drafted faster than anyone can check it is a direct route into that number. The approver is not a formality. The approver is the person who has to answer for the design in two years.
The audit log has to survive into the first close after go-live
An approval that is not recorded is the same as no approval once the people move on. The control is a log, held by you, that names three things for every agent-generated artifact: what the artifact is, who approved it, and when. It reads like a change register, because that is what it is.
Retention is the part programs get wrong. The log cannot be a working file the SI closes at go-live. It has to survive into the first weeks after go-live and through the first period close, because that is when a wrong posting rule or a bad mapping first shows up in a real number. An auditor reviewing the first quarterly close will ask how a given configuration got there. The answer is a log entry with a name and a date, or it is a finding.
Hold the log on your side, in your systems, from the first agent artifact. An SI's internal tooling is new, and if the agents underperform the SI has an incentive to control the record of what they produced. A log you own and the SI writes to removes that incentive.
An agent should read the least data the task needs
Agent access to data is a governance question in its own right, separate from approval. A mapping agent needs the structure of the legacy system and a sample of records to infer rules. It does not need the full customer master, the open payables, or the payroll file. A testing agent needs data shaped like production, not production itself.
The rule we recommend is least access by default. Give agents schema and sample sets for mapping work, and masked or synthetic data for test generation. Grant access to full master and transactional data only set by set, with each grant logged, and only when the task genuinely needs it. This is ordinary data-handling discipline, and it applies to an agent exactly as it applies to a contractor.
The reason to write it down is that agents can retain what they see. A model instance trained or prompted on your live data holds a residue of it, and that instance may sit with the SI or the tool vendor after go-live. Limiting what the agent reads limits what leaves with it. The next control closes the rest of that gap.
Ownership of the output, the model, and the prompts transfers at go-live
The agents on this market learn your program as they work it. Opkey gives each SI a dedicated model instance trained on that firm's methods, and Oracle lets partners extend its Fusion setup registry with their own configuration content. The test scripts, mapping rules, configuration runbooks, and prompts built on your data are assets, and without a clause they are the SI's assets.
Require three things to transfer to you at go-live. The output, meaning the scripts, mappings, runbooks, and the configuration record itself. The trained model instance, to the extent it was trained on your data and program. And the prompts, because a runbook you cannot rerun is a document, not a capability. Ask for all three in a form your own team, or a different SI, can use without the original vendor.
This is not a hypothetical. If the agents produced your regression test suite and that suite leaves with the SI, your first vendor update after go-live arrives with no way to test it except to rebuild the work you already paid for. Ownership at go-live is what keeps the saving, if there was one, from reversing the day the SI leaves.
Your auditors will ask who approved an agent-drafted configuration
For a company under SOX, this is the whole argument in one sentence. A configuration that sets how transactions post, who can approve a payment, or how tax is calculated is an internal control over financial reporting. The auditor's standard question about any such control is who designed it, who approved it, and where that is evidenced. "An agent drafted it" is not an answer. "An agent drafted it and no one is recorded as approving it" is a control deficiency.
The exposure is not the agent. The exposure is a process that lets agent output reach the production system without a named approval in a retained record. The four controls above close that gap, and they do it the way the vendors already expect. Oracle's model requires reviewer approval today. The discipline a SOX company needs is to require the same thing on any platform it runs, whether that is SAP, Oracle, Microsoft, Infor, or IFS, and whether the agent came from the vendor, the SI, or a third party.
The agents differ in maturity, and the control does not. SAP offers Joule for Consultants to its partners, Microsoft had Project Mia for Dynamics 365 in private preview in 2026, and Infor's only agentic delivery claim so far came from a partner rather than the vendor. On IFS Cloud the agents announced in 2026 sit inside the product, not in the implementation. Where the agent sits on that scale changes how much work it does. It does not change the need for a named approver, a retained log, a data limit, and an ownership transfer.