An AI assistant should prepare changes, not perform them. The difference sounds procedural and turns out to be the whole safety model: an assistant that writes directly to your business can be confidently wrong at machine speed, while one that produces a proposal for a human to confirm can only ever waste ten seconds of your time. When you evaluate AI features in business software, this is the question that separates the serious products from the demos.
Every business software vendor now ships an AI assistant. Most of the demos look identical: someone types a sentence, the screen fills with a reassuring animation, and a record changes. It is genuinely impressive, and it hides the only design decision that matters.
Ask a different question. Not what can it do, but what can it do without asking me first.
What does it mean for an AI to "propose" instead of act?
A proposing assistant never changes your data itself. When you ask it to do something, it produces a description of the change it intends to make, shows you exactly what would happen, and stops. The change only occurs when a person reads it and approves it. An acting assistant makes the change and then tells you it has done so.
Both feel similar in a demo, because in a demo the assistant is right. They diverge completely the first time it is wrong.
The distinction is not the same as an undo button. Undo assumes you noticed. A proposal is checked before it exists; an undo is a repair after the change has already propagated to whoever else was looking at that record.
Why does this matter more for business data than for a chatbot?
Because business records are shared, connected and audited, while a chat response is disposable. A wrong sentence in a chat window costs you nothing. A wrong stage change on a deal moves your forecast, a wrong job status tells a technician not to show up, and a wrong invoice reaches a client with your name on it.
Three properties make operational data unforgiving:
It fans out. One record touches several modules. A deal that moves stage changes a forecast, may trigger a notification, and shifts what your Monday report says. Correcting the record does not always unwind everything that read it.
It is shared. You are not the only person looking. By the time you spot the mistake, a colleague may have already acted on it.
It is evidence. Financial and client records are the trail you rely on in a dispute, an audit, or a POPIA request. A field that changed for no traceable human reason is a genuine problem, not an inconvenience.
What actually goes wrong when AI writes directly to your systems
Large language models fail in a specific way that makes unattended writes a poor fit. They do not fail loudly with an error. They produce a plausible, well-formatted, confident output that happens to be wrong, and it looks exactly like the outputs that were right.
The realistic failure modes are mundane:
The wrong record. You have two clients whose names are similar. You say to move the Kruger deal forward, and there are two Krugers. The model picks one. It sounds equally certain either way.
The right action, the wrong scope. You ask it to close last month's completed jobs. Its idea of last month and yours differ by a week.
Instructions hidden in your own data. This one surprises people. If an assistant reads a lead note, an email body or a file that a third party wrote, that text can contain something that reads like a command. A model that cannot distinguish content it is reading from instructions it is following can be steered by anyone who can get text into your system. Any assistant worth trusting labels retrieved data as untrusted precisely so this cannot happen, but the confirmation step is what makes the consequence survivable even if something slips through.
None of these are exotic. They are Tuesday. The question is only whether Tuesday costs you ten seconds or an afternoon of forensic work.
Does asking for confirmation make the assistant useless?
No, and the objection is worth answering directly. Confirmation costs one click on the small fraction of interactions that change something. It costs nothing at all on the majority, which are questions.
Most of what people actually ask an operations assistant is read-only. Which deals have gone quiet. What did we invoice last month, and how much is outstanding. Which jobs are behind. Who is carrying the most work. None of that touches a confirmation step, because none of it changes anything. The speed you came for is fully intact.
Where confirmation does apply, it is replacing something slower, not adding to it. The alternative to reading a proposal and clicking Confirm was never that the change happened instantly and correctly. It was navigating to the right screen, finding the record, and editing the field by hand.
The four questions to ask any AI vendor
Put these to every vendor, including us. The answers are usually short, and evasion is informative.
1. Can it change my data without a human approving it first? If yes, ask what happens when it is wrong, and who finds out. That there is an audit log is not an answer. An audit log tells you what happened after somebody thinks to look.
2. Can it see data the person asking is not allowed to see? The assistant's abilities should be filtered by the individual user's own permissions, and filtered before the model is given its list of what it can do. Filtering afterwards means the model cheerfully suggests things the person is then refused for, which teaches your team that the product is broken.
3. Can it reach another organisation's data? In a multi-tenant product, the model should have no ability to specify which business it is querying. If tenancy is a parameter the model fills in, it is a parameter the model can fill in wrongly.
4. Is my confirmation re-checked, or trusted? A confirmation that simply replays whatever the model prepared earlier is a formality. The permissions, the organisation and the record itself should all be validated again on the server at the moment you confirm, because circumstances may have changed since the proposal was drafted.
What a proposal-based assistant looks like in practice
This is how Synco, the assistant built into Syniq Business OS, handles it. It is offered as one concrete implementation, not the only possible one.
You ask which deals are expected to close this month. It reads your live pipeline and answers with the actual deals, values and stages. Nothing has changed; it was a question.
You then say to move the largest one to Negotiation. Instead of doing it, a card appears: the deal name, the stage it is in, the stage it would move to, and two buttons. The deal is still in Proposal. It stays in Proposal until you press Confirm, at which point the server re-validates your permissions, your organisation and the record before the change is committed.
The model itself never touches the database. It has no direct access at all, only a set of vetted functions that were filtered against your permissions before the conversation began. It also cannot specify which business it is looking at, because none of those functions accept an organisation as an input. They resolve it from your own logged-in session.
The list of changes it can propose is deliberately short: convert a lead into a deal, move a deal to a new stage, log an activity, create a job, change a job's status, and create a task. Deletion is not on the list, and that is not an oversight.
How to evaluate this on a trial
You do not need a technical review to test any of it. Two exercises, fifteen minutes.
Try to make it do something you are not allowed to do. If your organisation has role-based permissions, sign in as a restricted user and ask the assistant for something outside that role. The correct behaviour is that the ability simply is not there. The wrong behaviour is an attempt followed by a refusal, or worse, a success.
Ask it to change something, then walk away. Do not confirm. Go and look at the record directly. It should be untouched. If the change has already happened, you now know exactly what kind of product you are evaluating.
The short version
Speed is easy to demonstrate and easy to sell. Restraint is neither, which is why it is usually the thing that got cut.
An assistant that answers questions from your live data is genuinely useful, and you should expect that to be instant. An assistant that changes your business should be slower by exactly one deliberate click, and should be architecturally incapable of skipping it. When you compare AI features, ignore the animation and find out which of those two you are buying.
Frequently asked questions
A proposing assistant never writes to your data itself. When you ask it to change something, it produces a description of the intended change, shows you exactly what would happen, and stops. The change only occurs once a person reads and approves it. An acting assistant makes the change first and reports it afterwards.
Only on the small share of interactions that change something. Most questions put to an operations assistant are read-only — which deals went quiet, what you invoiced last month, which jobs are late — and none of those involve a confirmation. Where it does apply, one click replaces the slower manual alternative of finding the record and editing it by hand.
Four questions. Can it change my data without a human approving it first? Can it see data the person asking is not allowed to see? Can it reach another organisation's data? And is my confirmation re-validated on the server, or simply trusted? Short, direct answers are a good sign; evasion is informative.
It can, if it is poorly built. If an assistant reads a lead note, email body or document written by a third party, that text can contain something phrased as an instruction. A well-built assistant labels retrieved data as untrusted so it cannot be followed as a command, and a human confirmation step keeps the consequence survivable even if something slips through.
Two exercises. Sign in as a restricted user and ask for something outside that role — the ability should simply not be available, rather than being attempted and refused. Then ask the assistant to change a record and deliberately do not confirm it. Go and check the record directly. It should be completely untouched.
