Может ли ИИ сам отправлять письма клиентам: где нужен человек

ИИ можно разрешить отправлять письма самостоятельно, но не все типы и не сразу. Автоматическая отправка оправдана для конкретных типов сообщений, где последствия ошибки незначительны и ее легко проверить правилами: подтверждение получения заявки, напоминание о записи, статус заказа из учетной системы. Письма с новыми условиями, деньгами, договорами, персональными данными или ответом на жалобу следует показывать человеку до отправки.

Главное условие: контроль должен происходить до того, как письмо ушло, и касаться именно того текста, адресата и вложений, которые пойдут клиенту. Согласование «в целом» или проверка после отправки не защищают от ошибки. После этой статьи вы сможете разложить свои письма по риску, решить, где достаточно шаблона, а где нужна подпись работника, и составить план постепенного расширения полномочий ИИ.

Три режима работы: черновик, согласованная отправка, автоматическая отправка

Вопрос «может ли ИИ отправлять письма» звучит как выбор между «да» и «нет». На практике есть как минимум три режима, и в одной компании они сосуществуют для разных типов сообщений.

Черновик. ИИ готовит текст, но не имеет доступа к отправке. Работник открывает черновик в своей почтовой программе или CRM, редактирует и отправляет сам. Это самый безопасный старт: модель не может ничего отправить даже из-за ошибки или манипуляции входящим письмом. Польза от ИИ здесь в скорости подготовки, а не в автономности.

Согласованная отправка. ИИ готовит письмо и предлагает его к отправке, но кнопку «отправить» нажимает человек или система ждет его явного подтверждения. Отправляет уже не человек вручную, а система, но только после согласования конкретного сообщения.

Автоматическая отправка по разрешенному сценарию. Для заранее описанного типа письма система отправляет письмо без участия человека. Важно: разрешение выдается не модели вообще, а сценарию. Например, «подтверждение получения заявки по утвержденному шаблону с подстановкой номера заявки из CRM». Если модель решила добавить в такое письмо обещание скидки, это уже другой сценарий, и автоматического разрешения на него нет.

Один и тот же ассистент может работать во всех трех режимах в зависимости от типа письма. Поэтому решение принимается не об инструменте, а о каждом классе сообщений в отдельности.

Матрица рисков для писем: что автоматизировать, а что согласовывать

Риск письма определяется тем, что произойдет, если в нем будет ошибка. Письмо «мы получили вашу заявку» с неправильным номером вызовет уточняющий вопрос. Письмо «вернем деньги завтра», отправленное без полномочий на такое решение, создает обязательство, которое компания может не выполнить, и конфликт с клиентом.

Ниже обучающая матрица. Это редакционный пример политики, а не готовое разрешение отправлять конкретные письма в вашей компании. Границы для своего бизнеса определяете вы вместе с юристом там, где речь идет о договорах и персональных данных.

Обратите внимание на две последние строки. Скидка требует не только проверка текста человеком, но и серверной проверки, разрешена ли она вообще. А повтор после таймаута вообще не является вопросом содержания письма: это вопрос того, не отправили ли вы его уже.

Что проверять перед отправкой

Перед отправкой нужно проверить несколько отдельных условий. Одни из них проверяет код, другие — человек, но ни одно не следует оставлять на усмотрение модели.

Адресат. Принадлежит ли адрес именно тому клиенту, о котором письмо? Ошибка в подстановке может выслать счет или договор другому человеку. Самое простое правило: получатель берется из карточки клиента в CRM по его идентификатору, а не из сгенерированного моделью текста.

Вложения. Это нужный файл? Относится ли он к этому клиенту? Актуальна ли версия документа? Модель не должна сама выбирать файлы из общей папки.

Факты. Совпадают ли суммы, даты, номера заказов и условия с данными учетной системы? Цифры в письме должны поступать из системы, а не из памяти модели.

Полномочия. Имеет ли право тот, от чьего имени идет письмо, обещать то, что там написано? Возврат средств, компенсация, особая цена требуют роли с таким правом.

Основание для связи. Можно ли вообще писать этому человеку по этому каналу? Не отказалась ли она от рассылки? Это юридический и коммерческий вопрос, и он не решается тем, что работник нажал «одобряю». Согласование текста человеком и законность самого контакта — разные вещи.

Текущий статус клиента. Не изменилось ли что-то, пока письмо ожидало в очереди? Заказы могли отменить, жалобу могли уже решить другим каналом, а клиент мог попросить больше не писать.

Доставляемость — отдельный вопрос. Для писем на личные аккаунты Gmail всем отправителям нужны аутентификация SPF или DKIM, корректные прямые и обратные DNS-записи, TLS и уровень жалоб на спам ниже 0,3%. Если отправитель доставляет на Gmail более 5 000 писем в день, необходимы и SPF, и DKIM, запись DMARC и совпадение домена в поле From с доменом SPF или DKIM. Для маркетинговых писем и писем по подписке таких массовых отправителей нужна отписка в один клик. Одобрение человеком не гарантирует доставку, а настроенный домен не гарантирует правильность содержания письма. Это три отдельные проверки: содержание, право на контакт и техническая готовность отправителя.

Как организовать согласование, чтобы оно имело смысл

Согласование имеет смысл только тогда, когда человек видит и подтверждает то, что пойдет клиенту. Плохо устроенное согласование превращается в ритуал: сотрудник нажимает «да» после просмотра краткого резюме, а отправляется другой текст.

Минимальные требования к экрану:

• полный текст письма, а не резюме или первые строчки;
• точный адресат, включая копии и скрытые копии;
• перечень вложений с возможностью открыть каждый файл;
• происхождение фактов: откуда взяли сумму, дату, номер заказа;
• причина, по которой письмо отправлено на согласование, например «содержит обещание возврата средств».

Самое важное правило: согласование привязывается к конкретной версии письма. Технически это можно сделать следующим образом: система вычисляет отпечаток (хэш) от адресата, текста и вложений и сохраняет его вместе с решением человека. Перед отправкой отпечаток рассчитывается еще раз. Если после согласования изменилось хоть что-нибудь, например модель «улучшила» формулировку, добавила вложение или изменила адресата, отпечаток не совпадает, и письмо возвращается на новое согласование.

Например, в LangGraph interrupt приостанавливает граф и ждёт ответа человека. Чтобы возобновить выполнение с сохранённого состояния, нужны настроенный checkpointer и тот же thread_id. После возобновления узел запускается с начала, поэтому код до interrupt выполнится повторно. Поэтому побочные эффекты следует размещать после согласования или делать идемпотентными.

Как ограничить автоматизацию: лимиты, журнал, устранение дублей и остановка

Даже для разрешенного сценария автоматическая отправка требует предохранителей. Три отдельные причины вреда: избыточные функции, избыточные права и избыточная автономность. Каждую из них можно ограничить.

Минимально необходимые функции и права. Если ассистенту нужно только читать почту и готовить черновики, ему не следует предоставлять право отправки. Например, расширение для создания сводок по письмам не должно уметь их отправлять. Права на уровне почтового сервиса следует ограничивать так же, а не надеяться, что модель не захочет.

Проверка разрешений вне модели. Решение, разрешено ли действие, должно принимать код в системе, которая получает запрос, а не сама модель. Если сценарий позволяет только шаблон «заявку получили», сервер отклоняет любой другой текст.

Лимиты. Ограничьте количество писем в час, на одного клиента и в целом. Ограничение частоты не предотвращает ошибку, но уменьшает ущерб и даёт время её заметить.

Журнал. Для каждого письма сохраняйте: идентификатор операции, сценарий, версию шаблона, адресата, хэш содержимого (или правило, по которому письмо пошло автоматически), время и ответ почтового сервиса.

Дедупликация и таймауты. Это место, где чаще всего возникают дубликаты. Система вызвала отправку, ответ не пришел из-за таймаута, и код повторяет вызов. Но таймаут не означает, что письмо не отправлено: оно могло уйти, а ответ потерялся. Правильный порядок: каждая отправка имеет уникальный идентификатор операции; перед повтором система проверяет, подтвержден ли результат для этого идентификатора; повтор происходит только тогда, когда известно, что предыдущая попытка не удалась.

Остановка и отзыв доступа. Должна быть кнопка или переключатель, который мгновенно отключает автоматическую отправку для сценария или всей системы. Также нужна процедура отзыва ключей доступа к почте, если что-то пошло не так. Решите заранее, кто имеет право нажать стоп.

Когда расширять полномочия

Расширение полномочий ИИ следует производить на основании данных, а не ощущения, что «уже работает нормально». Разумная последовательность выглядит следующим образом.

Этап наблюдения. ИИ готовит черновики, а письма отправляют люди. Вы собираете статистику: сколько черновиков отправили без изменений, сколько с незначительными правками, сколько переписали полностью. Считайте отдельно для каждого типа письма.

Этап отправки с согласованием. Для типов писем, где черновики редко нуждаются в существенных поправках, включаете отправку после согласования. Теперь видно, сколько времени уходит на согласование и какие ошибки ловят люди.

Этап ограниченной автоматизации. Для узкого сценария с шаблоном и данными из системы включаете автоматическую отправку. Оставляете выборочную проверку уже отправленных писем, например, ежедневную проверку случайной выборки, чтобы заметить дрейф.

Критерии перехода между этапами зависят от типа письма. Для каждого сравнивайте стоимость ручной проверки (количество писем × время на согласование × стоимость рабочего часа) с ожидаемой общей стоимостью ошибок, которые дойдут до клиента (количество писем × вероятность, что ошибка пройдет оставшиеся проверки × ожидаемые последствия такой ошибки). Доля ошибок, найденных людьми при согласовании, не показывает, сколько ошибок пропустят автоматические проверки. Если вероятность такого сбоя пока неизвестна, не отменяйте согласование: сначала оцените остаточный риск в тестовом или контролируемом пилоте. Если ошибка может стоить договора или клиента, даже небольшая вероятность может перевесить экономию времени.

Учебный пример на условных числах: команда отправляет 400 писем «статус заказа» в месяц, а согласование одного занимает две минуты — это около 13 часов (400 × 2 = 800 минут). Если при согласовании сотрудники исправили существенные ошибки в 2 письмах из 400, это показывает, что выявила человеческая проверка, но не оценивает долю ошибок, которые пройдут автоматические проверки. Прежде чем убирать согласование, измерьте остаточные ошибки в тестовом или контролируемом пилоте; выборочная проверка уже отправленных писем не заменяет проверки до отправки. Для писем с договором и ценой учитывайте также возможный ущерб от одной ошибки. Используйте собственные данные о времени, выявленных и пропущенных ошибках и их последствиях.

Полномочия можно и сужать. Если после изменения шаблона, модели или правил количество ошибок выросло, возвращайте сценарий на предыдущий этап и проверяйте снова.

Вывод: что сделать в своем процессе

1. Составьте список типов писем, которые сейчас посылает ваша команда клиентам.
2. Для каждого типа опишите, что произойдет в случае ошибки, и распределите по трем режимам: черновик, согласованная отправка, автоматическая отправка.
3. Определите владельца решения для каждого типа и что именно записывается в журнал.
4. Установите экран согласования с полным текстом, адресатом, вложениями и происхождением каждой цифры; свяжите согласование с хэшем содержимого.
5. Заберите у ИИ права, которые не требуются для текущего режима, и перенесите проверку разрешений в серверную логику.
6. Присвойте каждой отправке уникальный идентификатор и проверяйте ее состояние перед повтором после таймаута.
7. Проверьте отдельное основание для связи с клиентом и техническую готовность домена отправителя.
8. Начните с наблюдения, считайте правки по типам писем и расширяйте полномочия только там, где данные это подтверждают.

Часто задаваемые вопросы