Надзор и безопасность ИИ-агентов: как контролировать автономные системы

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

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

У надзора два уровня. Предотвращение — до действия: гардианы отбраковывают опасное, гейты передают необратимое человеку. Разбор — после действия: аудит и воспроизводимость позволяют понять, что и почему произошло. Зрелая система имеет оба уровня; один без другого оставляет дыру.

Автономность — не выключатель «да/нет», а шкала. На одном конце — агент-подсказчик, который только предлагает, а делает всё человек; на другом — контур, исполняющий обратимые действия без остановок. Задача проектировщика — не задрать автономию до предела, а поставить каждый процесс на нужную точку этой шкалы: столько самостоятельности, сколько выдерживает цена ошибки. Надзор — это и есть механизм, который позволяет двигаться по шкале осознанно, а не вслепую.

Риски автономного агента — не абстракция, а набор конкретных, документированных сценариев отказа. Надзорный контур строится так, чтобы закрыть каждый из них.

• Необратимое действие по ошибке. Агент удалил запись, отправил письмо не тому, оформил заказ, изменил цену — там, где «отменить» уже нельзя.
• Галлюцинация, выданная за факт. Модель уверенно сообщает клиенту несуществующую скидку, срок или характеристику — и это уходит наружу от имени бизнеса.
• Prompt injection. Текст из письма, страницы или документа перехватывает инструкции агента и заставляет его действовать против задачи (подробнее — в глоссарии).
• Утечка данных. Персональные или коммерческие данные уходят за пределы периметра — во внешний сервис, в лог, в чужой ответ.
• Каскад ошибок. Один агент ошибся, другие приняли его вывод за истину — ошибка размножается по контуру.
• Разгон бюджета. Агент зацикливается и жжёт токены, вызовы API или рекламные деньги без результата.

Объединяет их одно: без надзора ошибка агента становится ошибкой бизнеса — мгновенно и часто необратимо. Задача контура — превратить потенциально необратимый сбой в отловленный и обратимый.

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

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

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

Гардиан — агент-надзиратель, единственная задача которого проверять действия других агентов до того, как они вступят в силу. Он сверяет подготовленное действие с правилами, требованиями закона и фактами и не пропускает то, что проверку не прошло. Несколько гардианов на разные классы рисков образуют гардиан-mesh.

Гардианы отличаются от guardrails — статических ограничений в промпте: guardrails задают рамки заранее, гардиан активно проверяет конкретное действие в моменте. Главное свойство гардиана — независимость: он работает по отдельным правилам, поэтому ловит ошибку, которую сам исполнитель уверенно не замечает. Как это устроено детально — в разборе «Гардианы: как агенты контролируют агентов».

Human-in-the-loop (человек в контуре) — принцип, по которому необратимые и высокорисковые решения агент готовит, но исполняет только после подтверждения человека. Это граница автономии, проведённая осознанно: не «человек проверяет всё», а «человек держит руку на необратимом».

За человеком обычно оставляют платежи и финансовые операции, публикации от имени бизнеса, юридически значимые коммуникации, удаление данных и всё, что нельзя откатить. Обратимое и рутинное агент ведёт сам под аудитом. Где именно проводят границу и как не превратить гейт в узкое горлышко — в статье «Human-in-the-loop: какие решения не отдают агенту».

Аудит решений ИИ — неизменяемый (append-only) журнал, в который агент записывает каждое действие: что решил, на каких данных, какие правила сработали, кто подтвердил. Записи только добавляются — их нельзя отредактировать или удалить, поэтому журнал годится как доказательство и для внутреннего разбора, и перед регулятором.

Технически это близко к event sourcing: система хранит не только итоговое состояние, но и всю последовательность событий, приведшую к нему. Благодаря этому любое решение агента можно воспроизвести постфактум и понять его причину. Зачем это бизнесу и регулятору — в разборе «Аудит решений ИИ: append-only лог».

Изоляция данных отвечает на вопрос «где физически оказываются данные, с которыми работает агент». Базовый уровень — маскирование: персональные данные (телефоны, почта, номера документов) заменяются на метки до вызова модели, так что наружу они не уходят. Следующий уровень — приватный контур: обработка внутри инфраструктуры компании, с контролируемым выходом во внешние сервисы.

Максимальный уровень — self-hosted модель: собственная языковая модель в своём периметре, когда данные не должны покидать инфраструктуру вообще. Это дорого и оправдано не всегда — выбор между облаком и своей моделью разобран в сравнении vLLM vs облачные API. Правило простое: уровень изоляции выбирается под чувствительность данных, а не «на всякий случай по максимуму».

Отдельно стоит развести два вопроса, которые часто смешивают: «уходят ли данные наружу» и «учится ли на них модель». Первое решается изоляцией и маскированием; второе — договором об обработке, который у серьёзных провайдеров прямо запрещает использовать данные API для обучения. Поэтому «облако» само по себе не равно «утечка»: риск возникает не от факта облачного вызова, а от того, что и как в этот вызов уходит. Инженерная задача — свести к минимуму сами данные, покидающие периметр, и закрыть остаток договором. Развёрнутый разбор уровней изоляции — от маскирования до self-hosted — в статье «Изоляция данных ИИ-агента».

152-ФЗ (персональные данные). В мультиагентном контуре ПДн проходят через несколько агентов и инструментов, поэтому важно, чтобы обработка была спроектирована по закону: согласие, цель, минимизация, маскирование там, где данные модели не нужны. Аудит-лог здесь работает как доказательство того, что данные обрабатывались правильно. Как 152-ФЗ применяется к мультиагентному контуру на практике — в разборе «152-ФЗ для ИИ-систем» (термин — в глоссарии).

38-ФЗ (реклама). Если агент готовит рекламные тексты или ведёт кампании, они должны проходить проверку на соответствие закону о рекламе до запуска — это одна из типовых задач гардиана. Раскрытие ИИ. Там, где с человеком общается агент — в чате или по телефону, — факт, что отвечает ИИ, и согласие на запись закладываются в сценарий, а не добавляются после жалобы. Это тот же принцип честности, что и на голосовом направлении: голосовой ИИ-агент.

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

1. Составить список необратимого. Прежде чем автоматизировать, выписать действия, которые агент не выполняет без человека: платежи, публикации, удаление, внешние коммуникации от имени компании.
2. Поставить гейты на границах. Human-in-the-loop не на каждый шаг, а именно на этих границах — иначе надзор убивает пользу автономии.
3. Включить гардианов на классы рисков. Факт-чек ответов клиенту, проверка на соответствие правилам площадок и закону, контроль безопасности вводимых данных.
4. Развернуть аудит с первого дня. Append-only журнал закладывается в архитектуру сразу, а не «когда-нибудь потом»: восстановить историю задним числом невозможно.
5. Изолировать данные. Маскирование ПДн до вызова модели, приватный контур, при необходимости — self-hosted модель для чувствительных данных.
6. Расширять автономию постепенно. Начать с узкой зоны под плотным надзором и снимать гейты по мере накопления доверия и статистики, а не наоборот.

«Надзор потом». Самая частая и дорогая ошибка: сначала запускают автономию, контроль добавляют после первого сбоя. Но append-only аудит нельзя восстановить задним числом, а доверие клиента, которому агент наврал, — тем более.

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

Логи, которые можно переписать. Обычный редактируемый лог не работает как аудит: если запись можно изменить или удалить, она ничего не доказывает ни при внутреннем разборе, ни перед регулятором. Нужен именно append-only.

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

«Облако = утечка» как аксиома. Обратное упрощение: любой облачный API объявляют небезопасным и отказываются от него совсем. На практике вопрос решается инженерно — маскированием ПДн до вызова, договором об обработке и изоляцией контура; self-hosted нужен там, где данные не должны покидать периметр вообще, а не везде.

Мы строим мультиагентные контуры именно так, как описано выше: плоскость управления с оркестратором, независимый гардиан-mesh поверх рабочих агентов, human-in-the-loop на необратимых действиях и append-only аудит с первого дня. Половина наших кейсов — собственные бизнесы студии, поэтому надзорный слой мы сначала обкатываем на себе, а не на клиенте.

Живой пример — чат на этом сайте: прежде чем отправить реплику в модель, контур маскирует телефоны и почту, так что персональные данные до неё не доходят (принцип 152-ФЗ на практике). Сам чат работает на облачной модели с этой защитой — мы это указываем честно и не выдаём за self-hosted. Где данные не должны покидать периметр, для клиентского контура поднимаем self-hosted модель.

Метод и состав работ по автономным контурам с надзором — на странице услуги ИИ-операторы. Ориентир по деньгам: проект — от 150 000 ₽, сопровождение контура — от 50 000 ₽ в месяц, первый рабочий контур — за 5–7 дней; точная смета зависит от процессов и требований к изоляции и считается по бесплатному разбору.