Реестр ИИ-агентов в компании: что фиксировать о правах, данных и владельцах

Одна строка должна объяснять назначение

Запишите название агента, владельца процесса, пользователей, задачу, источники данных, инструменты, разрешённые действия, дату последней проверки и канал связи при сбое. Для внешних ответов отдельно отметьте, кто утверждает текст и где сохраняется история. Если агент не имеет имени или владельца, лучше остановить расширение его прав до прояснения ответственности.

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

Разделите риск по действию

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

Проверьте актуальность раз в месяц

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

Playbook NIST AI RMF предлагает практики управления и мониторинга с учётом контекста; полный список не является обязательным чек-листом для каждой компании. Реестр — простой способ применить этот принцип: знать, какие системы работают и на каком основании.

Что делать при инциденте

У каждой строки должны быть контакты и инструкция остановки. Команда должна уметь отключить внешние действия, оставить принятые задачи в очереди и восстановить историю выполненного. Если агент после сбоя продолжает писать клиентам с неизвестным состоянием CRM, список его возможностей уже недостаточен: нужен план восстановления.

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

Как заполнить первую версию за один день

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

Когда запись должна измениться

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

Проверка после первого заполнения

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

Что делать с агентом, которого никто не признаёт своим?

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