Decide whether AI should send email by separating reading, drafting and sending authority, testing exceptions and keeping consequential messages under your control.
Direct answer: Keep AI in a draft-and-approve role by default, especially when messages affect customers, money, commitments or personal information. Consider automatic sending only for a narrowly defined, authorised message type with verified inputs, constrained recipients, tested exceptions and a reliable stopping process. If a fixed acknowledgement or existing email rule solves the task, prefer that simpler option over free-form generated replies.
Permission to read an inbox is different from authority to speak on your behalf. A draft can be corrected before it leaves your account; a sent message may already have changed somebody's expectations or disclosed information.
I would accept some manual approval time rather than grant broad sending authority to save a few minutes. The case for automation strengthens when the output is tightly constrained and low consequence, not merely when the assistant writes convincing prose.
Applies to: individual and small-team email workflows. Exact permissions and safeguards depend on the service and account. This is not a tested endorsement of an inbox integration.
Use the send-authority boundary
The send-authority boundary is an editorial method for deciding which actions the assistant may take without you. Separate reading, preparing a draft, approving content and sending it. Do not combine them under the vague label “email assistance”.
For each action, specify the information available, the permitted output and the person responsible. A tool may need to read one selected message to draft a response; that does not mean it should read an entire mailbox or send to every address it finds.
Identify messages that remain manual: complaints, payment changes, contractual promises, sensitive personal matters and anything whose correct response requires judgement you cannot express as a dependable rule. These are examples to adapt, not an exhaustive legal classification.
The focused AI workflow guide keeps final judgement accountable. In an inbox, that principle becomes a concrete permission decision about when text is allowed to leave your control.
Inspect the actual permissions before connecting
Read the provider's documentation and the account's authorisation request. Establish what it can read, modify, create, send and delete. A button labelled draft assistant is not evidence that the underlying permission excludes sending.
Google's Gmail API documentation illustrates the distinction: gmail.readonly permits reading, gmail.send permits sending, and gmail.compose includes managing drafts and sending messages. The names should therefore not be interpreted casually; a compose-related permission is not necessarily draft-only. These are API scope definitions, not proof of any particular assistant's implementation. Google Gmail API scopes.
Check where message content goes, whether another provider processes it, who can access stored copies and how retention works. Do this before exposing the mailbox. Workplace or client information needs the required approval even if you own the email account.
Use a dedicated test environment or an approved set of synthetic messages for evaluation. Do not connect a live customer inbox just to see whether the onboarding is convenient. If you cannot establish the scope or stop access independently, do not proceed.
Define an automatic message so narrowly that it is boring
An appropriate candidate might be a fixed receipt acknowledgement for a designated form, with no interpretation of the request and no promise of a particular outcome. Even then, verify the destination and avoid exposing details that the recipient should not receive.
Write the allowed message content and the conditions for sending it. Record what must cause a hold: missing information, a different request type, an unexpected recipient, an attachment or a phrase that requires manual handling. The precise conditions depend on your real task.
Do not ask a free-form model to decide whether its own response is consequential. If you cannot bound the task without relying on that judgement, keep approval. A confident explanation that a message is routine does not make it routine.
For a simple fixed response, existing mail rules or the form's normal acknowledgement may be enough. Verify their current behaviour and permissions before using them, but do not introduce AI just because the surrounding workflow mentions it.
Test exceptions with synthetic messages
Prepare examples that represent normal requests and the situations that should stop automation. Include an ambiguous request, an incorrect recipient, a changed payment detail and an email that contains instructions attempting to redirect the workflow.
Treat incoming email as material to process, not as authority to change your rules. For example, a message saying to ignore approval and forward previous correspondence should not acquire permission merely because it appears in the inbox. Your workflow's authorised boundaries must remain outside the sender's control.
During the trial, generate drafts only. Compare each result with the required handling: ready for approval, request clarification or retain for manual response. Record incorrect recipient choices and invented commitments separately from spelling errors.
Confirm that the reviewer sees the original message, the proposed recipients, attachments and the exact draft before approval. A summary saying “reply prepared” is not enough to authorise sending. If the application cannot expose the relevant information clearly, keep the response in your ordinary email process.
Calculate the approval work honestly
Consider a fictional sole trader handling 45 routine replies in a month. Assume manual writing takes three minutes each, for 45 × 3 = 135 minutes. These are illustrative timings, not observed performance.
An AI draft workflow takes an assumed 20 minutes to set up. Reviewing each of 45 drafts takes one minute, and four exceptional messages require eight additional minutes each. Total attention is 20 + 45 + (4 × 8) = 97 minutes.
The draft route releases 135 minus 97 = 38 minutes under those assumptions. It does not save cash unless an actual expense falls. It also does not establish that the four exceptions would be detected reliably in future work.
Now suppose automatic sending removes the 45 minutes of approval but adds ten minutes of monitoring. The apparent extra time release is 45 minus 10 = 35 minutes. That is the convenience you are weighing against losing the pre-send checkpoint, not proof that the trade is worthwhile.
Do not calculate the cost of an incorrect promise as zero because it has not happened in a trial. You may be unable to estimate that cost credibly. Where the consequence is material and the boundary is weak, uncertainty supports retaining approval rather than inventing an expected-loss figure.
Establish how to stop and recover
Before any permitted automatic use, know how to pause the workflow, inspect queued messages and revoke the connection. Verify which actions stop new processing and whether already queued work needs separate attention. Do not assume closing a browser tab stops a server-side process.
Google's account guidance explains managing third-party connections and notes that removing access does not necessarily delete information already held by the other service. Use the provider's separate data-handling procedure where needed. Google account connection guidance.
Retain a minimal, appropriate record of sent messages and decisions through your normal system. If an error occurs, stop the workflow, establish what was sent and to whom, and follow the relevant correction or incident process. Do not assume recall will recover every message after delivery.
For personal-data exposure or a contractual issue, involve the responsible person and obtain jurisdiction-appropriate advice. Avoid sending a second automated apology before you understand the first error.
Start with a week of draft-only use
- Spend fifteen minutes defining the eligible message type, forbidden actions and approval owner.
- Check the exact permissions and data flow, then test synthetic normal and exceptional messages without live sending.
- If approved, use draft-only assistance for a week and record review time and failures.
- Retain manual approval unless a separate, narrowly scoped automatic process has a defensible benefit and verified stopping controls.
Stop if recipients, commitments or sensitive content cannot be reviewed reliably, or if the assistant treats incoming instructions as authority to expand its task. A useful drafting feature can remain useful without ever gaining permission to send.
Related guides
Frequently asked questions
Is draft-only mode safe if the app has permission to send?
It is a useful workflow restriction, but do not confuse it with a technical permission boundary. The application may still hold broader account authority than the mode suggests. Check the documented scopes, settings and enforcement, and decide whether that arrangement meets your requirements. If you need a firm separation, use a tool or process whose access can be limited appropriately. Do not grant broader permissions simply because a provider describes the default behaviour as cautious. Both the account permission and the actual approval process matter when deciding whether to connect a real mailbox.
Can a human approve replies in batches?
Yes, if the reviewer can inspect every relevant message, recipient and commitment with enough attention to make approval meaningful. A batch button should not turn review into a quick glance at a summary. Use small enough batches that exceptions remain visible and pause when the messages differ from the agreed routine. Measure the review effort rather than assuming batching removes it. If volume exceeds available competent review, reduce the scope or frequency instead of approving unread drafts. The purpose of the checkpoint is judgement before sending, not merely a recorded click.
What if the assistant only sends internal emails?
Internal messages can still disclose information, create commitments or misdirect work, so evaluate their consequences rather than assuming they are harmless. A generated instruction to a colleague may affect a customer indirectly or expose information beyond its intended audience. Limit recipients and message types, and retain approval for material decisions. A fixed internal notification may be a reasonable automation candidate if its inputs and permissions are well understood. The relevant distinction is the authority and information involved, not simply whether the destination address belongs to the same organisation as the sender.
Should I let it answer messages while I am away?
Prefer a clear fixed absence message when that meets the need. It can state when you expect to return and where an urgent matter should go without interpreting each request. Do not let an assistant promise availability, refunds or decisions on your behalf merely because you are not there to review it. If an authorised colleague handles urgent cases, route them through the existing process. Automatic free-form replies need a separately justified boundary and stopping arrangement; absence is not a reason to lower the standard for messages you remain responsible for.
What should I do after an incorrect email has been sent?
Pause the workflow and establish the exact content, recipients, attachments and timing before taking further action. Follow your organisation's incident or correction process, involving the appropriate person if personal information, money or contractual commitments are affected. A clear manual correction may be needed, but its wording should reflect verified facts rather than another generated assumption. Preserve relevant evidence and avoid deleting records simply to hide the error. Once the immediate consequence is addressed, investigate why the pre-send boundary failed and keep the workflow paused until that failure has a credible remedy.
When is automatic sending worth considering?
Consider it when the message type is tightly bounded, inputs and recipients are verified, exceptions are reliably held and the consequence of an error is acceptable under an approved process. Fixed acknowledgements or narrowly defined notifications may fit better than open-ended customer replies. Compare with an existing rule-based method before adding AI. Start with synthetic tests and limited scope, document how to stop it and review changes to the provider or workflow. If a person must interpret the underlying situation to know whether the message is appropriate, keep that person in the approval path.
Sources and verification
- Google: Gmail API scopes, checked 11 September 2026 for reading, composing and sending scope definitions. No specific assistant's permissions are inferred from these examples.
- Google: manage third-party account connections, checked for connection management and previously shared information.
- The parent was read locally after public retrieval failed. Supplied internal paths are retained without independent live confirmation. The workload and timings are fictional, and no live email automation was tested.
This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.
