ИИ-агент для GRC на Microsoft Purview, Power Automate и Copilot Studio

Отчёты по управлению, рискам и соответствию требованиям (GRC) часто делаются вручную: аналитик выгружает журналы аудита, копирует их в Excel и собирает десятки вкладок со сводными таблицами, которые противоречат друг другу. Комплайенс из защиты превращается в демонстрацию: часы обработки данных нужны лишь затем, чтобы убедить аудиторов, что всё под контролем.

Есть альтернатива: автоматизированный GRC-агент на инструментах Microsoft. Microsoft Purview служит источником аудиторской истины, Power Automate оркестрирует процесс, а Copilot Studio превращает сухие данные в понятный текст. Ниже разберём, как такого агента построить: от подключения журнала аудита до отчёта, который публикуется по расписанию без участия человека.

Почему ручная отчётность GRC не работает

Ручная отчётность появляется там, где документацию путают с инсайтами. Данные выгружаются из Microsoft Purview, растягиваются по электронным таблицам, а на следующей неделе появляются новые события, и безупречные графики устаревают. Аудиторские следы, которые должны обеспечивать подотчётность, в итоге приводят к выгоранию.

Вторая проблема в том, что многие компании относятся к Purview как к сейфу, который открывают только перед аудитом. Журналы аудита накапливают огромные объёмы данных о том, кто, что, где и когда делал. Но каждая запись представляет собой плотный JSON-блок, и разбирать такие блоки вручную можно только ценой выходных. Это избыток данных при нулевой читаемости.

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

Что такое GRC-агент и из каких компонентов он состоит

GRC-агент — это не магия, а структурированная автоматизация на стеке Microsoft. Условно у неё три «головы», и каждая отвечает за свою часть процесса:

• Microsoft Purview — сырая память: журналы аудита, данные классификации, события соответствия. Каждое действие пользователя в Microsoft 365, от обмена документом до изменения политики, протоколируется.
• Power Automate — нервная система: собирает сигналы, фильтрует шум, следит за выполнением процессов по расписанию. Это дисциплинированный инструмент, который ничего не забывает.
• Copilot Studio — «рот и переводчик»: берёт структурированные данные и выдаёт понятные человеку сводки. Вместо JSON получается фраза вроде «пользователь пять раз повысил привилегии за 24 часа, превысив пороговое значение политики».

Большая часть задач по комплайенсу — это не принятие решений, а распознавание образов. Агент не пытается мыслить как человек, он просто организует данные лучше. При этом стек детерминирован: вы сами определяете логику, периодичность, объём данных и даже тон изложения. Автономность здесь — не случайность, а дисциплинированная автоматизация с навыками работы с текстом.

Конвейер данных: подключаем Microsoft Purview к Power Automate

Прежде чем агент начнёт делать выводы, он должен получить доступ именно к нужным данным аудита — не больше и не меньше. Без этого вы просто автоматизируете слепоту.

Извлечение и права доступа

Данные можно получать через встроенный коннектор Purview или через HTTP-действие, напрямую обращаясь к API журнала аудита. Результат один — поток событий вашего тенанта: общие файлы, изменения прав доступа, входы администраторов и многое другое. Область охвата лучше ограничить заранее и выбрать только события, которые влияют на соответствие требованиям.

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

• назначьте сервисной учётной записи роль читателя журналов аудита в Purview;
• убедитесь, что она проходит аутентификацию без запросов MFA, ведь поток не сможет подтвердить вход в два часа ночи;
• храните учётные данные в Azure Key Vault или в ссылках на подключения.

Фильтрация и разбор JSON

Никому не нужны события доступа к каждому файлу. Отфильтруйте реальные индикаторы риска: вход из нового места, изменение назначения роли, включение внешнего общего доступа, изменение политики. Фильтровать можно на этапе запроса через параметры API или внутри Power Automate с помощью условий.

Затем JSON превращается в структурированные поля с помощью действия «Анализ JSON» (Parse JSON). Схему берут из примера события Purview. Каждое свойство — ID пользователя, операция, рабочая нагрузка, статус результата, IP клиента — становится отдельной переменной. Некоторые поля аудита приходят массивами даже с единственным значением, другие спрятаны под несколькими уровнями вложенности. Здесь помогают выражения и «Применить к каждому», а небольшая опечатка позже превращается в бессмыслицу, поэтому каждое извлечение стоит проверять на небольших тестовых запусках.

Хранилище и расписание

Очищенные данные можно сохранять в SharePoint, Dataverse или SQL — в зависимости от объёма. Хранилище работает как кратковременная память: агент проводит исторический анализ, не обращаясь постоянно к Purview. Dataverse лучше взаимодействует с Power Automate и подходит, если нужны связи между наборами данных. SharePoint проще, но становится неповоротливым, когда строк больше нескольких тысяч.

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

Логика Power Automate: пороги риска и классификация

Power Automate не угадывает и не выдумывает риски — он выполняет заданные правила. Эта предсказуемая жёсткость и нужна для автономности. Логический уровень строится как цепочка шагов.

1. Триггер периодичности с часовым поясом ваших аудиторов.
2. Инициализация переменных: общее количество событий, число рисков высокого уровня, дата отчёта. Они служат рабочей памятью агента.
3. Запрос к Purview через коннектор или HTTP API.
4. Фильтрация массива: убираем записи служебных учётных записей и оставляем только операции, связанные с управлением данными или изменением политик.
5. Удаление дубликатов: журналы часто повторяют одни и те же события.
6. Группировка по имени участника и операции и подсчёт по каждой категории.

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

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

Доказательства выполнения

Каждый запуск должен оставлять артефакты: общее количество обработанных событий, пользователя с наивысшим риском, длительность выполнения. Их сохраняют в канал Teams или библиотеку SharePoint. Добавьте ID запуска и версию потока: если пороги изменятся, аудиторы смогут отследить, какая логика привела к результату.

Copilot Studio: учим агента писать отчёты

До этого шага агент классифицирует, считает и принимает решения, но молчит. Copilot Studio даёт ему голос и превращает JSON из Power Automate в аккуратный дайджест, понятный руководителям и достаточно точный для аудитора.

Три типа коммуникации

Сначала определите, какие тексты нужны. Обычно это краткое резюме для руководства (одного абзаца достаточно), техническое приложение с доказательствами для аудиторов и рекомендации. Достаточно одного copilot в Copilot Studio с несколькими промптами, каждый из которых задаёт тон, формат и объём. Например: «Обобщите основные риски простыми словами, ограничьтесь пятью пунктами и предложите способы устранения для каждого» или «Составьте техническое приложение со списком всех событий высокого риска в виде таблицы».

Связка работает так: в потоке HTTP-действие отправляет структурированную JSON-нагрузку на URL Copilot, а тот интерпретирует данные по заданному системному промпту. Доступ защищён аутентификацией Microsoft, поэтому вызвать его может только ваш поток. На выходе получается текст, который и есть отчёт: по степени серьёзности, с одним действием на каждое нарушение и анализом тенденций в конце.

Публикация

Поток делится на две ветви. Одна публикует сводку в канале Teams, другая сохраняет полную HTML-версию в SharePoint. Руководство читает сообщение в Teams, аудиторы берут документацию из архива. Оба варианта приходят автоматически, с отметкой времени и идентичной формулировкой.

Дисциплина промпт-инжиниринга

• Укажите точные заголовки: «Обзор», «Ключевые выводы», «Рекомендации».
• Задайте директивы: профессиональный нейтральный тон, никаких предположений, измеримые метрики. Без ограничений Copilot может увлечься литературным стилем или эмодзи, а им не место в аудиторском отчёте.
• Используйте контекстные переменные и плейсхолдеры для даты отчёта, длительности выполнения и количества записей — получится метаконтекст вроде «проанализировано N событий аудита».
• Чем строже инструкции, тем воспроизводимее результат, а соответствие требованиям держится именно на воспроизводимости.

Частые ошибки и подводные камни

• Нет прав на журнал аудита. Агент не видит событий и радостно сообщает «проблем нет». Это не безопасность, а слепота, замаскированная под успех. Проверьте роль читателя журналов аудита.
• Запрос MFA для сервисной учётной записи. Автоматика не пройдёт проверку и остановится.
• Выгрузка всего потока аудита. Без заранее ограниченной области охвата объём данных становится неуправляемым.
• Опечатки в выражениях разбора JSON. Они приводят к бессмысленным результатам, поэтому тестируйте извлечение на малых запусках.
• UTC вместо местного часового пояса. Отчёты приходят в неудобное время.
• Нет обработки ошибок. API Purview может вернуть «слишком много запросов». Нужны политики повторных попыток: например, три попытки с экспоненциальной задержкой, а в ветке сбоя — запись сообщения об ошибке, метки времени и ID запуска в список «Здоровье автоматизации». При превышении заданных показателей отправляйте сообщение в Teams. Аудиторы наказывают не за ошибки, а за отсутствие документации по ним.
• Пустой или неточный ответ Copilot. Добавьте проверку, что ответ не пуст; если это так, зафиксируйте ошибку в журнале и повторите операцию один раз.
• Нет версионирования промптов. Без него невозможно показать, по каким инструкциям составлен конкретный отчёт.

Практические выводы

• Разделите роли: Purview хранит данные, Power Automate собирает и классифицирует, Copilot Studio формулирует текст.
• Ограничьте охват аудита событиями, которые реально влияют на соответствие требованиям.
• Выдайте сервисной учётной записи роль читателя журналов аудита и храните учётные данные в Azure Key Vault или ссылках на подключения.
• Разбирайте JSON через «Анализ JSON» и проверяйте результат на тестовых запусках.
• Выберите хранилище по объёму: Dataverse для связей между данными, SharePoint для простых случаев.
• Задайте числовые пороги риска и явно фиксируйте случай «находок нет».
• Настройте повторные попытки, журнал ошибок и уведомления в Teams.
• Сохраняйте артефакты каждого запуска: ID запуска, версию потока, итоговые метрики.
• Фиксируйте в системном промпте структуру, тон и запреты, а его версии (V1, V1.1 и так далее) помечайте и связывайте с отчётами.
• Публикуйте отчёт в двух ветвях: краткая сводка в Teams и полная версия в SharePoint.

Заключение

GRC-агент на Microsoft Purview, Power Automate и Copilot Studio превращает отчётность о соответствии из подготовки к аудиту в постоянный ритм. Purview собирает данные, Power Automate интерпретирует их по заданным правилам, Copilot Studio пишет понятный текст, а результат приходит по расписанию с проверяемым происхождением. Главное преимущество не в скорости, а в стандартизации: каждый отчёт использует одни и те же пороги, терминологию и метаданные, а аудиторы оценивают содержание, а не формат. Так комплайенс из процесса документирования становится процессом оркестрации.