بناء وكيل ذكاء اصطناعي للحوكمة والمخاطر والامتثال باستخدام Purview وPower Automate وCopilot Studio

تقارير الحوكمة والمخاطر والامتثال (GRC) تستهلك من وقت الفرق أكثر مما تستحق. ما زال محللون كثيرون ينسخون سجلات التدقيق إلى Excel خلية بعد خلية. يبدأ الأمر بمصنف مرتب وبضعة فلاتر، وينتهي بعشرات علامات التبويب من الجداول المحورية المتضاربة. وهكذا يتحول الامتثال، الذي يفترض أن يكون إجراءً وقائياً، إلى جهد استعراضي هدفه طمأنة المدققين.

يعرض هذا المقال بديلاً عملياً: وكيل ذكاء اصطناعي لـ GRC يقوم على قواعد واضحة، ومبني بالكامل من أدوات Microsoft. تؤدي Microsoft Purview دور مصدر الحقائق، وتنظّم Power Automate المهام، وتحوّل Copilot Studio البيانات التقنية إلى لغة مفهومة. سنمرّ على المكونات وبناء خط البيانات ومنطق القرار وصياغة التقارير وأهم الأخطاء التي يجب تجنبها.

لماذا تفشل تقارير GRC اليدوية؟

تخلط كثير من المؤسسات بين التوثيق والرؤى. تسحب البيانات من Microsoft Purview وتصدّرها وتوزعها على جداول بيانات وتسمي ذلك حوكمة. بعد أسبوع تحدث أنشطة جديدة وتتغير البيانات، فتصبح المخططات الدقيقة التي أعددتها قديمة ومضللة. وبذلك تفرض مسارات التدقيق، التي وُجدت لضمان المساءلة، الإرهاق على من يعدّها.

وتعامل معظم الشركات Purview كخزنة لا تُفتح إلا قبل التدقيق. تتراكم فيها سجلات هائلة عن من فعل ماذا وأين ومتى. هذه السجلات مفيدة، لكنها شبه غير مقروءة، لأن كل إدخال كتلة JSON كثيفة. والمشكلة الأساسية إذن هي وفرة البيانات وغياب القابلية للقراءة.

الفكرة التي تعالج هذا الخلل بسيطة. تُحوَّل مهام الجلب والتحليل والشرح إلى وكيل آلي يعمل في موعده دون تعب، ويقرأ لغة JSON بطلاقة، ويكتب النتيجة بلغة طبيعية.

ما هو وكيل GRC وما مكوناته؟

وكيل GRC ليس مساعداً سحرياً يخمّن الإجابات. هو منظومة أتمتة تعتمد على القواعد، ولها ثلاثة أجزاء يؤدي كل منها وظيفة محددة:

• Microsoft Purview: الذاكرة الخام. تحفظ سجلات التدقيق وبيانات التصنيف وأحداث الامتثال، وتسجل كل إجراء للمستخدم عبر Microsoft 365، من مشاركة مستند إلى إنشاء سياسة أو تعديل تسمية احتفاظ.
• Power Automate: الجهاز العصبي. يجمع الإشارات ويفلتر الضوضاء ويضمن تشغيل العملية في موعدها. وعند حدوث خطأ في الإعداد يفشل التدفق بهدوء، لكنه يسجل الفشل بتفاصيل دقيقة.
• Copilot Studio: الفم والمترجم. يأخذ الرموز التقنية المعقدة ويخرجها ملخصات يفهمها البشر.

يعمل هذا النهج لأن معظم مهام الامتثال، بحسب التقدير الوارد هنا، تقوم على التعرف على الأنماط (نحو 90% منها)، لا على قرارات تقديرية. والنظام لا يحاول التفكير كإنسان، بل صُمم ليكون أكثر تنظيماً منه.

وهناك فارق مهم عن لوحات التحكم. هي تعرض البيانات ولا تشرح شيئاً، أما الوكيل فيكتب. يترجم الأنماط إلى جمل ويسدّ الفجوة التفسيرية التي سببت إخفاقات كثيرة في مراجعات الامتثال. وحين يطلب المدير التنفيذي تقرير أنماط المخاطر للشهر الماضي، لا ترسل له رابطاً بل تقريراً سردياً واضحاً أنتجه تدفق عمل مجدول.

بناء خط بيانات Purview: امنح الوكيل عينين

قبل أن يفكر الوكيل عليه أن يرى. ويعني ذلك ربطه مباشرة بسجلات تدقيق Microsoft Purview والوصول إلى الأجزاء الصحيحة منها، لا أكثر ولا أقل. فبدون هذه الرؤية ستؤتمت العمى.

الاستخراج وتحديد النطاق

هناك طريقتان للبدء: موصل Purview المدمج في Power Automate، أو إجراء HTTP يستدعي واجهة برمجة تطبيقات سجل تدقيق Purview مباشرة. كلاهما يعطي دفقاً من الأحداث داخل المستأجر، مثل مشاركات الملفات وتغييرات الأذونات وانتهاكات الوصول وتسجيلات دخول المسؤولين.

الأفضل تقييد النطاق مبكراً. سحب موجز التدقيق كاملاً يشبه نسخ الإنترنت احتياطياً لأنك فقدت ملف PDF. لذلك حدد الأحداث التي تؤثر فعلاً على الامتثال.

الأذونات والمصادقة

Power Automate يعمل بحدود الأذونات الممنوحة له فقط. إذا لم يستطع حساب الخدمة قراءة سجل التدقيق، فسيبلّغ الوكيل بأنه لم يجد أي مشكلة. هذه ليست طمأنة بل عمى متنكر في هيئة نجاح. تأكد من الآتي:

• أن لحساب الخدمة دور قارئ سجلات التدقيق داخل Purview.
• أنه يستطيع المصادقة دون انقطاعات MFA، لأن الأتمتة لن تستجيب لطلب مصادقة في الثانية صباحاً.
• أن بيانات الاعتماد مخزنة في Azure Key Vault أو في مراجع الاتصال.

التصفية والتحويل والتخزين

لا أحد يحتاج إلى كل حدث وصول في مجلد غير ذي صلة. صفِّ بحثاً عن إشارات المخاطر الحقيقية: تسجيل دخول من موقع جديد، أو تغيير تعيين دور، أو تفعيل مشاركة خارجية، أو تعديل سياسة تسمية. ويمكن إجراء التصفية في مرحلة الاستعلام عبر معلمات الواجهة، أو لاحقاً داخل Power Automate بمنطق شرطي.

بعد ذلك تُحوَّل كتل JSON إلى حقول مهيكلة باستخدام إجراء Parse JSON مع مخطط مشتق من حدث تجريبي. يصبح كل حقل، مثل معرف المستخدم والعملية وعبء العمل وحالة النتيجة وعنوان IP للعميل، متغيراً مستقلاً. وبعض حقول التدقيق تظهر مصفوفات متداخلة، وتتعامل معها Power Automate بالتعبيرات. خطأ مطبعي صغير هنا يعطي نتائج غير منطقية لاحقاً، فاختبر كل عملية استخراج على عينات صغيرة.

يمكن حفظ البيانات المنظفة في SharePoint أو Dataverse أو قاعدة بيانات SQL بحسب حجم التقارير. يعمل هذا المخزن كذاكرة قصيرة المدى تتيح مقارنة تاريخية دون إرهاق Purview بالاستعلامات. Dataverse أنسب عند الحاجة إلى الأعمدة والعلاقات بين مجموعات البيانات، أما SharePoint فأسهل لكنه يزداد تعقيداً بعد بضعة آلاف من الصفوف.

منطق Power Automate: كيف يتخذ الوكيل القرار؟

Power Automate ليس ذكاءً اصطناعياً. هو لا يتكهن ولا يختلق مخاطر، بل ينفّذ بانضباط. وهذه الصلابة المتوقعة هي ما تحتاجه الاستقلالية. يمكن بناء طبقة المنطق على النحو التالي:

1. مشغّل التكرار: يبدأ التدفق تلقائياً، يومياً أو أسبوعياً بحسب طبيعة البيئة. اضبطه على منطقتك الزمنية لا على التوقيت العالمي المنسق، وإلا وصلت التقارير في ساعات غريبة.
2. تهيئة المتغيرات: مثل إجمالي الأحداث وعدد المخاطر العالية وتاريخ التقرير. هذه ذاكرة الوكيل العاملة.
3. الاستدعاء: عبر موصل سجلات تدقيق Purview أو إجراء HTTP.
4. تصفية المصفوفة: لاستبعاد الضوضاء، كتجاهل السجلات التي نوع المستخدم فيها كيان خدمة، والإبقاء على أنواع العمليات المرتبطة بحوكمة البيانات أو تغيير السياسات.
5. إزالة التكرارات: عبر تعبير union أو مقارنة داخل حلقة، فيبقى ما يستحق التصنيف.
6. التجميع والعد: بإجراء Compose أو Select حسب اسم المستخدم والعملية، ثم حلقات Apply to each لحساب إجمالي كل فئة.

العتبات ومستويات المخاطر

سر الاستقلالية أن تحدد عتبات واضحة يستنتج النظام منها مستوى الخطر. مثال: إذا بلغت تصعيدات الصلاحيات ثلاثة فالمستوى عالٍ، وإذا حدثت مشاركة خارجية واحدة فالمستوى متوسط، وغير ذلك فهو طبيعي. هذا المنطق لا يبتكر المعنى بل يفرضه بوضوح رقمي بدل التخمين البشري.

بعدها تُستخدم شروط متداخلة. يُضاف المستخدم عالي الخطر إلى مصفوفة المخاطر العالية، ويوضع المتوسط في قائمة انتظار للمراجعة. وإذا لم يظهر شيء غير معتاد تُسجَّل رسالة "لا توجد نتائج" بدل الصمت، لأن التمييز بين بيانات مفقودة وعدم وجود بيانات أمر أساسي في الامتثال.

Copilot Studio: علّم الوكيل أن يكتب

حتى هذه المرحلة يكون الوكيل فعالاً لكنه صامت. دور Copilot Studio أن يحوّل مخرجات JSON إلى ملخصات لإجراءات المستخدمين وعدد المخاطر وسجلات الأحداث، بفقرات تناسب المديرين وتفي المدققين.

أنواع التقارير والمطالبات

هناك ثلاثة أنواع من التواصل، ولكل منها جمهوره:

• ملخص تنفيذي: فقرة واحدة تكفي الإدارة.
• ملحق فني: يسرد الأحداث عالية المخاطر في جدول، وهو ما يحتاجه فريق تقنية المعلومات.
• توصيات: إجراء مقترح لكل نتيجة.

يمكن بناء مطالبات متعددة داخل تجربة Copilot واحدة، تتحكم كل مطالبة في النبرة والتنسيق والإسهاب. مثال: "لخّص أهم المخاطر بلغة بسيطة، واقتصر على خمس نقاط، واقترح معالجة لكل منها".

الربط والأمان

يرسل إجراء HTTP داخل التدفق حمولة JSON المهيكلة إلى نقطة نهاية Copilot، الذي يفسرها بمطالبة النظام التي حددتها. وتُؤمَّن العملية بمصادقة Microsoft عبر Azure AD بحيث لا يصل إلى النقطة إلا تدفقك. والمخرج نص، وهو التقرير نفسه، يشبه مذكرة محلل: من تجاوز حدود الصلاحيات، ومن حاول مشاركة خارجية، وهل الاتجاه العام مستقر مقارنة بخط الأساس. وهو ليس تخميناً توليدياً بل تلخيص يتبع توجيهات حتمية.

انضباط هندسة الأوامر

• حدد العناوين التي يجب أن يلتزم بها Copilot، مثل: نظرة عامة، النتائج الرئيسية، التوصيات. وإلا لجأ إلى أسلوب سردي أو رموز تعبيرية لا تليق بتقرير تدقيق.
• اشترط نبرة احترافية محايدة وتجنب اللغة التخمينية وتضمين مقاييس قابلة للقياس.
• استخدم متغيرات السياق، كتاريخ التقرير وعدد السجلات، لتظهر في النص بصيغة مثل: "تم الإنشاء في الخامس عشر من مارس وتم تحليل 563 حدث تدقيق".

كلما كانت التعليمات أدق صارت المخرجات أكثر قابلية للتكرار، والامتثال يزدهر بالتكرار لا بالشخصية.

التوزيع والأرشفة وإمكانية التتبع

لا ينبغي أن يسجل الموظفون الدخول إلى Dataverse للعثور على التقارير. لذلك يُستخدم موصل Power Automate مرة أخرى بفرعين من التدفق نفسه: الأول ينشر ملخص Copilot في قناة Teams، والثاني يحفظ نسخة HTML كاملة في SharePoint. تقرأ الإدارة منشور Teams، ويفتح المدققون الأرشيف للتوثيق، وكلاهما يصل بطابع زمني تلقائي وصياغة متطابقة.

ولكي يكون الوكيل قابلاً للمساءلة، يكتب كل تشغيل دليلاً على تنفيذه. يُضاف إجراء أخير يحفظ مقاييس الملخص، وهي إجمالي الأحداث المعالجة والمستخدم الأكثر خطورة ومدة التشغيل. ويُفضَّل تضمين معرف التشغيل وإصدار سير العمل. وإذا تغيرت العتبات لاحقاً بقي المدققون قادرين على تتبع المنطق الذي أنتج كل نتيجة.

وينطبق المبدأ نفسه على Copilot. أصدر نسخاً من مطالبة النظام كلما تغيرت معايير الامتثال، وسجّل النسخة التي أنتجت كل تقرير. بهذا يستطيع المدقق مستقبلاً أن يرجع إلى ما حدث وإلى كيفية توجيه النموذج السردي وقتها. ويمكن إضافة توقيع ختامي طريف مثل "تم إعداد التقرير ذاتياً بواسطة وكيل Copilot GRC".

أخطاء شائعة وأسباب التعثر

• صلاحيات ناقصة: أبلغ الوكيل في أول اختبار عن صفر مشاكل امتثال، وتبيّن أن حساب الخدمة يفتقر إلى دور قارئ سجلات التدقيق. الأتمتة تفرض بالضبط ما تمنحها.
• سحب كل شيء: عدم تقييد النطاق يحوّل التدفق إلى ضغط غير مقصود على المستأجر.
• إهمال معالجة الأخطاء: قد تعيد واجهة Purview خطأ "طلبات كثيرة جداً". غلّف طلبات HTTP في نطاق مع سياسة إعادة محاولة (ثلاث محاولات مع تراجع أسّي للفواصل الزمنية)، وفي فرع الفشل سجّل رسالة الخطأ والطابع الزمني ومعرف التشغيل في قائمة SharePoint أو جدول Dataverse. وأرسل رسالة عبر Teams إذا تجاوزت النتائج الحدود المسموحة.
• الخلط بين المنطقة الزمنية والتوقيت العالمي: يؤدي إلى وصول التقارير في أوقات غير مناسبة.
• أخطاء التعبيرات: خطأ بسيط في استخراج الحقول من المصفوفات المتداخلة يفسد كل ما بعده.
• ترك الأوامر بلا ضوابط: يظهر في التقرير أسلوب غير مهني أو رموز تعبيرية.
• الاستجابة الفارغة: أضف شرطاً يتحقق من أن استجابة Copilot ليست فارغة، وإن كانت كذلك فسجّل الفشل وأعد المحاولة مرة واحدة.

والقاعدة الأهم أن يُعامَل الفشل كبيانات لا كأزمة، فالمدققون لا يعاقبون على الأخطاء بل على غياب توثيقها.

خلاصات عملية

• اجعل Purview مصدر الحقائق وPower Automate المنسّق وCopilot Studio المترجم.
• قيّد نطاق الأحداث مبكراً واختر الأحداث المؤثرة على الامتثال فقط.
• امنح حساب الخدمة دور قارئ سجلات التدقيق، وجهّز المصادقة دون انقطاع MFA، وخزّن بيانات الاعتماد في Azure Key Vault.
• حوّل JSON إلى حقول مهيكلة واختبر التعبيرات على عينات صغيرة.
• خزّن البيانات المنظفة في SharePoint أو Dataverse أو SQL للمقارنة التاريخية.
• حدد عتبات المخاطر بوضوح، وسجّل "لا توجد نتائج" عند غياب الأحداث.
• ضع في مطالبات Copilot عناوين ثابتة ونبرة محايدة ومقاييس قابلة للقياس.
• انشر التقرير في Teams واحفظ نسخة كاملة في SharePoint.
• سجّل معرف التشغيل وإصدار سير العمل وإصدار المطالبة لكل تقرير.
• أضف سياسات إعادة المحاولة وسجلات الفشل وتنبيهات Teams.

الخلاصة

وكيل GRC المبني على Purview وPower Automate وCopilot Studio ينقل الامتثال من التوثيق اليدوي المتعب إلى نظام يراقب ويفسر ويكتب التقارير في موعدها. وتكمن قيمته الأكبر في التقييس لا في السرعة وحدها: كل تقرير يستخدم الحدود نفسها والمصطلحات نفسها ويحمل بيانات وصفية متطابقة. وبذلك يتفرغ المدققون لتقييم الجوهر بدل مراجعة التنسيق، وتتحول أنماط المخاطر إلى روايات يمكن تتبعها عبر الزمن. وكلما بُنيت العينان (خط البيانات) والعقل (المنطق) واللسان (الصياغة) بانضباط وتوثيق، صار الوكيل جديراً بالثقة.