"Who approved this AI change?" — the SOX question your AI pilot can't answer

Every enterprise AI pilot eventually meets the same person: the one from internal audit who asks a question the whole project forgot to plan for.

"This record was changed by the AI. Who approved that?"

If the honest answer is "nobody, it just did it" — or worse, "we'd have to check the chat history" — the pilot is over, no matter how impressive the demo was. And the auditor is right to end it. A system of record that runs your financials is exactly where change accountability is non-negotiable.

Why this is a SOX question, not just an IT one

For companies under SOX (and its equivalents elsewhere), IT general controls expect that changes to systems affecting financial reporting are authorized, reviewed, and traceable to a person. Those controls were written for humans and change tickets, but they don't stop applying when the actor is an AI assistant. If Claude or ChatGPT can update a vendor master record, post a correction, or release a blocked invoice, then those actions sit inside the same control environment as any other change.

That creates three questions your AI integration must be able to answer, on demand, months later:

1. Who authorized this specific change? A named person — not a service account, not "the AI".
2. What exactly was changed? The precise payload, before it executed — not a reconstruction from logs.
3. Was the reviewer someone other than the requester? Segregation of duties doesn't disappear because one of the parties is a model.

Why chat logs don't count

Teams sometimes assume the AI conversation history is the audit trail. It isn't. A chat transcript shows what was discussed, not what was authorized. It has no approval decision, no independent reviewer, no guaranteed retention, and no link between the natural-language request and the exact API call that hit the ERP. Presenting a chat log to an auditor as change evidence is the fastest way to turn one finding into several.

The same goes for the shortcut of handing the AI an API key: every action executes under one credential, instantly and unreviewed. There is no control there to test — which, in audit terms, is the problem.

What a defensible answer looks like

The control auditors are looking for is old and well understood — it's an approval workflow. What's new is applying it between the AI and the ERP, so it cannot be skipped:

This is how DataTether treats every write: the AI can propose a change to SAP or any OData system, but the change waits at an approval gate until a named person reviews the payload and decides. Reads flow freely; writes wait. The approval and the outcome land in an audit log that answers the five questions above without archaeology.

The compliance officer is not your obstacle

Here's the reframe worth making before your next steering meeting: the compliance question isn't an attack on the AI project — it's the requirements document for it. A pilot that solves accountability first doesn't stall at the production gate the way most enterprise AI pilots do. It arrives with the answer pre-written, and compliance goes from veto-holder to the easiest sign-off in the room.

You can see the governance model in more depth on our security page, or read how the reads-flow-writes-wait model works in practice.

And if your team is being asked to put AI in front of SAP and keep the auditors comfortable, that's exactly the setup we walk through in a guided session — request guided access and bring your compliance lead along.