Can an AI assistant update the business management system? How to limit its actions

An assistant that gets an answer wrong is corrected by rereading it. An assistant that gets a write operation wrong leaves a wrong piece of data in the business management system, and from there an invoice, a delivery, or a phone call to a customer follows. It's the same technology, but the risk changes nature: you go from questionable information to a completed operation.

So the question "can artificial intelligence update the business management system?" has only one useful answer: yes, on operations defined in advance, with their own permissions, with a check before writing, and with a log of what it did. All the work lies in deciding which operations.

Reading, proposing, writing: three levels, three risks

The most useful distinction isn't technical but organizational, and it's about who takes responsibility for the outcome.

Almost all useful projects live in the first two levels. The third is allowed for repetitive, reversible operations; the fourth, in practice, isn't allowed at all.

The assistant isn't an administrator: it inherits a role's permissions

The most common setup mistake is connecting the assistant with access that can do everything, because it's quicker to configure. From that moment on, every limit depends solely on the instructions given to the model, which is the part that's easiest to get around.

• The assistant has its own account, separate from people's accounts, with the minimum permissions for the tasks it's assigned.
• If it responds to different users, it should see what that user would see: a salesperson shouldn't be able to obtain, through the assistant, data the business management system denies them.
• The connected tools are a closed list. "It can query the database" isn't a list: it's general access under a different name.
• Tests are run on a separate environment, not on production data, and need to be repeated every time the permissions change.

Writes are scoped by field, not by good intentions

Scoping means writing the list of allowed operations, each with its fields and its conditions. Whatever isn't on the list isn't possible, not merely discouraged: that's the whole difference.

• Which fields the operation can touch, and which stay read-only even when the assistant discusses them.
• Which values are allowed: a future date, a status among the ones defined, a customer that exists. Validation lives in the system, not in the instructions written for the model.
• On which records: its own, the open ones, the ones from the current period. The case "update all customers" should never be possible.
• How many times: a limit on the number of operations per session stops a misunderstanding from turning into hours of work to undo by hand.

An example flow: rescheduling an appointment

A repetitive, low-risk operation, with a customer on the other end. An illustrative sequence.

1. A request comes in: "Can Thursday's technician come Friday morning instead?" The assistant identifies which appointment is being discussed and, if the data isn't enough, asks instead of guessing.
2. It checks the conditions: the appointment exists, it isn't already closed, whoever wrote in has the right to move it, the new date is available for that technician.
3. It prepares the proposal with the values filled in: old date, new date, technician, customer.
4. It shows the proposal to whoever needs to authorize it and waits for explicit consent. The consent applies to that proposal, not to the following ones.
5. It executes only the authorized operation, with an identifier that prevents it from being applied twice if the request is repeated.
6. It logs the outcome and reports what changed. If the operation fails, it says so openly: an assistant that reports a success that never happened is worse than one that makes a mistake.

The step that gets cut first, and that everything else actually rests on, is the fourth one. Without an explicit confirmation, the system is no longer scoped: it's merely well instructed, and instructions aren't a limit.

Duplicates, repeats, and how to undo

Requests get repeated: someone writes in again, the network drops, the assistant retries. If every attempt produces an operation, you end up with three appointments moved and two notices sent to the customer.

• Every operation carries an identifier derived from the request: if it arrives twice, the second time produces nothing.
• Before creating something, you check whether it already exists: a customer, an order, a similar appointment on the same day.
• For every operation, you write down how to undo it and who can do so. Some are reversible, others aren't: a message sent to a customer can't be recalled, and that alone is enough to move it into the operations that require human confirmation.
• Operations carried out in sequence should be treated as a block: if the third one fails, you need to decide in advance whether the first two stay or get rolled back.

The log: what, when, at whose request

Without a log, you can't answer the question that sooner or later comes up: why was this appointment moved? The log is for reconstructing, not for assigning blame.

• The original request, the operation performed, and the values written.
• Who authorized it, when, and through which channel.
• The outcome, including failed attempts and operations rejected by the checks.
• How long it's kept and who can consult it: the log contains company data and sometimes personal data, and it's protected like everything else.

The logged rejections are the most useful part in the first months: they tell you what the assistant tried to do and couldn't. That's how you find out whether the limits are too tight or too loose, without having to discover it from a mistake.

What this guide doesn't cover

Here we cover the control of actions: which operations are allowed, who confirms them, how they're logged. The technical checks for connecting two pieces of software together, meaning what each one exposes and what happens when one of them changes, are a separate topic. So is the defense against deceptive instructions hidden inside documents or messages the assistant reads: that's a different risk, with its own countermeasures.