Can AI safely take action in your ERP?
Every conversation about ERP AI arrives at the same question, usually about fifteen minutes in. It deserves a specific answer rather than reassurance.
In short
AI can write to an ERP safely when five controls are in place: it acts as the signed-in user rather than a service account, it shows the exact payload before committing, permissions are enforced by the ERP itself, concurrent changes are detected, and every step is logged. Remove any one of these and the risk becomes hard to defend.
- The risk is not that the model is wrong; it is that a wrong action is committed without a human seeing it.
- Identity is the control that does the most work: acting as the user makes over-reach structurally impossible.
- Confirm-before-commit turns an autonomous write into a reviewed one.
- Auditability must be demonstrable, not asserted — ask to see the record.
What is the actual risk?
The risk is a wrong write that nobody reviewed. An AI assistant that reads badly gives a bad answer, which a person can sanity-check. An assistant that writes badly puts a wrong record into the system of record, where it propagates into planning, cost and compliance before anyone notices.
That framing matters, because it points at the mitigation. The problem is not "can the model be wrong" — of course it can, and so can a person. The problem is whether a wrong action can reach the database without a human looking at it. That is a design decision, not a model capability.
Whose permissions should the AI use?
The user’s. Each person should authenticate with their own IFS account and the assistant should call IFS with that user’s access token. IFS then enforces its projection-level permission model directly, so the assistant cannot read or write anything the person could not reach in Aurena — regardless of what the model decides to attempt.
The alternative — a shared integration account with broad grants, plus software logic deciding who may do what — moves the access decision out of the ERP, where it is enforced and audited, and into application code and prompts, where it is neither. It is faster to build and much harder to defend.
A useful question for any vendor: "does every call reach our ERP with the end user’s identity, or a service account’s?" The answer tells you most of what you need to know about the security model.
What does confirm-before-commit look like?
Confirm-before-commit means the assistant assembles the complete payload, renders every field it is about to write as a readable summary, and waits. Nothing reaches the ERP until the person approves. The person can also change a value at that point, which is usually faster than restating the whole request.
- The full field list, not a summary sentence — including the values resolved from defaults.
- The target entity and the operation: create, update, delete or a named action.
- An explicit approve step, with an equally easy way to amend.
- The record identifier returned afterwards, so the write can be verified in the ERP.
What should be in the audit trail?
An ERP AI audit trail should record, per message: who asked, what they typed, which tools ran with what parameters, what came back, which model handled it, how long it took, and any error. On the ERP side, the normal audit continues to work — because the calls arrive as the real user, not as an integration account.
Most vendors assert auditability. Very few show the schema. Asking to see it is a fast way to find out whether the logging is a designed feature or a log file.
| Field | What it captures |
|---|---|
| conversation_id, message_index | Which conversation, and where in it |
| role, content | Whether it was the user or the assistant, and what was said |
| tool_invocations | Every tool call, its parameters and its result |
| provider, model | Which model handled the turn |
| has_error, error_summary | Whether it failed, and how |
| token_usage, duration_ms | Cost and latency, per turn |
| created_at | Timestamp |
Scroll the table sideways to see every column.
Does write access have to be all or nothing?
No, and treating it that way is why so many ERP AI projects stall at the governance gate. What can be written is already defined by each person’s ERP permissions — the permission sets your administrators maintain today — rather than by a switch on the assistant.
That reframing changes the conversation in the room. The question stops being "do we trust an AI to write to production" and becomes "do we trust this named group of people to do the things they are already permitted to do, with a confirmation screen in front of each one". The second question has an obvious answer.
For the order to turn things on in, see the four-phase rollout in how to use AI with IFS ERP.