الخزينة الوكيلة تحتاج إلى Kill Switch: صمّم autopilot كما لو كان مصنعاً

لا مشكلة لديّ مع الاستقلالية. قضيت سنوات إلى جوار أنظمة تعمل دون أن تطلب الإذن كل دقيقة. الـ drives تضبط المحركات. المحوّلات تثبّت العمليات. أنظمة التحكم في المباني تحافظ على راحة الشاغلين. يمكن الوثوق بهذه الأنظمة لأنها مُصمَّمة كمنشآت تشغيلية لها حدود تشغيل واضحة وتوقّفات قسرية.

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

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

مغالطة autopilot في الخزينة: “إنه software، يمكننا ترقيعه لاحقاً”

في التكنولوجيا الصناعية نفترض الفشل. ليس لأن الفريق ضعيف، بل لأن الواقع فوضوي. المستشعرات تنحرف. الشبكات تتذبذب. المشغّلون يرتجلون. المورّدون يبدّلون المكوّنات. تبقى العملية آمنة لأننا نقيّد الاستقلالية.

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

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

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

هندس الاستقلالية عبر بوابات، لا عبر تدرّجات

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

هذا نمط أستخدمه، مستعار من أساليب commissioning الصناعية ومكيّف لوكلاء الذكاء الاصطناعي:

1. وضع Observe: يقرأ الوكيل البيانات ويقدّم توصيات. بلا آثار جانبية. كل شيء يُسجّل.
2. وضع Propose: يجهّز الوكيل مخرجات قابلة للتنفيذ (دفعات مدفوعات، اقتراحات تحوّط، سحب/تحويلات سيولة) لكنه لا يستطيع إرسالها. يعتمدها إنسان.
3. وضع Constrained execute: ينفّذ الوكيل ضمن حدود ضيقة (المبلغ، الطرف المقابل، العملة، النافذة الزمنية، والغرض). الاستثناءات تُعاد إلى قائمة انتظار.
4. autopilot تحت الإشراف: ينفّذ الوكيل ضمن نطاق أوسع، لكن تحت مراقبة لحظية وبشروط trip تلقائية.

الخلاصة أن لكل بوابة معايير دخول صريحة وخطة تراجع صريحة. إذا لم تستطع وصف البوابة في صفحة واحدة، فأنت لا تملك بوابة؛ لديك أمل.

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

قابلية تدقيق قابلة لإعادة التشغيل: ما يعادل مسجل الطيران في الخزينة

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

الخزينة تحتاج الانضباط نفسه عندما يكون هناك وكيل. “النموذج اقترح ذلك” ليست مسار تدقيق. و“الوكيل نفّذ ذلك” ليست تفسيراً.

قابلية التدقيق القابلة لإعادة التشغيل تعني أنك تستطيع إعادة بناء—بصورة حتمية—ما رآه الوكيل وما فعله. ليس عبر screenshots، بل عبر سجلات منظمة. تريد أن تجيب عن أسئلة مثل:

• ما مصادر البيانات المستخدمة لهذا القرار، وما طوابعها الزمنية؟
• ما القواعد والسياسات السارية (الحدود، الموافقات، فصل المهام)؟
• ما استدعاءات الأدوات التي تمت (ERP، TMS، bank APIs)، وما الردود؟
• ما إشارات عدم اليقين أو الثقة المتاحة، وما العتبات المطبقة؟
• ما البدائل التي نوقشت ثم رُفضت، ولماذا؟

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

عملياً، أريد مُخرَجين لكل فعل مستقل:

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

إذا لم تستطع إعادة تشغيله، فلن تستطيع تحسينه. وإذا لم تستطع شرحه، فلا ينبغي أتمتته.

Kill Switch: ليست زرّاً، بل إجراء مُختبَر

معظم الفرق تتعامل مع Kill Switch كعنصر واجهة: مفتاح تبديل، زر أحمر كبير. في المنشآت، آلية الإيقاف هي تصميم متكامل: أين تُوصل، ماذا تقطع، إلى أي حالة آمنة ينتقل النظام، وكيف تستعيد التشغيل.

Kill Switch في الخزينة يجب أن يغطي أكثر من “إيقاف الأفعال المستقبلية”. عليه أن يتعامل مع الأفعال الجارية، والإرسالات الجزئية، والتسويات. وإلا ستوقف الوكيل وتبقى ورشة الانفجار قائمة.

هذا هو الحد الأدنى من التصميم الذي أوصي به لمجالس الإدارة وفرق التشغيل:

• ثلاثة مسارات إيقاف مستقلة: إيقاف على مستوى التطبيق، وسحب الاعتمادات (API keys, tokens)، وضوابط على جانب البنك (limits, whitelists, call-backs). الاستقلالية مهمة؛ تعطل طبقة واحدة يجب ألا يمنع الإيقاف.
• شروط trip تلقائية: أحجام غير معتادة، مستفيدون جدد، نشاط خارج النافذة الزمنية، تكرار المحاولات، عدم تطابق التسويات، وانتهاكات حداثة البيانات. لا تراهن على أن البشر سيلتقطون الانحراف.
• تعريف واضح للحالة الآمنة: ما الذي يحدث للدفعات المعلّقة، والموافقات في الطابور، ومحاولات الإعادة عند التوقف. الحالة الآمنة يجب أن تكون صريحة.
• runbook للتعافي: من يراجع ماذا، وبأي ترتيب، قبل استئناف الاستقلالية. تضمّن خطوات التواصل وخطوات التسوية.
• تمارين ربع سنوية: تحاكي سيناريو سيئاً وتفعّل الإيقاف. إذا لم تختبره، سيفشل عندما تحتاجه.

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

أسرع طريقة لجعل هذا واقعاً هي التعامل مع الوكيل كأصل ضمن خط إنتاج. امنحه مالكاً. خطة صيانة. إنذارات ومسارات تصعيد. وبروتوكول إيقاف. إن لم تفعل، سيتصرف كـ shadow IT ولكن مع اتصال مصرفي.

عدسة قرار على مستوى مجلس الإدارة يمكنك تطبيقها هذا الربع

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

1. النطاق: ما القرارات التي يُسمح للوكيل باتخاذها، وما القرارات التي تبقى دائماً بشرية؟
2. المغلف التشغيلي: ما الحدود الصلبة (المبلغ، الطرف المقابل، العملة، التوقيت، الغرض)؟
3. قابلية الرصد: هل يمكننا إعادة تشغيل أي فعل مستقل طرفاً لطرف خلال 24 ساعة؟
4. فصل المهام: من يغيّر السياسات، من ينشر، من يعتمد الاستثناءات، من يوقف النظام؟
5. تصميم الإيقاف: هل لدينا مسارات إيقاف مستقلة، وسلوك حالة آمنة، وrunbook للتعافي؟
6. التمارين: متى اختبار Kill Switch التالي، ومن يوقّع على النتائج؟

إذا لم تستطع الإجابة عن هذه الستة بوضوح، فلا تُطلق “autopilot”. ابقَ في وضع Propose وشدّد النظام.

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

رأيي: الاستقلالية تُكتسب ولا تُفعَّل

يمكن للذكاء الاصطناعي الوكيل أن يخلق قيمة في الخزينة فعلاً، لكن فقط إذا تعاملت معه كعملية صناعية لا كميزة. الاستقلالية المُحكَمة بالبوابات تتفوق على الاستقلالية الواسعة. إعادة التشغيل تتفوق على الانطباعات. وKill Switch مُختبَر يتفوق على وثيقة سياسات.

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

autopilot ليست “قدرة”. إنها نظام تحكم مع إجراء إيقاف.

ابنه كمنشأة تشغيلية، ويمكنك أن تدعه يعمل. وابنه كـ chatbot، وستُجبَر في النهاية على إيقافه.