M365Con 2027 – konferensi online gratis · 11–22 Jan 2027 · 120 sessions→ m365con.net
Beranda / Bahasa Indonesia / 2026-10-29
M365.FM · Bahasa Indonesia

Membangun Agen AI GRC dengan Microsoft Purview, Power Automate, dan Copilot Studio: Laporan Kepatuhan Otomatis

Pelaporan GRC manual sering berarti mengekspor log Purview, membongkarnya di Excel, dan berharap grafiknya masih benar minggu depan. Episode ini menunjukkan bagaimana agen berbasis aturan dari Purview, Power Automate, dan Copilot Studio mengambil, menilai, dan menjelaskan data audit.

▶ Membangun Agen AI GRC dengan Microsoft Purview, Power Automate, dan Copilot Studio: Laporan Kepatuhan Otomatis (Sulih Suara AI)

Yang akan Anda pelajari:

  1. Tiga kepala agen: Purview sebagai memori, Power Automate sebagai sistem saraf, dan Copilot Studio sebagai penerjemah ke bahasa yang jelas
  2. Pipeline data: konektor Purview atau API log audit, akun layanan dengan peran pembaca log audit, kredensial di Key Vault, dan filter peristiwa
  3. Mengurai JSON, menyimpan data di SharePoint atau Dataverse, dan menjadwalkan dengan pemicu pengulangan di zona waktu yang benar
  4. Lapisan logika: memfilter, menghapus duplikat, menghitung per pengguna dan operasi, tingkat risiko berdasarkan ambang, kebijakan coba ulang, dan log galat
  5. Laporan dengan Copilot Studio: ringkasan eksekutif, lampiran teknis, rekomendasi, kiriman ke Teams, arsip di SharePoint, dan prompt berversi

Episode ini adalah versi Bahasa Indonesia dengan sulih suara AI dari video animasi M365 Show oleh Microsoft MVP Mirko Peters.

Pelaporan tata kelola, risiko, dan kepatuhan (GRC) sering berubah menjadi pekerjaan manual yang melelahkan. Analis menyalin log audit ke Excel, membuat beberapa pivot table yang saling bertentangan, lalu menghabiskan berjam-jam untuk meyakinkan auditor bahwa semuanya terkendali. Kepatuhan yang seharusnya melindungi organisasi justru menjadi pertunjukan dokumentasi.

Agen GRC Otomatis dengan Purview, Power Automate, dan Copilot Studio
  1. 1Hubungkan log PurviewGunakan konektor Purview atau HTTP API, dengan akun layanan berperan pembaca log audit.
  2. 2Saring dan strukturkanBatasi peristiwa relevan, lalu ubah JSON menjadi kolom lewat Parse JSON dan simpan.
  3. 3Jadwalkan alurPakai pemicu pengulangan harian atau mingguan sesuai zona waktu Anda, bukan UTC.
  4. 4Tetapkan ambang risikoKondisi bersarang menentukan tingkat risiko tinggi, sedang, atau normal dari batas yang Anda tentukan.
  5. 5Tulis dengan Copilot StudioKirim payload JSON ke Copilot dan hasilkan ringkasan dengan prompt yang ketat dan terversi.
  6. 6Validasi dan distribusikanPeriksa respons tidak kosong, lalu kirim ke Teams dan arsipkan di SharePoint.
M365.FM · Mirko Peters

Ada alternatif yang lebih disiplin: agen GRC otomatis yang dibangun dari alat Microsoft sendiri. Microsoft Purview menjadi sumber data audit, Power Automate mengorkestrasi alur kerja, dan Copilot Studio menulis ringkasan dalam bahasa manusia. Artikel ini menjelaskan cara kerja agen tersebut dan langkah membangunnya, dari menghubungkan log Purview sampai menjadwalkan laporan otomatis.

Mengapa Pelaporan GRC Manual Bermasalah

Pelaporan manual muncul ketika organisasi menganggap dokumentasi sebagai wawasan. Data ditarik dari Microsoft Purview, diekspor, disebar ke spreadsheet, lalu disebut tata kelola. Seminggu kemudian aktivitas baru terjadi, data bergeser, dan grafik yang rapi tidak lagi mencerminkan kenyataan.

Masalah kedua adalah Purview yang diperlakukan seperti berangkas yang hanya dibuka menjelang audit. Log auditnya terus mengumpulkan data tentang siapa melakukan apa, di mana, dan kapan. Namun setiap entri berupa blob JSON yang padat dan sulit dibaca. Datanya melimpah, tetapi keterbacaannya nol.

Risiko terbesar sebenarnya adalah ketergantungan pada proses yang rapuh. Jika satu analis berhalangan, seluruh siklus pelaporan bisa terganggu.

Apa Itu Agen GRC dengan Purview, Power Automate, dan Copilot Studio?

Agen GRC di sini bukan kopilot ajaib yang menebak jawaban. Ia adalah otomatisasi terstruktur berbasis aturan yang memiliki tiga bagian, masing-masing dengan tugas yang jelas:

  • Microsoft Purview menyediakan memori mentah: log audit, data klasifikasi, dan peristiwa kepatuhan.
  • Power Automate bertindak sebagai sistem saraf. Ia mengumpulkan sinyal, menyaring kebisingan, dan memastikan proses berjalan sesuai jadwal.
  • Copilot Studio menjadi penerjemah. Ia mengubah jargon teknis dari log menjadi ringkasan yang dapat dibaca manusia.

Pendekatan ini berhasil karena sebagian besar tugas kepatuhan, sekitar 90 persen menurut pengamatan di balik metode ini, bukan keputusan berdasarkan penilaian, melainkan pengenalan pola. Mengategorikan dan meringkas pola semacam itu adalah pekerjaan yang cocok untuk otomatisasi. Sistem ini tidak mencoba berpikir seperti manusia. Ia mengikuti aturan yang Anda tentukan: logika, frekuensi, cakupan, bahkan nada bahasanya.

Berbeda dengan dashboard yang hanya menampilkan indikator berkode warna, agen ini menulis. Ia menerjemahkan pola menjadi kalimat dan mengurangi celah interpretasi yang sering menjadi sumber masalah dalam tinjauan kepatuhan.

Membangun Jalur Data dari Log Audit Purview

Sebelum agen bisa menganalisis, ia harus bisa melihat data yang tepat, tidak lebih dan tidak kurang.

Menghubungkan Power Automate ke Purview

Ada dua jalur: konektor Purview, atau tindakan HTTP yang memanggil API log audit Purview secara langsung. Keduanya menghasilkan aliran data tentang aktivitas di tenant Anda, seperti berbagi file, perubahan izin, pelanggaran akses, dan login administrator.

Batasi cakupan sejak awal

Menarik seluruh umpan audit memang mungkin, tetapi tidak efisien. Tentukan peristiwa yang benar-benar memengaruhi kepatuhan, misalnya:

  • pengguna masuk dari lokasi baru,
  • penetapan peran berubah,
  • berbagi eksternal dilakukan,
  • kebijakan label dimodifikasi.

Penyaringan dapat dilakukan pada tahap query lewat parameter API, atau di hilir dalam Power Automate dengan logika kondisional. Tujuannya mengurasi data, bukan menimbunnya.

Kontrol akses dan kredensial

Power Automate hanya bertindak sesuai izin yang diberikan. Jika akun layanan alur tidak bisa membaca log audit, agen akan melaporkan "tidak ada masalah" padahal sebenarnya ia buta. Pastikan akun layanan memiliki peran pembaca log audit di Purview dan dapat melakukan autentikasi tanpa gangguan MFA, karena tidak ada yang akan menyetujui permintaan autentikasi pada pukul 2 pagi. Simpan kredensial di Azure Key Vault atau gunakan referensi koneksi.

Mengubah JSON Menjadi Data Terstruktur

Langkah berikutnya adalah mengonversi blob JSON menjadi kolom yang bisa diinterpretasikan. Cara sederhananya adalah tindakan Parse JSON dengan skema yang diambil dari sampel peristiwa Purview. Setiap properti, seperti ID pengguna, operasi, beban kerja, status hasil, dan IP klien, menjadi variabelnya sendiri.

Struktur data Microsoft kadang membingungkan. Sebagian bidang muncul sebagai array padahal hanya berisi satu nilai, dan sebagian hasil tersembunyi di bawah beberapa lapisan sarang. Power Automate menanganinya dengan ekspresi. Kesalahan kecil di tahap ini menghasilkan keluaran yang keliru di tahap berikutnya, jadi uji setiap ekstraksi dengan sampel kecil.

Penyimpanan sebagai memori jangka pendek

Data yang sudah dibersihkan sebaiknya disimpan agar agen dapat membuat perbandingan historis. Pilihannya SharePoint, Dataverse, atau basis data SQL, tergantung beban laporan. SharePoint lebih mudah, tetapi menjadi canggung jika melebihi beberapa ribu baris. Dataverse lebih cocok jika Anda memerlukan kemampuan kolom atau hubungan antar set data.

Penjadwalan

Gunakan pemicu pengulangan Power Automate dan atur zona waktunya sesuai lokasi Anda, bukan UTC, kecuali Anda tidak keberatan laporan tiba pada pukul 3 pagi. Ringkasan harian cocok untuk lingkungan yang dinamis, sedangkan ringkasan mingguan cocok untuk lingkungan yang lebih tenang.

Pelaporan GRC Manual vs Agen GRC Otomatis

Pelaporan Manual

  • Analis menyalin log audit ke Excel dan membuat pivot table
  • Data cepat usang dan grafik tidak lagi mencerminkan kenyataan
  • Log JSON padat dan sulit dibaca
  • Bergantung pada proses rapuh dan satu analis
  • Kepatuhan menjadi pertunjukan dokumentasi

Agen GRC Otomatis

  • Purview, Power Automate, dan Copilot Studio berbagi tugas dengan jelas
  • Alur berjalan sesuai jadwal tanpa diminta
  • Ambang batas risiko eksplisit menggantikan intuisi manusia
  • Laporan memakai terminologi konsisten dan metadata yang dapat diaudit
  • Auditor menilai substansi, bukan memvalidasi format
M365.FM · Mirko Peters

Lapisan Logika: Ambang Batas Risiko di Power Automate

Power Automate bukan AI. Ia tidak berspekulasi dan tidak berhalusinasi. Kekakuannya yang dapat diprediksi itulah yang dibutuhkan otomatisasi kepatuhan. Urutan lapisan logikanya sebagai berikut:

  1. Pemicu pengulangan memulai alur sesuai jadwal tanpa diminta.
  2. Inisialisasi variabel seperti total peristiwa, jumlah risiko tinggi, dan tanggal laporan. Variabel ini menjadi memori kerja agen.
  3. Pemanggilan log audit lewat konektor Purview atau HTTP API.
  4. Filter array membuang catatan yang tidak relevan, misalnya yang bertipe pengguna service principal. Pertahankan hanya tipe operasi yang terkait tata kelola data atau perubahan kebijakan.
  5. Penghapusan duplikat, karena banyak aliran log mengulang peristiwa yang identik. Ekspresi union dapat dipakai untuk ini.
  6. Pengelompokan dengan tindakan Compose atau Select berdasarkan prinsipal pengguna dan operasi, lalu diproses dalam loop Apply to each.

Menetapkan tingkat risiko

Rahasia otonomi adalah membiarkan sistem menyimpulkan tingkat risiko dari ambang batas yang Anda tetapkan. Contohnya, jika eskalasi hak istimewa mencapai 3, tingkat risiko ditetapkan tinggi. Jika berbagi eksternal mencapai 1, tingkat risiko sedang. Selain itu, dianggap normal. Dengan menuliskan batas ini secara eksplisit, intuisi manusia diganti dengan kejelasan numerik.

Gunakan tindakan kondisi bersarang. Pengguna berisiko tinggi ditambahkan ke array risiko tinggi, kasus sedang dimasukkan ke antrean tinjauan, dan jika tidak ada temuan, alur mencatat pesan "tidak ada temuan". Jangan biarkan hasilnya hening, karena dalam kepatuhan data yang hilang berbeda dari tidak adanya data.

Integrasi Copilot Studio: Mengajari Agen Menulis Laporan

Setelah alur bisa mengklasifikasi dan memutuskan, Copilot Studio memberinya kemampuan berbicara. Mulailah dengan menentukan jenis komunikasi yang dibutuhkan. Biasanya ada tiga: ringkasan eksekutif, lampiran teknis, dan rekomendasi. Manajemen menginginkan satu paragraf, auditor membutuhkan jejak bukti, dan staf TI ingin melihat setiap kolom. Anda cukup membuat satu pengalaman Copilot dengan beberapa perintah (prompt), masing-masing dengan nada, format, dan tingkat detail berbeda.

Menghubungkan Power Automate dan Copilot Studio

Gunakan tindakan HTTP di dalam alur untuk mengirim payload JSON terstruktur ke URL endpoint Copilot. Copilot menafsirkan payload itu menggunakan perintah sistem yang sudah Anda tentukan, dan panggilannya diautentikasi melalui Azure. Hasilnya berupa teks, dan teks itulah laporan Anda. Contoh instruksinya: ringkas hasil dalam laporan kepatuhan singkat, kategorikan berdasarkan tingkat keparahan, rekomendasikan satu tindakan per kategori, dan tutup dengan tren keseluruhan.

Keluarannya menyerupai memo analis: berapa pengguna menunjukkan perilaku berisiko tinggi, siapa melampaui ambang batas eskalasi hak istimewa, siapa mencoba berbagi eksternal, serta apakah tren dibandingkan garis dasar stabil. Ini bukan tebakan generatif, melainkan sintesis terformat yang mengikuti perintah deterministik.

Distribusi laporan

Gunakan dua cabang dari alur yang sama. Satu memposting ringkasan Copilot ke saluran Teams untuk manajemen, yang lain menyimpan versi HTML lengkap ke SharePoint untuk dokumentasi auditor. Keduanya tiba otomatis dengan stempel waktu dan redaksi yang identik.

Rekayasa Prompt dan Validasi Output

Kepatuhan bergantung pada reproduktibilitas, bukan kepribadian. Karena itu, prompt perlu dibatasi dengan ketat:

  • tentukan tajuk yang wajib dipakai, misalnya ikhtisar, temuan utama, dan rekomendasi,
  • minta nada netral dan profesional,
  • hindari bahasa spekulatif dan emoji,
  • sertakan metrik terukur.

Copilot Studio juga mendukung variabel konteks. Tanggal laporan atau jumlah catatan yang dianalisis bisa disisipkan secara dinamis, sehingga laporan memuat informasi seperti tanggal pembuatan dan jumlah peristiwa audit yang dianalisis. Metadata semacam ini memudahkan auditor memverifikasi laporan.

Langkah terakhir adalah validasi. Tambahkan kondisi di Power Automate yang memeriksa apakah respons Copilot tidak kosong. Jika kosong, catat kegagalan ke log dan ulangi satu kali. Terakhir, beri versi pada perintah sistem Copilot dan catat versi mana yang menghasilkan laporan mana. Audit di masa depan dapat merujuk bukan hanya pada apa yang terjadi, tetapi juga pada bagaimana model naratif diinstruksikan saat itu.

Kesalahan Umum dan Stolpersteine

  • Akun layanan tanpa izin. Tanpa peran pembaca log audit, agen melaporkan nol masalah. Itu bukan kepatuhan sempurna, melainkan agen yang buta. Otomatisasi hanya menegakkan apa yang diizinkan kepadanya.
  • Cakupan terlalu luas. Menarik seluruh umpan audit membebani alur dengan data yang tidak relevan bagi kepatuhan.
  • Zona waktu UTC. Laporan bisa tiba pada jam yang tidak masuk akal.
  • Tanpa penanganan kesalahan. API bisa terkena throttling atau gangguan. Bungkus panggilan HTTP dalam scope dengan kebijakan retry (tiga kali percobaan dengan jeda eksponensial), lalu catat pesan kesalahan, stempel waktu, dan ID eksekusi alur ke daftar SharePoint atau tabel Dataverse bernama kesehatan otomatisasi. Auditor tidak menghukum kesalahan, tetapi menghukum hilangnya dokumentasi atas kesalahan tersebut.
  • Ekstraksi JSON yang tidak diuji. Kesalahan kecil di tahap parsing berdampak besar pada laporan akhir.
  • Prompt longgar. Tanpa batasan format dan nada, hasil tulisan menjadi tidak konsisten.
  • Tanpa versi dan bukti eksekusi. Simpan ringkasan setiap eksekusi, seperti total peristiwa yang diproses, pengguna dengan risiko tertinggi, dan durasi proses, lalu versikan ambang batas dan alatnya agar auditor dapat melacak logika di balik setiap hasil.

Takeaways Praktis

  • Bagi tugas dengan jelas: Purview sebagai sumber data, Power Automate sebagai orkestrator, Copilot Studio sebagai penulis laporan.
  • Batasi cakupan log audit pada peristiwa yang relevan bagi kepatuhan.
  • Pastikan akun layanan memiliki peran pembaca log audit dan simpan kredensial di Azure Key Vault atau referensi koneksi.
  • Gunakan Parse JSON dengan skema dari sampel peristiwa, dan uji dengan sampel kecil.
  • Simpan data di SharePoint atau Dataverse untuk perbandingan historis.
  • Tetapkan ambang batas risiko secara eksplisit di dalam alur.
  • Selalu catat hasil, termasuk saat tidak ada temuan.
  • Terapkan kebijakan retry dan log kesehatan otomatisasi.
  • Batasi prompt Copilot dengan tajuk, nada netral, dan metrik terukur, lalu validasi bahwa responsnya tidak kosong.
  • Versikan prompt, ambang batas, dan alat, serta distribusikan laporan ke Teams dan SharePoint.
Kesalahan Umum dalam Membangun Agen GRC
M365.FM · Mirko Peters

Fazit

Agen GRC berbasis Microsoft Purview, Power Automate, dan Copilot Studio mengubah pelaporan kepatuhan dari sprint menjelang audit menjadi proses berkelanjutan. Purview mengumpulkan data, Power Automate menafsirkannya berdasarkan ambang batas yang jelas, dan Copilot Studio merangkumnya dalam bahasa yang mudah dipahami. Manfaat terbesarnya adalah standarisasi: setiap laporan memakai ambang batas yang sama, terminologi yang konsisten, dan metadata yang dapat diaudit. Dengan begitu, auditor dapat menilai substansi, bukan memvalidasi format.

Pertanyaan umum

Apa itu agen GRC otomatis dengan Microsoft Purview, Power Automate, dan Copilot Studio?

Agen GRC adalah otomatisasi terstruktur berbasis aturan, bukan kopilot yang menebak jawaban. Purview menyediakan data audit, Power Automate mengorkestrasi alur kerja dan menilai risiko, sedangkan Copilot Studio menerjemahkan log teknis menjadi ringkasan yang mudah dibaca manusia.

Mengapa pelaporan GRC manual dianggap bermasalah?

Data diekspor dari Purview ke spreadsheet dan cepat usang karena aktivitas baru terus terjadi. Log audit berbentuk blob JSON yang sulit dibaca. Proses juga rapuh, sebab jika satu analis berhalangan, seluruh siklus pelaporan bisa terganggu.

Bagaimana cara Power Automate menentukan tingkat risiko dalam agen GRC?

Anda menetapkan ambang batas numerik secara eksplisit. Misalnya, eskalasi hak istimewa mencapai 3 berarti risiko tinggi, berbagi eksternal mencapai 1 berarti sedang, selain itu normal. Kondisi bersarang lalu memilah kasus, dan alur tetap mencatat pesan "tidak ada temuan" bila tidak ada masalah.

Apa kesalahan umum saat membangun agen GRC ini dan bagaimana menghindarinya?

Kesalahan umum meliputi akun layanan tanpa peran pembaca log audit, cakupan log terlalu luas, zona waktu UTC, dan tanpa penanganan kesalahan. Juga JSON yang tidak diuji, prompt longgar, serta tidak adanya versi dan bukti eksekusi. Terapkan retry, log kesehatan, dan pembatasan prompt.

Episode lainnya

Hentikan Kekacauan AI

Copilot Studio vs Azure AI Foundry

AI perusahaan dengan Power Platform dan Azure OpenAI

Tata kelola agen Copilot

Jawaban Copilot Samar? Perbaiki Izin, SharePoint, dan…

Copilot Studio vs Teams Toolkit

Semua episode →