Ask a vendor whether their AI can send without approval and you will get a reassuring answer. There is a review step. There is an approval flow. Nothing goes out unchecked.
Then ask a different question. Where does the block live?
If the answer is that the send button is disabled until someone approves, you have been shown a user interface, not a control. Anything that reaches the system another way, an integration, an API call, a background job, a future feature written by someone who did not know the rule existed, goes around it completely.
If the only thing stopping a send is a greyed-out button, then the rule is a rendering decision.
Why this matters more with AI than without
Interface-level controls were always weak, but they used to be weak in a low-consequence way. A person had to click something to break the rule, and people mostly do not go looking for ways to bypass their own process.
Automation removes that friction. The whole point of an automated desk is that things happen without a person initiating them. Once that is true, every rule you rely on has to hold in paths where nobody is watching, because most of the paths are now paths where nobody is watching.
That is the shift. Under manual working, the interface was where the work happened, so a rule in the interface caught nearly everything. Under automation, the interface is one entrance among many.
What server-enforced actually means
It means the check runs at the point of sending, in the service that does the sending, and it cannot be reached around. Three things follow from that, and they are the things worth verifying.
- The rule is evaluated on every path. Manual send, automated send, API, scheduled follow-up. Not just the one with a button.
- The interface reports the decision, it does not make it. The reason shown on screen is a courtesy so a human knows why something is held. Remove the screen entirely and the block still holds.
- The rule cannot be turned off by a setting a hurried person can find. Some things should be configurable. Whether a quote can leave without a human click is not one of them.
The rules we hold this way
Ours are deliberately few, because a long list of enforced rules is usually a sign that none of them are.
| Rule | Why it is absolute |
|---|---|
| Nothing under 8 out of 10 sends | A draft that cannot pass a check against the requirement is not ready, no matter who wrote it. |
| Quotes and proposals never auto-send | These commit the company. A human click, logged under a name, is the approval. |
| No send past a deadline | A late submission is not a partial success. It is noise sent to a buyer who has closed the file. |
| Submission needs your password again | The one action that cannot be recalled gets an explicit, deliberate confirmation. |
Four rules, enforced in the service that sends. Everything else is configurable.
How to test a vendor on this
You do not need to read their code. Ask three questions and listen for whether the answer is architectural or cosmetic.
- If someone calls your API directly, does the approval requirement still apply, or is it a property of the web app?
- What happens if a scheduled job tries to send something that has not been approved? Not what should happen. What does the code do.
- Which of your safety rules can an administrator switch off, and which are structural?
The last one is the most revealing. A vendor who says everything is configurable is telling you they have no guarantees, only defaults. Defaults are what a busy quarter changes.