Governance AI-агентов: доступ, approval, audit

2026-09-14 · Слаживание

Если AI-агент может читать данные и делать шаги в ваших системах, ему нужны не “настройки по умолчанию”, а 3 слоя контроля: _доступ_, _согласование_ и _аудит_. Иначе одна ошибка может дойти до HR, платежей, договоров или инцидентов ИБ без человека в цепочке.

Я бы свёл смысл статьи к очень простой схеме:

• Доступ - агент видит и делает только то, что нужно под одну задачу
• Согласование - часть шагов идёт сама, часть требует проверки, часть запрещена без человека
• Аудит - каждый запрос, источник данных, решение и итог пишутся в журнал без права задним числом что-то менять

Это не теория. В статье приведён пример из августа 2026 года, когда агент на базе Claude) уволил сотрудника после анализа записей о прогулах. Для любой компании это один вывод: _если агент может влиять на людей, деньги или документы, его надо ставить в рамки до запуска, а не после сбоя_.

Вот что я бы вынес сразу:

• у каждого агента должна быть отдельная сервисная учётная запись
• права стоит выдавать на срок одной задачи с автоотзывом
• доступ к CRM, 1С, почте, дискам и другим системам лучше вести через единый слой политик
• действия надо делить по риску: зелёные, жёлтые, красные
• согласование должно относиться не “вообще к агенту”, а к конкретному действию, данным, сроку и исполнителю
• в журнале надо хранить не только API-лог, но и цель действия, использованные данные, policy на тот момент и итог

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

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

How to Build Audit-Ready Governance for Autonomous AI Agents | Okta

Доступ: что агент может видеть и делать

Первый слой управления - это база всей схемы. Именно доступ задаёт рамки, внутри которых потом работают согласование и аудит.

Отдельные идентификаторы и минимальные права

У каждого AI-агента должна быть своя сервисная учётная запись, конкретный владелец и жёстко ограниченный набор действий. Доступ стоит выдавать только на время задачи и сразу отзывать после завершения. Для этого подходят временные токены с сроком жизни под саму задачу. Логика простая: сначала агенту дают отдельную идентичность, потом урезают права через роли и политики.

Важно разделять низкорисковые инструменты и привилегированные системы. Поиск по базе знаний или чтение публичных отчётов - это один уровень. Доступ к зарплате, карточкам кандидатов и платёжным модулям - уже совсем другой. Такой доступ нужно открывать только под конкретную задачу и с автоотзывом сразу после её выполнения.

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

RBAC, ABAC и PBAC для корпоративных агентов

Для корпоративных агентов чаще всего используют три модели доступа.

На практике крупные компании редко выбирают что-то одно. Обычно модели комбинируют: RBAC задаёт базовые роли, ABAC добавляет ограничения по контексту, а PBAC проверяет каждое действие прямо в момент выполнения. Такой подход не выглядит изящно на бумаге, зато в жизни работает куда лучше.

Единый слой управления интеграциями

Все интеграции - CRM, 1С, почта, диск, телефония - лучше пропускать через единый брокер политик. Он проверяет роль агента, контекст запроса и тип действия, а уже потом решает: пропустить запрос или заблокировать.

Слаживание помогает собрать единый контур доступа. Агент работает внутри периметра клиента, с разделением ролей, токенизацией и on-prem-развёртыванием, если это нужно.

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

Согласование: где автоматика останавливается и нужен человек

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

Уровни риска для действий агента

Действия агентов удобно делить на три уровня.

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

Жёлтый - нужно подтверждение по политике. Например, изменение статуса кандидата в HR-системе, правка записи в финансовом реестре или доступ к журналам инцидентов безопасности. Такое действие можно откатить, но ошибка уже обходится дорого.

Красный - только человек. Это инициация платежа, изменение условий договора, увольнение сотрудника. Тут ставка слишком высока, чтобы пускать всё на самотёк.

Согласование привязано к конкретному запросу

Согласование должно относиться не “вообще” к задаче, а к конкретному действию, конкретному набору данных, конкретному агенту и заданному сроку. Если срок истёк, согласование аннулируется.

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

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

На практике такой подход проще всего закрепить через матрицу по функциям и типам действий.

Матрица согласования: продажи, HR, финансы, безопасность

Дальше уже стоит отдельно зафиксировать, какие именно действия и решения нужно хранить в журнале.

Аудит: как сделать действия агентов проверяемыми

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

Что должен фиксировать журнал действий

Одних технических API-логов здесь мало. Запись вроде «агент вызвал инструмент» почти бесполезна: она не даёт понять, зачем это было сделано и к чему привело. Журнал должен хранить не только сам вызов, но и цель действия.

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

Неизменяемость и доказательная база

Редактируемый лог не подходит как доказательство. Журнал должен быть защищён от изменений: ни агент, ни администратор не должны иметь возможности удалить запись или переписать её после создания. Для финансовых операций, HR-решений и изменений конфигурации это особенно важно.

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

Когда в 2026 году Claude от Anthropic автономно уволил сотрудника магазина в Сан-Франциско за прогулы [1], отсутствие такого журнала сильно осложнило бы разбор инцидента: кто запустил агента, какая политика была активна, было ли действие санкционировано.

Таксономия событий для аудита агентов

Ниже - типы событий, которые важно разделять в журнале.

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

Операционная модель: как запустить governance, не тормозя бизнес

Минимальный пакет для первого запуска

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

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

Поэтапное развёртывание по отделам

Когда политики и журнал уже заданы, переходите к одному пилотному сценарию. Хороший ориентир - подход к пилотированию системы «СВОД»: сначала ограниченный пилот, потом масштабирование [2].

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

Есть и ещё один важный момент. В каждом отделе нужен отдельный ответственный за трансформацию. Это тот человек, который следит, чтобы governance не оставался документом “для галочки”, а работал в ежедневных процессах.

Слаживание помогает провести диагностику, запустить пилот и проверить эффект без расширения на всю компанию.

Заключение: три контроля, которые делают агентов управляемыми

ИИ-агенты уже становятся частью операционного контура компании. Если не задать структуру заранее, риск быстро выходит из-под контроля. Доступ, согласование и аудит - это три опоры, которые помогают держать агентов под контролем и не останавливать автоматизацию.

FAQs