M365Con 2027 – безкоштовна онлайн-конференція · 11–22 Jan 2027 · 120 sessions→ m365con.net
Головна / Українська / 2026-10-29
M365.FM · Українська

ШІ-агент для GRC на Microsoft Purview, Power Automate і Copilot Studio

автоматичні звіти про відповідність

Ручна GRC-звітність зазвичай означає вивантаження журналів Purview, розбір в Excel і надію, що графіки будуть актуальними й за тиждень. У цьому випуску показано, як агент на основі правил із Purview, Power Automate і Copilot Studio збирає, оцінює й зрозуміло описує дані аудиту.

▶ ШІ-агент для GRC на Microsoft Purview, Power Automate і Copilot Studio: автоматичні звіти про відповідність (ШІ-дубляж)

Що ви дізнаєтеся:

  1. Три голови агента: Purview як пам’ять, Power Automate як нервова система, Copilot Studio як перекладач зрозумілою мовою
  2. Конвеєр даних: конектор Purview або API журналу аудиту, службовий обліковий запис з роллю читача, секрети в Key Vault, фільтри подій
  3. Розбір JSON, зберігання даних у SharePoint або Dataverse і розклад через тригер повторення в потрібному часовому поясі
  4. Логічний рівень: фільтрація, видалення дублів, підрахунок за користувачами й операціями, рівні ризику за порогами, повторні спроби та журнал помилок
  5. Звіти в Copilot Studio: підсумок для керівництва, технічний додаток, рекомендації, публікація в Teams, архів у SharePoint і версії промптів

Цей випуск — українська версія з ШІ-дубляжем анімованого відео з M365 Show від Microsoft MVP Мірко Петерса.

GRC, тобто управління, ризики та комплаєнс, у багатьох командах досі означає ручну роботу: логи аудиту копіюють в Excel, зведені таблиці множаться, а звіт застаріває, щойно з'являються нові події. Комплаєнс перетворюється на вправу з документування замість реального контролю.

GRC-агент на Microsoft Purview, Power Automate і Copilot Studio
  1. 1Джерело данихЖурнали аудиту Microsoft Purview підключають через конектор або API з правами читача журналів аудиту.
  2. 2Фільтрація та розбірВідбирають події з реальним ризиком і розбирають JSON у структуровані поля через Parse JSON.
  3. 3Сховище й розкладОчищені дані зберігають у SharePoint чи Dataverse, а потік запускає тригер Recurrence.
  4. 4Пороги ризикуPower Automate підраховує події й за заданими порогами визначає рівень ризику.
  5. 5Звіт від Copilot StudioСтруктурований JSON перетворюється на текстовий звіт за чіткими заголовками й нейтральним тоном.
  6. 6Публікація й доказиРезюме йде в Teams, повна версія в SharePoint, з ідентифікатором запуску та версіями.
M365.FM · Mirko Peters

Є й інший підхід: GRC-агент на базі екосистеми Microsoft. Microsoft Purview постачає дані, Power Automate збирає й обробляє їх за розкладом, а Copilot Studio перетворює результат на зрозумілий звіт. Нижче розглянемо, як побудувати таку систему крок за кроком.

Чому ручна GRC-звітність не працює

Ручна звітність виникає, коли організації плутають документацію з інсайтами. Дані витягують із Microsoft Purview, експортують, розкладають по таблицях і називають це управлінням. Усе починається з охайної книги та кількох фільтрів, а закінчується десятками вкладок із розрізненими зведеними таблицями. Наступного тижня дані змінюються, і бездоганні графіки вже показують неактуальну картину.

Purview часто сприймають як сейф, який відкривають лише перед аудитом. Тим часом журнали аудиту тихо накопичують величезні обсяги даних про те, хто, що, де і коли зробив. Кожен запис — це щільний JSON-блок. Обробляти їх вручну можна, але це шлях до вигорання, а не до підзвітності.

Є й структурний ризик: якщо процес тримається на одному аналітику, його відсутність руйнує аудиторський слід. Справжній ризик — не автоматизація, а надто крихкий ручний процес.

Що таке GRC-агент на Microsoft Purview, Power Automate і Copilot Studio

GRC-агент — це структурована автоматизація на стеку Microsoft, яка поводиться як інтелектуальна система. Її можна уявити як істоту з трьома «головами», кожна з яких виконує свою роль.

  • Microsoft Purview — пам'ять і сирі дані: журнали аудиту, дані класифікації, події відповідності.
  • Power Automate — нервова система: збирає сигнали, відфільтровує шум і запускає процеси за графіком.
  • Copilot Studio — «рот» і перекладач: перетворює технічні журнали на зрозумілі людині підсумки.

Основа підходу проста: значна частина завдань комплаєнсу — це не судження, а розпізнавання шаблонів. Аналітики годинами переглядають стовпці з типами активності та статусами результатів, хоча автоматизація може категоризувати й підсумувати їх сама. Система не намагається думати як людина — вона структурує краще за людину.

Чим агент відрізняється від дашборду

Дашборди показують, але не пояснюють. Агент натомість пише: перетворює шаблони на речення й усуває розрив в інтерпретації, який нерідко стає причиною проблем під час перевірок. Коли керівник питає про динаміку ризиків, йому можна надіслати готовий текстовий звіт, а не посилання на дашборд, якому ви самі ледве довіряєте.

Цей стек детермінований: ви самі визначаєте логіку, частоту, обсяг і навіть тон викладу. Автономність тут — не випадковість, а дисциплінована автоматизація.

Конвеєр даних: як підключити журнали аудиту Purview до Power Automate

Перш ніж агент зможе щось аналізувати, він має «бачити». Для цього потрібен конвеєр, який дає доступ лише до потрібних сегментів аудиторських даних Purview.

Вилучення даних

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

Доступи та облікові дані

Power Automate діє лише в межах наданих дозволів. Якщо сервісний обліковий запис потоку не може читати журнал аудиту, агент дивитиметься в порожнечу й сумлінно звітуватиме про відсутність проблем. Це сліпота, замаскована під успіх. Переконайтеся, що обліковий запис має роль читача журналів аудиту в Purview і може проходити автентифікацію без переривання через MFA. Облікові дані зберігайте в Azure Key Vault або у посиланнях на з'єднання.

Фільтрація за індикаторами ризику

Нікому не потрібна кожна подія доступу до файлів. Фільтруйте за реальними індикаторами ризику:

  • вхід користувача з нової локації;
  • зміна призначення ролі;
  • активація зовнішнього обміну;
  • зміна політики міток.

Фільтрувати можна на етапі запиту, через параметри API, або пізніше в Power Automate за допомогою умовної логіки.

Розбір JSON і сховище

Далі JSON-блоки перетворюють на структуровані поля за допомогою дії Parse JSON зі схемою, створеною на основі зразка події Purview. Кожна властивість — ідентифікатор користувача, операція, робоче навантаження, статус результату, IP-клієнт — стає окремою змінною. Частину полів Microsoft подає як масиви навіть з одним значенням, інші ховає під кількома рівнями вкладеності, тому кожне вилучення варто тестувати на невеликих вибірках.

Очищені дані зручно зберігати в SharePoint, Dataverse або SQL — залежно від складності звітів. Таке сховище працює як короткочасна пам'ять і дає змогу порівнювати з попередніми днями без постійних запитів до Purview. Dataverse краще підходить для роботи зі стовпцями та зв'язками між наборами даних, а SharePoint простіший, але стає незграбним після кількох тисяч рядків.

Розклад і обробка помилок

Для запуску використовуйте тригер Recurrence: щоденний для динамічних середовищ, щотижневий для спокійніших. Налаштовуйте його на свій часовий пояс, а не на UTC, інакше звіти можуть приходити посеред ночі. Також припускайте, що API іноді повертатиме помилку через забагато запитів: створіть політику повторних спроб і резервні повідомлення, записуйте помилки в лог і надсилайте сповіщення в Teams. Збої варто обробляти як дані, а не як драму, адже аудитори карають не за помилки, а за їх відсутність у документації.

Ручна GRC-звітність проти GRC-агента

Ручна звітність

  • Логи аудиту копіюються в Excel, таблиці множаться
  • Звіт застаріває, щойно з'являються нові події
  • Процес тримається на одному аналітику, аудиторський слід крихкий
  • Комплаєнс стає вправою з документування
  • Ручна обробка JSON-блоків веде до вигорання

GRC-агент на стеку Microsoft

  • Purview постачає дані, Power Automate обробляє їх за розкладом
  • Copilot Studio пише зрозумілий текстовий звіт
  • Кожен звіт використовує ті самі пороги, терміни та метадані
  • Логіка, частота, обсяг і тон визначені заздалегідь
  • Комплаєнс стає безперервним процесом із простежуваним походженням
M365.FM · Mirko Peters

Логіка агента в Power Automate: пороги, ризики й докази

Power Automate — це не штучний інтелект. Він не вгадує й не вигадує ризики, а послідовно виконує кроки, і саме ця передбачувана жорсткість потрібна для автономності.

Структура потоку

  1. Тригер Recurrence запускає потік за розкладом, узгодженим із часовим поясом аудиторів.
  2. Блок ініціалізації створює змінні: загальна кількість подій, кількість високих ризиків, дата звіту. Це робоча пам'ять агента.
  3. Конектор журналів аудиту Purview або HTTP-запит отримує дані.
  4. Крок Filter array прибирає шум. Типовий шаблон — ігнорувати записи сервісних суб'єктів і залишати лише операції, пов'язані з керуванням даними чи зміною політик.
  5. Дублікати видаляються виразом Union або порівнянням у циклі.
  6. Дії Compose або Select групують записи за користувачем і операцією, а цикли Apply to each підсумовують кожну категорію.

У результаті агент має знімок стану: хто що зробив, як часто і чи виходить це за межі визначених ризиків.

Пороги замість здогадок

Рівень ризику визначається за вашими порогами. Наприклад, якщо кількість підвищень привілеїв дорівнює трьом, ризик — «високий»; якщо є одне зовнішнє поширення — «середній»; в іншому разі — «нормальний». Так поняття «забагато» отримує числове вираження замість людських здогадок.

Використовуйте вкладені умови: високий ризик додає користувача до окремого масиву, середній можна поставити в чергу на перевірку. Якщо нічого незвичайного немає, запишіть повідомлення про відсутність результатів. У комплаєнсі різниця між відсутністю даних і нульовим результатом принципова.

Докази виконання

Кожен запуск має залишати артефакти. Фінальна дія (Append to File або Create Item) зберігає підсумкові метрики: загальну кількість подій, користувача з найвищим ризиком, тривалість виконання. Додайте також ідентифікатор запуску та версію потоку, тоді навіть після зміни порогів аудитори зможуть відстежити, яка логіка призвела до конкретного результату.

Copilot Studio: як навчити агента писати звіти про відповідність

До цього моменту агент ефективний, але мовчазний. Copilot Studio дає йому голос: перетворює структуровані дані на параграфи, достатньо зрозумілі для керівників і достатньо точні для аудиторів.

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

Спершу визначте, які тексти вам потрібні. Зазвичай їх три: виконавче резюме, технічний додаток і рекомендації. Керівництву потрібен один параграф, аудиторам — доказова база, а технічному персоналу — кожне поле. Усередині одного агента в Copilot Studio можна створити кілька запитів (промптів), кожен із власним тоном, форматом і обсягом. Наприклад: «Підсумуйте основні ризики простою мовою, обмежтеся п'ятьма пунктами та запропонуйте рішення для кожного».

Підключення до Power Automate

У потоці використовується HTTP-дія, яка надсилає структурований JSON-пакет на кінцеву точку Copilot. Виклик автентифікується через Azure AD, тож доступ має лише ваш потік. У відповідь ви отримуєте текст, і саме він стає звітом: знахідки впорядковані за серйозністю, до кожної додано одну рекомендовану дію, наприкінці — загальна тенденція.

Дисципліна промптів

  • Вкажіть точні заголовки: «Огляд», «Ключові висновки», «Рекомендації».
  • Задайте професійний нейтральний тон, уникайте спекулятивної мови, вимагайте кількісних показників.
  • Використовуйте контекстні змінні, наприклад дату звіту чи кількість проаналізованих подій, щоб вони автоматично підставлялися у вивід.

Що чіткіші інструкції, то краще відтворюваний результат, а комплаєнс потребує саме відтворюваності, а не індивідуальності. Copilot тут не вигадує, а описує статистику, яку йому передали.

Перевірка і розповсюдження

Додайте умову, яка перевіряє, що відповідь Copilot не порожня. Якщо вона порожня, помилку записують у журнал і повторюють спробу один раз. Далі потік розгалужується: стисле резюме публікується в каналі Teams для керівництва, а повна HTML-версія зберігається в SharePoint для аудиторів. Обидва варіанти мають автоматичну позначку часу й однакове формулювання.

Щоразу, коли змінюються критерії відповідності, створюйте нову версію системного запиту (V1, V1.1 тощо) і фіксуйте, яка версія сформувала конкретний звіт. Так майбутні аудити зможуть посилатися не лише на те, що сталося, а й на інструкції, які мала мовна модель у той момент.

Типові помилки та стопори

  • Бракує прав у сервісного облікового запису. Без ролі читача журналів аудиту агент повідомляє про «нуль проблем», хоча насправді просто нічого не бачить. Це найнебезпечніший збій, бо він виглядає як ідеальна відповідність.
  • MFA блокує автентифікацію. Автоматизація не може підтвердити вхід посеред ночі, тому обліковий запис має проходити автентифікацію без втручання людини.
  • Надто широкий обсяг подій. Завантаження всього потоку аудиту без фільтрів перевантажує процес і ховає сигнали в шумі.
  • Помилки в схемі JSON. Невелика друкарська помилка у вилученні поля згодом перетворюється на безглузді дані у звіті.
  • Неправильний часовий пояс. Розклад на UTC може доставляти звіти в невчасний час.
  • Відсутня обробка помилок. API може не витримати великої кількості запитів, а без повторних спроб і логів збій лишається непоміченим.
  • Вільний промпт без обмежень. Якщо не вказати заголовки й тон, Copilot може обрати невідповідний для аудиторського звіту стиль.

Практичні висновки

  • Обмежуйте сферу журналів аудиту Purview подіями, які справді впливають на відповідність.
  • Надайте сервісному обліковому запису роль читача журналів аудиту й зберігайте облікові дані в Azure Key Vault або посиланнях на з'єднання.
  • Фільтруйте за індикаторами ризику: нова локація, зміна ролей, зовнішній обмін, зміна політики міток.
  • Розбирайте JSON через Parse JSON зі схемою зі зразка й тестуйте на малих вибірках.
  • Зберігайте очищені дані в SharePoint або Dataverse для порівняння з попередніми періодами.
  • Налаштуйте Recurrence у власному часовому поясі, політику повторних спроб і сповіщення в Teams.
  • Закодуйте пороги ризику явно та розрізняйте «немає даних» і «нульовий результат».
  • Фіксуйте ідентифікатор запуску, версію потоку й версію промпту в кожному звіті.
  • Публікуйте резюме в Teams, а повну версію архівуйте в SharePoint.
Типові помилки під час побудови GRC-агента
M365.FM · Mirko Peters

Висновок

Зв'язка Microsoft Purview, Power Automate і Copilot Studio замінює ручну звітність єдиним робочим процесом: Purview збирає дані, Power Automate фільтрує, класифікує й документує, а Copilot Studio пояснює результат зрозумілою мовою. Головна перевага — не швидкість, а стандартизація: кожен звіт використовує ті самі пороги, терміни та метадані, а аудитори оцінюють суть, а не формат. Комплаєнс перестає бути спринтом перед аудитом і стає безперервним процесом із простежуваним походженням кожного висновку.

Часті запитання

Що таке GRC-агент на базі Microsoft Purview, Power Automate і Copilot Studio?

Це структурована автоматизація на стеку Microsoft, яка поводиться як інтелектуальна система. Purview постачає сирі дані з журналів аудиту, Power Automate збирає, фільтрує й обробляє їх за розкладом, а Copilot Studio перетворює результат на зрозумілий звіт.

Чим GRC-агент відрізняється від звичайного дашборду?

Дашборд показує дані, але не пояснює їх. Агент пише текстові звіти: перетворює шаблони на речення й усуває розрив в інтерпретації, який часто спричиняє проблеми під час перевірок. Керівнику можна надіслати готовий звіт замість посилання на дашборд.

Чому агент може повідомити «нуль проблем», хоча насправді проблеми є?

Так буває, якщо сервісний обліковий запис потоку не має ролі читача журналів аудиту в Purview. Тоді агент нічого не бачить і сумлінно звітує про відсутність проблем. Це найнебезпечніший збій, бо він виглядає як ідеальна відповідність.

Як у Power Automate визначити рівень ризику без здогадок?

Рівень ризику задають явними числовими порогами. Наприклад, три підвищення привілеїв означають «високий» ризик, одне зовнішнє поширення — «середній», в іншому разі — «нормальний». Для цього використовують вкладені умови, а відсутність даних відрізняють від нульового результату.

Інші випуски

Годі ШІ-хаосу: дія RFI в Microsoft Copilot Studio для…

Як зупинити галюцинації ШІ

Copilot Studio чи Azure AI Foundry

Корпоративний ШІ з Power Platform і Azure OpenAI

Керування агентами Copilot

Copilot відповідає розмито? Наведіть лад у правах…

Усі випуски →