Who approved that? Building an audit trail for AI changes in your ERP and shop
When AI changes prices, orders or charges, you need to know who asked, what was proposed and who approved it. How Steward records reviewed changes.
The question that comes up eventually
Three weeks after the fact, someone notices that 60 article prices went down by 10 %. Or a discount code was valid for the whole store instead of one collection. Or a guest was charged for a minibar item they say they never took.
The first question is always the same: who did this, and why?
With a person working directly in the system, the change log might give a user name. With AI tools, the answer is often worse: “the AI did it”, using a token that belongs to the managing director, triggered from somebody’s personal chat that nobody else can see.
What a useful AI audit trail contains
For every change prepared by AI, a business needs five facts:
- The request: who asked for it, in what words?
- The proposal: exactly which records and values were going to change?
- The decision: who approved or rejected it, and when? If rejected, why?
- The result: what actually happened in the system, item by item?
- The context: which conversation, project and business reason led to it?
Many AI connectors record only some of these.
How Steward records changes
Every change Steward prepares in Ask for approval mode, or that an approval rule requires to be reviewed, becomes a proposal in the conversation. Changes that run in Automatic mode are not reviewed proposals: nobody decides on them before they run.
- The request is the chat message, from a named person in a shared project.
- The proposal lists each item with its field name, current value and proposed value. It also includes the exact request that will be sent. See review and approve changes.
- An independent explanation. For weclapp, a separate AI model describes the business effect of the request without seeing the working conversation. It gives the approver a second opinion.
- The decision is recorded with the person who decided and any rejection message. Only people with Approve access and a Contributor or Manager role in the project can decide.
- The results appear per item, including partial failures. Uncertain outcomes are marked as uncertain, never as success.
All of this stays in the project’s shared history, where colleagues with access can find it later.
Separation of duties, built in
Auditors like a simple principle: the person who prepares a change should not be the only person who approves it. In Steward, that principle is an access setting:
| Role | Steward permissions on the connection |
|---|---|
| Clerk or assistant | Contributor |
| Manager | Read and Approve: can approve changes |
| IT partner | Configure: maintains the connection, no business data |
Give these permissions to people or teams in connection permissions. One approval applies to the exact prepared batch. It never expands anyone’s permissions or approves later changes.
Changes that must always be reviewed
Some changes should never run without a person, whatever the chat mode. Steward has strict defaults:
- Shopify: refunds, payment capture, cancellations, fulfillment, publishing, deletion and customer notifications.
- ASA HOTEL: room charges, charge documents, reservation creation, spa bookings and room messages.
For any connection, approval rules let you add your own, such as “always review sales order creation” for weclapp.
Uncertain results are recorded, not hidden
If a change may or may not have reached the system, for example after a timeout, Steward records it as uncertain and does not retry. For ASA HOTEL, a person checks the system and records the verified outcome with a reference as evidence. The original result stays unchanged, and the human verification is added beside it.
Reads and recurring reports
Not every entry is a change. Scheduled tasks show who they run as, which connections they use, which permission mode they run in and every run’s result. A Read only daily report is evidence in itself that the process cannot change data.
What this does not replace
Steward’s record covers changes prepared through Steward. Your ERP, shop and hotel system keep their own logs, and changes made directly in those systems appear there, not in Steward. Your bookkeeping obligations stay the same.
Get started
Project roles. Viewers follow results, Contributors use configured connections and prepare changes, and Managers approve. Invited project members need no separate connection grant.