Human review before an AI agent changes your data

An AI agent that only answers questions carries limited risk. Once it can change a customer's status in your CRM, create documents in your ERP or start approvals in your collaboration tool, every action lands on real data. Human review has to be designed before the agent acts, not after.

In short: put review in front of write operations. Reads pass by default; writes pause until someone confirms. Send the request to the person responsible for that data, show what will change and why, and keep an exportable record of every operation.

1. Separate reads from writes

Agent operations fall into two groups:

• Reads: queries, summaries, document search. Nothing changes, so they pass by default.
• Writes: creating, updating or deleting records, starting approvals, sending external messages. They change data or reach outside, so they pause by default.

Adjust the defaults by actual risk, one operation at a time: a low-risk write that runs every day can be relaxed; a read that touches sensitive data can be tightened. The unit is a single operation, not a whole system.

2. Who receives the request

Do not route every request to IT or an administrator. Send it to the person who owns the data: sales leads for customer records, procurement for purchase orders, legal or the contract manager for the contract register. They know whether the change is right.

Split cross-system tasks into steps. If an agent reads from the CRM, writes to the ERP and then sends a notice through Feishu, the ERP write and the notice can each require a different approver.

3. What the approver needs to see

A pop-up that only says "Proceed?" asks people to sign blind. A request should show at least:

• which system and which record will change;
• the value before and after;
• where the basis comes from, such as a file or a message;
• which step of which task this is.

With that on screen, the approver can decide in seconds instead of checking the system again each time.

4. Use "always allow" sparingly

Approvers usually have four choices: allow once, always allow, deny once, always deny. "Always allow" removes repeated prompts, but it only suits operations that are low-risk, repetitive and easy to undo. Keep a list of every "always allow" you grant, review it regularly and withdraw grants when the business changes.

5. Log every operation

Whether an operation passes or is stopped, record the time, the user, the connected system, the action, its parameters and the result. Logs should be filterable and exportable, so you can trace problems and hand evidence to compliance reviews.

6. Start with one write operation

You do not need write access to every system on day one. Pick one frequent write with clear rules, such as turning action items from meeting notes into tasks. Run it for a few weeks and check whether requests carry enough information, who is approving, and whether anyone is just clicking "allow". Then expand. If your company uses several collaboration tools, see one AI assistant for DingTalk, Feishu and WeCom.

Summary

Human review before an agent changes data comes down to: separate reads from writes and pause writes by default; send requests to the data owner with what changes and why; keep a reviewed list of "always allow" grants; and log every operation in an exportable form.

For reference, FIM One from Beijing FIM Network Technology Co., Ltd. (北京飞沐网络科技有限公司) is a self-hosted enterprise agent platform. Write operations pause before they run and go to a designated person, who can allow or deny once or always; gating can be set per operation, and every operation is logged and exportable. See where human review sits for the mechanism and security and deployment for audit features. FIM One is source-available software.