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

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

Надзор — инженерная практика, сопоставимая с ревью кода, тестами и мониторингом. Для автономного контура до запуска задают проверяемые классы действий, fail-closed границы и метрики пропусков; это снижает риск, но не исключает неизвестные сценарии и обходные пути.

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

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

Риски автономного агента описывают конкретными сценариями отказа. Надзорный контур проектируют под заданные сценарии и явно фиксируют непокрытые классы.

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

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

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

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

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

Гардиан — агент-надзиратель для проверки заданных классов действий до исполнения. В исправном fail-closed пути отрицательный результат не выпускает действие наружу; полнота правил, bypass и отказ гейта проверяются отдельно. Несколько проверяющих образуют гардиан-mesh.

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

Human-in-the-loop (человек в контуре) — политика, по которой заданные необратимые и высокорисковые решения маршрутизируются человеку. В исправном fail-closed пути исполнение ждёт подтверждения; полноту классификации, обходы, гонки и отказ гейта проверяют отдельно.

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

Аудит решений ИИ — журнал предусмотренных событий: что решил контур, на каких данных, какие правила сработали и кто подтвердил. Append-only задаёт семантику добавления, но устойчивость к административной подмене обеспечивают отдельно — WORM или tamper-evident хранением, подписями либо цепочками хешей, контролем доступа и retention.

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

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

Строгий уровень — self-hosted модель в заданном периметре. Данные могут оставаться внутри него только при корректной сетевой изоляции и контроле телеметрии, зависимостей, обновлений и иных внешних вызовов. Такой вариант может изменить стоимость, задержку и качество; их измеряют для конкретной конфигурации. Сравнение — в разборе vLLM vs облачные API.

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

152-ФЗ (персональные данные). Для сценария определяют правовое основание, цель, минимизацию и технические меры; согласие — одно из возможных оснований, а не универсальная формула. Аудит-лог показывает только предусмотренные записанные события и сам по себе не доказывает законность, полноту или правильность обработки. Конкретную схему подтверждают с юристом.

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

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

1. Составить список необратимого. Прежде чем автоматизировать, выписать действия, которые по политике не должны исполняться без человека: платежи, публикации, удаление, внешние коммуникации от имени компании. Fail-closed поведение и обходные пути проверяются отдельно.
2. Поставить гейты на выбранных границах. Точки human-in-the-loop определять по цене ошибки, задержке и измерениям, а не считать необходимым гейт на каждый шаг.
3. Включить гардианов на классы рисков. Проверки заданных фактов, признаков нарушения правил и опасного ввода. Precision, recall, слепые зоны и правовая оценка остаются отдельными критериями.
4. Развернуть аудит с первого дня. Незаписанные события нельзя достоверно восстановить только из журнала; для разбора могут остаться другие первичные источники, но их полнота не гарантируется.
5. Изолировать данные. Минимизировать payload, тестировать покрытие маскирования, контролировать внешние вызовы и при необходимости проектировать self-hosted контур. Ни одна мера отдельно не гарантирует отсутствие утечки.
6. Расширять автономию постепенно. Начать с узкой зоны под плотным надзором и снимать гейты по мере накопления доверия и статистики, а не наоборот.

«Надзор потом». Если контроль добавить после сбоя, незаписанные события нельзя достоверно восстановить только из будущего журнала. Другие первичные источники могут помочь разбору, но не обещают полной истории; репутационный эффект также оценивается отдельно.

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

Считать append-only синонимом неизменяемости. Семантика «только добавление» помогает сохранить хронологию, но администратор обычного хранилища всё ещё может переписать файлы или базу. Для устойчивости к подмене нужны отдельные меры: WORM или tamper-evident хранение, подписи или цепочки хешей, контроль доступа, резервирование и проверяемая retention-политика.

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

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

Мы проектируем мультиагентные контуры с плоскостью управления, гардианами для заданных классов риска, human-in-the-loop на выбранных необратимых действиях и аудитом предусмотренных событий. Состав, fail-closed пути и остаточные слепые зоны фиксируются в критериях приёмки; собственные сценарии используем как один из тестовых контуров, но не как доказательство полноты защиты.

Живой пример — чат на этом сайте: до облачной модели он маскирует распознаваемые email, российские телефоны и длинные цифровые идентификаторы. Это снижает риск, но не распознаёт имена, адреса, @handle и все возможные ПДн, поэтому пользователь не должен вводить чувствительные сведения: иной свободный текст может быть передан облачному провайдеру. Для строгого периметра проектируется изолированный self-hosted контур без неучтённых внешних вызовов.

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