Запустить ассистента - это вообще то не очень сложная задача. НО ! Важно сделать так, чтобы его не пришлось вырубать в панике после первого же фейла. С AI-фичами нужно жить как с любым продовым сервисом: логи, версии, фича-флаги, аварийный план, а не вера в “ну модель же умная, справится”.
Что логировать обязательно
Если ассистент работает “сам по себе” и у тебя нет логов - это не магия, а мина замедленного действия . Нормальная эксплуатация начинается с того, что любой диалог можно восстановить и понять, почему ассистент ответил именно так, без утечки персональных данных.
Минимальный набор, который надо писать с первого дня:
• Входящий запрос: текст, язык, канал (чат, звонок, виджет), ID пользователя или сессии. PII (телефон, email, реквизиты) или не логируем вообще, или жёстко маскируем.
• Ответ ассистента: полный текст, выбранная модель, версия промпта или сценария, включённые фичи (RAG, инструменты, внешние API), окружение (prod/stage), чтобы было понятно, где накосячили - промпт, модель или интеграция.
• Оценки и фидбек: ручные пометки менеджеров (“ок/не ок”, тип ошибки) плюс реакции клиентов (лайк/дизлайк, NPS, “полезно/нет”) как сырьё для дообучения и правки сценариев; перед дообучением хорошо бы анонимизировать диалоги.
Дополнительно сильно упростят жизнь:
• Теги и классификация: тема, продукт, сегмент клиента - по этим срезам хорошо видно, где ассистент реально помогает, а где только имитирует бурную деятельность.
• Техметрики: время ответа, токены, ошибки внешних API, доля фолбэков на человека, error rate по сценариям - помогают отличить “ассистент тупит” от “упала CRM/телефония/платёжка”.
Как быстро откатить опасный релиз
С более менее сложной AI системой нельзя жить по принципу “если что - потом поправим”, потому что “потом” обычно наступает в пятницу вечером. Нужна нормальная дисциплина релизов: версионирование сценариев, фича‑флаги, kill switch и понятная процедура отката.
Что должно быть в базовом аварийном плане:
Версионирование промпта и сценариев
• Каждое изменение - отдельная версия: v1, v1.1, v2 и так далее, с датой релиза, тем, кто выкатывал, и описанием, на какую долю трафика оно уехало.
• Для каждой версии фиксируй, какие метрики считаются нормой и по каким принимается решение “оставляем” или “откатываем”.
• Ключевое требование: возможность за 1-2 клика вернуться к последней стабильной версии через конфиги или фича‑флаг, без перекомпоновки пайплайна и правок в коде.
Фича‑флаги и kill switch
• Ассистент должен быть обёрнут в фича‑флаг с раздельным включением по каналам (сайт, телега, голос, админка) и сегментам (новые, текущие, внутренние).
• Нужен глобальный kill switch, который одним действием отключает ассистента от боевых пользователей и переводит их либо на старый бот, либо сразу на менеджера.
• Хорошая практика - завязать kill switch на алерты по SLA и ошибкам, чтобы при превышении порогов можно было автоматически или полуручными действиями погасить фичу.
Ручной дубль критичных функций
• Всё, что трогает деньги, договоры, статусы заказов, блокировки, должно иметь прописанный ручной сценарий‑двойник.
• Если ассистент начинает портить данные (тарифы, суммы, сроки, статусы), должна быть готовая процедура перевода этих операций в ручной режим, оставив ассистенту только консультативные ответы.
Три красных флага, когда ассистента надо вырубать
Есть ситуации, когда “подождём недельку, он дообучится” - это путь к юридическому или репутационному суициду. Нормальный аварийный план включает формализованные триггеры отключения ассистента с порогами метрик и понятными действиями.
Три жёстких красных флага:
1.Риск для денег и юридической ответственности
• Ассистент даёт неверные суммы, сроки, обещает скидки и условия, которых нет в реальных офертах.
• Пользователи начинают ссылаться на его ответы в претензиях и официальных обращениях.
В этот момент ассистента надо отправлять в песочницу, а все финансовые и юридические вопросы возвращать людям, пока не появятся жёсткие ограничения в промпте и пост‑проверка критичных ответов.
2.Безопасность и приватность
• Ассистент “сливает” данные одного клиента другому или начинает показывать личные данные, которые не должны светиться.
• В ответах появляются телефоны, email, реквизиты, полные номера карт и прочие вещи, за которые прилетают не только жалобы, но и регуляторы.
Это уже полноценный инцидент, который нужно фиксировать, расследовать и закрывать отдельным набором мер, а ассистента в проде временно глушить.
3.Системное падение качества, которое бьёт по бизнесу
• В тикетах и чате растёт доля жалоб “бот не помогает”, “бот тупит”, “сразу зовите менеджера”
• Увеличивается время решения заявок или падает конверсия на этапах, где ассистент задействован
• В логах видно, что он часто галлюцинирует и уходит от регламентов и базы знаний.
В этом случае имеет смысл временно вернуть людей в ключевые точки, ассистента оставить на задачах с низкой ценой ошибки и пересобрать сценарии и промпты по фактическим данным.
Что должно быть в PDF/Notion‑шаблоне аварийного плана
Под всё это лучше собрать один нормальный артефакт - “План внедрения AI‑ассистента с аварийным выходом”, чтобы при первом же инциденте команда не устраивала мозговой штурм на голом поле. Готовый шаблон можно положить в Notion или сделать компактный PDF и раздать всем, кто имеет доступ к промптам и настройкам.
В шаблоне должны быть блоки:
• “Что логируем”: список полей по диалогу, оценкам и техметрикам, плюс ссылки, где смотреть эти данные (BI, ClickHouse, отчёты), с пометкой, какие поля маскируются или вообще не пишутся
• “Процедура релиза”: кто и как выкатывает новую версию ассистента, как включается фича‑флаг, какие метрики считаются нормой, через сколько времени после релиза принимается решение “оставить/откатить” и какие схемы rollout’а используются (процентный, канареечный и так далее)
• “Аварийный выход”: кто принимает решение отключить ассистента, какие флаги дёргаются и в каком порядке, какие каналы коммуникации используются (чат инцидентов, рассылка менеджерам, сообщения пользователям), плюс чек‑лист возврата на предыдущий сценарий и проверки, что система стабилизировалась.
Что тебе сделать дальше
Если ассистент уже живёт в проде — просто собери команду на один созвон и по этому чек‑листу набросайте свой аварийный план, без красоты, но с конкретикой под ваш стек. Потом это можно аккуратно упаковать в Notion или PDF и показывать каждому, кто лезет менять промпт или настройки ассистента.
А дальше можно разбирать реальные кейсы в комментах или в телеге: какой канал, какая модель, какие грабли уже поймали - под это как раз хорошо допиливается рабочий чек‑лист под твой боевой контур