Мы сделали AI-оператора и начали его ломать. Сам AI оказался самой простой частью

Практические разборы автоматизации, сервисов и цифровых продуктов я собираю в Telegram — «Не по гайду». Здесь — один из таких экспериментов.

В какой-то момент у нас появилась довольно очевидная идея: сделать AI-оператора, которому можно отдать типовой бизнес-процесс. Не чат-бота, который отвечает «спасибо, ваша заявка принята», а оператора, который действительно работает: получает клиента, создаёт контакт, формирует заказ, выдаёт оплату, ждёт подтверждение, продолжает процесс, отправляет данные клиенту и фиксирует всё в CRM.

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

Один из сценариев СОВЫ выглядит примерно так:

клиент → контакт → заказ → QR для оплаты → подтверждение оплаты → резерв → письмо → CRM → SUCCESS.

Пока мы проверяем обычный сценарий, всё выглядит прекрасно: клиент написал, заказ появился, QR сгенерировался, оплата подтвердилась, резерв создался, письмо ушло, CRM получила данные. Готово. На демонстрации это уже можно красиво показать.

Но для реального бизнеса такой тест почти ничего не доказывает. Потому что настоящая проверка начинается с других вопросов: что будет, если программа закроется через секунду после оплаты? А если платёжное событие придёт дважды? Если письмо уже отправлено, а CRM в этот момент не отвечает? Если приложение перезапустилось посреди заказа? Если тестовый сервер исправен, но СОВА по ошибке примет его за production?

Вот здесь «AI-помощник» внезапно превращается в обычную инженерную задачу. И мы начали СОВУ специально ломать.

Самая опасная иллюзия в автоматизации звучит так: один раз прошло от начала до конца — значит работает.

На самом деле это значит только то, что один конкретный сценарий один раз прошёл от начала до конца. Поэтому после первого полного цикла мы начали проверять не happy path, а всё, что может пойти не так: закрывали программу во время операции, перезапускали её, повторно отправляли события, проверяли восстановление незавершённого заказа, смотрели, не отправится ли письмо дважды, не появится ли повторная запись в CRM, и отдельно проверяли, не сможет ли staging случайно притвориться production.

И именно в этот момент стало понятно, где проходит граница между красивым демо и инструментом, которому хотя бы потенциально можно доверить клиента.

Возьмём простую ситуацию. Платёжная система отправляет событие:

«Заказ №1047 оплачен».

СОВА его получает и продолжает выполнение процесса. А затем сервер по какой-то причине присылает то же самое событие повторно.

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

Для этого существует идемпотентность. Термин звучит сложнее самой идеи. Смысл простой:

Поэтому СОВА должна понимать не только «оплата пришла», но и «я уже обработала именно эту оплату?».

Отсюда получается очень простой тест для любой бизнес-автоматизации: что произойдёт, если система получит одну и ту же команду два раза подряд? Если ответ неизвестен — это уже повод тестировать.

Ещё один сценарий. Заказ создан, оплата получена, клиенту отправлено письмо. Следующий этап — запись в CRM. И ровно в этот момент программа закрывается.

После запуска есть два плохих варианта. Первый: «какой заказ? Ничего не знаю». Второй ещё веселее: «о, заказ! Давайте начнём всё заново».

Нормальный вариант третий. Система поднимает сохранённое состояние и понимает: заказ создан — выполнено; оплата получена — выполнено; письмо отправлено — выполнено; CRM — ещё нет; завершение заказа — ещё нет. И продолжает с нужного этапа.

Именно поэтому в таких системах важна не только бизнес-логика. Нужно отдельно хранить состояние процесса и историю выполненных действий. Потому что программа может закрыться, сеть может пропасть, API может зависнуть, компьютер могут просто перезагрузить.

Отдельно мы подняли внешний staging. По сути это тестовая среда, где СОВА может пройти полный сценарий, не трогая реальные production-сервисы.

И она действительно может быть полностью исправна. Backend отвечает, проверки проходят, сценарий выполняется, ready=true.

Но это всё ещё staging. А значит — тестовые данные, тестовые сценарии, нет реальных клиентов, нет реальных денег и совсем другая цена ошибки.

Поэтому СОВА отдельно проверяет окружение и не должна принимать исправный staging за настоящий Production Backend.

Для себя мы теперь довольно жёстко разделяем три состояния:

Работает — функция выполняется.

Проходит тесты — она выдерживает известные сценарии и ошибки.

Production ready — системе можно доверять реальные данные, деньги и клиентов.

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

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

Есть backend, состояния, CRM, платежи, API, вебхуки, повторные попытки, контроль доступа, логи, восстановление после сбоев, защита от повторных действий.

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

Но если под ним нет предсказуемой системы действий, получается очень умный собеседник, которому нельзя доверить даже простой заказ.

Поэтому сейчас мы всё меньше воспринимаем СОВУ как «ещё одну нейросеть». Скорее это исполнитель бизнес-процессов, у которого AI — один из инструментов.

И мне эта формулировка нравится гораздо больше.

Если бы сейчас мы начинали такой проект заново, первый вопрос звучал бы не «какую модель использовать?», а «что именно происходит с задачей от начала до конца?».

Я бы сначала разобрал процесс на семь частей.

1. Процесс. Что именно автоматизируем и где его начало и конец?

2. Состояния. В каких состояниях может находиться заказ, клиент или задача?

3. События. Что переводит процесс из одного состояния в другое: сообщение, оплата, таймер, ответ API, действие сотрудника?

4. Необратимые действия. Что нельзя безболезненно повторить: оплату, отправку, удаление, резерв, выдачу доступа?

5. Исключения. Что произойдёт, если сервис недоступен, данные неправильные или пользователь сделал что-то неожиданное?

6. Интеграции. Какие системы должны обмениваться данными: CRM, платёжка, почта, мессенджер, внутренний backend?

7. AI. И только теперь — где во всём этом действительно нужна модель?

Иногда оказывается, что нужна. А иногда обычное условие или webhook решает задачу быстрее, дешевле и надёжнее.

Чем дольше мы строим СОВУ, тем меньше меня интересует вопрос «насколько умно она разговаривает?» и тем больше другой: что произойдёт, если оставить её один на один с процессом и что-нибудь пойдёт не по плану?

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

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

И вот только когда этот фундамент появляется, сверху действительно имеет смысл ставить AI.

СОВА пока развивается, и до состояния «можно спокойно оставить её на реальных клиентах и уйти пить кофе» ещё есть дистанция. Но именно поэтому проект и оказался полезнее, чем я ожидал.

Мы начинали с идеи сделать AI-помощника. А в процессе получили гораздо более интересную задачу: построить систему, которая умеет не просто говорить, а действовать — и не разваливаться, когда реальность отклоняется от сценария.

И, кажется, именно здесь начинается настоящая автоматизация.

Если вам интересны такие разборы — без пересказа гайдов, а с реальными экспериментами, ошибками, архитектурой и выводами — продолжение публикую в Telegram:

«Не по гайду» — t.me/nepogaydu

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