Представим, что ИИ помогает бухгалтерии работать со счетами поставщиков. Он замечает новые банковские реквизиты, читает сопроводительное письмо и решает, что всё в порядке. Возможно, реквизиты действительно изменились. Возможно, письмо поддельное. Уверенность модели здесь ничего не доказывает.
Теперь дадим этому же помощнику право самостоятельно обновлять карточку поставщика и подтверждать платёж. Модель осталась прежней, а последствия её ошибки изменились радикально.
Вот для чего нужны guardrails — ограничения вокруг ИИ-системы. Они определяют, что произойдёт, если модель ошибётся, неверно поймёт задачу или получит вредную инструкцию.
Ошибка не обязательно выглядит как атака
О безопасности ИИ часто говорят через jailbreak и попытки обойти системный промпт. Такие атаки существуют, но в реальной работе не менее опасны обычные ошибки: выбран не тот клиент, устаревший документ принят за действующую инструкцию, неоднозначная просьба истолкована слишком смело.
Более качественный промпт может снизить вероятность ошибки. Но промпт не отзовёт доступ к базе данных, не установит лимит на сумму перевода и не проверит полномочия сотрудника.
Поэтому я бы не делал текст инструкции последней линией защиты. Самые важные ограничения должны работать даже тогда, когда модель их проигнорировала.
Начинать стоит с последствий
Не с выбора библиотеки для guardrails, а с вопроса: какое действие помощника будет трудно отменить?
Поиск по открытой документации — один уровень риска. Письмо от имени компании — другой. Удаление клиентских данных, изменение реквизитов или подтверждение финансовой операции требуют совсем иных правил.
Из этого довольно быстро складывается архитектура: доступ только к необходимым данным, проверка полномочий при вызове инструмента, лимиты расходов и количества операций, подтверждение чувствительных действий, журнал фактически выполненных изменений.
Речь не о том, чтобы директор одобрял каждый ответ чат-бота. Нужно заранее отделить решения, которые можно автоматизировать, от тех, за которые всё ещё должен отвечать человек.
Ограничение должно пережить ошибку модели
Допустим, агент готовит возвраты покупателям, но операции выше согласованного лимита требуют подтверждения. Проверку суммы должно выполнять приложение перед вызовом платёжного инструмента. Просить модель «не забывать о лимите» недостаточно.
То же относится к доступу. Если агент помогает одному сотруднику, он не должен случайно получить документы другого подразделения. Это правило авторизации, а не особенность промпта. Подробно я разбираю его в статье о правах AI-агентов.
Документы, письма и веб-страницы тоже нельзя считать доверенными инструкциями. Внутри них может оказаться текст, который пытается изменить поведение помощника. Здесь нужны разделение данных и команд, ограничения инструментов и защита от prompt injection.
После ответа модели могут понадобиться дополнительные проверки: корректность формата, допустимость действия, соответствие бизнес-правилам. Но у каждой проверки должен быть понятный исход. Если система обнаружила нарушение и всё равно молча продолжила операцию, пользы от неё немного.
Подтверждение человеком тоже можно испортить
Часто предлагают универсальный ответ: пусть каждое действие ИИ подтверждает сотрудник. На практике такой подход легко превращается в поток кнопок «Одобрить».
Чтобы подтверждение имело смысл, человек должен видеть, какое действие готовится, к каким объектам оно относится, на основании каких данных принято решение и можно ли его отменить. Формулировка «ИИ предлагает продолжить» этих вопросов не закрывает.
Проверка стоит времени. Если подтверждать приходится сотни безобидных операций, люди быстро привыкают соглашаться не глядя. Лучше оставить ручное решение для действительно значимых случаев и исключений.
Это продуктовая договорённость между бизнесом, безопасностью и разработкой. Добавить её после запуска гораздо сложнее, чем обсудить до того, как помощнику дали доступ к реальным действиям.
Проверять нужно не только ответы
Команды любят измерять качество модели. А что происходит, когда политика запрещает действие? Сколько таких отказов? Какие из них оправданны? Может ли сотрудник решить задачу другим способом? Где автоматизация постоянно спотыкается о согласования?
Слишком строгие ограничения сделают продукт неудобным. Слишком мягкие обнаружатся во время первого серьёзного инцидента. Здесь нельзя настроить всё однажды и забыть.
Прежде чем расширять самостоятельность агента, я бы проверил не только результаты AI Evaluation, но и реальную работу полномочий, журналов и процедуры восстановления после ошибки.
Хорошие guardrails почти не замечают, пока всё работает. Их смысл становится виден в тот момент, когда ошибочное решение останавливается на правильной границе и не превращается в проблему всей компании.