تشتري معظم الفرق المالية اليوم من الذكاء الاصطناعي أكثر مما تبنيه. تستدعي واجهة برمجة نموذج مستضاف، فتحصل على إجابة مفيدة، ثم تمضي في طريقك. لكن هذه السهولة تُخفي حقيقة حوكمية يستمر الناس في نسيانها: حين تستدعي نموذج غيرك عبر الشبكة، تكون قد تحمّلت خدمة لتقنية المعلومات والاتصالات، بكل ما يرافقها من مخاطر الذكاء الاصطناعي من طرف ثالث. فالنموذج ليس في مستودعك البرمجي، والأوزان ليست ملكك، ومع ذلك يجلس مخرجه في مسار عمل يمسّ أموال العملاء.
هذا ليس سبباً لتجنّب نماذج المورّدين. فبناء كل شيء بنفسك نادراً ما يكون الجواب الصحيح، وأفضل النماذج المستضافة جيدة للغاية. بل هو سبب لإحاطة الذكاء الاصطناعي المُشترى بالقدر نفسه من الانضباط الذي تحيط به أي مورّد حسّاس بالفعل.
واجهة برمجة النموذج طرفٌ ثالث في سجلّك
ابدأ من الحقيقة الإدارية المملّة. فواجهة برمجة نموذج مستضاف هي خدمة لتقنية المعلومات والاتصالات يقدّمها طرف ثالث، ومكانها سجلّ الأطراف الثالثة لديك إلى جانب منصّة الحفظ وتغذية بيانات السوق. يتوقّع DORA من المؤسسات المالية أن تحتفظ بسجلّ للترتيبات التعاقدية لخدمات تقنية المعلومات والاتصالات، وأن تقيّم المخاطر المرافقة لكلٍّ منها. ولا تحظى نقطة نهاية نموذجٍ يلجأ إليها فريقك بشكل عابر بأي إعفاء لمجرد سهولة استدعائها.
لذا فإن أول مهمّة غير برّاقة: العثور على كل موضع يُستخدم فيه نموذج خارجي. وعملياً يعني ذلك البحث عن مفاتيح واجهات البرمجة وعناوين النطاقات الأساسية عبر قواعد الشيفرة، وسؤال الفرق عمّا ربطوه فعلاً، وتدوين ما يفعله كل استدعاء حقيقةً. بعض هذه الاستدعاءات سيغذّي قراراً يواجه العميل، وبعضها سيقوم باستخراج بيانات الإفصاحات في مكتب خلفي. على السجلّ أن يعرف أيّها أيّ، لأن المخاطرة ليست واحدة.
مخاطر التركّز والمورّد الواحد
بمجرد أن تمتلك القائمة، يظهر نمطٌ عادةً. ثلاثة فرق، وخمسة مسارات عمل، ومورّدٌ واحد خلفها جميعاً. هذه هي مخاطر التركّز، وهي الجانب الذي يشدّد عليه DORA أكثر من سواه. فإذا اعتمدت أداة دمج الكيانات، ومُلخّص المستندات، وروبوت محادثة العملاء جميعاً على المورّد نفسه، فإن انقطاعاً واحداً أو تغييراً في التسعير أو تبديلاً في شروط الخدمة يضرب كلاً منها دفعة واحدة.
التركّز ليس سيئاً تلقائياً. فالتوحّد على مورّدٍ واحد قادر قد يكون القرار الصحيح. المقصود أن يُتّخذ القرار عن قصد ويُدوَّن، لا أن يُبلَغ إليه مصادفةً لأن الجميع لجأ إلى الاسم نفسه. أنت تريد أن تعرف حجم انكشافك قبل أن يمرّ المورّد بأسبوع سيّئ، لا أثناءه.
هنا يكفّ الخروج والاستمرارية عن كونهما أوراقاً. اطرح الأسئلة الصريحة:
- لو سحب هذا المورّد النموذج المحدّد الذي نعتمد عليه، كم سيستغرق الأمر حتى نعمل على بديل؟
- هل بإمكان مطالباتنا ومجموعة تقييمنا الانتقال إلى مورّد آخر، أم أنها مفصّلة على نزوات نموذج بعينه؟
- هل ثمّة مسار احتياطي يتراجع بسلاسة، ولو إلى نموذج أبطأ أو أرخص، بدلاً من إفشال مسار العمل بالكامل؟
مشكلة التحديث الصامت
وهنا الجزء الذي يوقع الفرق الحذرة. فمع نموذجك الخاص أنت تتحكّم بالأوزان، فالتغيير حدثٌ جدولته بنفسك. أما مع نموذج المورّد فقد تتبدّل الأوزان من تحتك. يبقى وسم الإصدار كما هو، ونقطة النهاية لم تتغيّر، ومع ذلك ينحرف السلوك لأن المورّد أعاد التدريب أو ضبط شيئاً ما. يقول سجلّ التدقيق لديك إن شيئاً لم يتغيّر، بينما تقول مخرجاتك خلاف ذلك.
لا يمكنك تفحّص نموذج مورّد مُعتم، لذا تتحقّق من حوله. وتقوم طريقتان بمعظم العمل. أولاً، قيّد المدخلات: حدّ ما ترسله بحيث يعمل النموذج ضمن نطاق اختبرته، وارفض أو علّم أي شيء خارجه. ثانياً، قابِل المخرجات بمصدر مستقل. فإذا استخرج النموذج رقم إيرادات من إفصاح، فتحقّق منه مقابل التغذية المنظَّمة. وإذا صنّف معاملة، فخذ عيّنة وقارنها بنتيجة قائمة على القواعد. وحين يتباعد الاثنان أكثر من المعتاد، فتلك إشارتك المبكّرة إلى أن النموذج قد تحرّك، حتى وإن لم يخبرك المورّد أبداً.
ثبّت إصدارات النموذج حيثما تسمح واجهة البرمجة بذلك، واحتفظ بمجموعة تقييم دائمة تستطيع إعادة تشغيلها وفق جدول. فهبوط تلك الدرجة هو ما يكشف لك تحديثاً صامتاً قبل أن يكتشفه العميل. لا شيء من هذا يتيح لك النظر داخل النموذج، لكنه يتيح لك ملاحظة متى يكفّ سلوكه عن مطابقة ما صادقت عليه.
هذا ليس استشارة قانونية، والتزاماتك تجاه DORA تتوقّف على تصنيفك وترتيباتك المحدّدة. لكن الموقف الهندسي يثبت بغضّ النظر عن كيفية وقوع التنظيم عليك: عامِل كل واجهة برمجة نموذج كمورّد، واعرف أين يقع تركّزك، وافترض أن النموذج قد يتغيّر دون أن يخبرك.