Пилот ИИ проверяет один бизнес-маршрут на реальных данных и заранее заданных критериях. До разработки нужно измерить исходный процесс, собрать обычные и опасные примеры, определить права и ручные остановки. Сначала система работает на сохранённой выборке, затем в теневом режиме без внешней записи. Ограниченный рабочий запуск начинается только после проверки дублей, таймаутов и эскалаций.
Почему демонстрация не равна пилоту
Демо показывает удачный проход. Пилот должен пережить пустую карточку, неверный формат, отказ API, повтор события и вмешательство сотрудника.
В EST.EPIL ранний тестовый набор прошёл полностью. После выхода к реальным обращениям обнаружились другие ошибки: неверное понимание дат, повторные вопросы и проблемы на шаге SMS-подтверждения. Это не означало, что ранние тесты были бесполезны. Они проверяли только известные сценарии.
Шаг 1. Зафиксировать исходную точку
До автоматизации измерьте один и тот же маршрут:
- сколько ручных действий делает сотрудник;
- сколько времени проходит до результата;
- где заявка обычно застревает;
- какие ошибки уже возникают без ИИ;
- какая доля случаев требует исключения.
Без этой точки нельзя честно посчитать эффект. После запуска команда будет помнить сложные дни и забывать обычные.
Шаг 2. Собрать контрольный набор
Контрольный набор включает нормальные случаи и края. Для записи это может быть понятная услуга, неоднозначное название, дата без года, отсутствие окна, перенос и повтор запроса. Для каталога: точный товар, похожий бренд, пустое поле, конфликт цены и проданная позиция.
На каждом примере записывается ожидаемый результат и допустимая ручная ветка. Ответ «похоже разумно» не подходит для приёмки.
Шаг 3. Проверить интеграции отдельно
До агента выполните короткие технические проверки:
авторизация
→ чтение тестового объекта
→ чтение пустого результата
→ разрешённая тестовая запись
→ повтор и проверка состоянияТак отделяются проблемы прав от поведения модели. В YCLIENTS booking endpoints могли работать, а методы CRM отвечали 403, потому что техническому пользователю не хватало роли в филиале.
Шаг 4. Запустить офлайн-прогон
Система получает сохранённые входы и не касается рабочего аккаунта. Здесь проверяют маршрутизацию, формат инструментов, подтверждение фактов и причины отказа.
Ошибки группируются по уровню: данные, права, код, модель, интерфейс. Если модель выбрала неверный UUID, исправление может находиться в контракте инструмента или кодовом ограничении, а не в длинном промте.
Шаг 5. Включить теневой режим
Агент видит живое событие и готовит действие, но отправка заблокирована на уровне транспорта. Сотрудник продолжает обычную работу, а команда сравнивает решения.
Важно, чтобы блокировка находилась в нижнем уровне. В DOLOROSA тестовый entrypoint однажды пропустил сообщения в рабочую Telegram-группу. После этого dry-run добавили в сам транспорт, а не только в запускающий скрипт.
Шаг 6. Ограничить рабочий запуск
Разрешите один канал, одну группу операций или небольшое окно времени. Назначьте человека, который видит эскалации. Сохраните кнопку остановки и возможность вернуться к ручному маршруту.
Для необратимых операций оставьте подтверждение. В обработке фотографий генерация и подготовка идут автоматически, но публикация в карточку требует review.
Критерии приёмки
Критерии зависят от процесса, но каждый должен проверяться по журналу:
- доля завершённых целевых действий;
- доля правильных эскалаций;
- число дублей;
- число неподтверждённых фактов в отправленных ответах;
- время от события до результата;
- ручное время на один случай;
- стоимость API и инфраструктуры на единицу работы.
Целевые значения утверждаются до запуска. Мы не переносим тестовые проценты из одного проекта в другой.
Решение после пилота
Пилот может закончиться автоматическим режимом, ассистентом с подтверждением или отказом от модели в пользу обычного правила. Все три результата нормальны, если они подтверждены данными.
Geron Labs готовит карту пилота из одного реального процесса. Она включает контрольный набор, точки интеграции, критерии и границы ручного решения.