AI-агенты в GRC уже забирают у специалистов тестирование контролей, сбор доказательств и сопоставление требований разных стандартов. Главный риск для команды комплаенса — не сама автоматизация, а ситуация, в которой агент делает выводы по плохим данным, а человек не способен ни объяснить, ни оспорить результат. Для российских IT-компаний это знакомый сюжет: ручные таблицы и скриншоты пока держатся бодро, но аудиторы, ИБ и владельцы продуктов всё чаще ищут способ превратить их в управляемый процесс.
Об этом пишет BleepingComputer в спонсорской колонке сооснователя и CEO платформы Anecdotes Яира Кузницова. Его тезис звучит жёстко: GRC-менеджера заменит не искусственный интеллект, а коллега, который раньше научился ставить задачи агентам, проверять их работу и отвечать за принятые ими решения.
Под GRC обычно понимают governance, risk and compliance — управление, риски и соответствие требованиям. На практике это проверка доступов, контроль уязвимостей, сверка политик, сбор артефактов для аудита, заполнение реестров рисков и подготовка отчётов. Значительная часть этой работы состоит из повторяющихся действий: запросить выгрузку, проверить дату, приложить подтверждение, сопоставить контроль с пунктом стандарта. Именно на таких задачах программные агенты выглядят убедительнее всего: они не устают, не забывают напомнить владельцу системы и могут обработать большой объём однотипных данных.
Но автоматизация не отменяет ответственность. Если агент получает устаревший экспорт, скриншот без контекста или вручную сведённую таблицу, он способен быстро подготовить аккуратный и совершенно неверный отчёт. Плохо здесь не только качество результата: ошибка получает видимость достоверности, потому что оформлена как вывод системы. На встрече с руководством такой отчёт может оказаться опаснее честно незаполненного поля.
Данные важнее красивой панели
Первый навык, который автор предлагает развивать GRC-специалистам, — грамотность в данных. Речь не о том, чтобы каждому менеджеру переквалифицироваться в data engineer. Нужно уметь пройти от доказательства по конкретному контролю к первоисточнику: API, журналу событий, конфигурации облака, системе управления доступом или другой системе, где факт возник. И затем понять, насколько этим данным можно доверять.
Это меняет привычный порядок работы. Вместо вопроса «собрали ли мы доказательства?» появляется другой: «какой процесс и какая интеграция гарантируют, что доказательства появляются регулярно, полны и не были изменены по дороге?» Для разработчиков и DevOps-команд это означает больше запросов на стабильные API, нормальные схемы данных, журналирование и понятного владельца интеграции. Для бизнеса — меньше ручного труда перед аудитом, но только если на фундамент данных выделены деньги и время, а не лишь на лицензию для очередного AI-сервиса.
Второй навык — управление самими агентами. Кузницов предлагает относиться к каждому из них как к сотруднику, за работу которого отвечает руководитель. До доступа к рабочему контуру должны быть определены задача, допустимые действия, порог точности, ожидаемый эффект, стоимость использования и условия эскалации человеку. Агент, который молча пропускает проблемные случаи ради высокого показателя, и агент, который эскалирует каждую мелочь, одинаково плохо выполняют роль.
Здесь AI-агенты в GRC превращают комплаенс из функции сбора документов в инженерную дисциплину. Команде потребуется следить за метриками: сколько проверок проведено, сколько решений подтверждено или отменено человеком, какова доля ложных срабатываний, где агент перестал справляться после изменения системы или политики. Это не обязательно требует создания отдельного отдела по «агентному управлению». Но без явного владельца, регулярного контроля и возможности быстро ограничить полномочия автоматизация становится не ускорением, а неконтролируемым источником риска.
Наблюдаемость — не декоративная опция
Третий навык — коммуникация, причём не в смысле презентаций с градиентами. Инструкции агенту должны быть похожи на хороший runbook: конкретные входные данные, условия остановки, исключения, ожидаемый формат результата и маршрут эскалации. Если несколько агентов передают работу друг другу, каждый переход должен оставлять видимый след с отметкой времени. Иначе после ошибки команда получит знакомое, но особенно неприятное «система так решила».
Для компаний, работающих с персональными данными, финансовыми системами, критической инфраструктурой или строгими требованиями заказчиков, это вопрос не только удобства. Нужны журналы действий, сохранённый контекст решения, понятные границы доступа и процедура отката. Разработчикам придётся закладывать наблюдаемость в интеграции, а владельцам рисков — заранее решать, какие действия допустимы без человека, а где автоматизация может лишь подготовить рекомендацию. Граница зависит от процесса: напомнить о просроченном подтверждении доступа и закрыть доступ сотруднику — задачи совсем разной цены ошибки.
В российской практике дополнительную сложность создаёт разнородный ландшафт: часть доказательств живёт в отечественных системах, часть — в самописных сервисах, часть — в почте и таблицах. Поэтому попытка начать с универсального агента, который «сам всё разберёт», почти наверняка закончится дорого. Реалистичнее выбрать один повторяемый контроль, описать его источники, критерии качества и исключения, затем проверить результаты на исторических данных и только после этого расширять область применения.
AI-агенты в GRC не делают профессию ненужной — они снижают ценность механического сбора подтверждений и повышают ценность контекста, контроля и способности объяснить решение. Победит не тот, кто первым подключит агента к корпоративным данным, а тот, кто сможет доказать, откуда взялся каждый вывод, кто его проверил и что произойдёт, если агент ошибётся. Подробную позицию автора можно сверить в .
