Любой разговор о рисках ИИ в бизнесе застревает на галлюцинациях, а бояться стоит совсем не их.
Модель, которая сказала неправду в окне чата, — это неловко. Модель, которая сказала неправду, обязывающую вашу компанию, — цену, скидку, дату доставки, подтверждённую запись, возврат денег, — это событие совсем другого класса. Первое — плохой ответ. Второе — договор, на который ваш бизнес не соглашался, заключённый системой, у которой нет полномочий соглашаться на что бы то ни было.
Разница не в точности. Разница в полномочиях, и из неё вытекает правило, которое мы применяем к каждой ИИ-системе, которую строим:
ИИ может находить, составлять и предлагать. Но он никогда не должен быть последним звеном перед обязательством.
Одно это предложение определяет архитектуру. Всё, что ниже, — о том, как это правило обеспечивается на практике, на примерах систем, которые у нас работают в продакшне.
Шаблон 1: не запрещайте возможность — уберите её
Самая слабая форма контроля — сказать модели чего-то не делать. Промпт — это рекомендация, а не система прав доступа, и инструкция, которая выдерживает тысячу разговоров, провалится на том единственном, который важен.
Сильная форма — убрать саму возможность.
В нашем голосовом ИИ-администраторе, который записывает клиентов на узбекском и русском, ни один инструмент не принимает цену. Не «модели сказано не торговаться», а во всей схеме инструментов нет ни одного параметра, через который цена могла бы попасть внутрь. Услуги, свободное время и данные о заведении берутся из собственных записей бизнеса, и это единственный путь.
Точно так же бот поддержки Bronjoy не имеет вообще ни одного инструмента, который что-то меняет. Он может найти и объяснить. Изменить аккаунт, перенести запись или что-то оформить он не может. Худший возможный его сбой — неправильное объяснение, а это поправимо.
Вопрос при проектировании звучит не как «как мне запретить ему делать X». Он звучит так: какой минимальный набор инструментов позволит ему делать свою работу и что худшего этот набор допускает?
Шаблон 2: изменение состояния требует токена, который модель не может выдумать
Если ИИ может действовать, действие должно быть заперто на что-то, чего он не мог сочинить.
Администратор не может записать клиента на время напрямую. hold_slot резервирует конкретное время и возвращает hold_token, а book_appointment без него не запустится. Модель не может записать на слот, который календарь никогда не предлагал, а двум звонящим не может достаться один и тот же слот.
Та же идея работает в MCP-серверах Bronjoy, которые позволяют ассистентам вроде Claude искать и записываться по всему маркетплейсу из 23 727 заведений. Чтобы создать запись, нужен шестизначный код, отправленный на собственный телефон или почту клиента, — он действует пять минут и годится для одной записи. Ассистент этот код никогда не видит. Его диктует сам пользователь.
Шаблон обобщается: модель предлагает действие; отдельная детерминированная система выдаёт разрешение; действие требует разрешения. Уверенность модели выпадает из причинно-следственной цепочки.
Шаблон 3: сверяйте утверждение с тем, что произошло на самом деле
Этот шаблон почти никто не строит, а он самый важный.
Модель может вызвать инструмент, получить ошибку — и после этого сообщить клиенту, что всё прошло успешно. Она не врёт: она просто заканчивает предложение самым вероятным образом. Но клиент теперь уверен, что записан.
Поэтому у администратора есть страж утверждений. Каждая фраза, в которой говорится о записи, отмене или переносе, — на русском, узбекском или английском — до того, как будет произнесена, сверяется с вызовами инструментов, которые действительно прошли успешно. Если совпадения нет, фраза переписывается в уточняющий вопрос, а перехват записывается в лог.
Общее правило: никогда не позволяйте модели быть источником истины о её собственных действиях. Сравнивайте её вывод с записями вашей системы и вмешивайтесь при расхождении. Если в этом году вы построите только один защитный механизм — постройте этот.
Шаблон 4: разделите риски по уровням и отправьте дорогую половину в очередь
Не каждое решение требует человека, а если требовать его для всего, получится система настолько медленная, что ей никто не будет пользоваться.
Nomadeo — ИИ-агент по продажам, который мы делаем для WhatsApp и Telegram на русском, узбекском и казахском, — решает это явными уровнями. Факты и обязательства извлекаются из переписки, распределяются по уровням риска и сверяются с более ранними. Факты с низким риском подтверждаются автоматически. Факты с высоким риском — всё, что обязывает бизнес деньгами: цена, скидка, срок — ждут в очереди решений, где менеджер подтверждает или отклоняет их одним касанием или свайпом, с возможностью отмены. Дальше, в CRM, уходят только подтверждённые факты — через вебхук с подписью HMAC.
Вокруг этого стоят девять проверок каждого черновика перед отправкой: опора на факты, полномочия на скидку, запрещённые утверждения, промпт-инъекции, персональные данные, устаревшие факты, ночной режим, лимиты запросов и бюджет. Заблокированный черновик пересобирается или передаётся человеку.
Та же схема есть в ИИ-ассистенте админки Knigopoisk, у которого есть реальные инструменты для работы с заказами, товарами, контентом и пользователями. Когда он предлагает действие, требующее согласования, выполнение приостанавливается, предложение фиксируется, и работа продолжается только после того, как администратор его одобрит или отклонит, — остаётся журнал аудита: что было предложено и что было сделано.
Обратите внимание на разницу между паузой в процессе и вопросом заранее. Вопросы заранее вызывают усталость от согласий. Пауза в точке решения оставляет запись.
Шаблон 5: пусть модель предлагает, а решает что-то детерминированное
Самая полная версия принципа — и та, у которой больше всего плюсов.
Чтобы её проверить, мы сделали Keystone на AMD Developer Hackathon. Задача — составление графика смен для персонала с жёсткими правилами вроде «никогда не ставить неквалифицированную медсестру на смену в реанимации». Попросите чат-бота составить график — и получите план, который хорошо читается, часто стоит дешевле и тихо нарушает правило, за которое кто-то несёт юридическую ответственность.
Архитектура делит одно решение на три роли:
- Gemma читает данные, правила на запутанном естественном языке и цель — и предлагает формальную целочисленную модель.
- Google OR-Tools CP-SAT решает эту модель с доказанной оптимальностью — или возвращает минимальный набор конфликтующих правил.
- Независимый верификатор перепроверяет каждое жёсткое ограничение точной целочисленной арифметикой и выдаёт сертификат, который можно проверить машинно.
LLM делает то, в чём она действительно сильнее всего, — превращает размытые человеческие правила в структуру. Она никогда не принимает решение и никогда не ручается за ответ. Тот же верификатор параллельно оценивает план, составленный «голой» LLM, так что разницу видно наглядно.
Это самое ценное применение языковой модели в бизнес-процессе: как переводчика в то, что можно проверить, а не как оракула.
То же правило — в работе с доказательствами
Ещё два наших инструмента применяют этот принцип не к действиям, а к утверждениям, и на это стоит посмотреть, потому что большинству компаний нужна именно такая версия.
Testify проверяет записи звонков по взысканию долгов на соответствие правилам FDCPA и TCPA. Требование считается выполненным, только если есть дословная цитата с таймкодом. Отсутствие доказательств не превращается ни в провал, ни в успех — оно превращается в статус «недостаточно доказательств» и уходит на проверку человеку.
Legible адаптирует документы для экранных дикторов. Когда визуальная модель не может считать значение с графика, значение остаётся пустым и помечается флагом, потому что в процессе, за который кто-то отвечает юридически, уверенная неверная цифра хуже, чем никакой.
Оба инструмента закрепляют одну и ту же идею: вывод с тремя состояниями — да, нет, не знаю — вот что делает ИИ-систему пригодной для регулируемого процесса. Вывод с двумя состояниями вынуждает сочинять.
Один инцидент через все пять шаблонов
С абстрактными принципами легко согласиться и трудно их применить, поэтому вот один правдоподобный сбой — и то, где каждый шаблон его остановил бы.
Исходные данные. Мебельный магазин запускает ИИ-ассистента в WhatsApp. Клиент спрашивает про диван, упоминает распродажу у конкурента и говорит, что купит сегодня, если цена будет такой же. Ассистент, стараясь быть полезным, отвечает: «Могу сделать вам скидку 15% сегодня — и отложу один на складе».
Никакой галлюцинации в этом сообщении нет. Каждое слово правдоподобно, хорошо написано и ровно то, что мог бы сказать хороший продавец. А ещё это скидка, которую никто не утверждал, на товар, который никто не резервировал, — и теперь у клиента это есть в письменном виде.
Где это ломается и где каждый шаблон это ловит:
| Шаблон | Остановил бы он это? |
|---|---|
| 1. Уберите возможность | Да, в корне. Если ни один инструмент и ни один путь через промпт не может выдать процент, такую фразу просто не составить. Это самое дешёвое исправление, и большинство команд его пропускает, потому что оно кажется слишком жёстким. |
| 2. Запирайте на токен | Да, в части резерва. «Отложу один» — правда, только если удержание было оформлено. Нет токена удержания — нет и утверждения. |
| 3. Сверяйте утверждение | Да, в обеих частях. Исходящая проверка сравнивает «скидку 15%» и «отложу» с вызовами инструментов, которые действительно прошли, не находит ни того, ни другого и переписывает фразу в вопрос: «Сейчас уточню, что могу сделать по цене и можно ли отложить один экземпляр, — минутку». |
| 4. Уровни и очередь | Да, и это та версия, которая всё равно закрывает продажу. Скидка распознаётся как денежное обязательство, уходит в очередь менеджеру и за несколько минут возвращается одобренной или со встречным предложением — а клиенту сообщают, что подтверждает живой человек. |
| 5. Предложение, потом детерминированное решение | Да, на уровне структуры. Модель предлагает «дать скидку»; движок ценовых правил решает, допускают ли её этот клиент, этот товар и эта маржа. |
Заметьте: четыре из пяти не останавливают разговор. Ленивое прочтение этой статьи — «закрутить ассистенту гайки, пока от него не останется толку». Точное прочтение — ассистенту с чёткими границами можно доверить больше самостоятельности, потому что дорогие исходы для него структурно недоступны.
Заметьте и цену сбоя, если ничего из этого нет. Дело не в 15%, а в прецеденте, в клиенте, который расскажет трём друзьям, что такая скидка бывает, и в том, что узнаете вы об этом через несколько недель из вопроса бухгалтерии, а не из лога.
Чек-лист перед запуском чего угодно
- Перечислите все инструменты. Для каждого: что худшего случится, если он сработает неправильно?
- Уберите все инструменты, для которых ответ на этот вопрос неприемлем. Не смягчайте — убирайте.
- Для оставшихся изменений состояния: каким детерминированным токеном они заперты?
- Что сверяет утверждения модели с записями вашей системы?
- Какие выводы обязывают вас деньгами? Они идут в очередь на согласование, с журналом аудита.
- Является ли «я не знаю» допустимым выводом? Если нет, вы спроектировали систему, которая обязана выдумывать.
- Как разговор передаётся человеку и передаётся ли вместе с ним контекст?
- Где потолок расходов и что происходит, когда он достигнут?
Последний пункт — не вопрос безопасности, пока вдруг не становится им. Nomadeo ограничивает расходы глобально и отдельно для каждого клиента платформы, а после лимита агент деградирует ступенями — модель подешевле, потом только ответы из кеша, потом человек, — вместо того чтобы сломаться посреди разговора.
Почему это коммерческий аргумент, а не осторожность
Всё это не про то, чтобы притормозить ИИ. Ровно наоборот.
Системе с жёсткими границами можно дать гораздо больше самостоятельности внутри них, потому что радиус поражения известен. Bronjoy может открыть запись любому ИИ-ассистенту в интернете без всякого аккаунта именно потому, что проверка, лимиты и сверка утверждений живут за интерфейсом. Ограничения — это то, что делает открытость безопасной.
Меньше всего от ИИ в ближайшие три года получат компании, которые либо отказываются его внедрять, либо внедряют без всякой архитектуры, а после первого инцидента отступают. Оба пути ведут в одно и то же место.
Наши проекты по внедрению ИИ и автоматизации стоят от $299 со сроком 1–3 недели, и первый этап — аудит процессов, ровно по этой причине: вопрос не в том, что умеет ИИ, а в том, какие из ваших шагов он может безопасно взять на себя.
Расскажите, что вам нужно. В ответ вы получите фиксированную цену и дату сдачи — бесплатно и без обязательств продолжать.
Частые вопросы
Разве хороший промпт с этим не справится?
Промпт снижает частоту сбоя. Но не ограничивает последствия. Для всего, что вас обязывает, нужен механизм, который невозможно уговорить изменить поведение хитро составленным сообщением, — см. также про промпт-инъекции.
Все эти согласования не замедляют агента?
Только там, где и должны. В этом и смысл уровней: частая работа с небольшими последствиями идёт на полной скорости, и в очередь попадают только обязательства. На практике клиенты видят быстрого ассистента, который иногда говорит «давайте я уточню это у коллеги», — ровно так поступает хороший младший сотрудник.
Кто отвечает, если ИИ пообещал что-то не то?
Исходите из того, что вы, и проектируйте соответственно. Именно из-за этого допущения очередь согласований и журнал аудита важнее любого выбора модели: вы должны быть в состоянии показать, что было предложено, что одобрено и кем.
Это актуально только для регулируемых отраслей?
Нет. Любой бизнес, который называет цены, принимает записи, обещает сроки или оформляет возвраты, берёт на себя обязательства. Регулирование меняет размер штрафа, а не архитектуру.
Какую ошибку вы видите чаще всего?
Ассистенту в первый же день дают право изменять данные в боевой системе, потому что на демо он показал себя хорошо. Такие системы ломаются не на демо. Они ломаются на нестандартном разговоре, через три месяца, когда никто не смотрит.
