Can AI send emails to customers on its own? When human review is needed

AI can be allowed to send some emails on its own, but not every type and not all at once. Automatic sending is justified for specific types of messages, where an error has low consequences and can be caught easily by rules: confirmation that a request has been received, an appointment reminder, or an order status pulled from the business system. Emails with new terms, payments, contracts, personal data, or responses to complaints should be shown to the person before sending.

The key condition is that checks happen before the email is sent and cover the exact text, recipients, and attachments the customer will receive. General approval or review after sending does not protect against errors. After reading this article, you'll be able to categorize your emails by risk, decide where a template is sufficient and where human approval is required, and create a plan for gradually expanding the AI’s authority.

Three modes of operation: draft, human-approved sending, and automatic sending

The question "can AI send emails" sounds like a choice between yes and no. In practice, there are at least three modes, and in one company they coexist for different types of messages.

Draft. The AI prepares the text but has no permission to send. An employee opens the draft in their email program or CRM, edits it, and sends it themselves. This is the safest start: the model cannot send anything even due to an error or manipulation of the incoming email. The benefit of AI here is faster drafting, not autonomy.

Human-approved sending. The AI prepares an email and proposes it for sending. A person either presses “Send” or gives explicit approval, after which the system sends that specific message.

Automatic sending within an approved scenario. For a predefined type of email, the system sends an email without human intervention. Permission is granted to a defined scenario, not to the model in general. For example, "confirmation of receipt of the application according to the approved template, with substitution of the application number from CRM." If the model adds a promise of a discount to such an email, this is a different scenario, and there is no automatic permission for it.

The same assistant can operate in all three modes depending on the type of email. Therefore, the decision is not made about the tool, but about each class of messages separately.

Email risk matrix: what to automate and what to approve

An email’s risk depends on the consequences of an error. An email saying “We received your request” with an incorrect reference number will prompt the customer to ask for clarification. An email saying “We will issue a refund tomorrow” sent without the right to such a decision creates an obligation that the company may not fulfill and a conflict with the customer.

The table below is an illustrative policy matrix, not authorization to send these specific emails on behalf of your company. You should set the limits for your business, consulting a lawyer where contracts or personal data are involved.

Notice the last two lines. A discount offer may need both human review of the text, but also a server check to see if it is allowed at all. And repeating after the timeout is not a question of email content; the system first needs to determine whether the email has already been sent.

What to check before sending

Pre-send checks involve several separate questions. Code can handle some and a person others, but none should be left to the model.

Addressee. Does the email address belong to the customer the message is about? A mistake when filling in a recipient field could send an invoice or contract to the wrong person. The simplest rule is to take the recipient from the customer’s CRM record using its ID, not from text generated by the model.

Attachments. Is this the correct file? Does it belong to this customer? Is it the current version of the document? The model should not select files from the shared folder by itself.

Facts. Do the amounts, dates, order numbers and conditions match the accounting system data? The numbers in the email should come from the system, not from the model's memory.

Authority. Does the person on whose behalf the email is sent have the right to promise what it says? Refunds, compensation, and special pricing require the sender to have the appropriate authority.

Reason for contact. Is it even possible to write to this person through this channel? Have they opted out of marketing emails? This is a legal and commercial issue and is not resolved by the employee clicking "I agree". Human approval of the wording and the legal basis for contacting the person are separate questions.

Current customer status. Has anything changed while the email was waiting in the queue? The order could be canceled, the complaint could already be resolved through another channel, and the client could ask not to write anymore.

Deliverability is separate. For email to personal Gmail accounts, all senders need SPF or DKIM authentication, valid forward and reverse DNS, TLS, and a spam rate below 0.3%. Senders delivering more than 5,000 messages a day to Gmail accounts must use both SPF and DKIM, publish DMARC, and align the From domain with the SPF or DKIM domain. Their marketing and subscribed messages must support one-click unsubscribe. Human approval alone does not guarantee delivery, and a configured domain does not guarantee correct email content. These are three separate checks: content, the right to contact, and technical sender readiness.

How to make approval meaningful

Approval makes sense only when a person sees and confirms exactly what will be sent to the client. A poorly arranged approval turns into a ritual: the employee clicks "yes" on a short summary, and another text is sent.

Minimum requirements for the approval screen:

• the full text of the email, not a summary or first lines;
• exact recipients, including CC and BCC;
• list of attachments with the ability to open each one;
• source of facts: where the amount, date, and order number came from;
• the reason why the email was approved, such as "contains a refund promise."

The most important rule is that approval must be tied to a specific version of the email. Technically, it can be done as follows: the system calculates a fingerprint (hash) from the addressee, text and attachments and saves it together with the human decision. The fingerprint is calculated again before sending. If something has changed after approval, for example, the model "improved" the wording, added an attachment or changed the addressee, the hash no longer matches, and the email must be submitted for approval again.

For example, in LangGraph, interrupt pauses the graph and waits for a human response. Resuming from saved state requires a configured checkpointer and the same thread_id. After resumption, the node starts from the beginning, so code before interrupt runs again. Side effects should therefore run after approval or be idempotent.

How to limit automation: rate limits, logging, deduplication, and a stop switch

Even for the permitted scenario, auto-send needs safeguards. There are three separate sources of harm: excessive functionality, excessive permissions, and excessive autonomy. Each of them can be limited.

Minimum necessary features and permissions. If an assistant only needs to read email and prepare drafts, it should not have permission to send. For example, an email-summarization extension should not be able to send messages. Restrict permissions in the email service itself instead of trusting that the model “won’t want to.”

Check permissions outside the model. The decision about whether an action is allowed should be made by code in the system receiving the request, not by the model itself. If the script only allows the "request received" pattern, the server rejects any other text.

Limits. Limit the number of emails per hour, per customer, and in total. Rate limiting does not prevent an error, but it reduces the damage and gives people time to notice it.

Logging. For each email, store: operation ID, scenario, template version, recipients, content hash, who approved (or the rule that authorized automatic sending), time and response of the email service.

Deduplication and timeouts. This is where duplicates occur most often. The system requested a send, but no response arrived before the timeout, so the code tries again. But the timeout does not mean that the email was not sent: it may have been sent while the confirmation was lost. Correct order: each email has a unique operation ID; before repeating, the system checks whether there is a confirmed result for this identifier; a retry occurs only when the previous attempt is known to have failed.

Stop and revoke access. There should be a button or checkbox that instantly disables automatic sending for the scenario or for the entire system. You also need a procedure to revoke mail access keys if something goes wrong. Decide in advance who has the right to press "stop".

When to expand the AI’s authority

Expand the AI’s authority based on data, not a feeling that "already works well". A reasonable sequence looks like this.

Observation stage. The AI prepares drafts; people send them. You collect statistics: how many drafts were sent without changes, how many with minor edits, how many were completely rewritten. Count separately for each type of email.

Human-approval stage. For email types whose drafts rarely need significant edits, enable sending after human approval. Now you can see how much time is spent on approval and what mistakes people make.

Limited-automation stage. For a narrowly defined scenario using an approved template and system data, enable automatic sending. Leave a selective check of already sent emails, like reviewing a random sample each day to notice a drift.

The criteria for moving between stages depend on the type of email. For each type, compare the cost of manual review (number of emails × review time × employee hourly cost) with the expected total cost of errors that reach customers (number of emails × probability that an error gets through the remaining checks × expected impact of that error). The share of errors caught during human review does not show how many errors would pass automated checks. If that escape probability is unknown, keep approval in place and estimate the residual risk in a test or controlled pilot first. If an error could cost a contract or customer, even a small probability may outweigh the time saved.

Illustrative calculation using hypothetical numbers: a team sends 400 “order status” emails per month, and approving one takes two minutes—about 13 hours (400 × 2 = 800 minutes). If reviewers substantially corrected 2 of the 400 emails, that shows what human review caught; it does not estimate how many errors would pass the automated checks. Before removing approval, measure residual errors in a test or controlled pilot; spot-checks after sending do not replace pre-send checks. For emails with a contract and price, also account for the possible impact of one error. Use your own data for review time, errors caught and missed, and their consequences.

You can also reduce the AI’s authority. If the number of errors increases after changing the template, model, or rules, roll back the script to an earlier stage and test again.

Conclusion: what to do in your process

1. List the types of emails your team currently sends to customers.
2. For each type, describe what happens in the event of an error and assign it to one of three modes: draft, human-approved sending, or automatic sending.
3. Define the decision owner for each type and what exactly is logged.
4. Set up the approval screen with the full text, recipient, attachments and origin of each number; tie approval to a hash of the message content.
5. Remove permissions from the AI ​​that are not needed for the current mode and move permission checking to the server logic.
6. Assign a unique operation ID to each email and check its status before retrying after a timeout.
7. Check separately the reason for contacting the customer and the technical readiness of the sender's domain.
8. Start with monitoring, count edits by email type, and escalate only where the data warrants it.

Frequently asked questions