What an ERP AI audit trail should contain
For internal audit, compliance and anyone who has to explain to a regulator what a machine did on a Tuesday.
In short
An ERP AI audit trail should let you reconstruct any action end to end: who asked, in what words, which tools ran with which parameters, what the ERP returned, which model was involved, and what changed. If a vendor cannot show you the schema, they have logging rather than auditability.
- Reconstruction is the standard: could you replay what happened from the log alone?
- The prompt is part of the record — an action without its request is not explainable.
- ERP-side audit must remain intact, which requires calls to arrive as the real user.
- Ask to see the schema and run a query against it during evaluation.
Why is an AI audit trail different from normal ERP audit?
ERP audit records what changed and who changed it. An AI audit trail must additionally record why the system did what it did — the request in the user’s own words, the intermediate steps the assistant took, and what each step returned. Without that, a correct-looking record has no explanation behind it.
This matters most when something goes wrong. "The work order has the wrong site" is answerable from ERP audit. "Why did it choose that site" is only answerable if the tool calls and their results were kept.
What should be captured per turn?
Every conversation turn should produce a durable record with the conversation identifier, position, role, content, all tool invocations with parameters and results, the model used, error state, token usage, duration and a timestamp. That set is enough to reconstruct any interaction without access to the running system.
Three of those are the ones most often left out. Tool parameters, because storing only the tool name halves the value — you learn that a create was attempted, not what it was about to write. Failed attempts, because a permission refusal is evidence the control worked and belongs in the record. And the model identifier, because when behaviour changes between two dates, the first question anyone asks is whether the model did.
The field-by-field schema NgageChat writes is published on the security page rather than repeated here.
Does the ERP still record the change itself?
It should, and this is a design consequence rather than a feature. If the assistant calls IFS with the individual user’s token, IFS records the change against that user with its normal audit machinery. If it calls with a shared integration account, every AI-driven change in your ERP audit is attributed to one anonymous robot.
That second outcome is worth picturing before it happens. Six months in, a compliance question arrives about a batch of adjustments, and every one of them is attributed to SVC_AI_INTEGRATION. The conversation log may explain it — but your ERP audit no longer stands on its own.
What should you test during evaluation?
Do not accept a description. During a proof of concept, perform a write through the assistant, then reconstruct it from the audit data alone: find the prompt, the tool calls, the ERP response and the resulting record identifier, and confirm the ERP’s own audit names the right person.
- Perform a create and an update through conversation.
- Query the audit store directly for that conversation.
- Confirm every tool call and result is present, not just the final message.
- Check the ERP-side audit attributes the change to the individual user.
- Confirm a failed action is logged with the actual ERP error.