كيف تكتب سرديات مجلس الإدارة العربية من Power BI باستخدام وكلاء الذكاء الاصطناعي و MCP: قالب موجه + دليل أسلوب سعودي

ما الذي ستبنيه

ستخرج من هذا الدرس بأربعة أصول قابلة للنسخ مباشرة إلى مؤسستك:

1. قالب System Prompt كامل بالعربية، يحدد شخصية الوكيل، قواعد التحقق من الحقائق، وتنسيق المخرجات لتقارير مجلس الإدارة الشهرية.
2. دليل أسلوب سعودي (Style Guide) يفرض المصطلحات التنظيمية الرسمية، التقويم المالي الهجري والميلادي، السجل اللغوي الرسمي، ومعالجة الأرقام.
3. حلقة تحقق من الحقائق (Fact-Check Loop) تعيد استخراج كل رقم في السردية من النموذج الدلالي قبل تسليمها للمراجعة البشرية.
4. سير عمل النشر عبر Microsoft Teams، البريد، أو واتساب — مع نقطة المراجعة البشرية الإلزامية قبل أي إرسال خارجي.

النتيجة النهائية: مدير المالية يفتح Teams في الساعة 8 صباحاً يوم الأحد، فيجد سردية شهرية عربية فصحى من 250 كلمة عن أداء المنطقة الشرقية، مرفقة بثلاثة أسئلة جاهزة لطرحها على مدير الإقليم — مولّدة في الخامسة فجراً، موقّعة من محلل بشري في السابعة.

السياق: لماذا تفشل سرديات Power BI Copilot في السعودية

قبل بناء البديل، يجب فهم لماذا الحل المدمج غير كافٍ. ثلاثة إخفاقات متكررة نراها في عمليات تدقيق Power BI لدى مؤسسات سعودية متوسطة الحجم:

1. السجل اللغوي خاطئ. ينتج Copilot نصاً ركيكاً مثل: "الإيرادات زادت بنسبة 12% الشهر الماضي. هذا جيد." — لغة محادثة لا تليق بتقرير مرفوع لمجلس إدارة بنك أو شركة مدرجة في تداول. السجل المطلوب هو الفصحى الرسمية بصيغة الغائب: "سجّلت الإيرادات نمواً نسبته 12% خلال شهر ربيع الأول، يعزى أساساً إلى توسع المنطقة الشرقية."

2. المصطلحات التنظيمية مترجمة، لا رسمية. يكتب Copilot "هيئة الضرائب" بدلاً من "هيئة الزكاة والضريبة والجمارك". "البنك المركزي" بدلاً من "البنك المركزي السعودي (SAMA)". مراجع التدقيق السعوديون يرفضون السرديات التي لا تستخدم الأسماء النظامية الرسمية.

3. التقويم المالي غير معالج. السنة المالية الحكومية السعودية تنتهي في 31 ديسمبر ميلادياً، لكن العديد من الكيانات الوقفية والخيرية والشركات العائلية تتبع التقويم الهجري. Copilot لا يعرف الفرق ولا يعرف كيف يحوّل بين الاثنين. النتيجة: سرديات تذكر "الربع الثاني" دون توضيح أي تقويم، مما يربك القارئ.

السبب الجذري لهذه الإخفاقات الثلاثة: Copilot نموذج عام، مدرّب على نصوص إنجليزية في الغالب، يولّد بالعربية عبر طبقة ترجمة آلية ضحلة. الحل ليس انتظار Microsoft — بل بناء طبقة وكيل مخصصة فوق نفس النموذج الدلالي، مع قالب موجه وقاموس مصطلحات يفرضان السلوك الصحيح.

البنية: ثلاث طبقات فوق Power BI

┌────────────────────────────────────┐
│  Microsoft Teams / Email / WhatsApp │  ← التسليم
└────────────────┬───────────────────┘
                 │ بعد توقيع المحلل البشري
┌────────────────▼───────────────────┐
│  مراجعة بشرية (محلل / مدير مالي)    │  ← بوابة الجودة
└────────────────┬───────────────────┘
                 │
┌────────────────▼───────────────────┐
│  وكيل السردية العربية (LLM + موجه)   │
│  ├── قالب System Prompt              │
│  ├── دليل الأسلوب السعودي            │
│  └── حلقة التحقق من الحقائق          │
└────────────────┬───────────────────┘
                 │ MCP (JSON-RPC)
┌────────────────▼───────────────────┐
│  خادم MCP لـ Power BI (من #304)     │
│  ├── list_datasets / list_measures   │
│  ├── query_dataset (DAX)             │
│  └── get_measure                     │
└────────────────┬───────────────────┘
                 │ REST + Service Principal
┌────────────────▼───────────────────┐
│  Power BI Service (النموذج الدلالي) │
└────────────────────────────────────┘

الطبقات السفلية (Power BI + خادم MCP) موصوفة بالكامل في الدرس #304. هذا الدرس يركّز على الطبقات الثلاث الوسطى.

القالب الكامل لـ System Prompt

هذا هو قلب الحل. انسخه إلى ملف prompts/narrative-agent-ar-ksa.md في مستودعك، وعدّل الأقسام الموسومة بـ {{ }} لتخصيصها لشركتك:

أنت كاتب سرديات مالية احترافي لمجلس إدارة {{اسم_الشركة}}، شركة سعودية
في قطاع {{القطاع}}. تنتج تقارير شهرية باللغة العربية الفصحى الرسمية،
موجهة إلى لجنة التدقيق والمدير المالي.
 
## مصدر البيانات
- لديك وصول إلى أدوات MCP التي تستعلم نموذج Power BI الدلالي.
- يجب استدعاء أداة query_dataset قبل ذكر أي رقم أو نسبة في السردية.
- لا تخمّن أبداً. إذا كان الرقم غير متوفر، اطلب توضيحاً بدلاً من تقديره.
 
## السجل اللغوي
- اكتب بالفصحى الرسمية، بصيغة الغائب فقط.
- لا تستخدم ضمير المتكلم ("أرى"، "أعتقد").
- لا تستخدم عبارات محادثة ("هذا رائع"، "النتائج ممتازة").
- استخدم المبني للمجهول حيث يكون التحفظ ملائماً ("سُجّلت زيادة" بدلاً من
  "حققت الشركة زيادة").
 
## المصطلحات التنظيمية الإلزامية
استخدم دائماً الأسماء النظامية الكاملة عند أول ذكر، ثم الاختصار:
- "هيئة الزكاة والضريبة والجمارك (ZATCA)" — وليس "هيئة الضرائب".
- "البنك المركزي السعودي (SAMA)" — وليس "ساما" أو "المركزي".
- "هيئة السوق المالية (CMA)" — وليس "هيئة السوق".
- "وزارة الموارد البشرية والتنمية الاجتماعية" — وليس "وزارة العمل".
- "نظام حماية البيانات الشخصية" — وليس "PDPL" منفرداً.
 
## التقويم المالي
- السنة المالية للشركة: {{بداية_السنة_المالية}} إلى {{نهاية_السنة_المالية}}
  ميلادياً.
- اذكر دائماً التقويم: "خلال شهر يناير 2026م" أو "في الربع الثالث الهجري
  1447هـ".
- إذا كان التقرير لجهة حكومية تستخدم الهجري، أضف المكافئ الميلادي بين قوسين.
 
## معالجة الأرقام
- في الجداول: استخدم الأرقام الغربية (123) — مفروض من قالب PDF.
- في النص السردي: استخدم {{نوع_الأرقام: "غربية" | "شرقية"}}.
- العملة: "ر.س" بعد الرقم، بمسافة فاصلة ("1,250,000 ر.س").
- النسب المئوية: علامة % بعد الرقم بدون مسافة ("12%").
- ضع الرقم دائماً مع وحدته الكاملة ("1.25 مليون ر.س" وليس "1.25M").
 
## بنية السردية المطلوبة
الإخراج النهائي يجب أن يحتوي على أربعة أقسام بهذا الترتيب:
 
1. **الملخص التنفيذي** (جملتان كحد أقصى): الاتجاه الرئيسي والسبب الأهم.
2. **المؤشرات الرئيسية** (3-5 نقاط): كل نقطة برقم + سياق مقارن.
3. **النقاط المثيرة للانتباه** (1-3 نقاط): شذوذات أو انحرافات تستحق
   النقاش في الاجتماع.
4. **أسئلة مقترحة للإدارة** (2-4 أسئلة): أسئلة محددة جاهزة لطرحها على
   المسؤولين التنفيذيين، مبنية على البيانات.
 
## قواعد التحقق من الحقائق
- قبل كتابة كل رقم، استدعِ query_dataset للتحقق منه من النموذج.
- في نهاية السردية، أنتج قسماً مخفياً <!-- VERIFICATION --> يحتوي على:
  - كل رقم ذكرته
  - استعلام DAX الذي استخرجه
  - القيمة الناتجة
- إذا اكتشفت تضارباً بين رقمين، أوقف التوليد واطلب من المراجع البشري الفصل.
 
## القيود
- لا تقدّم توصيات استثمارية أو قرارات تجارية.
- لا تتنبأ بأرقام مستقبلية إلا إذا طُلب صراحةً، ووسمها بـ "تقدير".
- لا تذكر بيانات خارج نطاق RLS الذي يراه الوكيل.
- إذا طُلب منك بيانات حساسة (رواتب أفراد، عقود مفردة)، ارفض وأشر إلى الإذن
  المطلوب.
 
## أمثلة موجهة (Few-Shot)
{{أدرج هنا 3 إلى 5 سرديات سابقة كتبها محلل بشري كنماذج للأسلوب}}

دليل الأسلوب السعودي بالتفصيل

القالب أعلاه يلخص القواعد. هذا القسم يشرح المنطق وراءها — مفيد عندما تحتاج إلى توسيع القالب لشركتك.

السجل اللغوي: الفصحى الرسمية فقط

تقارير لجان التدقيق في السعودية تتبع تقاليد كتابة محافظة. الانتقال إلى لغة محادثة، حتى لو كانت دقيقة، يُقرأ كنقص في الجدية. الفروقات العملية:

ملاحظة: تجنّب اللهجة السعودية تماماً في السرديات المكتوبة. اللهجة مقبولة في الاجتماعات الشفوية، لكنها غير ملائمة لتقرير مرفوع لجهة تنظيمية.

المصطلحات التنظيمية: استخدم الأسماء النظامية

المراجعون المعتمدون في السعودية (SOCPA) يقرؤون السرديات مع التشريع في ذهنهم. استخدام الاسم الشائع بدلاً من النظامي يثير الشك في دقة بقية التقرير. الأسماء الكاملة الأكثر استخداماً:

• هيئة الزكاة والضريبة والجمارك (سابقاً GAZT)
• البنك المركزي السعودي (سابقاً SAMA — لا يزال الاختصار شائعاً)
• هيئة السوق المالية
• مجلس هيئة المحاسبين القانونيين (SOCPA)
• الهيئة العامة للإحصاء (GASTAT)
• وزارة الموارد البشرية والتنمية الاجتماعية

عند الإشارة إلى أنظمة محددة، استخدم الاسم الكامل:

• "نظام ضريبة القيمة المضافة" — وليس "VAT"
• "نظام الفوترة الإلكترونية المرحلة الثانية" — وليس "ZATCA Phase 2"
• "نظام حماية البيانات الشخصية" — وليس "PDPL"

التقويم المالي: الازدواجية الإلزامية

كثير من الكيانات السعودية تتعامل مع تقويمين بالتوازي:

• التقويم الميلادي: الشركات المساهمة المدرجة، البنوك (السنة المالية تنتهي 31 ديسمبر).
• التقويم الهجري: بعض الأوقاف، الجمعيات الخيرية، الميزانيات الحكومية السنوية.

عند كتابة سردية ستُقرأ من قبل جمهور مختلط، اذكر التقويم دائماً، وإذا كان أحدهما أساسياً ضع الآخر بين قوسين:

"بلغت الإيرادات خلال شهر شعبان 1447هـ (فبراير 2026م) ما مقداره 12.4 مليون ر.س..."

الأرقام: الجداول غربية، النص حسب التفضيل

السبب التقني وراء قاعدة "الأرقام الغربية في الجداول": معظم خطوط PDF العربية في قوالب التقارير الاحترافية لا تعالج محاذاة الأرقام الشرقية بشكل صحيح، خاصة عند الخلط مع الرموز اللاتينية مثل % و ر.س. النتيجة: جداول غير محاذية بصرياً.

للنص السردي، الخيار يعود لتفضيل الشركة. القاعدة العملية:

• الكيانات الحكومية والوقفية: عادة أرقام شرقية (١٢٣).
• الشركات المساهمة المدرجة، البنوك، الشركات متعددة الجنسيات: عادة أرقام غربية (123).
• القطاع العائلي / الخاص: استشر مجلس الإدارة.

اجعل هذا متغيراً في القالب ({{نوع_الأرقام}}) لتجنب الجدال في كل تقرير.

حلقة التحقق من الحقائق

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

الآلية الأولى: استدعاء إلزامي قبل كل رقم

القاعدة في System Prompt: "يجب استدعاء أداة query_dataset قبل ذكر أي رقم أو نسبة في السردية." هذا يمنع الوكيل من توليد رقم من ذاكرته الإحصائية (الهلوسة الكلاسيكية للنماذج اللغوية على البيانات المالية).

الآلية الثانية: قسم التحقق المخفي

في نهاية كل سردية، يُنتج الوكيل قسماً مخفياً بصيغة HTML comment:

<!-- VERIFICATION
- الرقم: 12.4 مليون ر.س (إيرادات شعبان)
  استعلام: EVALUATE SUMMARIZECOLUMNS('Date'[Month], "Revenue", [TotalRevenue])
  النتيجة: 12,387,422.50 — مدور إلى 12.4 مليون
- الرقم: 12% (نمو على أساس سنوي)
  استعلام: EVALUATE { CALCULATE([TotalRevenue]) / CALCULATE([TotalRevenue], SAMEPERIODLASTYEAR('Date'[Date])) - 1 }
  النتيجة: 0.1184 — مدور إلى 12%
-->

هذا القسم لا يظهر في PDF النهائي، لكنه يبقى في النسخة الأصلية بصيغة Markdown، ويُحفظ في سجل التدقيق. عند الشك، يستطيع المراجع البشري إعادة تنفيذ نفس استعلامات DAX يدوياً والتحقق.

الآلية الثالثة: تمريرة تحقق ثانية مستقلة

في خط معالجة الإنتاج، نضيف خطوة ثانية: استدعاء LLM منفصل يستلم السردية + قسم التحقق، ويُطلب منه: "تحقق أن كل رقم في النص متطابق مع نتيجة الاستعلام المذكورة في قسم VERIFICATION. أبلغ عن أي تباين."

هذه التمريرة تكلف 30 إلى 50% إضافية من تكلفة التوليد الأصلي، لكنها تكتشف أخطاء التقريب، أخطاء الوحدات (مليون مقابل ألف)، وأخطاء التحويل بين العملات.

أمثلة موجهة: ثلاث سرديات نموذجية

قسم Few-Shot في القالب هو ما يحدد جودة المخرجات أكثر من أي تعليمة أخرى. أدرج 3 إلى 5 سرديات حقيقية كتبها محلل بشري للأشهر السابقة. النموذج اللغوي يقلّد الأسلوب بدقة أعلى من إتباع التعليمات المجردة.

نموذج موجز (للإيضاح فقط — استبدل ببيانات شركتك):

### مثال 1: سردية شهرية لشركة تجزئة سعودية
 
**الملخص التنفيذي**
سجّلت إيرادات الشهر نمواً نسبته 8% على أساس سنوي، يُعزى أساساً إلى توسع
المنطقة الشرقية واستقرار هامش الربح الإجمالي عند 34%.
 
**المؤشرات الرئيسية**
- إجمالي المبيعات: 18.2 مليون ر.س مقارنة بـ 16.9 مليون ر.س لنفس الفترة
  من العام السابق.
- عدد الفروع العاملة: 47 فرعاً، بإضافة فرعين جديدين في الدمام.
- متوسط قيمة السلة: 142 ر.س، بانخفاض طفيف نسبته 2%.
 
**النقاط المثيرة للانتباه**
- انخفض أداء فرع الرياض (شارع التحلية) بنسبة 14% — تزامن مع إغلاق مؤقت
  لمواقف السيارات المجاورة.
 
**أسئلة مقترحة للإدارة**
1. هل توجد خطة تعويضية لفرع التحلية خلال فترة الإغلاق؟
2. ما السبب وراء انخفاض متوسط السلة رغم نمو الإيرادات الإجمالية؟

اكتب نموذجين أو ثلاثة بهذا الشكل من تقارير شركتك السابقة، وضعها في قسم Few-Shot. الجودة سترتفع بشكل ملحوظ بعد أول 5 أمثلة.

النشر: من السردية إلى Teams والبريد

السردية المُولَّدة لا قيمة لها إن بقيت في طرفية المطور. خط النشر النموذجي:

1. 5:00 ص: مهمة cron تستدعي الوكيل، تولّد السردية + قسم التحقق.
2. 5:05 ص: تمريرة التحقق الثانية تفحص التطابق.
3. 5:10 ص: إذا نجح التحقق، تُحفظ السردية في مجلد المسودات وتُرسل إشعار إلى محلل المراجعة عبر Teams.
4. 7:00 ص: المحلل يفتح المسودة، يراجع، يعدّل عند الحاجة، يوقع.
5. 7:30 ص: السردية الموقّعة تُرسل تلقائياً إلى قناة لجنة التدقيق في Teams، مع PDF مرفق.

النقطة الحرجة: المحلل البشري بوابة إلزامية. لا يُرسل الوكيل مباشرة إلى الجمهور الخارجي. هذا ليس قيداً تقنياً بل قراراً تشغيلياً — مسؤولية الأرقام المرسلة إلى مجلس الإدارة تبقى على شخص قابل للمساءلة.

للنشر على واتساب (الأكثر شيوعاً للتنبيهات السريعة، لا للتقارير الكاملة): نستخدم نفس النمط، مع توليد ملخص مختصر من 3 أسطر إضافة إلى السردية الكاملة. الملخص يذهب إلى واتساب، والكامل إلى البريد.

التكامل مع الدرس #304

هذا الدليل يفترض أن لديك خادم MCP من الدرس السابق يعمل ومتصل بـ Claude Desktop أو عميل MCP مكافئ. التكامل العملي:

1. ضع ملف narrative-agent-ar-ksa.md (القالب أعلاه) في مستودع منفصل عن خادم MCP.
2. حمّل القالب كـ System Prompt في عميل MCP الخاص بك.
3. عند تشغيل السردية، يفتح العميل اتصال MCP مع الخادم، فيستطيع الوكيل استدعاء list_datasets و query_dataset بشكل تلقائي.
4. خادم MCP يحترم RLS — الوكيل يرى فقط ما تسمح به الأذونات الممنوحة لمبدأ الخدمة.

للنشر في بيئة الإنتاج (وليس Claude Desktop المحلي)، استبدل العميل بسكربت يستخدم نفس بروتوكول MCP عبر mcp-client للـ TypeScript أو ما يكافئها للـ Python. خط الأنابيب التشغيلي الكامل، مع جدولة cron ومعالجة الفشل، يخرج عن نطاق هذا الدليل لكنه موصوف بإسهاب في إطار التفعيل الكامل لـ Power BI في السعودية.

ما الذي يجب تجنبه

من تجربة نشر هذا النمط لدى عدد من العملاء السعوديين، أربعة أخطاء متكررة:

1. محاولة إنشاء قالب موحّد لكل الجماهير. سردية لجنة التدقيق تختلف عن سردية اجتماع التشغيل اليومي. ابن قالبين منفصلين، ولا تحاول التبديل بمتغيرات.
2. تجاهل خطوة Few-Shot. بدون 3 إلى 5 أمثلة حقيقية، يولّد الوكيل لغة عامة تشبه ChatGPT. مع الأمثلة، يقلّد الوكيل أسلوب محللك الرئيسي بدقة عالية.
3. السماح بالنشر التلقائي. أول مرة يرسل فيها الوكيل رقماً خاطئاً إلى مجلس الإدارة دون مراجعة، يُلغى المشروع. اجعل المراجعة البشرية إلزامية حتى لو بدت بطيئة في البداية.
4. تخطي قسم التحقق. السردية بدون قسم VERIFICATION لا يمكن مراجعتها لاحقاً. اجعله إلزامياً في القالب من اليوم الأول.

الخطوة التالية

ركّب القالب على خادم MCP من #304، شغّله على بيانات شهر واحد سابق، قارن السردية المُنتَجة بالسردية التي كتبها محللك البشري للشهر نفسه. إذا كان الفارق صغيراً، انتقل إلى نشر تجريبي لمدة شهر مع مراجعة بشرية كاملة. إذا كان الفارق كبيراً، عدّل قسم Few-Shot وأضف 3 أمثلة إضافية.

للسياق الاستراتيجي الكامل عن تفعيل Power BI الخامل في المملكة العربية السعودية — نمط التفعيل، اقتصاديات الترخيص، تحديات الحوكمة في PDPL وZATCA — راجع دليلنا الشامل: Power BI في المملكة العربية السعودية.

هذا الدرس جزء من سلسلة Power BI × الذكاء الاصطناعي × MCP. للدرس التقني السابق حول بناء الخادم نفسه، راجع: بناء خادم MCP لـ Power BI.