Чи може ШІ сам надсилати листи клієнтам: де потрібна людина

ШІ можна дозволити надсилати листи самостійно, але не всі й не одразу. Автоматична відправка виправдана для конкретних типів повідомлень, де помилка коштує мало і її легко перевірити правилами: підтвердження отримання заявки, нагадування про запис, статус замовлення з облікової системи. Листи з новими умовами, грошима, договорами, персональними даними чи відповіддю на скаргу варто показувати людині до відправки.

Головна умова: контроль має відбуватися до того, як лист пішов, і стосуватися саме того тексту, адресата й вкладень, які підуть клієнту. Погодження «загалом» чи перевірка після відправки не захищають від помилки. Після цієї статті ви зможете розкласти свої листи за ризиком, вирішити, де достатньо шаблону, а де потрібен підпис працівника, і скласти план поступового розширення повноважень ШІ.

Три режими роботи: чернетка, погоджена відправка, автоматична відправка

Питання «чи може ШІ надсилати листи» звучить як вибір між «так» і «ні». На практиці режимів щонайменше три, і в одній компанії вони співіснують для різних типів повідомлень.

Чернетка. ШІ готує текст, але не має доступу до відправки. Працівник відкриває чернетку у своїй поштовій програмі чи CRM, редагує й надсилає сам. Це найбезпечніший старт: модель не може нічого відправити навіть через помилку чи маніпуляцію вхідним листом. Користь від ШІ тут у швидкості підготовки, а не в автономності.

Погоджена відправка. ШІ готує лист і пропонує його до відправки, але кнопку «надіслати» натискає людина або система чекає її явного підтвердження. Відправляє вже не людина вручну, а система, проте лише після погодження конкретного повідомлення.

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

Один і той самий асистент може працювати в усіх трьох режимах залежно від типу листа. Тому рішення приймається не про інструмент, а про кожен клас повідомлень окремо.

Матриця ризику листів: що автоматизувати, а що погоджувати

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

Нижче навчальна матриця. Це редакційний приклад політики, а не готовий дозвіл надсилати конкретні листи у вашій компанії. Межі для свого бізнесу визначаєте ви, разом із юристом там, де йдеться про договори та персональні дані.

Зверніть увагу на два останні рядки. Знижка потребує не тільки людського погляду на текст, а й серверної перевірки, чи дозволена вона взагалі. А повтор після таймауту взагалі не є питанням змісту листа: це питання того, чи не відправили ви його вже.

Що перевіряється до відправки

Перевірка перед відправкою складається з кількох окремих питань. Деякі з них вирішує код, деякі людина, але жодне не варто залишати моделі.

Адресат. Чи належить адреса саме тому клієнту, про якого лист? Помилка в підстановці може відправити рахунок чи договір іншій людині. Найпростіше правило: адресат береться з картки клієнта в CRM за ідентифікатором, а не з тексту, який згенерувала модель.

Вкладення. Чи те саме вкладення, яке має бути? Чи стосується воно цього клієнта? Чи актуальна версія документа? Модель не повинна сама обирати файли з загальної папки.

Факти. Чи збігаються суми, дати, номери замовлень і умови з даними облікової системи? Цифри в листі мають надходити з системи, а не з пам’яті моделі.

Повноваження. Чи має право той, від чийого імені йде лист, обіцяти те, що там написано? Повернення коштів, компенсація, особлива ціна потребують ролі з таким правом.

Підстава для зв’язку. Чи можна взагалі писати цій людині цим каналом? Чи не відмовилася вона від розсилки? Це юридичне й комерційне питання, і воно не вирішується тим, що працівник натиснув «погоджую». Погодження тексту людиною і законність самого контакту є різними речами.

Поточний статус клієнта. Чи не змінилося щось, поки лист чекав у черзі? Замовлення могли скасувати, скаргу могли вже вирішити іншим каналом, а клієнт міг попросити більше не писати.

Окремо перевіряйте технічну доставлюваність. Для листів на особисті Gmail-акаунти всім відправникам потрібні автентифікація SPF або DKIM, коректні прямі й зворотні DNS-записи, TLS і рівень скарг на спам нижче 0,3%. Якщо відправник надсилає понад 5 000 листів на день на Gmail, потрібні 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. Почніть зі спостереження, рахуйте правки за типами листів і розширюйте повноваження лише там, де дані це підтверджують.

Часті запитання