AI Suggests, Humans Approve: Our Rule for AI in Operations

There is a tempting version of AI in a business, and it is the wrong one. In that version the AI reads an email and sends the reply. It looks at an order and updates the record. It notices a slow-moving product and changes the price. No human in the loop, no waiting, pure speed. It demos beautifully. Then one day it confidently sends the wrong customer the wrong quote, or drops a zero off a price, and because nobody was watching, the mistake is already out in the world before anyone knows it happened.

We built AI helpers into our own internal system, and we chose a different rule from the start. The AI drafts. A human approves. Nothing that touches a real customer or real money changes until a person says yes. This article is about that rule, why it is the right one, and why we enforce it in the code itself rather than trusting everyone to be careful. It is a governance decision as much as a technical one, and it is one of the load-bearing choices behind the operating system we built for our own business.

AI is a superb drafter and an unreliable decider

The single most useful thing to understand about today's AI is the split between those two jobs. As a drafter it is excellent. Hand it a long email thread and it produces a tidy summary in seconds. Ask it for a first-pass reply to a customer and it gives you something 90% of the way there. Point it at a stalled task and it proposes a sensible next step. This is real, useful speed, and turning it down would be leaving money on the table.

As a decider it is a different animal. The same tool that writes a great summary will also, every so often, state something false with total confidence. It has no reliable sense of when it is out of its depth. It does not know that this particular customer is a special case, or that this number looks wrong, or that this reply would breach a promise you made last week. A human doing the same task carries all that context and, crucially, hesitates when something feels off. AI does not hesitate. It just proceeds.

So the design question is not "is the AI good enough to act." It is "what happens on the occasions it is confidently wrong." If the answer is that a person catches it in half a second before anything is committed, you have a great assistant. If the answer is that the mistake is already live, you have a liability wearing a helpful face.

The rule: AI drafts, a human commits

Here is exactly how it works in our system. The AI helpers produce drafts and suggestions: summaries of a thread, a proposed reply to a client, ideas for the next step on a job. Those outputs appear in front of a person as a suggestion, clearly marked as a draft. The person reads it, edits it if needed, and only then approves. The moment of approval is the moment anything real happens. Until then, the AI's output is just text on a screen. No email has been sent. No record has been updated. No price has moved.

The distinction that matters is between reading and writing. We let AI read freely, because reading is safe: summarizing, drafting, proposing all happen in a sandbox where the worst case is a suggestion you ignore. We do not let AI write, because writing is where consequences live. Changing a business record, sending a message to a customer, moving money: those are commit actions, and every commit action in our system routes through a human first.

Why we enforce it in the architecture, not in good intentions

It is easy to say "we will always review the AI's output." It is a policy, and policies erode. People get busy. On a hectic day, when there are forty drafts to clear, "always review" becomes "skim, approve, approve, approve." If the only thing standing between an AI draft and a live customer email is a tired person's discipline at 5pm, you do not really have a safeguard. You have a hope.

So we built the boundary into the structure of the system instead. The AI helpers simply do not have the ability to commit a change. They can produce a draft and nothing more. The pathway that actually writes to a business record or sends a message is a separate step that only a human action can trigger. This is not a setting someone can switch off in a hurry, and it is not a rule that depends on anyone remembering it. The AI cannot act on its own because it was never given the keys, and that is a property of the architecture rather than a promise in a policy document.

The practical difference is that safety does not degrade under pressure. The busiest, most tired day in the business is exactly when a policy-based safeguard fails and a structural one holds. On that day the AI still cannot send anything on its own, because there is no path in the code for it to do so.

This is a different question from whether AI replaces your staff

It is worth being clear about what this article is not. There is a separate, important conversation about whether AI takes people's jobs, and we have made our position plain in how to use AI without replacing your staff. That piece is about roles, headcount, and what your team does all day.

This piece is about something narrower and more technical: the architectural rule for how AI is allowed to touch your data. The two connect, because the "AI suggests, humans approve" pattern is precisely what keeps your people in the decision seat rather than downstream of a machine that already acted. But you could adopt this rule with a large team or a small one. It is about where authority to change real records sits, and the answer is that it sits with a person, by design.

What you actually get from the rule

The point of drawing the line this carefully is not caution for its own sake. It is that this specific design gives you the good part of AI without the dangerous part.

• Speed on the drafting. The slow, blank-page work of writing summaries and first-draft replies is done in seconds, so your people start from 90% instead of zero.
• Control at the commit. Every change that reaches a customer or a record was seen and approved by a person who could catch what the AI could not.
• No silent failures. Because nothing commits without a human, an AI mistake surfaces as a draft to reject, not as an incident to clean up.
• Safety that holds under load. The boundary is structural, so it does not weaken on the exact busy days when a discipline-based rule would.
• A clear line of accountability. When a change happens, a person approved it, which matters for trust, for auditing, and for getting the mistake back to a human who can learn from it.

That is the trade we chose, and we would choose it again. AI gets the speed. People keep the keys. The cost is a couple of seconds of human review on each action, and against the cost of a wrong automated action on real customer or money data, those seconds are the cheapest insurance in the building.

How to apply this in your own operations

If you are thinking about putting AI into how your business runs, the single most useful question to ask any tool or any developer is this: can the AI change real data or contact a real customer without a person approving it first. If the answer is yes, you are being sold the tempting version, and you should push back. If the answer is no, and the boundary is built into the system rather than promised in a policy, you are looking at the safe one.

The honest caveat is that no design removes the need for judgment entirely. A human who rubber-stamps every draft without reading it has rebuilt the dangerous version by hand. What the architecture does is make careful review the default and unsafe automation impossible, which is the strongest position software can put your people in. The rest is a team culture of actually reading before approving, and that part is worth protecting.