Три контура защиты ИИ-агента: база, стоп-темы, журнал

Рабочего ИИ-агента от демонстрации отличают три контура вокруг модели. Первый решает, откуда берутся факты: агент отвечает только по найденным фрагментам ваших документов и прикладывает ссылку на источник. Второй решает, чего агент не сделает никогда: список запретных тем и действий, лимиты на суммы, скидки и сроки, белый список доступных инструментов — всё это живёт в коде, а не в тексте промпта. Третий решает, как вы об этом узнаете: журнал каждого диалога, выборочная проверка и автоматические сигналы на события, которые требуют вмешательства в тот же день.

Порядок не случайный. Первый контур убирает основную массу выдумок, второй закрывает то, что дорого стоит деньгами и репутацией, третий показывает, работают ли первые два через два месяца после запуска. В соседнем материале раздела те же средства перечислены как четыре инженерных приёма — здесь они сгруппированы иначе, по признаку «кто это обслуживает»: первый контур ведёт методист, второй — инженер, третий — операционный руководитель.

Дальше по каждому контуру: что он ловит, что не ловит, как проверить его включённость своими руками и во что он обходится в часах на старте и в часах ежемесячно. Все суммы — модельный расчёт на прозрачных ставках: инженер 3 000 ₽/час, методист базы знаний 900 ₽/час, оператор 700 ₽/час, руководитель 2 500 ₽/час. Это не прайс, а арифметика, которую можно пересчитать под свои цифры.

Что ловит каждый контур: таблица «риск — контур»

Полезно начать с распределения рисков, а не с описания технологий: тогда становится видно, что контуры не дублируют друг друга и убрать любой из них означает открыть конкретный класс происшествий. Таблица ниже — тот минимум, который мы разбираем с заказчиком до сметы.

Заметно, что второй контур закрывает больше всего строк, но именно его чаще всего заменяют вежливой формулировкой в промпте, потому что так дешевле и быстрее. И заметно, что третий контур не предотвращает ничего — он только показывает. Ниже разберём, почему без него первые два всё равно перестают работать.

Контур 1. Ответ только по базе знаний со ссылкой на источник

Механика простая. Вопрос клиента сначала уходит не в модель, а в поиск по вашим документам: регламентам, прайсам, описаниям услуг, накопленным ответам поддержки. Поиск возвращает несколько фрагментов, и только они вместе с инструкцией «отвечай строго по приведённым фрагментам, ничего не добавляй» передаются модели. К ответу прикладывается ссылка: название документа, редакция, номер пункта. Клиент видит её в чате, оператор — в журнале.

Главное здесь не поиск, а поведение при пустом результате. Если релевантных фрагментов не нашлось, ответа быть не должно вообще: система пишет, что уточнит, и передаёт вопрос человеку. Именно эта строчка кода отличает контур от его имитации. Мы регулярно видим внедрения, где поиск настроен, ссылки прикладываются, а при пустом результате модель всё равно отвечает — потому что запрет на ответ никто не поставил, а разработчику показалось невежливым отказывать клиенту.

Основная работа в первом контуре — не программирование, а подготовка документов, и её объём владельцы обычно недооценивают. Регламент на 40 страниц в формате «сплошной текст с приложениями» нужно разрезать на фрагменты по смыслу, а не по количеству символов: один фрагмент — одно правило целиком, вместе с исключениями, иначе агент найдёт правило и не найдёт исключение к нему. К каждому документу привязываются редакция, дата и владелец на вашей стороне. Отдельно собирается словарь: как клиенты называют то, что у вас в документах называется иначе — «минимальная партия» против «отгрузка от», «предоплата» против «авансовый платёж», народные названия артикулов. В модельном проекте на 150 страниц это 26 часов, и почти все они уходят на разбор документов, а не на код.

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

Как проверить, что первый контур действительно включён

Проверка занимает пятнадцать минут и не требует технических знаний. Достаточно доступа к тому же чату, который показывает подрядчик, — все четыре теста делаются со стороны клиента.

1. 1Спросите про заведомо несуществующий товар с правдоподобным названием. Правильный ответ — «не нашёл, уточню у сотрудника». Развёрнутое описание характеристик означает, что запрета на ответ при пустом поиске нет.
2. 2Спросите содержание пункта договора с заведомо неверным номером. Агент должен сказать, что такого пункта нет, а не пересказать соседний.
3. 3Откройте ссылку из любого фактического ответа. Она должна вести в конкретный документ с конкретной редакцией. Ссылка на раздел сайта или на «базу знаний» вообще — это не источник.
4. 4Задайте один вопрос тремя формулировками с интервалом в пару минут. Ответы могут отличаться словами, но не должны отличаться по существу: разные цифры означают, что модель отвечает из себя, а не из документа.

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

Контур 2. Жёсткие ограничители в коде

Второй контур — это набор проверок, которые выполняются программой до и после обращения к модели и не зависят от того, что модель решит написать. Их три группы, и путать их не стоит: они срабатывают в разные моменты и настраиваются разными людьми.

1. 1
   Стоп-темы — проверка до генерации

   Словарь триггерных фраз плюс простой классификатор проверяют входящее сообщение раньше, чем включится модель. Типовой список: возврат денег, жалоба, юридическая претензия, вопросы здоровья, персональные данные третьих лиц, прямая просьба позвать человека, упоминание проверяющих органов. При срабатывании генерация не запускается вообще — диалог уходит человеку. Это важно: если сначала сгенерировать ответ, а потом решать, отправлять ли его, ошибка в решении сразу становится отправленным сообщением.

2. 2
   Числовые лимиты — проверка после генерации

   Готовый текст ответа проверяется на вхождение чисел и обязательств: названная скидка выше согласованного порога, сумма выше лимита, конкретный срок доставки, не подтверждённый данными из системы, слова-обязательства вроде «гарантируем» и «вернём». Сработавшая проверка не правит текст, а отменяет отправку и передаёт диалог оператору. Эта группа даёт ложные срабатывания, и на их разбор закладывается 2–4 часа инженера в месяц — иначе через месяц ограничитель тихо отключат как мешающий.

3. 3
   Белый список инструментов — ограничение возможностей

   Агенту перечисляется, что ему разрешено делать: посмотреть статус заказа, создать заявку, записать на приём, отправить письмо из утверждённого шаблона. Всё, что не перечислено, недоступно физически — не по инструкции, а потому что соответствующего инструмента у него нет. Чёрные списки запретов здесь не работают: перечислить всё нежелательное невозможно, и любая новая формулировка проходит мимо запрета. Отдельно проверяется, что у инструментов на чтение и на запись разные права доступа.

Все три группы объединяет одно свойство: они не находятся внутри промпта. Просьба «никогда не обещай скидок», написанная в системной инструкции, — это текст, который модель взвешивает наравне с сообщением клиента. Достаточно настойчивой формулировки, ссылки на «прошлый разговор с менеджером» или простого повторения просьбы в третий раз, чтобы вероятностный баланс сместился. Условие в программе не смещается ни от настойчивости, ни от повторения. Это единственное надёжное различие между ограничителем и пожеланием.

Контур 3. Журнал, выборочный контроль и сигналы тревоги

Третий контур ничего не предотвращает — он показывает. В журнал пишется каждый диалог целиком: вопрос, найденные фрагменты с их оценками релевантности, отправленный в модель контекст, ответ, сработавшие ограничители, версия промпта и модели, время и стоимость вызова. Хранить это надо не в переписке мессенджера, а в своей базе, с возможностью выгрузки и поиска; журнал в чужом сервисе, к которому у вас нет доступа, третьим контуром не является.

Поверх журнала работают две процедуры. Первая — регулярная выборочная проверка: раз в неделю человек берёт 3–5% диалогов и оценивает их по короткому чек-листу из четырёх-пяти пунктов (ответ соответствует источнику, источник актуален, тон уместен, эскалация сработала вовремя, задача клиента решена). Вторая — автоматические сигналы на события, которые нельзя откладывать до недельной проверки. Их немного, и каждый должен приводить к конкретному действию, а не к записи в отчёт.

• Фактический ответ ушёл без ссылки на источник — разбирать в тот же день, это отказ первого контура.
• Сработал числовой лимит, но сообщение всё-таки отправлено — критично, означает дефект в самом ограничителе.
• В ответе появилась сумма, скидка или конкретная дата, которых не было ни в одном найденном фрагменте.
• Одна и та же формулировка клиента за сутки встретилась больше пяти раз — вероятная попытка подобрать обход правила.
• Доля эскалаций за сутки упала больше чем вдвое к среднему — обычно означает, что кто-то ослабил правила или сломался классификатор стоп-тем.
• Клиент вернулся с тем же вопросом в течение 48 часов — сам по себе не тревога, но всплеск таких случаев показывает пробел в базе знаний.

Почему без третьего контура первые два бесполезны

Причина не в философии, а в наблюдаемом свойстве систем: ограничитель, о срабатываниях которого никто не знает, живёт несколько недель. Дальше происходит одно из трёх. Первое — ограничитель мешает: он отдаёт оператору диалоги, которые кажутся простыми, и его порог тихо ослабляют, потому что «слишком много ложных срабатываний». Второе — ограничитель ломается при обновлении: поменялся формат ответа модели, регулярное выражение перестало находить суммы, и проверка молча пропускает всё подряд. Третье — ограничитель работает, но перестал соответствовать реальности: лимит скидки был согласован в марте, в июне ввели новую акцию, и агент теперь отказывает клиентам там, где отказывать не надо.

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

Как это выглядит по неделям на реальном внедрении. Первая-вторая неделя: ограничитель на скидки срабатывает 20–30 раз, операторы разбирают эти диалоги вручную, всё работает. Третья-четвёртая: накапливается раздражение, потому что примерно половина срабатываний — ложные (клиент просто спросил, бывают ли у вас скидки), и порог поднимают. Шестая-восьмая: обновляется промпт, формат ответа немного меняется, проверка на числа перестаёт находить суммы, записанные словами. Десятая: никто не помнит, что ограничитель существовал, а в отчёте по-прежнему стоит галочка «защита от денежных обещаний — есть». Разорвать эту последовательность может только одно: еженедельный отчёт, в котором видно число срабатываний. Ноль срабатываний в отчёте — такой же повод для разбора, как и всплеск.

Ограничитель, о срабатываниях которого никто не знает, живёт три недели. Дальше он либо ослаблен, либо сломан, либо устарел — и во всех трёх случаях выглядит работающим.

Сколько стоит каждый контур: часы на старте и часы в месяц

Модельный проект тот же, что и в остальных материалах раздела: клиентский агент на базе знаний из 150 страниц, поток около 6 000 обращений в месяц, интеграция с CRM для статусов заказов. Часы ниже — на внедрение всех трёх контуров, без стоимости самого сценария диалога, интеграций и приёмки.

Сравните с рыночными ориентирами на сентябрь 2026: заказной ИИ-агент стоит 250 000–500 000 ₽, «рабочий» агент в эксплуатации — 300 000–1 500 000 ₽. Три контура занимают внутри такого проекта примерно половину бюджета, и это главная причина, по которой предложения «ИИ-агент под ключ от 100 000 ₽» и наши сметы отличаются в разы. В соседней статье раздела разобран усечённый набор без автоматических сигналов и тестового набора — там выходит 82 часа; разница в 18 часов и есть цена возможности узнавать о поломке контура в тот же день, а не через месяц.

Минимально жизнеспособный вариант — только пополнение базы и выборочная проверка, 17 700 ₽ в месяц. Он допустим на первые два-три месяца при небольшом потоке, но у него есть цена: без разбора сигналов и правки лимитов вы узнаёте о проблеме на недельной выборке, то есть в среднем на три-четыре дня позже. Для потока в 6 000 обращений это 600–800 диалогов, прошедших через сломанный контур. Решать здесь надо осознанно, а не по умолчанию.

Чек-лист приёмки: что попросить показать подрядчика

Приёмка по демонстрации диалога не проверяет ничего: демонстрация идёт по подготовленным вопросам. Проверять надо артефакты, и их всего пять. Список ниже стоит согласовать до начала работ и вложить в договор приложением — тогда на приёмке не будет спора о том, что именно сдаётся.

1. 1
   Код ограничителей, а не описание

   Попросите показать файл или модуль, где перечислены стоп-темы, числовые лимиты и белый список инструментов. Читать код не нужно — достаточно увидеть, что список существует отдельно от промпта и что его можно менять без переобучения чего-либо. Заодно спросите, кто на вашей стороне сможет править этот список после сдачи и что для этого нужно.

2. 2
   Журнал за неделю в вашем доступе

   Выгрузка минимум за семь дней с полями: вопрос, найденные фрагменты, ответ, сработавшие ограничители, версия промпта. Проверьте, что доступ у вас, а не только у подрядчика, и что данные можно выгрузить в файл. Отдельно уточните срок хранения и что происходит с персональными данными в диалогах — это зона 152-ФЗ, и её лучше закрыть до запуска.

3. 3
   Отчёт выборочного контроля

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

4. 4
   Тестовый набор вопросов и результат прогона

   120–200 вопросов с эталонными ответами, включая заведомо провокационные: несуществующий товар, неверный номер пункта, просьба о скидке, стоп-тема. Прогон этого набора после каждого обновления промпта или модели — единственный способ заметить, что обновление сломало то, что раньше работало. Попросите показать результат последнего прогона с датой.

5. 5
   Инструкция дежурного и маршрут эскалации

   Кому уходит диалог, за какое время, что делает дежурный, если ответственный недоступен, и что происходит после 18:00 и в выходные. Эскалация без назначенного получателя — это кнопка, ведущая в пустоту, и на приёмке это проверяется одним тестовым обращением в нерабочее время.

Внутренний бот для сотрудников: контуры нужны и там

Распространённое рассуждение: внутреннему помощнику ограничители не нужны, потому что сотрудник — не клиент, он поймёт, если бот ошибётся. На практике ошибка внутреннего бота выходит наружу через сотрудника и обходится дороже, потому что теряется след: клиенту неверную информацию сообщает человек своим голосом, в переписке от своего имени, и при разборе никто не вспомнит, откуда взялась цифра. Диалог с ботом при этом обычно нигде не сохранён.

Правильная настройка для внутреннего помощника отличается от клиентской, но не отсутствием контуров, а их составом. Первый контур обязателен без изменений: ответ по документам со ссылкой, отказ при пустом поиске. Второй сокращается почти до нуля — белый список инструментов у справочного бота пустой, потому что он ничего не делает, а стоп-темы сводятся к кадровым и персональным данным. Третий остаётся полностью и даже важнее: именно журнал показывает, каких документов не хватает в базе — по вопросам, на которые бот честно не смог ответить. Это, кстати, самый дешёвый способ понять, где у компании дыры в регламентах.

Когда контуры избыточны

Строить все три контура нужно не всегда, и честнее сказать об этом до сметы. Есть три ситуации, где полный набор — лишние деньги.

• Агент не разговаривает с людьми, а обрабатывает документы: классифицирует, извлекает поля, раскладывает по папкам. Здесь ошибка видна на следующем шаге, потому что результат проверяет человек перед подтверждением. Достаточно журнала и выборочного контроля; стоп-темы и лимиты бессмысленны — обещать агенту нечего и некому.
• Внутренний черновик, который всегда отправляет человек. Модель готовит текст ответа, сотрудник читает и нажимает кнопку. Второй контур сводится к запрету автоматической отправки, первый нужен только если черновик опирается на регламенты, а не на текст обращения.
• Поток меньше 500–800 обращений в месяц. При таком объёме 100 часов внедрения и 28 часов в месяц не окупаются ни при каких ставках. Порог, с которого клиентский агент начинает окупаться, — примерно 2 000 обращений; ниже дешевле упорядочить шаблоны ответов и взять человека на неполный день.

Отдельно стоит сказать про каналы связи, потому что в 2026 году это влияет на смету сильнее, чем выбор модели. По состоянию на сентябрь 2026 WhatsApp в России заблокирован, Telegram работает с ограничениями, MAX развивается как основной канал для новых внедрений и имеет собственный Bot API. Прямых официальных интеграций MAX с amoCRM и Битрикс24 на начало 2026 года не было, связка идёт через прослойку. Практический вывод для контуров простой: все три должны находиться на вашей стороне, а не в настройках конкретного мессенджера. Тогда смена канала — это несколько дней работы, а не пересборка защиты с нуля.

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