7 ошибок production AI-агентов и handoff человек↔агент

Большинство AI-агентов «ломаются» не на демо, а в production: из-за размытого handoff человек↔агент, отсутствия stop-list, слепых KPI и знаний без владельца — не из-за «слабой модели».

Ниже — семь ошибок, которые я чаще всего разбираю после go-live, и как их закрывать. Фокус на поддержке, квалификации лидов и внутренних ops-агентах. Цифры — порядок величины из пилотов 2025–2026, не обещание «вам будет так же».

---

Ошибка 1. Агент без чёткой границы ответственности

Симптом: бот отвечает «обо всём», потом уверенно врёт в edge-кейсе.

Плохо	Норма
«Помощник по любым вопросам»	Scope = топ-N тем + явный out-of-scope
Модель сама решает, когда звать человека	Правила эскалации + stop-list
Нет списка запрещённых действий	Деньги, юр. обещания, смена договора — только человек

Правило: агент — исполнитель процесса, не «универсальный сотрудник». Чем шире scope без данных, тем выше hallucination rate.

---

Ошибка 2. Handoff = «перекинуть в чат» без контекста

Если оператор получает пустой «клиент написал», handoff вреден: человек тратит время на раскопки, клиент повторяет историю.

Минимальный пакет эскалации

• Полная история диалога (не последний реплик)
• Определённый intent и почему эскалация
• Что агент уже пообещал / какие данные собрал
• ID клиента / заказа / тикета в CRM
• Рекомендованный next step для человека (не обязательно верный, но структурированный)
• Приоритет (VIP, деньги, жалобы, срок SLA)

Метрика handoff	Target после настройки
% эскалаций «не туда»	<12–15%
Время до первого ответа человека после эскалации	по SLA, не «когда заметили»
Повтор «расскажите ещё раз»	→ 0 в идеале

---

Ошибка 3. KPI только «% закрыл бот»

Автозакрытие без качества — ловушка. Агент может «закрывать» диалоги отписками.

KPI	Зачем
% автозакрытия в scope	ёмкость
CSAT / оценка по закрытым ботом	качество
Reopen rate за 48–72 ч	ложные закрытия
Hallucination / factual error rate	доверие
Cost per resolved dialog	экономика
% эскалаций с полным контекстом	зрелость handoff

В пилотах я закладываю: автозакрытие 40–60% в узком scope при CSAT ≥ baseline и reopen не хуже ручного режима. Если автозакрытие 80%, а reopen взлетел — это не успех.

---

Ошибка 4. Знания «залили PDF» и забыли

Production умирает от устаревших карточек: новый тариф, старый ответ.

Владение знаниями

Роль	Ответственность
Owner процесса	что правда, что можно обещать
Редактор базы	карточки, версии, даты
Оператор/тимлид	сигнал «ответ устарел» из смены
Разработчик	не единственный, кто «правит промпт»

Чеклист:

• У каждой карточки источник и дата ревизии
• Канал алерта: «ответ неверный» → тикет на базу за 24–48 ч
• Freeze критичных формулировок (оферта, возврат, гарантия)
• Rollback на предыдущую версию базы

---

Ошибка 5. Нет теней и логов — только «в проде посмотрим»

Без shadow-mode и логов вы не отличите баг сценария от бага модели.

Минимум наблюдаемости:

1. Лог input/output + tool calls (с маскированием ПДн).
2. Разметка 15–25 диалогов в день первую месяц.
3. Алерты: spike эскалаций, latency, cost, пустые tool-ответы.
4. Еженедельный отчёт: топ fail-intent’ов.

Сигнал	Что проверять первым
Рост эскалаций	дыра в знаниях / новый intent
Падение CSAT	overconfident тон, вранье, петли
Рост cost/dialog	лишние tools, длинный контекст, ретраи
Latency	внешние API, тяжёлые tools

---

Ошибка 6. Агент меняет мир без подтверждения

Списание, смена статуса заказа, отмена, скидка, публикация ответа клиенту «в никуда» — опасная зона.

Действие	Рекомендация
Ответ FAQ	авто, если в базе
Создание тикета	авто
Смена статуса / возврат денег	human-in-the-loop или жёсткий policy engine
Исходящее обещание срока/цены	только из системы-источника, не «из головы»

Handoff здесь — фича, не слабость. Лучше 10 честных эскалаций, чем один «агент отменил заказ не тому».

---

Ошибка 7. После go-live — бесконечный scope creep

«Раз бот работает, пусть ещё продаёт, ещё WhatsApp, ещё 1С». Через две недели нельзя понять, что сломалось.

Freeze на 14 дней после production

• Не добавляем каналы и upsell.
• Чиним только fail-кейсы из логов.
• Фиксируем baseline KPI.
• Backlog v2 — отдельно, с оценкой риска.

Фаза	Можно	Нельзя
Пилот	узкий scope, A/B	«сразу вся компания»
Go-live + 14 дн.	багфиксы знаний	новые процессы
v2	второй процесс / канал	без нового baseline

---

Чеклист handoff человек↔агент (сводка)

• Явный scope и out-of-scope
• Stop-list действий и тем
• Триггеры эскалации (intent, confidence, keywords, $$, VIP)
• Пакет контекста для оператора
• SLA ответа человека и владельцы смены
• Логи + еженедельный разбор fail
• Owner базы знаний
• Freeze 14 дней после go-live

---

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

Сколько эскалаций — это нормально?

Для first-line FAQ после настройки часто 35–60% остаётся у людей, если scope узкий и честный. «Почти 0 эскалаций» на широком scope — красный флаг: агент либо не берёт сложное, либо закрывает мусором.

Нужен ли отдельный «оператор надзора»?

На первые 30–60 дней production — да, хотя бы 0,2–0,5 FTE: разбор логов, правка карточек, обучение смены handoff. Потом можно снизить.

Модель или процесс — что чинить первым?

Сначала процесс, знания, tools и handoff. Смена модели без логов и stop-list почти никогда не лечит systemic errors.

Чем handoff отличается от «просто напишите оператору»?

Handoff — это протокол: когда, с каким контекстом, с каким SLA и кто owner. «Напишите оператору» без пакета — это потерянное время обеих сторон.

---

Читайте также

• Внедрение AI-агента за 90 дней: этапы, цифры и процесс
• Кейс: автоматизация отдела поддержки за 30 дней
• Оркестрация AI-агентов для бизнеса

---

🚀 Агент в проде «сыпется» на эскалациях и качестве?
Разберу логи, handoff и KPI, соберу stop-list и протокол передачи человеку — чтобы production перестал быть вечным пилотом.

Заказать консультацию — raisovich.ru

Почему AI-агенты чаще ломаются в production, а не на демо?

Из-за размытого handoff, отсутствия stop-list, слепых KPI и устаревших знаний — а не из-за «слабой модели» на демо.

Какой минимальный пакет нужен при эскалации человеку?

Полная история диалога, intent и причина эскалации, что уже пообещали, ID в CRM, приоритет и рекомендованный next step для оператора.

Зачем freeze scope на 14 дней после go-live?

Чтобы зафиксировать baseline KPI и чинить только fail-кейсы из логов, а не расползаться по новым каналам и upsell, пока непонятно, что сломалось.