Рабочего ИИ-агента от демонстрации отличают три контура вокруг модели. Первый решает, откуда берутся факты: агент отвечает только по найденным фрагментам ваших документов и прикладывает ссылку на источник. Второй решает, чего агент не сделает никогда: список запретных тем и действий, лимиты на суммы, скидки и сроки, белый список доступных инструментов — всё это живёт в коде, а не в тексте промпта. Третий решает, как вы об этом узнаете: журнал каждого диалога, выборочная проверка и автоматические сигналы на события, которые требуют вмешательства в тот же день.
Порядок не случайный. Первый контур убирает основную массу выдумок, второй закрывает то, что дорого стоит деньгами и репутацией, третий показывает, работают ли первые два через два месяца после запуска. В соседнем материале раздела те же средства перечислены как четыре инженерных приёма — здесь они сгруппированы иначе, по признаку «кто это обслуживает»: первый контур ведёт методист, второй — инженер, третий — операционный руководитель.
Дальше по каждому контуру: что он ловит, что не ловит, как проверить его включённость своими руками и во что он обходится в часах на старте и в часах ежемесячно. Все суммы — модельный расчёт на прозрачных ставках: инженер 3 000 ₽/час, методист базы знаний 900 ₽/час, оператор 700 ₽/час, руководитель 2 500 ₽/час. Это не прайс, а арифметика, которую можно пересчитать под свои цифры.
Что ловит каждый контур: таблица «риск — контур»
Полезно начать с распределения рисков, а не с описания технологий: тогда становится видно, что контуры не дублируют друг друга и убрать любой из них означает открыть конкретный класс происшествий. Таблица ниже — тот минимум, который мы разбираем с заказчиком до сметы.
| Риск | Как выглядит в жизни | Ловит контур | Что будет без него |
|---|---|---|---|
| Выдуманный факт | Агент называет несуществующий пункт регламента или характеристику товара, которой нет в карточке | 1 — ответ только по базе знаний | Клиент действует по несуществующему правилу и оказывается прав: ответ дан от лица компании |
| Обещание денег | Названа скидка, обещан возврат, подтверждена компенсация | 2 — лимиты в коде | Обещание придётся исполнить или объяснять клиенту, что ваш ассистент ошибся |
| Обещание срока | Назван срок доставки или выполнения работ, не подтверждённый данными из системы | 2 — лимиты в коде | Сорванное ожидание, отмена заказа, в опте — претензия по договору |
| Действие в чужой системе | Агент меняет заказ, отменяет запись, выставляет счёт, правит карточку клиента | 2 — белый список инструментов | Ошибочные операции в учёте, которые обнаруживаются при сверке через недели |
| Уход в постороннюю тему | Разговор о политике, здоровье, чужих компаниях, советы вне компетенции | 2 — стоп-темы | Публикуемые скриншоты, из которых складывается позиция компании по вопросам, которых она не касалась |
| Медленная деградация | Поменялся прайс или регламент, агент продолжает отвечать по-старому | 3 — журнал и выборочный контроль | Качество плывёт незаметно, узнаёте из жалобы на третий-четвёртый месяц |
| Целенаправленная манипуляция | Клиент подбирает формулировки, чтобы получить выгодное обещание или обойти правило | 2 предотвращает, 3 обнаруживает | Приём расходится по форумам и превращается в поток однотипных обращений |
Заметно, что второй контур закрывает больше всего строк, но именно его чаще всего заменяют вежливой формулировкой в промпте, потому что так дешевле и быстрее. И заметно, что третий контур не предотвращает ничего — он только показывает. Ниже разберём, почему без него первые два всё равно перестают работать.
Три вложенных прямоугольника. В центре блок «Модель». Внутренний контур подписан «1. База знаний и ссылка на источник», к нему выносками привязан риск «выдуманный факт». Средний контур «2. Ограничители в коде» — выноски «обещание денег», «обещание срока», «действие в системе», «посторонняя тема». Внешний контур «3. Журнал и контроль» — выноски «деградация», «манипуляция». Сбоку колонка «кто обслуживает»: методист, инженер, руководитель.
Контур 1. Ответ только по базе знаний со ссылкой на источник
Механика простая. Вопрос клиента сначала уходит не в модель, а в поиск по вашим документам: регламентам, прайсам, описаниям услуг, накопленным ответам поддержки. Поиск возвращает несколько фрагментов, и только они вместе с инструкцией «отвечай строго по приведённым фрагментам, ничего не добавляй» передаются модели. К ответу прикладывается ссылка: название документа, редакция, номер пункта. Клиент видит её в чате, оператор — в журнале.
Главное здесь не поиск, а поведение при пустом результате. Если релевантных фрагментов не нашлось, ответа быть не должно вообще: система пишет, что уточнит, и передаёт вопрос человеку. Именно эта строчка кода отличает контур от его имитации. Мы регулярно видим внедрения, где поиск настроен, ссылки прикладываются, а при пустом результате модель всё равно отвечает — потому что запрет на ответ никто не поставил, а разработчику показалось невежливым отказывать клиенту.
Основная работа в первом контуре — не программирование, а подготовка документов, и её объём владельцы обычно недооценивают. Регламент на 40 страниц в формате «сплошной текст с приложениями» нужно разрезать на фрагменты по смыслу, а не по количеству символов: один фрагмент — одно правило целиком, вместе с исключениями, иначе агент найдёт правило и не найдёт исключение к нему. К каждому документу привязываются редакция, дата и владелец на вашей стороне. Отдельно собирается словарь: как клиенты называют то, что у вас в документах называется иначе — «минимальная партия» против «отгрузка от», «предоплата» против «авансовый платёж», народные названия артикулов. В модельном проекте на 150 страниц это 26 часов, и почти все они уходят на разбор документов, а не на код.
Чего первый контур не закрывает. Он не спасает от устаревшего документа: если в базе лежит февральская редакция условий отгрузки, агент честно процитирует её со ссылкой, и формально всё будет правильно. Он не спасает от промаха поиска: если клиент спросил «минимальная партия», а в документе написано «отгрузка от», поиск может вернуть пустоту там, где ответ есть. И он не имеет отношения к обещаниям денег: агент может добросовестно процитировать пункт про скидки и тут же самостоятельно применить его к случаю, к которому пункт не относится. Для этого есть второй контур.
Схема слева направо: «Вопрос клиента» → «Поиск по документам» → ромб «Найдены релевантные фрагменты?». Ветка «да» ведёт в блок «Модель отвечает строго по фрагментам» → «Ответ + ссылка на источник». Ветка «нет» ведёт вниз в блок «Ответа не даём: уточню» → «Передача человеку с историей диалога». Ветка «нет» выделена и подписана «эта стрелка и есть контур».
Как проверить, что первый контур действительно включён
Проверка занимает пятнадцать минут и не требует технических знаний. Достаточно доступа к тому же чату, который показывает подрядчик, — все четыре теста делаются со стороны клиента.
- 1Спросите про заведомо несуществующий товар с правдоподобным названием. Правильный ответ — «не нашёл, уточню у сотрудника». Развёрнутое описание характеристик означает, что запрета на ответ при пустом поиске нет.
- 2Спросите содержание пункта договора с заведомо неверным номером. Агент должен сказать, что такого пункта нет, а не пересказать соседний.
- 3Откройте ссылку из любого фактического ответа. Она должна вести в конкретный документ с конкретной редакцией. Ссылка на раздел сайта или на «базу знаний» вообще — это не источник.
- 4Задайте один вопрос тремя формулировками с интервалом в пару минут. Ответы могут отличаться словами, но не должны отличаться по существу: разные цифры означают, что модель отвечает из себя, а не из документа.
Пятый тест делается уже не в чате, а в журнале, и его стоит потребовать при приёмке: попросите открыть один диалог целиком и показать, какие фрагменты вернул поиск и что именно ушло в модель. Если в журнале записан только вопрос и ответ, проверить контур в дальнейшем будет нечем — при любом спорном случае вы не отличите выдумку от промаха поиска, а это разные ремонты и разные счета.
Самая распространённая имитация первого контура: модель генерирует ответ свободно, а ссылку ей подставляют отдельно — «ближайшим» документом по теме. Внешне это неотличимо от настоящего контура, пока не сверить текст ответа с текстом документа. Проверяется одним действием: откройте документ по ссылке и найдите в нём фразу, на которой построен ответ. Если её там нет — ссылка декоративная.
Контур 2. Жёсткие ограничители в коде
Второй контур — это набор проверок, которые выполняются программой до и после обращения к модели и не зависят от того, что модель решит написать. Их три группы, и путать их не стоит: они срабатывают в разные моменты и настраиваются разными людьми.
- 1Стоп-темы — проверка до генерации
Словарь триггерных фраз плюс простой классификатор проверяют входящее сообщение раньше, чем включится модель. Типовой список: возврат денег, жалоба, юридическая претензия, вопросы здоровья, персональные данные третьих лиц, прямая просьба позвать человека, упоминание проверяющих органов. При срабатывании генерация не запускается вообще — диалог уходит человеку. Это важно: если сначала сгенерировать ответ, а потом решать, отправлять ли его, ошибка в решении сразу становится отправленным сообщением.
- 2Числовые лимиты — проверка после генерации
Готовый текст ответа проверяется на вхождение чисел и обязательств: названная скидка выше согласованного порога, сумма выше лимита, конкретный срок доставки, не подтверждённый данными из системы, слова-обязательства вроде «гарантируем» и «вернём». Сработавшая проверка не правит текст, а отменяет отправку и передаёт диалог оператору. Эта группа даёт ложные срабатывания, и на их разбор закладывается 2–4 часа инженера в месяц — иначе через месяц ограничитель тихо отключат как мешающий.
- 3Белый список инструментов — ограничение возможностей
Агенту перечисляется, что ему разрешено делать: посмотреть статус заказа, создать заявку, записать на приём, отправить письмо из утверждённого шаблона. Всё, что не перечислено, недоступно физически — не по инструкции, а потому что соответствующего инструмента у него нет. Чёрные списки запретов здесь не работают: перечислить всё нежелательное невозможно, и любая новая формулировка проходит мимо запрета. Отдельно проверяется, что у инструментов на чтение и на запись разные права доступа.
Все три группы объединяет одно свойство: они не находятся внутри промпта. Просьба «никогда не обещай скидок», написанная в системной инструкции, — это текст, который модель взвешивает наравне с сообщением клиента. Достаточно настойчивой формулировки, ссылки на «прошлый разговор с менеджером» или простого повторения просьбы в третий раз, чтобы вероятностный баланс сместился. Условие в программе не смещается ни от настойчивости, ни от повторения. Это единственное надёжное различие между ограничителем и пожеланием.
Горизонтальная лента с тремя воротами. Слева «Сообщение клиента» → ворота «Стоп-темы» (подпись «до генерации», ветка вниз «человек») → «Модель» → ворота «Числовые лимиты» (подпись «после генерации», ветка вниз «человек») → «Отправка». Под блоком «Модель» отдельный прямоугольник «Белый список инструментов» с четырьмя пунктами: статус заказа, создать заявку, записать на приём, письмо из шаблона, и пометкой «остального у агента нет».
Контур 3. Журнал, выборочный контроль и сигналы тревоги
Третий контур ничего не предотвращает — он показывает. В журнал пишется каждый диалог целиком: вопрос, найденные фрагменты с их оценками релевантности, отправленный в модель контекст, ответ, сработавшие ограничители, версия промпта и модели, время и стоимость вызова. Хранить это надо не в переписке мессенджера, а в своей базе, с возможностью выгрузки и поиска; журнал в чужом сервисе, к которому у вас нет доступа, третьим контуром не является.
Поверх журнала работают две процедуры. Первая — регулярная выборочная проверка: раз в неделю человек берёт 3–5% диалогов и оценивает их по короткому чек-листу из четырёх-пяти пунктов (ответ соответствует источнику, источник актуален, тон уместен, эскалация сработала вовремя, задача клиента решена). Вторая — автоматические сигналы на события, которые нельзя откладывать до недельной проверки. Их немного, и каждый должен приводить к конкретному действию, а не к записи в отчёт.
- Фактический ответ ушёл без ссылки на источник — разбирать в тот же день, это отказ первого контура.
- Сработал числовой лимит, но сообщение всё-таки отправлено — критично, означает дефект в самом ограничителе.
- В ответе появилась сумма, скидка или конкретная дата, которых не было ни в одном найденном фрагменте.
- Одна и та же формулировка клиента за сутки встретилась больше пяти раз — вероятная попытка подобрать обход правила.
- Доля эскалаций за сутки упала больше чем вдвое к среднему — обычно означает, что кто-то ослабил правила или сломался классификатор стоп-тем.
- Клиент вернулся с тем же вопросом в течение 48 часов — сам по себе не тревога, но всплеск таких случаев показывает пробел в базе знаний.
Абстрактный экран панели (не скриншот реального продукта). Слева колонка «Сигналы за сутки» с четырьмя строками: «Ответ без источника — 1», «Лимит сработал, письмо ушло — 0», «Новая сумма в ответе — 2», «Повтор формулировки — 7». Справа карточка одного диалога с четырьмя блоками сверху вниз: «Вопрос», «Найденные фрагменты (3, с оценками)», «Ответ», «Сработавшие ограничители». Внизу строка «версия промпта, модель, время, стоимость вызова». Всё по-русски.
Почему без третьего контура первые два бесполезны
Причина не в философии, а в наблюдаемом свойстве систем: ограничитель, о срабатываниях которого никто не знает, живёт несколько недель. Дальше происходит одно из трёх. Первое — ограничитель мешает: он отдаёт оператору диалоги, которые кажутся простыми, и его порог тихо ослабляют, потому что «слишком много ложных срабатываний». Второе — ограничитель ломается при обновлении: поменялся формат ответа модели, регулярное выражение перестало находить суммы, и проверка молча пропускает всё подряд. Третье — ограничитель работает, но перестал соответствовать реальности: лимит скидки был согласован в марте, в июне ввели новую акцию, и агент теперь отказывает клиентам там, где отказывать не надо.
Все три сценария внешне выглядят как «всё в порядке»: жалоб нет, диалоги идут. Обнаружить их можно только через журнал и регулярную выборку. Поэтому мы считаем некорректной сдачу проекта, где первые два контура сделаны, а третий отложен «на следующий этап»: сдаётся система, качество которой невозможно проверить ни вам, ни нам. Практическое следствие для договора: журнал и панель контроля должны входить в первый этап, а не в опциональные работы.
Как это выглядит по неделям на реальном внедрении. Первая-вторая неделя: ограничитель на скидки срабатывает 20–30 раз, операторы разбирают эти диалоги вручную, всё работает. Третья-четвёртая: накапливается раздражение, потому что примерно половина срабатываний — ложные (клиент просто спросил, бывают ли у вас скидки), и порог поднимают. Шестая-восьмая: обновляется промпт, формат ответа немного меняется, проверка на числа перестаёт находить суммы, записанные словами. Десятая: никто не помнит, что ограничитель существовал, а в отчёте по-прежнему стоит галочка «защита от денежных обещаний — есть». Разорвать эту последовательность может только одно: еженедельный отчёт, в котором видно число срабатываний. Ноль срабатываний в отчёте — такой же повод для разбора, как и всплеск.
Лента времени на десять недель с линией «число срабатываний ограничителя в неделю»: 25, 22, 18, 9, 7, 4, 1, 0, 0, 0. Над линией четыре подписанные отметки: «1–2 нед. — работает», «3–4 нед. — порог подняли из-за ложных срабатываний», «6–8 нед. — обновление промпта сломало проверку», «10 нед. — в отчёте по-прежнему галочка «защита есть»». Внизу ремарка: «Ноль срабатываний — повод для разбора, а не хорошая новость».
Ограничитель, о срабатываниях которого никто не знает, живёт три недели. Дальше он либо ослаблен, либо сломан, либо устарел — и во всех трёх случаях выглядит работающим.
Сколько стоит каждый контур: часы на старте и часы в месяц
Модельный проект тот же, что и в остальных материалах раздела: клиентский агент на базе знаний из 150 страниц, поток около 6 000 обращений в месяц, интеграция с CRM для статусов заказов. Часы ниже — на внедрение всех трёх контуров, без стоимости самого сценария диалога, интеграций и приёмки.
| Контур | Из чего складывается | Часы на внедрение | Кто обслуживает |
|---|---|---|---|
| 1. База знаний и ссылка на источник | Сбор, чистка и разметка 150 страниц — 26 ч; ответ строго по фрагментам, ссылка, отказ при пустом поиске — 10 ч | 36 ч | Методист + инженер |
| 2. Ограничители в коде | Белый список инструментов — 8 ч; стоп-темы и числовые лимиты — 16 ч; эскалация с передачей контекста — 12 ч | 36 ч | Инженер |
| 3. Журнал и контроль | Журнал и панель — 10 ч; автоматические сигналы — 8 ч; тестовый набор из 120 вопросов для проверки после обновлений — 10 ч | 28 ч | Инженер + руководитель |
| Итого | — | 100 ч, около 300 000 ₽ при ставке 3 000 ₽/час | — |
Сравните с рыночными ориентирами на сентябрь 2026: заказной ИИ-агент стоит 250 000–500 000 ₽, «рабочий» агент в эксплуатации — 300 000–1 500 000 ₽. Три контура занимают внутри такого проекта примерно половину бюджета, и это главная причина, по которой предложения «ИИ-агент под ключ от 100 000 ₽» и наши сметы отличаются в разы. В соседней статье раздела разобран усечённый набор без автоматических сигналов и тестового набора — там выходит 82 часа; разница в 18 часов и есть цена возможности узнавать о поломке контура в тот же день, а не через месяц.
Минимально жизнеспособный вариант — только пополнение базы и выборочная проверка, 17 700 ₽ в месяц. Он допустим на первые два-три месяца при небольшом потоке, но у него есть цена: без разбора сигналов и правки лимитов вы узнаёте о проблеме на недельной выборке, то есть в среднем на три-четыре дня позже. Для потока в 6 000 обращений это 600–800 диалогов, прошедших через сломанный контур. Решать здесь надо осознанно, а не по умолчанию.
Горизонтальная столбчатая диаграмма из четырёх полос, ось в часах от 0 до 16. Полосы: «Контур 1: пополнение базы — 8 ч, 7 200 ₽», «Контур 2: разбор срабатываний — 3 ч, 9 000 ₽», «Контур 3: выборочная проверка — 15 ч, 10 500 ₽», «Контур 3: разбор сигналов и отчёт — 2 ч, 5 000 ₽». Справа итог: «28 ч, 31 700 ₽/мес». Пунктиром отмечена группа «минимальный вариант — 17 700 ₽».
Чек-лист приёмки: что попросить показать подрядчика
Приёмка по демонстрации диалога не проверяет ничего: демонстрация идёт по подготовленным вопросам. Проверять надо артефакты, и их всего пять. Список ниже стоит согласовать до начала работ и вложить в договор приложением — тогда на приёмке не будет спора о том, что именно сдаётся.
- 1Код ограничителей, а не описание
Попросите показать файл или модуль, где перечислены стоп-темы, числовые лимиты и белый список инструментов. Читать код не нужно — достаточно увидеть, что список существует отдельно от промпта и что его можно менять без переобучения чего-либо. Заодно спросите, кто на вашей стороне сможет править этот список после сдачи и что для этого нужно.
- 2Журнал за неделю в вашем доступе
Выгрузка минимум за семь дней с полями: вопрос, найденные фрагменты, ответ, сработавшие ограничители, версия промпта. Проверьте, что доступ у вас, а не только у подрядчика, и что данные можно выгрузить в файл. Отдельно уточните срок хранения и что происходит с персональными данными в диалогах — это зона 152-ФЗ, и её лучше закрыть до запуска.
- 3Отчёт выборочного контроля
Не форма отчёта, а заполненный отчёт хотя бы за одну неделю тестовой эксплуатации: сколько диалогов проверено, по какому чек-листу, что найдено, что исправлено. Пустая форма означает, что процедуры нет — есть только страница в интерфейсе.
- 4Тестовый набор вопросов и результат прогона
120–200 вопросов с эталонными ответами, включая заведомо провокационные: несуществующий товар, неверный номер пункта, просьба о скидке, стоп-тема. Прогон этого набора после каждого обновления промпта или модели — единственный способ заметить, что обновление сломало то, что раньше работало. Попросите показать результат последнего прогона с датой.
- 5Инструкция дежурного и маршрут эскалации
Кому уходит диалог, за какое время, что делает дежурный, если ответственный недоступен, и что происходит после 18:00 и в выходные. Эскалация без назначенного получателя — это кнопка, ведущая в пустоту, и на приёмке это проверяется одним тестовым обращением в нерабочее время.
Две колонки. Левая «Что показывают на демонстрации»: три строки — «диалог по подготовленным вопросам», «красивый интерфейс», «слайд с описанием безопасности». Правая «Что принимать»: пять строк — «код ограничителей», «журнал за неделю в вашем доступе», «заполненный отчёт выборочного контроля», «тестовый набор 120–200 вопросов и результат прогона», «инструкция дежурного и маршрут эскалации». Между колонками вертикальная разделительная линия.
Внутренний бот для сотрудников: контуры нужны и там
Распространённое рассуждение: внутреннему помощнику ограничители не нужны, потому что сотрудник — не клиент, он поймёт, если бот ошибётся. На практике ошибка внутреннего бота выходит наружу через сотрудника и обходится дороже, потому что теряется след: клиенту неверную информацию сообщает человек своим голосом, в переписке от своего имени, и при разборе никто не вспомнит, откуда взялась цифра. Диалог с ботом при этом обычно нигде не сохранён.
Правильная настройка для внутреннего помощника отличается от клиентской, но не отсутствием контуров, а их составом. Первый контур обязателен без изменений: ответ по документам со ссылкой, отказ при пустом поиске. Второй сокращается почти до нуля — белый список инструментов у справочного бота пустой, потому что он ничего не делает, а стоп-темы сводятся к кадровым и персональным данным. Третий остаётся полностью и даже важнее: именно журнал показывает, каких документов не хватает в базе — по вопросам, на которые бот честно не смог ответить. Это, кстати, самый дешёвый способ понять, где у компании дыры в регламентах.
Когда контуры избыточны
Строить все три контура нужно не всегда, и честнее сказать об этом до сметы. Есть три ситуации, где полный набор — лишние деньги.
- Агент не разговаривает с людьми, а обрабатывает документы: классифицирует, извлекает поля, раскладывает по папкам. Здесь ошибка видна на следующем шаге, потому что результат проверяет человек перед подтверждением. Достаточно журнала и выборочного контроля; стоп-темы и лимиты бессмысленны — обещать агенту нечего и некому.
- Внутренний черновик, который всегда отправляет человек. Модель готовит текст ответа, сотрудник читает и нажимает кнопку. Второй контур сводится к запрету автоматической отправки, первый нужен только если черновик опирается на регламенты, а не на текст обращения.
- Поток меньше 500–800 обращений в месяц. При таком объёме 100 часов внедрения и 28 часов в месяц не окупаются ни при каких ставках. Порог, с которого клиентский агент начинает окупаться, — примерно 2 000 обращений; ниже дешевле упорядочить шаблоны ответов и взять человека на неполный день.
Отдельно стоит сказать про каналы связи, потому что в 2026 году это влияет на смету сильнее, чем выбор модели. По состоянию на сентябрь 2026 WhatsApp в России заблокирован, Telegram работает с ограничениями, MAX развивается как основной канал для новых внедрений и имеет собственный Bot API. Прямых официальных интеграций MAX с amoCRM и Битрикс24 на начало 2026 года не было, связка идёт через прослойку. Практический вывод для контуров простой: все три должны находиться на вашей стороне, а не в настройках конкретного мессенджера. Тогда смена канала — это несколько дней работы, а не пересборка защиты с нуля.
Обратная ситуация тоже бывает: контуров нужно больше трёх. Если агент работает с деньгами напрямую — выставляет счета, оформляет возвраты, меняет условия договора — добавляются подтверждение второй стороной и раздельные права доступа для чтения и записи. Если в диалогах есть медицинские или юридические сведения, добавляется обезличивание до передачи в модель и, как правило, требование держать модель в собственном контуре. Это уже отдельный разговор, и начинать его надо не с выбора модели, а с описания того, какие данные в систему попадают.
