All-or-nothing access is why AI-to-ERP projects either stall in read-only purgatory or terrify compliance. The working model splits the problem: reads flow freely, writes wait for a named human.
By DataTether
Most conversations about AI access to SAP get stuck on a false binary. One camp says "read-only, forever" — safe, and safely useless beyond Q&A. The other says "give it access and let's move fast" — which lasts exactly until the first unreviewed write to production, or the first auditor's question nobody can answer.
The model that actually works in production isn't a point between those extremes. It's a split: reads flow, writes wait.
Reads and writes are different risks, so treating them with one policy guarantees you get one of them wrong.
A scoped read is low-risk and high-value: "show me overdue invoices over €50k by region" touches nothing, and answering it instantly is most of the daily payoff. Throttling reads behind human review just recreates the reporting backlog AI was supposed to remove.
A write is a different animal. Creating a record, updating a vendor, releasing a block — these change the system that runs the business. The risk isn't that the AI is usually wrong; it's that one wrong or misunderstood write is expensive, and an unreviewed write is indefensible afterward, correct or not.
One policy for both means either your reads are needlessly slow or your writes are dangerously fast.
Here's how the split works in DataTether, decision by decision:
Reads flow — inside scopes you set. You choose which entities are exposed, which operations (list, get, count), and which fields, down to the column. Within that boundary, the AI answers at full speed. Outside it, the tools simply don't exist — there's nothing to jailbreak into calling, because unexposed entities were never turned into tools.
Writes wait — at an approval gate. When a write operation is enabled and the AI proposes one, nothing executes. The proposed change — the exact payload, not a summary — lands with a designated approver. A named person reviews it and approves or rejects with one click. Only an approval releases the write to SAP.
Everything is logged. Identity, payload, approver, decision, outcome — for reads and writes alike. This is the difference between "we think it's fine" and an audit trail; the SOX version of this argument is its own post.
If you know the four-eyes principle from payments or change management, this is that — applied at the only place it can't be skipped, between the AI and the ERP. The requester (the AI, acting for a user) and the approver are structurally separate. That's segregation of duties, not a checkbox.
The day-to-day is less ceremonious than "governance" sounds. Someone asks Claude to correct a customer's payment terms. Claude finds the record, drafts the update, and the request appears for the approver: which entity, which record, which fields change from what to what, requested by whom. Ten seconds of reading, one click. The write executes, the log updates, Claude confirms completion.
Compare that ten seconds to the alternative — the same change made by hand: find the transaction, find the record, retype the values, screenshot it for the email thread that asked. The gate isn't slower than the old way. It's dramatically faster, with a reviewer.
The adoption path we recommend to every team, including the ones excited to automate everything:
Trust the ratchet, not the demo. Every step is reversible — a scope or a write operation can be turned off as easily as it was turned on.
The deeper security model — credential vaulting, scoping, audit — is on our security page. And if you're designing this for your own SAP landscape, request guided access: the first working session is exactly this exercise, on your services, with your approvers.
Keep reading
sapA sales order isn't one record. When AI creates the header but the line item fails, someone has to find and delete the orphan by hand. Atomic writes remove the entire failure class.
sapEvery generic 'connect AI to your API' demo dies on its first real SAP Gateway service. Here are the four quirks that kill it — and what handling them properly actually involves.
complianceThe moment AI writes to a system of record, it enters audit scope. Most AI pilots have no answer to the change-accountability question. Here is what a defensible one looks like.
