Governance ИИ-агентов без ML-отдела: чеклист для ЛПР

Почему governance агентов — это не про ML, а про ответственность

Вы запустили первого агента. Он прошёл пилот, показал метрики — и теперь работает с реальными данными: создаёт задачи в CRM, ищет документы в 1С, отвечает клиентам. В этот момент контроль перестаёт быть вопросом «качества модели» и становится вопросом «кто отвечает головой».

IBM в своём Agentic AI Governance Playbook формулирует это точно: старый governance был про валидацию модели до деплоя, новый — про контроль каждого действия агента в реальном времени. Провалы случаются не в пилоте, а при интеграции в живые процессы, когда агент получает доступ к данным, которые не должен видеть, или когда его действия перестают соответствовать изначальному замыслу.

Для компании без ML-отдела это означает: governance не требует data scientist’ов. Он требует трёх ролей, которые у вас уже есть: IT-директор, бизнес-владелец процесса, специалист по информационной безопасности. Их задача — выстроить систему, в которой каждый агент имеет именованного владельца, задокументированные права доступа, логируемые действия и понятную процедуру отключения.

Чеклист запуска governance с нуля: 7 шагов до первого агента в продакшне

Вы можете пройти эти шаги за две недели силами существующей команды.

1. Инвентаризация активных агентов. Составьте список всех агентов, которые уже работают или готовятся к запуску. Для каждого зафиксируйте: название, назначение, текущий владелец (если есть), перечень инструментов и источников данных.
2. Назначение владельца. Каждый агент получает named owner из бизнес-подразделения. Владелец отвечает за цель агента, актуальность его конфигурации и регулярный ревью. Без владельца агент не получает доступ к продуктиву.
3. Создание реестра агентов. Простой документ (таблица или Confluence-страница) с обязательными полями: ID агента, имя, владелец (ФИО и роль), статус (active/retired), дата последнего ревью, разрешённые инструменты, запрещённые категории данных. Это ваш agent registry.
4. Определение data access зон. Для каждого агента пропишите, к каким данным он имеет доступ и в каком режиме: read-only, masked, запрещено. Учитывайте категории: ПДн, коммерческая тайна, публичные данные. (Подробная таблица — в разделе ниже.)
5. Включение логирования tool calls. Минимально: каждая операция агента (вызов API, чтение файла, запись в базу) логируется с полями agentid, toolname, timestamp, policy_decision (allow/deny). Логи хранятся в неизменяемом виде.
6. Настройка policy enforcement. На каждое действие агента должен срабатывать policy decision: разрешено ли агенту с такими правами выполнять этот tool call. Если нет — действие блокируется, инцидент логируется. Это можно реализовать через middleware на API-шлюзе или через встроенные механизмы платформы агента.
7. Утверждение процедуры offboarding. Закрепите регламент: при выводе агента из эксплуатации его учётные данные отзываются в течение 24 часов, запись в реестре переводится в статус retired, владелец уведомляется.

Паспорт агента: шаблон, который заполняется за 30 минут

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

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

Матрица ответственности RACI без ML-ролей

В классических фреймворках governance фигурируют CDO, MLOps, AI Risk Officer. В компании без ML-отдела эти роли распределяются между четырьмя существующими позициями. Ниже — матрица для шести ключевых решений.

R — Responsible (исполнитель), A — Accountable (принимает окончательное решение и отвечает головой), C — Consulted (консультирует), I — Informed (информируется).

Ключевой принцип: бизнес-владелец отвечает за то, что делает агент, IT-директор — за как это реализовано технически, ИБ-специалист — за безопасность данных. Юрист подключается на этапе запуска, если агент касается ПДн или регуляторных требований.

Data access зонирование: как не нарушить 152-ФЗ и не дать агенту лишнего

Агент без явного ограничения доступа — это сотрудник с правами администратора, который выполняет команды на естественном языке. Чтобы избежать утечек, разграничьте данные по категориям и примените least-privilege.

Если агент использует внешний LLM (OpenAI, Anthropic), передача ПДн через API без отдельного DPA и без проверки трансграничной передачи — прямое нарушение. С мая 2025 года регистрация оператора ПДн обязательна, а оборотные штрафы за утечку 1–10 тыс. субъектов достигают 3–5 млн ₽. При повторном нарушении штраф считается как процент от выручки.

Практический совет: для агентов, работающих с CRM или 1С, создайте отдельные service accounts с правами только на необходимые объекты. Никогда не используйте shared API-ключ на нескольких агентов — при инциденте вы не сможете определить, кто именно выполнил действие.

Еженедельный дашборд ЛПР: 5 метрик с порогами

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

1. % агентов с named owner в реестре. Цель ≥95%. Если агент есть в проде, но не имеет владельца — это orphan, который должен быть немедленно назначен или остановлен.
2. Orphan-agent count. Цель = 0. Каждый такой агент — инцидент. Причина появления: увольнение сотрудника-владельца без передачи ответственности или запуск агента «на коленке» без регистрации.
3. % tool calls с policy decision. Цель ≥90%. Показывает, какая доля действий агента прошла через проверку политик. Если меньше 90% — у вас есть слепая зона, где агент действует без контроля.
4. Control drift rate. Красная зона >5%. Это доля агентов, чья текущая конфигурация (модель, промпт, права доступа) отличается от утверждённого baseline. Дрифт возникает, когда разработчик меняет промпт «на лету» без ревью владельца.
5. Median time to revoke credentials после offboarding. Цель <24 часов. Если агент выведен из эксплуатации, а его учётные данные всё ещё активны — вы сохраняете вектор атаки.

Дополнительно отслеживайте escalation rate — долю запросов, переданных человеку. Базовая линия устанавливается в первые две недели; отклонение более чем на 20% от baseline — триггер для ревью. Подробнее о проектировании эскалации — в статье human-in-the-loop-peredacha.

Чеклист инцидента: 6 шагов без ML-команды

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

1. Остановка агента. IT-директор немедленно отзывает service account или блокирует API-ключ. Время реакции — минуты, а не часы.
2. Фиксация логов. ИБ-специалист выгружает все tool calls агента за последние 24 часа (или за период инцидента) в неизменяемый архив.
3. Определение масштаба. Какие данные были затронуты? Есть ли среди них ПДн? Если да — юрист оценивает необходимость уведомления Роскомнадзора в течение 24 часов.
4. Root cause analysis. Бизнес-владелец и IT-директор выясняют, что пошло не так: ошибка в промпте, слишком широкие права, отсутствие policy enforcement на конкретный tool call.
5. Корректировка политик. По результатам анализа обновляется паспорт агента, сужаются права доступа, добавляется новое правило в policy engine.
6. Post-mortem. Краткий документ (1 страница): что случилось, почему, что сделано, чтобы не повторилось. Рассылается всем владельцам агентов.

Три антипаттерна, которые мы видим в РФ-компаниях

1. Shared API-ключ на несколько агентов. Удобно для разработчика, смертельно для аудита. При инциденте логи показывают, что ключ использовался, но не говорят, какой именно агент выполнил действие. Решение: отдельный service account на каждого агента.

2. Широкий доступ к CRM «на всякий случай». Агент получает read/write на всю базу клиентов, хотя ему нужно только создавать задачи в определённом проекте. При сбое промпта он может изменить или слить данные всех субъектов ПДн. Решение: принцип least-privilege, доступ только к необходимым объектам через ролевую модель.

3. Отсутствие реестра агентов. Агенты запускаются в разных отделах, владельцы не назначены, после увольнения сотрудника агент продолжает работать. Через полгода вы обнаруживаете пять «сирот» с доступом к корпоративным системам. Решение: единый реестр с обязательным полем «владелец» и ежеквартальным аудитом.

Что делать, если агент уже в проде без governance

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

Оценку надёжности агента до запуска governance — метрики приёмки пилота, пороги PAEF/CLASSic — вы найдёте в статье agent-eval-priemka-pilota. Там же описано, как принять решение «агент готов к продуктиву». Наш чеклист начинается после этого решения.

Governance ИИ-агентов без ML-отдела — это не абстрактная рамка, а набор конкретных действий: реестр, паспорт, владелец, зоны доступа, метрики. Всё, что нужно, — выделить ответственных, заполнить шаблон и настроить логирование. Дальше система работает как часть операционного управления, а не как проект «внедрения AI-культуры».