الهندسة الوكيلية للبنوك: مخطّط 2026 للقيادة التنفيذية وللمهندسين الذين سيُنفّذونه #
انتقل الذكاء الاصطناعي الوكيلي من التجربة إلى الإنتاج في الخدمات المصرفية العالمية. تستخدمه 70% من المؤسسات بدرجاتٍ متفاوتة؛ ولدى واحدةٍ من كلّ خمسٍ نموذج حوكمة ناضج. في الوقت نفسه، يعمل الخصوم المستقلّون بسرعة الآلة، والممتلكات القديمة COBOL التي يجب أن تتفاعل معها الأنظمة الجديدة كُتبت لافتراضات الدفعات في الستينيات، وموعد «المخاطر العالية» في EU AI Act على بُعد اثني عشر أسبوعاً. هذا هو الموقف الهندسي والحوكمي الذي يحتاج البنك للحفاظ عليه.
Mga Pangunahing Punto
- التحوّل من vibe coding إلى التطوير المُوجَّه بالمواصفات لم يعد طموحياً. اعترف Andrej Karpathy، الذي صاغ "vibe coding" في فبراير 2025، بعد عامٍ ⧉ بانتهاء هذه الحقبة وأن الافتراضي الجديد للمحترفين هو الهندسة الوكيلية — تنسيق الوكلاء مقابل مواصفاتٍ مفصّلة بإشرافٍ بشري.
- تبنّي البنوك حقيقي ومتسارع. 70% من شركات الخدمات المصرفية ⧉ تُبلّغ عن استخدام الذكاء الاصطناعي الوكيلي بدرجاتٍ متفاوتة (16% في الإنتاج، 52% في التجربة، EY 2026)؛ 44% من فرق التمويل ستستخدمه هذا العام — زيادة 600%+ سنوياً وفق Wolters Kluwer.
- الحوكمة لم تواكب الوتيرة. يجد Deloitte State of AI 2026 أن واحدةً من كلّ خمس شركاتٍ فقط لديها نموذج حوكمة ناضج لوكلاء AI المستقلّين. يُحدّد تحليل Deloitte لقاعدة بيانات مخاطر MIT AI أكثر من 350 خطراً ⧉ يمكن أن ينشأ من السلوك المستقلّ أو الوكيلي.
- مشهد التهديد تصنّع. كشفت Anthropic في نوفمبر 2025 أن مجموعةً مدعومة من الدولة الصينية GTG-1002 اختطفت Claude Code لتشغيل تجسّسٍ مستقلّ ضدّ نحو 30 هدفاً، مع تعامل AI مع 80-90% من العمليات التكتيكية باستقلالية. لاحظ Flashpoint ارتفاع نقاشات AI غير المشروعة بنسبة 1500% ⧉ بين نوفمبر وديسمبر 2025 وحدهما.
- الممتلكات القديمة هي القيد الصامت. تستهلك ميزانيات IT للخدمات المالية 70-75% بالصيانة القديمة، 63% من البنوك لا تزال تعتمد على كودٍ كُتب قبل 2000، ومعظم البنوك تُبلّغ عن وجود شخصٍ أو شخصَين فقط داخلياً يستطيعون صيانة COBOL الذي تعمل عليه منصّاتها الأساسية. الذكاء الاصطناعي الوكيلي هو الآن النهج المهيمن لإغلاق تلك الفجوة.
- الكومة التنظيمية تتقارب. بموجب EU AI Act، يُحفّز 2 أغسطس 2026 الإنفاذ الكامل لأنظمة AI عالية المخاطر (يشمل Annex III صراحةً تقييم الائتمان وتقييم الجدارة الائتمانية). DORA نافذة بالفعل. SR 11-7 جرى تمديده في الممارسة التنظيمية ليُغطّي LLMs والأنظمة الوكيلية. والغرامات على الانتهاك تصل إلى 35 مليون يورو أو 7% من حجم الأعمال العالمي السنوي.
- الإشراف البشري ليس مفهوماً واحداً. التمييز بين HITL (Human-in-the-Loop، حيث لا يمكن للوكيل التنفيذ دون موافقةٍ بشرية صريحة) و HOTL (Human-on-the-Loop، حيث ينفّذ الوكيل باستقلالية تحت مراقبةٍ بشرية) هو الإطار العامل الآن للامتثال لـ EU AI Act Article 14، ويحتاج كلّ وكيل عالي المخاطر إلى موقفٍ صريح بشأن النموذج المُطبَّق.
- معظم الوكلاء سيُشترَون لا يُبنَون. إدارة مخاطر الأطراف الثالثة بموجب DORA هي التحدّي الأقلّ اعترافاً به والأكثر صوتاً في 2026. سيُورِّد البائعون معظم القدرة الوكيلية التي تنشرها البنوك؛ يبقى الالتزام التنظيمي مع البنك، ومعظم عقود البائعين الحالية لا يمكنها تلبية متطلبات وثائق Article 13.
- الهندسة الوكيلية ليست "ChatGPT زائد MCP servers". هي موقف ملكيةٍ هيكلية على التدفّقات من طرفٍ إلى آخر للمؤسسة — رحلات العملاء، ودورات حياة المعاملات، ومستوى التحكّم، وركيزة التدقيق، والأساس التشفيري الآمن للكم — مبني ومُشغَّل من قِبَل وظيفة الهندسة للمؤسسة نفسها، لا مُفوَّض إلى chatbot.
العام الذي أصبحت فيه الهندسة الوكيلية لا مفرّ منها #
سيطر على حوار الذكاء الاصطناعي في الخدمات المالية، حتى وقتٍ قريب جداً، أمران متجاوران لكن متمايزان: واجهات الدردشة التوليدية (مفيدة لكن محدودة)، وأنماط Retrieval-Augmented Generation المُرتبة فوق بيانات المؤسسة (مفيدة، محدودة أيضاً). ما تغيّر بين أواخر 2025 ومطلع 2026 هو أن الفئة الثالثة — الوكلاء المستقلّون الذين يُخطّطون وينفّذون ويُكملون سير عملٍ متعدّد الخطوات بإشرافٍ بشري محدود — انتقلوا من العرض التقني إلى الواقع التشغيلي، وعبروا آنياً إلى كلٍّ من المؤسسة والجهة الفاعلة في التهديد.
Andrej Karpathy، الذي صاغ مصطلح "vibe coding" في فبراير 2025 ⧉، أمضى العام التالي يُراقب المهندسين المحترفين يتجاوزونه. مراجعته — "الهندسة الوكيلية" — هي الآن المصطلح العامل عبر الصناعة. جوهر التحوّل مباشر: في العمل الهندسي الجدّي في 2026، لا يكتب المهندسون الكود مباشرةً 99% من الوقت. يُنسّقون الوكلاء الذين يفعلون، فيما يتصرّفون بصفة المُشرف. لم يعد العمل كتابة الحروف في محرّر؛ هو إنتاج المواصفات التي تُقيّد ما يمكن للوكلاء توليده، وتصميم بوّابات التحقّق التي يجب أن تمرّ بها المخرجات، وتنسيق القرارات المعمارية التي ينفّذها الوكلاء.
يبدو هذا التحوّل حواراً لفريق هندسي. في الخدمات المصرفية ليس كذلك. هو حوار على مستوى مجلس الإدارة، لأن القدرة الوكيلية نفسها التي تُعيد كتابة كيفية إنتاج الكود الداخلي تُعيد أيضاً كتابة كيفية عمل الخصوم الخارجيين، وكيف تتوقّع الجهات التنظيمية ممارسة الإشراف، وكيف يُعرَّف المحيط المؤسسي. البنك الذي لا يمتلك موقفه بشأن الهندسة الوكيلية بحلول نهاية 2026 ليس بنكاً تجنّب السؤال. هو بنكٌ أجاب بائعوه وخصومه وجهاته التنظيمية عن السؤال نيابةً عنه.
حالة التبنّي في الخدمات المصرفية #
الصورة الإجمالية لا لبس فيها. وفقاً للأبحاث المُجمَّعة عبر استطلاعاتٍ متعدّدة في 2026، يُبلّغ 70% من التنفيذيّين في البنوك ⧉ عن أن شركاتهم تستخدم بالفعل الذكاء الاصطناعي الوكيلي بدرجاتٍ متفاوتة. تتوقّع Gartner ⧉ أن بحلول نهاية 2026 ستُشغّل نحو 40% من جميع شركات الخدمات المالية وكلاء AI بشكلٍ ما. الإنفاق على AI للخدمات المالية في طريقه للوصول إلى 67 مليار دولار بحلول 2028 (IDC). يُقدّر McKinsey أن AI الوكيلي يمكن أن يُعيد 10-12 ساعة أسبوعياً لمديري العلاقات في الخدمات المصرفية.
صورة التنفيذ أقلّ تشجيعاً. يُبلّغ KPMG ⧉ عن أن 99% من الشركات تُخطّط لوضع الوكلاء المستقلّين في الإنتاج لكن 11% فقط فعلت ذلك. يجد EY أن 34% من القادة بدأوا استخدام وكلاء AI و 14% فقط نفّذوهم بالكامل. يجد Forrester أن 57% من المنظمات تعتقد أنها تفتقر إلى القدرات الداخلية للاستفادة من AI الوكيلي. الفجوة بين النيّة والتنفيذ ليست أثراً تسويقياً. هي انعكاسٌ حقيقي للعمل الهندسي والحوكمي والثقافي الذي لم يُنجَز بعد.
رفعت Financial Conduct Authority في المملكة المتحدة مخاوف ⧉ علناً بشأن سرعة النشر التي تتجاوز نضج الحوكمة — توتّر أطّرته Jessica Rasu، Chief Data Officer لـ FCA، كخطرٍ قريب الأمد لمستهلكي التجزئة. حذّر McKinsey بشكلٍ منفصل من أن البنوك التي تفشل في تكييف نماذج أعمالها ⧉ تُخاطر بتآكل حتى 170 مليار دولار من الأرباح العالمية بحلول 2030. كلتا الملاحظتَين صحيحتان آنياً. السؤال ليس ما إذا كان يجب التحرّك؛ بل كيف يجب التحرّك بالنزاهة التشغيلية والحوكمية التي طلبتها تنظيمات الخدمات المالية دائماً، والتي تجعلها الأنظمة الوكيلية أحدّ.
ثلاثة متّجهات مخاطر يجب على البنوك استيعابها #
قبل أيّ حوارٍ معماري، ينبغي أن يستقرّ اهتمام مجلس الإدارة على ثلاثة مخاطر خاصّة بالأنظمة الوكيلية وتصل أبكر ممّا خطّطت له معظم البنوك.
1. الخصم المستقلّ #
أكثر تطوّرات 2026 إرباكاً هو تشغيل AI الوكيلي على جانب الهجوم. في أغسطس 2025، كشفت Anthropic عن فئةٍ من النشاط أسمتها vibe hacking ⧉: مجرمو الإنترنت يستخدمون AI الوكيلي لتنفيذ هجماتٍ متطوّرة على نطاقٍ واسع، مع تضمين AI في الاستطلاع، وجمع بيانات الاعتماد، واختراق الشبكة، وتحليل البيانات المسروقة. في نوفمبر 2025 ⧉، كشفت Anthropic أنها عطّلت حملةً من قِبَل مجموعةٍ مدعومة من الدولة الصينية (مُصنَّفة GTG-1002) اختطفت نُسخ Claude Code لتشغيل تجسّسٍ مستقلّ ضدّ نحو ثلاثين هدفاً للدفاع والطاقة والتقنية، مع تعامل AI مع 80-90% من العمليات التكتيكية والعمل بـ آلاف الطلبات في الثانية — سرعاتٌ مستحيلة على المُشغّلين البشريين.
في يناير 2026، اخترقت Step Finance — مدير محفظة DeFi قائم على Solana — بطريقةٍ حوّلت تطفّلاً على جهاز إلى خسارة 27-30 مليون دولار لأن وكلاء التداول AI للشركة كان لديهم أذونات لتنفيذ تحويلاتٍ كبيرة دون موافقةٍ بشرية. هندس المهاجم اجتماعياً AI نفسه، مدّعياً تشغيل برنامج مكافآت أخطاء مُرخَّص. لم يكن الدرس ⧉ أن AI كان آمناً جوهرياً؛ بل أن وكيل AI الذي يقبل التفويض المُدَّعى دون تحقّق هو نقطة ضعفٍ في المحيط.
الاتجاه الإجمالي هو ما يجب على البنوك استيعابه. حدّد تقرير Flashpoint Global Threat Intelligence لـ 2026 ارتفاعاً بنسبة 1500% في النقاشات غير المشروعة المتعلّقة بـ AI ⧉ بين نوفمبر وديسمبر 2025، مع تطوير المهاجمين بنشاطٍ أنظمةً مستقلّة تكشط البيانات، وتُدير البنية التحتية، وتُعدّل الرسائل، وتتعلّم من المحاولات الفاشلة دون إشرافٍ بشري متواصل. كان Jamie Dimon من JPMorgan صريحاً علناً ⧉ بأن الميزة الأولية في هذه التقنية تذهب للهجوم، لا للدفاع. التداعي غير مريح: بنكٌ يُشغّل عمليات أمنٍ كلاسيكية ضدّ خصوم وكيليّين هو، هيكلياً، في موقف لاعب شطرنج أُعطيَ خصمه حاسوب.
2. تراجع جودة الكود #
المتّجه الثاني داخلي وأكثر هدوءاً. كود LLM المُولَّد، في غياب انضباط المواصفات والتحقّق الصارم، يُشحَن بعيوبٍ بمعدّلٍ أعلى بكثيرٍ من الكود المكتوب بشرياً. وجد تحليل SonarQube لخمسة LLMs حدودية ⧉ تولّد كود Java أن أكثر من 70% من الثغرات المُكتشَفة في مخرجات Llama 3.2 90B صُنّفت بشدّة BLOCKER، مع نحو ثُلثَي ثغرات GPT-4o و OpenCoder-8B مصنّفة BLOCKER أو CRITICAL. وجد Pearce et al. (IEEE S&P) أن نحو 40% من برامج LLM المُولَّدة في سياقاتٍ حسّاسة أمنياً تحتوي ثغرات. وضع Yan et al. (2025) النطاق عند 9.8-42.1% عبر معاييرهم. حدّد فهرسٌ منفصل من Fu et al. 43 CWE عبر ثلاث أدوات توليد كود AI.
لصناعةٍ غير منظَّمة، هذه ضريبة إنتاجية. للبنك، هي خطرٌ تنظيمي وتشغيلي يتراكم. الكود الذي يُشحَن بمعدّل ثغراتٍ مرتفع في نظامٍ يتعامل مع المدفوعات أو التسوية أو بيانات العملاء ليس قضية جودة كود بشكلٍ مُجرَّد؛ هو السطح الذي ستُحقّقه الخصوم من فئة GTG-1002 في 2027 بنفس الأدوات الوكيلية التي أنتجته. الدفاع ليس حظر كود LLM المُولَّد (مستحيلٌ تجارياً) بل إحاطته ببنية التحقّق والمواصفات التي تضمن ظهور العيوب قبل النشر. هذا هو السبب العملي الذي يُتبنّى به التطوير المُوجَّه بالمواصفات بسرعة من قِبَل منظمات هندسة المؤسسات التي ليست شركات تقنية أصلاً.
3. مرساة الإرث #
المتّجه الثالث هو الذي تفهمه البنوك بالفعل أفضل، والذي جعلته نقلة AI الوكيلي آنياً أكثر إلحاحاً وأكثر قابلية للمعالجة. أكثر من 70% من شركات Fortune 500 لا تزال تعتمد على mainframes، تُلاحظ تحليلات Computer Weekly ⧉، مبنيّةً غالباً على عقودٍ من COBOL و RPG المُتشابكَين مع منطق أعمالٍ مخصّص. في الخدمات المالية تحديداً، تستهلك التقنيات القديمة 70-75% من الإنفاق السنوي على IT ⧉. وجدت دراسة CIO المذكورة في تحليل صناعة 2026 أن 63% من البنوك لا تزال تعتمد على كودٍ كُتب قبل 2000، وأبلغ أكثر من 75% عن وجود شخصٍ أو شخصَين فقط داخلياً بمهارات صيانته.
ما تغيّر في فبراير 2026 كان وصول أدواتٍ وكيلية موثوقة لتحديث الإرث. إعلان Anthropic بأنّ Claude Code يستطيع رسم تبعيات COBOL، وتوثيق سير العمل، وتحديد المخاطر ⧉ التي يستغرق المحلّلون البشر شهوراً لإبرازها — مقترناً بقدراتٍ مماثلة من Microsoft (GitHub Copilot for COBOL، Watsonx Code Assistant) و AWS (Mainframe Modernization مع AI الوكيلي) — ضغط منحنى تكلفة التحديث مادياً. كان ردّ فعل سعر سهم IBM (انخفاض 13% يوم الإعلان) إشارة سوق غير أنيقة لكنها دقيقة. يُمثّل AI الآن نحو ثلث استثمار التحديث المؤسسي، وأكثر من 75% من المؤسسات تستخدم AI في استراتيجية التحديث لديها. مرساة الإرث هي، للمرّة الأولى، مشكلة هندسية قابلة للمعالجة لا مشكلة جيلية.
لماذا لا يمكن أن يكون vibe coding الافتراضي في الخدمات المصرفية #
يجدر التحديد بدقّةٍ سبب فشل vibe coding — موجَّز قصير، ملاحظة المخرَج، التكرار — كسير عمل افتراضي في ممتلكاتٍ منظَّمة. وضع الفشل ليس الواضح (LLM يُهلوس أحياناً). وضع الفشل هيكلي ويظهر في أربعة أماكن آنياً.
الأول انعدام الاتفاقيات المشتركة. سينتج مهندسون متعدّدون يعملون عبر موجّزات الدردشة خمس طرقٍ مختلفة لفعل الشيء نفسه في قاعدة الكود نفسها خلال ربعٍ واحد. في سياقٍ غير منظَّم، هذه ديون تقنية. في سياقٍ منظَّم، هذا هو السطح الذي ينكسر تحت الفحص.
الثاني تحلّل السياق. وكلاء AI عديمو الحالة. في مشروعٍ كبير، تتجاوز المحادثات نوافذ السياق، ويتبخّر التفكير وراء القرارات المعمارية السابقة. الوكيل نفسه، بعد أسبوعَين، سيتّخذ القرار العكسي في دردشةٍ جديدة لأن لا شيء يُحفظ من منطق الأولى. للأنظمة التي تحتاج إلى مسار تدقيقٍ للجهات التنظيمية، هذا غير متوافقٍ هيكلياً.
الثالث تراكم العيوب غير المرئي. نتائج Pearce و Yan و SonarQube المذكورة أعلاه ليست حالات زاوية. هي المعدّل الأساسي الذي تُولّد فيه LLMs كوداً ضعيفاً في غياب انضباط المواصفات والاختبار الصارم. بنكٌ يُشغّل سير عمل vibe coding في الإنتاج يُراكم هذه العيوب بنفس المعدّل، دون رؤية السطح لمعرفة ما شُحن.
الرابع هو مشكلة التتبّع التنظيمي. تتطلب Article 12 من EU AI Act تسجيلاً آلياً للمدخلات والمخرجات لأنظمة AI عالية المخاطر. يتطلب SR 11-7 أدوار مالك النموذج والمُحقّق الموثّقة، وإدارة التغيير لتحديثات النموذج، وتقريراً لمجلس الإدارة حول مخاطر نموذج AI. تتطلب DORA إدارة شاملة لمخاطر ICT بأدلّةٍ موثّقة. لا يمكن تلبية أيٍّ من هذه الالتزامات بسير عمل قطعته الأثرية الأولية هي تاريخ دردشةٍ لا يحفظه أحد.
الاستنتاج ليس أن LLMs غير ملائمة للخدمات المصرفية. الاستنتاج هو أن سير العمل المُحيط بها يجب أن يُنتج مواصفاتٍ ومسارات تدقيقٍ وبوّابات تحقّقٍ كمخرجاتٍ من الدرجة الأولى لا كأفكار لاحقة. هذا ما هو عليه التطوير المُوجَّه بالمواصفات، تشغيلياً.
التطوير المُوجَّه بالمواصفات في ممتلكاتٍ منظَّمة #
يقلب التطوير المُوجَّه بالمواصفات (SDD) ترتيب العمل. بدلاً من القفز إلى التنفيذ والتكرار مع وكيل، يُنتج الفريق مواصفةً أولاً — قرارات معمارية، متطلّبات، عقود واجهات، معايير نجاح، قيود أمن — ويُولّد الوكيل كوداً يُلبّي المواصفة. التحقّق مُنظَّم: تُعرّف المواصفة ما يجب أن يفعله المخرج، ويفحص عمليةٌ منفصلة (توليد الاختبارات، مراجعة الكود، التحقّق الرسمي حيث يُطبَّق) ما إذا كان قد فُعل.
تماسكت الأدوات العملية في أواخر 2025 ومطلع 2026. تُضفي GitHub's Spec Kit ⧉ (الصادرة في أواخر 2025) الطابع الرسمي على القصد قبل توليد الكود. تُدمج AWS سير عمل أوّلية للمواصفات مباشرةً في Kiro IDE. قدّمت JetBrains و Cursor أوضاع تخطيطٍ تُهيكل تفاعل AI. تدفع أُطرٌ مثل BMAD (Breakthrough Method for Agile AI-Driven Development) أبعد بفرقٍ من وكلاء AI متخصّصين يعكسون أدوار المحلّل والمعماري والمطوّر و QA عبر SDLC. يُضمّن Constitutional SDD، المُنسَّق في ورقة arXiv في فبراير 2026، قيود الأمن الصريحة مع تعيينات ثغرات CWE في المواصفة نفسها.
للبنك، المتغيّر الذي يهمّ هو ما يُسمّيه تحليل Augment Code التطوير المرتكز على المواصفة — تأتي المواصفات أولاً، يُولّد AI كوداً مُقيَّداً بها، وتجلس طبقات حوكمةٍ إضافية (قيود دستورية، نقاط فحص الإشراف، بوّابات الموافقة البشرية) بين التوليد والدمج. هذا هو المتغيّر الوحيد الذي يُنتج مسار التدقيق الذي تتوقّعه Article 12 من EU AI Act، ودور المُحقّق الموثّق الذي يتطلبه SR 11-7، وانضباط إدارة التغيير الذي تتطلبه DORA.
الكومة التنظيمية المُطبَّقة الآن #
محيط التنظيم لـ 2026 حول AI في الخدمات المصرفية لم يعد قائمةً مرجعية؛ هو كومةٌ من الالتزامات المتداخلة التي تحتاج إلى التفكير فيها معاً. التاريخ الواحد الأكثر تبعاتٍ هو 2 أغسطس 2026، حين تصبح التزامات أنظمة EU AI Act عالية المخاطر قابلة الإنفاذ بالكامل ⧉. يُصنّف Annex III صراحةً تقييم الائتمان وتقييم الجدارة الائتمانية، وتقييم المخاطر في تأمين الحياة والصحة، وتقييم أو تصنيف الوضع المالي للأفراد كعالي المخاطر. الالتزامات التي تتدفّق من ذلك التصنيف تشمل تقييمات الامتثال، وأنظمة إدارة الجودة، وأُطر إدارة المخاطر، والوثائق التقنية، والتسجيل في قاعدة بيانات الاتحاد الأوروبي، وحوكمة البيانات القوية، والإشراف البشري، وحماية الأمن السيبراني. تصل عقوبات انتهاك التزامات المخاطر العالية إلى 35 مليون يورو أو 7% من حجم الأعمال العالمي السنوي، أيّهما أعلى.
تجلس بجانب AI Act:
- DORA (Digital Operational Resilience Act) نافذة منذ يناير 2025 وتُنشئ 22 التزاماً لإدارة مخاطر ICT يُغطّي صراحةً أنظمة AI المُستخدَمة في وظائف الخدمات المالية الحرجة.
- SR 11-7 — إرشاد إدارة مخاطر النموذج لـ Federal Reserve و OCC، المكتوب أصلاً في 2011 — جرى تمديده في الممارسة التنظيمية ⧉ ليُغطّي LLMs والأنظمة الوكيلية.
- NIST AI RMF (1.0، يناير 2023) طوعي في الولايات المتحدة لكنه يُشار إليه كخطّ أساس من الجهات التنظيمية الفيدرالية.
- ISO/IEC 42001 (المنشورة في ديسمبر 2023) هو معيار أنظمة إدارة AI القابل للاعتماد الأول.
- UK SM&CR و Consumer Duty — يتطلب نظام Senior Managers and Certification الآن المساءلة المسمّاة لكلّ نظام AI عالي المخاطر.
- خارطة طريق G7 لما بعد الكم (يناير 2026)، وإطار NCSC ذو المراحل الثلاث، ونتائج BIS Project Leap تجلس بجانب هذه الكومة. (للنظرة الأعمق على الجانب التشفيري، انظر مقالة مايو 2026 عن هجرة ما بعد الكم في التمويل المؤسسي.)
ثلاثة أنماط من التطوير المُساعَد بـ AI مُقارَنة #
| البُعد | Vibe Coding | التطوير المُوجَّه بالمواصفات | الهندسة الوكيلية |
|---|---|---|---|
| المدخل الأساسي | موجّز قصير | مواصفة رسمية | مواصفة + خطة تنسيق الوكيل |
| دور المهندس | مكرّر الموجّز | مؤلّف المواصفة | المُنسّق والمُحقّق |
| انضباط المخرج | توليد مباشر للكود | كود مُقيَّد بالمواصفة | سير عمل متعدّد الوكلاء يُنتج الكود والاختبارات والوثائق |
| مسار التدقيق | تاريخ الدردشة (غير محفوظ) | مواصفة + كود مُولَّد + اختبارات | مواصفة + آثار الوكيل + قطع التحقّق |
| معدّل العيوب (LLM فقط) | معدّل ثغرات 10-40% (خطّ أساس الأدبيات) | منخفض مادياً بقيود المواصفة | الأدنى مع بوّابات التحقّق |
| التتبّع التنظيمي | غير كافٍ لـ AI عالي المخاطر | متوافق مع EU AI Act Article 12 | مُصمَّم لـ Article 12 + SR 11-7 + DORA |
| ملائم للخدمات المصرفية؟ | لا، للإنتاج | نعم، مع الحوكمة | نعم، مع حوكمةٍ ناضجة |
| سقف القدرة | محدود بالموجّز الواحد | محدود بجودة المواصفة | محدود بجودة التنسيق |
بناء البنك الوكيلي: نظرة معمارية #
الموقف الاستراتيجي وراء سير العمل هذا هو ما يحتاج C-suite إلى امتلاكه صراحةً. الهندسة الوكيلية في الخدمات المصرفية ليست مبادرة إنتاجية للمطوّر. هي قدرةٌ مؤسسية تمسّ رحلات العملاء من طرفٍ إلى آخر، ودورة حياة المعاملة بأكملها، والركيزة التشفيرية والتدقيقية التي تستند إليها كلتاهما. تستحقّ أربع طبقاتٍ من تلك القدرة اهتماماً تنفيذياً مباشراً، من القمّة إلى القاعدة:
الطبقة 4 — مستوى تحكّم الوكيل الحوكمة، التدقيق، مفاتيح الإيقاف، اكتشاف الشذوذ السلوكي، التجاوز البشري. تكوينات إشراف HITL و HOTL لكلّ فئة وكيل.
الطبقة 3 — سير العمل الوكيلي رحلات العملاء، العمليات الداخلية، خطّ التطوير. مُوجَّه بالمواصفات افتراضياً للتدفّقات عالية المخاطر.
الطبقة 2 — طبقة البيانات والنموذج AIBOM (AI Bill of Materials)، سجلّ النموذج، ركيزة الاسترداد، تحكّم في إصدار قالب الموجّز، نسب التدريب الدقيق.
الطبقة 1 — الأساس الآمن للكم ML-KEM، ML-DSA، PKI هجين، المرونة التشفيرية. الركيزة التي تعتمد عليها ادّعاءات التكامل لكلّ طبقةٍ أعلى.
الإشراف البشري عملياً: HITL مقابل HOTL #
التمييز الواحد داخل الطبقة 4 الذي تُركّز عليه الجهات التنظيمية أكثر في 2026 هو بين نموذجَي إشراف. كلاهما أشكالٌ من الإشراف البشري؛ يختلفان في الكُمون والمقياس والافتراض الذي تكون الجهة التنظيمية على استعداد لمنحه بشأن سلوك الوكيل.
Human-in-the-Loop (HITL) هو النموذج الذي لا يستطيع فيه وكيلٌ تنفيذ إجراءٍ تبعي دون موافقةٍ بشرية صريحة. وكيل معالجة KYC يُعلِّم حساباً للإغلاق لكنه لا يستطيع إغلاقه دون توقيع موظف الامتثال هو HITL. المُقايضة تشغيلية: HITL أكثر أماناً ويُنتج مسار تدقيق Article 14 لا لبس فيه، لكنه لا يتوسّع إلى سير العمل عالي الحجم منخفض الكُمون.
Human-on-the-Loop (HOTL) هو النموذج الذي ينفّذ فيه الوكيل باستقلالية ضمن معلَماتٍ محدّدة، مع بشرٍ يراقبون القياس عن بُعد في الوقت الفعلي ويحتفظون بسلطة إيقاف الوكيل في أيّ نقطة. وكيل فحص احتيالٍ في الوقت الفعلي يحظر تلقائياً المعاملات المطابقة لأنماط مخاطرٍ محدّدة، مع فريق عملياتٍ بشري يراقب حجم التنبيهات ويتدخّل في الشذوذات، هو HOTL.
EU AI Act Article 14 لا تُحدّد HITL مقابل HOTL؛ تتطلب أن يكون الإشراف البشري ذا معنى. التداعي العملي هو أن كلّ وكيلٍ عالي المخاطر يُشغّله البنك يجب أن يكون له موقفٌ صريح ومُوثَّق بشأن النموذج المُطبَّق ولماذا، وما هو مسار التصعيد عندما يواجه الوكيل مواقف خارج معلَماته المحدّدة.
الشراء مقابل البناء: مشكلة الوكلاء من الأطراف الثالثة #
واقع 2026 الذي تسلّل إلى معظم البنوك هو أنها لن تبني، في الغالب، القدرة الوكيلية. ستشتريها. مشهد البائعين — منصّة Oracle المصرفية الوكيلية المُطلَقة في فبراير 2026، Watsonx من IBM، مجموعة Copilot من Microsoft، AWS Bedrock Agents، Salesforce Agentforce، NowAssist من ServiceNow، وموجة بائعي الوكلاء المتخصّصين في FinTech — يتحرّك أسرع ممّا تستطيع هندسة البنك الداخلية. التبعة الاستراتيجية هي أن معظم الوكلاء العاملين داخل بنكٍ في 2027 ستكون قد كُتبت من قِبَل شخصٍ آخر، وسؤال الحوكمة لم يعد "هل يمكننا الوثوق بوكلائنا؟" بل "هل يمكننا الوثوق بالوكلاء الذين أشتريناهم، وهل يمكننا إثبات ذلك لجهةٍ تنظيمية؟"
هذا هو التحدّي الأقلّ اعترافاً به والأكثر صوتاً بموجب DORA. تجعل Articles 28-30 من التنظيم إدارة مخاطر الأطراف الثالثة لـ ICT منطقةً إشرافية فاعلة. الواقع التشغيلي الجديد هو أن بائعي AI في 2026 — مُوفّرو النماذج الحدودية، وبائعو منصّات الوكلاء، و SaaS المُمكّن لـ AI — هم، بشكلٍ متزايد، الأطراف الثالثة لـ ICT التي كُتبت DORA لتغطيتها.
للبنك في موقف الشراء، تُطبَّق ثلاثة انضباطات عملية:
اطلب AIBOM من البائع. أيّ منتج وكيل مُشترى للاستخدام في سير عملٍ عالي المخاطر يجب أن يأتي بقائمة موادٍ موثّقة تُغطّي النماذج الأساسية، وأصل بيانات التدريب وقيودها، والتدريبات الدقيقة المُطبَّقة، ومؤشّرات الاسترداد المُتاحة، وإصدارات قوالب الموجّز، وسلسلة التبعية لمكوّنات الوكيل في الأسفل.
اختبر الصندوق الأسود، لا الكُتيّب. يجب على المؤسسة إجراء اختبارٍ سلوكي للوكيل تحت ظروفٍ مماثلة لنشره الإنتاجي المقصود — بما في ذلك التحقيق الخصومي لحقن الموجّز، ومقاومة الهندسة الاجتماعية (متّجه Step Finance)، والانجراف تحت تحوّلات توزيع البيانات، وأنماط الكُمون والفشل لمسار مفتاح الإيقاف والتجاوز.
أعد التفاوض على العقود بشروط Article 13. معظم اتفاقيات بائعي AI الحالية لا تتضمّن أيّاً من حقوق التوثيق، أو إخطار تغيير النموذج، أو إبلاغ الحوادث، أو حقوق التدقيق، أو إفصاحات المعالج الفرعي التي يطلبها EU AI Act و DORA معاً.
ماذا يعني ذلك بحسب نوع البنك #
البنوك الشاملة من المستوى الأول #
المؤسسات بميزانياتٍ عمومية تتجاوز تريليون دولار وحضور عالمي هي آنياً الأكثر عرضةً (أوسع محيط تنظيمي، أكبر ممتلكات قديمة، أعلى هدف قيمي للخصوم المستقلّين) والأفضل تجهيزاً. الأولوية الاستراتيجية هي بناء مستوى التحكّم أولاً — الطبقة 4 من المعمارية أعلاه — وإحضار انضباط التطوير المُوجَّه بالمواصفات إلى وظيفة الهندسة الداخلية قبل توسيع نشر الوكيل أكثر.
البنوك من المستوى المتوسّط والإقليمية #
سؤال المنافسة لبنوك المستوى الثاني أحدّ من بنوك المستوى الأول. تواجه المحيط التنظيمي نفسه دون ميزانية الحوكمة نفسها. الإجابة العملية هي التوحيد القياسي على عددٍ صغير من البائعين المُدقّقين (بعقودٍ تُلبّي متطلبات وثائق Article 13)، والاستثمار في انضباط التطوير المُوجَّه بالمواصفات بدلاً من هندسة المنصّات المخصّصة، واستخدام الأدوات الوكيلية لضغط جدول تحديث COBOL.
FinTechs، PSPs، والمؤسسات الملاصقة للعملات المشفّرة #
لقطاع FinTech ومؤسسات المدفوعات المشكلة العكسية: المرونة عالية، الحوكمة غالباً أقلّ من البنوك النظيرة، وتعرّض عقوبات EU AI Act، لـ FinTech متوسط الحجم، قد يكون وجودياً. الانضباط الاستراتيجي هو معاملة حوكمة AI كبوّابة جاهزية منتج بدلاً من تراكب امتثال.
وظائف الهندسة الداخلية #
للمهندسين والباحثين الذين يقرؤون هذا، الانضباط العامل الذي يهمّ هو اليومي. انقل مركز ثقل العمل من كتابة الحروف إلى إنتاج المواصفات وأدوات التحقّق. عامل آثار الوكيل، والخطط الوسيطة، وبوّابات الموافقة كقطعٍ أثرية من الدرجة الأولى في تحكّم الإصدار لديك. استثمر في الأدوات — Spec Kit، Kiro، وضع خطة Cursor، Claude Code بملفات مهارات على مستوى المشروع — التي تجعل المواصفة هي القطعة الأثرية الدائمة والكود المُولَّد هي القابلة للتخلّص.
خطة العمل لمدّة 12 أسبوعاً حتى أغسطس 2026 #
للراعي التنفيذي الذي يُدير برنامج هندسةٍ وكيلية بين الآن وتاريخ إنفاذ EU AI Act، يضغط العمل في تسلسلٍ من اثني عشر أسبوعاً.
الأسبوعان 1-2 — إنتاج AIBOM. أنشئ الجرد المركزي لكلّ نظام AI، ونموذج، ومجموعة بيانات، وقالب موجّز، ومؤشّر استرداد، وتدريب دقيق، وتبعية AI من طرفٍ ثالث في الإنتاج أو قيد التطوير. ارسم خريطة كلّ إدخالٍ إلى تصنيف EU AI Act Annex III.
الأسبوعان 3-4 — صنّف نموذج الإشراف لكلّ نظام. لكلّ وكيلٍ عالي المخاطر وتبعي، وثّق صراحةً ما إذا كان نموذج الإشراف هو HITL أو HOTL، والمنطق، ومسار التصعيد، والإنسان المسمّى المسؤول بموجب SM&CR (المملكة المتحدة) أو النظام الوطني المُكافئ.
الأسبوعان 5-6 — ابنِ أو شدّد مستوى تحكّم الوكيل. تسجيل الإجراءات في الوقت الفعلي، اكتشاف الشذوذ السلوكي، مسارات مفتاح الإيقاف والتجاوز عاملة على كلّ وكيل إنتاجي.
الأسبوعان 7-8 — مراجعة عقود البائعين. القانوني والمشتريات يسيران كلّ عقد بائع AI نشط لحقوق وثائق Article 13، وإخطار تغيير النموذج، وإبلاغ الحوادث، وحقوق التدقيق، وإفصاحات المعالج الفرعي.
الأسبوعان 9-10 — تجريبة جافّة لتقييم الامتثال. لكلّ نظامٍ عالي المخاطر بموجب Annex III، أكمل سير عمل تقييم الامتثال كما لو كانت هيئةٌ مُبلَّغة ستصل الأسبوع التالي.
الأسبوعان 11-12 — التحقّق قبل التحوّل وموافقة مجلس الإدارة. المراجعة النهائية لـ AIBOM، وتصنيفات HITL/HOTL، وأدلّة مستوى التحكّم، وحالة معالجة البائعين، ومخرجات تقييم الامتثال. مساءلة كبار المديرين المسمّاة مُؤكّدة. مجلس الإدارة يُسجّل الموقف في المحضر.
الخاتمة #
الملاحظة القاسية التي تبلورت عبر الصناعة في الأشهر الستّة الأخيرة هي أن الطرق القديمة للعمل بمقياس المؤسسة تتجاوزها لا تقنية جديدة بل نمط عملٍ جديد. كشفت الأدوات الوكيلية — أحياناً في الإنتاج، أحياناً في تقارير الحوادث — عيوباً وفجواتٍ في الممتلكات القديمة كانت تتراكم بصمتٍ لسنوات. أتاحت الأدوات نفسها للجهات الفاعلة الخبيثة الموارد التي كانت تتطلب سابقاً دعم جهةٍ على مستوى الدولة. الأدوات نفسها، المستخدَمة داخلياً وبانضباط، هي الطريق الأكثر موثوقية الذي لدى المؤسسات لإغلاق فجوة الإرث، وتلبية موعد أغسطس 2026 التنظيمي، والوصول إلى الإيقاع التشغيلي الذي تتطلبه الآن توقّعات العملاء والواقع التنافسي.
المؤسسات التي تمتلك هذا الموقف داخلياً — التي تُعامل الهندسة الوكيلية كقدرةٍ هيكلية للبنك بدلاً من تراكب إنتاجية مُشترى من بائع — ستقضي العامَين المقبلَين تُراكم الميزة. المؤسسات التي لا تفعل ستقضي العامَين المقبلَين تكتشف، في تقارير الحوادث ونتائج الجهات التنظيمية، ما كان ينبغي بناؤه.
الأسئلة الشائعة #
ما الفرق بين generative AI و agentic AI والهندسة الوكيلية؟
ينتج generative AI محتوى استجابةً لموجّز؛ هو تفاعلي. agentic AI يسعى لتحقيق أهدافٍ مُحدّدة بشكلٍ مستقلّ، يصل إلى البيانات، يستخدم الأدوات، ويتّخذ إجراءاتٍ عبر سير عملٍ متعدّد الخطوات دون الحاجة إلى موجّز بشري في كلّ خطوة. الهندسة الوكيلية — المصطلح الذي تبنّاه Karpathy في 2026 ⧉ — هو الانضباط العامل لتنسيق الوكلاء مقابل مواصفاتٍ مفصّلة بإشرافٍ بشري.
لماذا موعد EU AI Act في أغسطس 2026 ذو تبعاتٍ للبنوك؟
يُصنّف Annex III من AI Act صراحةً عدّة حالات استخدام AI أساسية في الخدمات المصرفية كعالية المخاطر: تقييم الجدارة الائتمانية وتقييم الائتمان للأشخاص الطبيعيّين، وتقييم المخاطر والتسعير في تأمين الحياة والصحة، وتقييم أو تصنيف الوضع المالي للأفراد. من 2 أغسطس 2026، يجب على ناشري هذه الأنظمة إثبات الامتثال لأنظمة إدارة الجودة، وأُطر إدارة المخاطر، والوثائق التقنية، وتقييمات الامتثال، والتسجيل في قاعدة بيانات الاتحاد الأوروبي، وحوكمة البيانات القوية، والإشراف البشري، وحماية الأمن السيبراني. تصل العقوبات إلى 35 مليون يورو أو 7% من حجم الأعمال العالمي السنوي.
ما الفرق العملي بين HITL و HOTL، ومتى ينبغي تطبيق كلٍّ منهما؟
HITL يعني أن الوكيل لا يستطيع تنفيذ إجراءاتٍ تبعية دون موافقةٍ بشرية صريحة. HOTL يعني أن الوكيل ينفّذ باستقلالية ضمن معلَماتٍ محدّدة، مع بشرٍ يراقبون القياس عن بُعد ويحتفظون بسلطة الإيقاف في أيّ نقطة. EU AI Act Article 14 تتطلب أن يكون الإشراف ذا معنى لكنها لا تُحدّد أيّ نموذج. قاعدة القرار هي تطبيق HITL حيث يكون الإجراء تبعياً ومنخفض الحجم وغير قابلٍ للتراجع (رفض الائتمان، إغلاق الحساب، تفويض تحويل عالي القيمة، تقديم ملفّ تنظيمي)؛ و HOTL حيث يكون الإجراء عالي الحجم قابلاً للتراجع ومحدوداً بالمعلَمات (تنبيهات مراقبة المعاملات، تصنيف المستندات، فرز خدمة عملاء روتيني).
معظم وكلائنا سيأتون من بائعين. كيف نُلبّي DORA و EU AI Act لأنظمةٍ لم نبنِها؟
يجلس الالتزام التنظيمي مع الناشر، لا البائع. الإجابة العملية ثلاثية. أولاً، اطلب AIBOM موثّقاً من البائع قبل التوقيع. ثانياً، أجرِ اختباراً سلوكياً للوكيل تحت ظروفٍ مماثلة للإنتاج. ثالثاً، أعد التفاوض على عقود البائعين لتشمل حقوق وثائق Article 13. تُغطّي DORA Articles 28-30 إدارة مخاطر الأطراف الثالثة لـ ICT.
كم ينبغي على البنوك أن تقلق فعلاً بشأن الخصوم الوكيليّين؟
الإجابة الصادقة هي أن التهديد حقيقي ومتميّز تشغيلياً عن التهديدات السيبرانية السابقة. كشف Anthropic في نوفمبر 2025 عن GTG-1002 هو المثال الأساسي: AI الوكيلي يتعامل مع 80-90% من العمليات التكتيكية في حملة تجسّسٍ مدعومة من الدولة ضدّ نحو ثلاثين هدفاً، يعمل بآلاف الطلبات في الثانية. حادثة Step Finance في يناير 2026 — خسارة 27-30 مليون دولار مدفوعة بوكلاء تداول AI بسلطة مُفرَطة — هي المثال الأساسي لكيف يمكن لنشر AI داخلي أن يصبح سطح هجوم.
هل AI الوكيلي مجرّد "ChatGPT زائد MCP servers"؟
لا، وهذا أحد أكثر المفاهيم الخاطئة تبعاتٍ في السوق الحالي. واجهة دردشةٍ مُعزَّزة بـ MCP servers نمطٌ مفيد لاسترداد البيانات والتصرّف عليها داخل جلسةٍ محدّدة. الهندسة الوكيلية قدرةٌ هيكلية للمؤسسة — AIBOM، مستوى تحكّم الوكيل، خطّ تطوير مُوجَّه بالمواصفات، ركيزة التدقيق، الأساس التشفيري الآمن للكم، أنماط التنسيق عبر رحلات العملاء من طرفٍ إلى آخر.
ما الشيء الأكثر أهميةً الذي ينبغي أن يفعله البنك في الاثني عشر أسبوعاً المقبلة؟
ثلاثة أشياء، مرتّبة. أولاً، أنتج AI Bill of Materials. ثانياً، ابنِ مستوى تحكّم الوكيل لأيّ نظام AI يصنع حالياً أو يُؤثّر مادياً على قرارات تمسّ العميل. ثالثاً، انقل ثقافة الهندسة الداخلية من vibe coding إلى التطوير المُوجَّه بالمواصفات على العمل الأكثر أهمية.
المراجع #
- Sebastien Rousseau, (2026). Securing the Ledger: A Board-Level Guide to Post-Quantum Migration.
- Sebastien Rousseau, (2026). The novembre 2026 pacs.008 Structured-Address Deadline.
- Sebastien Rousseau, (2026). Quantum Thresholds Are Moving Again.
- Mansurova, M. (2026). From Vibe Coding to Spec-Driven Development ⧉. Towards Data Science.
- Deloitte, (2026). Managing the new wave of risks from AI agents in banking ⧉. Deloitte.
- Anthropic, (2025). Detecting and countering misuse of AI: août 2025 ⧉. Anthropic.
- Anthropic, (2025). Disrupting the first reported AI-orchestrated cyber espionage campaign ⧉. Anthropic.
- Flashpoint, (2026). 2026 Global Threat Intelligence Report ⧉. HSToday.
- European Commission, (2024). Regulation (EU) 2024/1689 on Artificial Intelligence (EU AI Act).
- AegisAI Compliance, (2026). AI Governance for Banks: SR 11-7 & EU AI Act ⧉. AegisAI.
Huling sinuri .