الذكاء الاصطناعي المالي عبر MCP في ازدياد. لكن التحقق لا يزال غائبًا

افتح سجلّ تحديثات أي منصة FP&A تقريبًا هذا العام، وستجد البند نفسه يتكرر: خادم MCP، أو مجلدًا قابلًا للتنزيل من “مهارات الذكاء الاصطناعي” (وهي في جوهرها قوالب مطالبات) (prompts) تُدرجها في Claude أو أي مساعد آخر ليعرف كيف يطلب تقرير انحراف أو توقّع قوى عاملة. والرسالة التسويقية واحدة دائمًا بصيغة أو بأخرى: “الآن يمكن للذكاء الاصطناعي أن يتحدث مع بياناتك المالية”. خلال ربع سنة واحد فقط، تحوّل هذا من ميزة تنافسية إلى شرط أساسي لدخول السوق. الجميع بات يملكه.

وهذا يعني أن MCP بحدّ ذاته لم يعد يخبرك بشيء مفيد عن المزوّد. فهو بروتوكول، لا وعد. وقالب المطالبة سؤال مصاغ بعناية، لا إجابة. السؤال الحقيقي هو ما الذي يقف خلف نقطة الاتصال قبل أن يتدخل البروتوكول أصلًا: هل مخرجات عاملك الذكي حقيقة، أم تخمين مُغلّف بصيغة JSON؟ معظم الموجة الحالية من خوادم MCP المالية لم تجب عن هذا السؤال. هي فقط جعلت طرحه أسهل.

MCP وسيلة نقل. لا رأي له في الصحة

يحلّ بروتوكول Model Context Protocol مشكلة حقيقية: يمنح الذكاء الاصطناعي طريقة موحدة لاستدعاء الأدوات وجلب السياق، بدل أن يخترع كل مزوّد صيغة إضافات خاصة به. هذه فائدة فعلية، ولهذا انتشر تبنّي البروتوكول بسرعة. لكن انظر إلى ما يحدده MCP فعليًا: أشكال الطلب والاستجابة، اكتشاف الأدوات، مصافحات المصادقة، البث المباشر. لا يوجد في المواصفة بند واحد عن صحة الرقم الذي تعيده الأداة. فـMCP لا يسوّي دفتر الأستاذ العام لديك، ولا يعرف إن كانت “الإيرادات” التي يعرضها أحد الموارد قيمة عقد، أو إيرادًا معترفًا به، أو رقمًا من الربع الماضي لم يُحدَّث قط. كل ما يفعله هو نقل البيانات من خادم إلى نموذج بصيغة يتفق عليها الطرفان.

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

ملفات المهارات تعاني الفجوة نفسها، من طبقة أعلى

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

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

ما يتطلبه “التحقق” فعلًا، وأين يجب أن يحدث

الطبقة	ما تفعله	ما لا تفعله
قالب المطالبة / المهارة	يصوغ الطلب بشكل متسق	لا يؤكد صحة البيانات
خادم MCP	ينقل الطلب والاستجابة عبر بروتوكول موحد	لا يسوّي الرقم الأساسي أو يتحقق من مصدره
النموذج المسوّى	يربط كل رقم بمعاملته المصدر عبر الأنظمة	هنا يحدث التحقق فعليًا
المحرك الحتمي	يحسب الرقم بالطريقة نفسها في كل مرة، دون تخمين من النموذج	هنا تتحقق الدقة فعليًا

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

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

السؤال الذي يفرّق فعلًا بين المزوّدين

بما أن كل مزوّد تقريبًا بات يملك قصة MCP خاصة به، يجب أن ينتقل سؤال العناية الواجبة من “هل تدعمون MCP؟” (سيقول الجميع نعم) إلى سؤال يكشف الطبقة التي تحته:

“عندما يسحب عاملي رقمًا عبر خادم MCP لديكم، ما الذي يثبت أنه صحيح؟”

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

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

الخلاصة

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