Step 1: Identify where AI actually belongs
AI automation earns its place on specific types of work: high-volume, repetitive tasks with well-defined inputs and outputs; tasks where the cost of being slightly wrong is low and the cost of doing it manually at scale is high; and tasks where the value is in processing speed and consistency, not in judgment.
Good fits for AI automation in an SMB context: classifying inbound inquiries by type and urgency; extracting specific fields from documents, invoices, or forms; drafting a first-pass response to a standard support question; matching a new record against an existing database to flag duplicates; generating a summary of a long document so a staff member can review the key points without reading the whole thing.
Poor fits, regardless of how compelling the demo looked: any decision that has significant consequences if wrong and is hard to reverse (hiring, firing, large financial transactions, legal communications); any situation where the inputs are highly variable and the output affects a real customer before any human review; and any task where the process itself is poorly understood by the people who currently do it — automating a poorly understood process makes it faster but does not make it better.
Step 2: Define what confident means before you build anything
Every AI system — no matter what the vendor tells you — has a confidence level for every output. Sometimes it expresses this explicitly as a probability score. Sometimes it does not. Before you deploy any AI automation, you need to decide: what level of confidence is required for the system to act without human review, and what happens when the system is below that threshold?
This is not a philosophical question — it is a system design question with a specific answer. For example: 'If the AI is more than 90% confident that an incoming inquiry is a standard billing question, it routes it to the billing queue automatically. If it is below 90%, it routes it to a human for review with its best guess attached.' That policy can be written down, tested, and adjusted. 'The AI uses its judgment' cannot.
The confidence threshold you should never skip
Any automation that writes to a live database, sends an email to a customer, changes a record, or triggers a payment must have an explicit confidence threshold below which a human reviews before anything happens. This is not optional. The cost of one bad automated action at scale — a wrong email sent to 500 customers, a wrong record updated across your CRM — is not proportional to the time it saves.
Step 3: Build the human approval gate
A human approval gate is a step in the automation where a real person sees what the AI produced and confirms it before the action is taken. This is not a bureaucratic hurdle — it is the mechanism that keeps the automation's error rate within acceptable bounds and keeps your team informed of what is happening in their name.
The approval gate should show the reviewer: the input (what the AI was given), the AI's output (what it is about to do), and the AI's confidence level or any flags it raised. The reviewer should be able to approve, reject, or edit in under 30 seconds for a well-designed interface. If your approval gate takes a reviewer two minutes per item, it will not be used.
- 1Identify which specific actions in the automation require human sign-off before they execute.
- 2Design the review interface so a reviewer sees input, proposed output, and any uncertainty flags — without needing to understand the underlying system.
- 3Set a maximum review queue size — if more than N items are queued for review, notify a manager before the backlog causes delays.
- 4Test the approval interface with the people who will actually use it, not with the developer who built it.
- 5Set a fallback policy: if no one reviews an item within X hours, does it escalate, wait, or get routed differently?
Step 4: Log everything, from the start
An AI automation that does not produce a structured log of its decisions is an audit liability. When something goes wrong — and at some point, something will — you need to be able to answer: what input did the system receive, what did it decide, what action did it take, and when? Without logs, you cannot answer those questions, you cannot fix the underlying issue, and you cannot demonstrate to a client or regulator what happened.
- Log every input the system processes, with a timestamp and a unique identifier.
- Log the AI's output and confidence score for every item, regardless of what action was taken.
- Log the human reviewer's decision (approve/reject/edit) and their identity, if a review step exists.
- Log the final action taken — what was written, sent, updated, or triggered.
- Retain logs for a minimum of 90 days. Check your industry's compliance requirements — some mandate longer.
- Make the logs accessible to someone who is not a developer, so you can audit them yourself.
Step 5: Build and test the fallback path
Every AI automation needs a documented fallback: what happens when the AI is unavailable, when it encounters an input type it has not seen before, or when its error rate exceeds the acceptable threshold? The fallback is not a hypothetical — it is a path that gets tested before the automation goes live and that your team knows how to activate.
The simplest fallback is usually the manual process that the automation replaced. Make sure that process is still documented and that someone on your team knows how to do it. If the automation goes down and the fallback is 'no one knows how to do this manually anymore,' you have created a single point of failure.
Step 6: Address privacy and data handling before deployment
If your automation sends customer data to an external AI service — including major commercial APIs — you need to understand: where that data goes, how long it is retained by the provider, whether it is used to train models, and whether your customer agreements permit you to process their data this way.
- Read the data processing agreement for any AI API you use. Most offer a business agreement that prevents training data use — you usually have to opt into it explicitly.
- Do not send personally identifiable information that is not necessary for the task. Strip names, emails, and identifiers where the automation only needs the content.
- If your business operates in a regulated industry (healthcare, finance, legal), get legal advice before sending customer data to an AI API. The regulatory exposure may outweigh the efficiency gain.
- Store only the minimum data required for the log. Detailed logs are useful; logs that duplicate your entire customer database are a liability.
What you should not automate with AI
Some things look like good automation candidates and are not. Any communication with a customer that requires empathy, context, or relationship history — a complaint, a difficult conversation, a retention situation — should never be fully automated. AI can draft; a human should send. Any decision where being wrong has a consequence that is hard to reverse and significant in scale should not be automated without a very conservative confidence threshold and a mandatory human review step.
The right starting point for an AI pilot
Start with the highest-volume, lowest-consequence workflow you have. Something that happens 50 times a day and is tedious to do manually, but where a wrong output means a small correction rather than a customer problem. Run the automation in shadow mode for two weeks — let it process items and log what it would have done, without actually taking action — and measure its accuracy against the manual baseline. Expand only after the shadow-mode accuracy meets your threshold.