نماذج LLMs مكانها طبقة السرد، لا طبقة الحقيقة المالية

أحب السرعة. أحب تقليل الخطوات اليدوية. أحب أي أداة تُزيل العمل غير الضروري من دورة الإقفال.

لكنني لا أحب الالتباس في الحقيقة المالية.

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

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

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

نموذج الطبقتين: الحقيقة مقابل السرد

معظم الفرق تخلط بين الطبقتين دون أن تنتبه. يتم نسخ جدول. يُعاد تصنيف رقم “فقط للعرض”. يحرّر أحدهم شرحاً بعد وقوع الحدث. فتبدأ القصة بقيادة الأرقام.

ومع LLMs يتضاعف هذا الخطر، لأن الأداة مصممة لإنتاج إجابة تبدو معقولة. وليست مصممة للحفاظ على سلسلة الحيازة.

لذلك أفصل النظام إلى طبقتين واضحتين:

• طبقة الحقيقة المالية: الدفاتر، والدفاتر الفرعية، ومستودع البيانات، والحسابات الحتمية، وقواعد محاسبية بإصدارات مُدارة، والموافقات والتوقيعات. كل شيء هنا قابل لإعادة الإنتاج وقابل للتدقيق.
• طبقة السرد: تعليق الإدارة، وصياغة الإفصاحات، وشرح الانحرافات، وQ&A لأصحاب المصلحة الداخليين. كل ما هنا مشتقّ، وليس مرجعاً مُعتمداً.

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

ولمن يريد نموذجاً ذهنياً من التكنولوجيا الصناعية: تعامل مع دفتر الأستاذ كأنه المستشعر، ومع LLM كأنه تعليق على لوحة القياس. يمكنك تعديل التعليق طوال اليوم. لكنك لا “تحسّن” قراءة المستشعر بالكتابة الإبداعية.

تصميم قابل للتدقيق: من البيانات إلى النص، لا من النص إلى البيانات

التصميم الوحيد الذي أثق به في السياقات الخاضعة للرقابة هو مسار data-to-text. ليس text-to-data. وليس “تحادث مع الأرقام ودع الأداة تحدّث الجدول”.

هذه هي الخطة التي سأعرضها على لجنة التدقيق.

1. مصدر حقيقة مُقفل: دفتر الأستاذ العام وجداول مستودع البيانات الخاضعة للحَوْكمة. غير قابلة للتغيير حيث يلزم، ومضبوطة الوصول في كل مكان.
2. طبقة حسابات حتمية: تجميعات، وربط وتصنيفات، وإلغاءات، ومنطق FX، وقواعد توزيع. قواعد بإصدارات مُدارة وتشغيلات قابلة لإعادة الإنتاج. بلا خطوات خفية.
3. حزمة أدلة غير قابلة للتغيير: الاستعلامات المنفذة حرفياً، وقيم المعلمات، ولقطات من مجموعات النتائج، وروابط إلى جداول المصدر، والطوابع الزمنية، وهوية التشغيل. فكّر بها كـ “build artifact” للتقارير.
4. LLM مُقيّدة بالحزمة: لا يرى النموذج إلا حزمة الأدلة وقالب تقارير ثابتاً. يصوغ التعليق ونصوص الإفصاح، وعليه أن يذكر أي artifact يدعم أي عبارة.
5. سجلات تغييرات وموافقات: تُتبع التعديلات على السرد. تبقى الموافقة النهائية بشرية، وتشير إلى معرّف حزمة الأدلة المستخدمة.

هذا هو مبدأ التشغيل ذاته الذي اعتمدته عندما قدتُ فرق R&D دولية. لم نقبل منطق “يعمل على جهازي”. قبلنا artifacts للإصدار، واعتماديات بإصدارات مُدارة، وأدلة اختبار. التقارير تستحق معيار الإثبات نفسه.

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

ما تتفوّق فيه LLMs (وما لا تتفوّق فيه)

عند استخدامها بالطريقة الصحيحة، يمكن لـ LLMs إزالة العمل الأقل قيمة في تقارير التمويل وESG. العمل الذي يستهلك وقت القيادات ويولّد أخطاء بفعل الإرهاق.

هذه استخدامات جيدة:

• صياغة تعليق الانحرافات انطلاقاً من شجرة انحرافات محددة مسبقاً (السعر، الحجم، المزيج، البنود غير المتكررة)، وبالاعتماد فقط على حزمة الأدلة.
• تجميع نصوص الإفصاح عبر تركيب نصوص معتمدة مسبقاً مع حقائق خاصة بالفترة، مع إسنادها إلى الأدلة.
• استرجاع الأدلة الداعمة لأسئلة داخلية، ما دام الاسترجاع من مستودعات مُحكَمة governance، لا من الويب المفتوح.
• فحوص الاتساق اللغوي: هل تتعارض الشروحات مع بعضها، هل تنحرف التعريفات بين الأقسام، هل نستخدم المصطلح نفسه للمفهوم نفسه.

وهذه استخدامات سيئة، حتى لو بدت فعّالة في عرض تجريبي:

• توليد الأرقام (“تقدير البيانات الناقصة”، “سد الفجوات”، “تنعيم الشذوذ”). هذا نمذجة، لا إعداد تقارير.
• تحويل الأرقام داخل prompt (“حوّل هذا الجدول إلى الإيراد المُبلّغ حسب المنطقة”). هذا التحويل يحتاج طبقة حتمية بمنطق مُدار بالإصدارات.
• تصحيح البيانات (“يبدو هذا خطأ، عدّله”). الأداة لا يمكن أن تملك الضبط. على البشر التحقيق من المنبع ثم إعادة تشغيل المسار الحتمي.
• الموافقة التلقائية على المسودات أو التوقيعات. التوقيع يجب أن يرتبط بالمساءلة، لا بالراحة.

في مشاريعي الخاصة، بما فيها IBHQ وShopeno، أفكر في AI بالطريقة نفسها: ليُسرّع القرارات، لا ليحل محل system of record. في اللحظة التي يصبح فيها النموذج هو السجل، تفقد الثقة وتفقد قابلية التشخيص.

ضوابط يمكنك تطبيقها هذا الربع

إذا كنت CFO، أو مراقباً مالياً، أو مسؤولاً عن التقارير، أو عضواً في مجلس الإدارة يسأل “ماذا نفعل الآن”، فسأبدأ بقائمة تحقق قصيرة. هذه خطوات تشغيلية، لا تنظير.

1) اكتب سياسة الحدود في صفحة واحدة

• مخرجات LLM ليست أبداً سجلاً مالياً.
• يمكن لـ LLM فقط صياغة نص، ويجب أن يُحيل إلى artifacts الأدلة.
• لا تحصل أي أداة LLM على صلاحية كتابة إلى دفتر الأستاذ أو مستودع البيانات أو محرك التوحيد.

هذه السياسة تمنع “اختصارات” تبدو مفيدة ثم تتحول لاحقاً إلى دينٍ تشغيلي غير مرئي.

2) ابنِ حزمة أدلة كما لو كانت artifact لإصدار برمجي

• احفظ الاستعلامات والمعلمات التي أنتجت كل جدول مُبلّغ.
• احفظ لقطات من النتائج، لا الروابط فقط.
• امنح الحزمة معرّفاً فريداً واجعله مرساة لكل مسودة سرد.

بصفتي قائداً سابقاً للجودة في إلكترونيات القدرة، رأيتُ كيف تنضبط الفرق سريعاً حين يمكن ربط كل فشل ببناء محدد. جودة التقارير تتحسن بالطريقة نفسها حين تُربط كل دعوى بـ artifact محدد.

3) افرض الإحالات داخل السرد

لا تقبل تعليقاً حراً بلا مراجع. اشترط أن تتضمن المسودة إحالات داخلية مثل “EvidencePack:2026-05 CloseRun:14 Query:RevenueByRegion_v3”. وإذا لم يستطع النموذج الإحالة، فعليه أن يقول “insufficient evidence”.

4) اجعل تعليق الانحرافات قالباً خاضعاً للحَوْكمة

• عرّف شجرة الانحراف مرة واحدة.
• عرّف ما الذي يُعدّ بنداً غير متكرر.
• عرّف عتبات متى يمكن للنموذج اقتراح سرد، ومتى يجب التصعيد إلى مالك مسؤول.

هذا يقلل خطر انحراف السرد، ويجعل التعليق قابلاً للمقارنة ربعاً بعد ربع.

5) افصل بين “الصياغة” و“الموافقة” في الأدوات

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

سؤال مجلس الإدارة: ما الذي نحسّنه فعلاً؟

معظم النقاشات حول AI في التقارير تتوقف عند وفورات العمالة. هذه ليست دالة الهدف الصحيحة.

الهدف الحقيقي هو: تقليص زمن الدورة دون زيادة مخاطر التدقيق.

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

لذلك لا أريد “تقارير بالذكاء الاصطناعي”. أريد تسريعاً قابلاً للتدقيق. صياغة أسرع، مراجعة أسرع، فحوص اتساق أسرع. طبقة الحقيقة نفسها. وملكية الضوابط نفسها.

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

خلاصتي: أبقِ الآلة أمينة بإبقائها خارج الحقيقة

يمكن لـ LLMs أن تجعل التقارير أفضل فعلاً. يمكنها إزالة تكرار الصياغة، وتحسين الوضوح، وتقليص الدورات. وقد ترفع معيار الجودة عبر فرض لغة وبنية متسقتين.

لكن فقط إذا كنت صارماً بشأن أين يُسمح لها بالعمل.

ضعها في طبقة السرد. زوّدها بحزمة أدلة غير قابلة للتغيير. اشترط الإحالات. سجّل كل تغيير. أبقِ الحسابات حتمية وبإصدارات مُدارة. وأبقِ الموافقات بشرية ومصحوبة بالمساءلة.

هكذا تحصل على المكاسب دون أن تساوم على الشيء الوحيد الذي لا يمكن للتقارير أن تعيش بدونه: الحقيقة المالية.