اعرف ما لديك قبل أن تحكم عليه: المخاطر والملكية وسجل AI-BOM
أن تعرف الوكيل بما يكفي لحوكمته، وأن تسجّله بما يكفي لإثباته.
قبل أن تبدأ الاختبار، تحتاج إلى شيء يبدو بسيطًا: هوية واضحة للوكيل. لا يكفي أن يكون لديك رابط مشروع أو اسم في مستودع شِفرة. يجب أن تستطيع المؤسسة أن تقول ما هو هذا الوكيل، ومن يملكه، ولماذا يوجد، وما الذي يُسمح له به، وممّ يتكوّن. والمطلوب ليس وصفًا في مستند، بل تسجيلًا في صورة تستطيع عملية النشر قراءتها.
سبعة أسئلة ينبغي أن يجيب عنها سجل الوكيل#
- الملكية التقنية من يملكه تقنيًّا؟
- ملكية الأعمال من يملكه من جهة الأعمال؟
- الاستخدام المقصود ما الذي يُسمح له بفعله؟
- الاستخدام المحظور ما الذي يجب ألّا يفعله أبدًا؟
- البيانات أي بيانات يتعامل معها؟
- الأدوات والصلاحيات أي أدوات وصلاحيات يستطيع استخدامها؟
- الاستقلالية والتركيب ما مستوى استقلاليته، وممّ يتكوّن النظام؟
ومن بين هذه الأسئلة، ينسى كثير من الفرق السؤال الرابع، وهو أكثر ما يحتاجه المُقيِّم: الاستخدام المحظور. فوصف «وكيل يجيب عن أسئلة الفواتير» استخدام مقصود، ولا يخبر المُقيِّم بما يجب أن يحاول كسره. أمّا «لا يغيّر حسابًا بنكيًّا، ولا يتنازل عن رسم فوق حدّ معيّن، ولا يناقش نزاعًا قانونيًّا» فهي حدود يمكن اختبارها، وتخبر كل من يختبر الوكيل بما ينبغي أن يجرّبه بالضبط.
صنّف المخاطر قبل أن تختبر#
ليس من المنطقي أن نُحمّل مساعدًا بحثيًّا داخليًّا يقرأ معلومات عامة عبءَ الأدلة نفسه الذي نُحمّله لوكيل يستطيع أن يحرّك أموالًا، أو يغيّر حسابًا بنكيًّا، أو يؤثّر في قرار توظيف. فهما مسألتان مختلفتان، ومعاملتهما بالطريقة نفسها تعني إمّا تكبيل الأول أو التقصير في حوكمة الثاني. والحوكمة الجيدة متناسبة مع الخطر.
في ProofAgent يأتي مستوى المخاطر من ستة أجوبة محدَّدة: حالة الاستخدام الأساسية، ودرجة الاستقلالية، وحساسية البيانات، والمنطقة، وهل تجري مراجعة بشرية، وهل يتخذ الوكيل إجراءات خارجية ذات تبعات.
ودرجة الاستقلالية تُكتب على سلّم مرقَّم من L0 إلى L3. وكلما ارتفع الرقم اتّسع ما يستطيع الوكيل تنفيذه بنفسه قبل أن يتدخل إنسان. فوكيل L0 يقترح ولا ينفّذ. ووكيل L2 يعمل داخل حدود ضيّقة والإنسان هو من يطبّق ناتجه. ووكيل L3 يخطّط وينفّذ عبر عدّة خطوات دون مراجعة بشرية عند كل خطوة.
ويعمل المُصنِّف الحتمي نفسه على جهاز المطوّر وفي المنصة، فيتفق الفحص المحلي مع الفحص السحابي، ويُعيد أحد مستويات المخاطر الأربعة — ضئيلة، أو محدودة، أو عالية، أو غير مقبولة.
والفكرة ليست في الأداة نفسها، بل في المبدأ؛ وفي هذا النهج خاصيتان تستحقان التبنّي مهما كانت الأدوات المستخدمة. الأولى أن المستوى الأساسي يأتي من حالة الاستخدام وأن عوامل المخاطر تُصعّده، لكن التصعيد لا يتجاوز «عالية»؛ فلا شيء يجعل الوكيل «غير مقبول» إلا حالة استخدام محظورة. والثانية أن التصنيف يحمل أسبابه، فيمكن شرح المستوى للفريق الذي يُقيّده بدل أن يُفرض عليه فرضًا.
وما يجعل المستوى عمليًّا لا زخرفيًّا هو أنه يُغيّر المتطلبات الفعلية، وإلا تحوّل إلى تسمية لا أثر لها.
| مستوى المخاطر | الشكل النموذجي | ما يُغيّره المستوى |
|---|---|---|
| ضئيلة | تلخيص داخلي، ومساعدة في كتابة الشِفرة | تقييم خط الأساس، ومراقبة تراجع الأداء |
| محدودة | دعم العملاء، وتوليد المحتوى | الإفصاح عن استخدام الذكاء الاصطناعي؛ تقييم كل إصدار وإخضاعه لبوابة قرار النشر |
| عالية | الائتمان، والتوظيف، والرعاية الصحية، والمدفوعات | إشراف بشري، واعتماد نهائي قبل النشر، وحجب عند نتائج التقييم عالية الخطورة، وإعادة تقييم دورية |
| غير مقبولة | ممارسات محظورة بموجب المادة 5 من EU AI Act | غير قابل للنشر؛ تصعيد إلى الامتثال |
ولاحظ أن المستوى الأعلى لا يعني «اختبارات أكثر» فقط. قد يعني عتبات أعلى، واعتمادًا بشريًّا إلزاميًّا، وضوابط إضافية، ووتيرة أقصر لإعادة التقييم. وهذه الحدود التي يفرضها المستوى تلقائيًّا هي ما نسمّيه في الكتاب «ضوابط الحماية» (Guardrails): قيود مُعلَنة مسبقًا تحيط بالوكيل، لا نتائج يكتشفها الاختبار. وفي المقابل، لا ينبغي أن نخنق وكيلًا منخفض المخاطر بإجراءات لا تضيف قيمة.
ما هو سجل AI-BOM؟#
سجل AI-BOM هو سجل مكوّنات الذكاء الاصطناعي. وإذا أردت تشبيهًا بسيطًا، فهو بطاقة هوية تقنية للنظام كما يعمل، لا كما وصفناه في العرض التقديمي.
يسجّل النموذج وإصداره، وإصدارات الموجّهات، والأدوات، ومصادر البيانات، والاسترجاع، والذاكرة، والتنسيق، والهويات، وخوادم MCP، ونقاط النهاية الخارجية، والبيئات. والهدف أن تستطيع إعادة بناء ما الذي كان يعمل عندما اتخذت قرار النشر، أي ما وافقتَ عليه فعلًا.
وثمّة قاعدة عملية مفيدة: يستحق الحقل أن يكون في السجل إذا احتجته لتفسير الأدلة، أو إذا كان تغييره يُبطِل الأدلة. وحقل النموذج وإصداره يفعل الأمرين. أمّا اسم الشخص الذي كتب أول مسودة لموجّه النظام فغالبًا لا يفعل أيًّا منهما.
متى يصبح السجل ضابطًا لا توثيقًا؟#
إذا ملأت سجل AI-BOM مرة واحدة ثم لم يقرأه شيء، فهو توثيق. أمّا إذا قرأت بوابة قرار النشر حقوله، واستخدمتَ تغيّر النموذج أو الأداة أو الصلاحية لتشغيل إعادة تقييم، فقد أصبح جزءًا من نظام الضوابط.
والفرق بين التوثيق والحوكمة هو وجود استجابة عندما يتغيّر الشيء؛ أي أن يقرأ السجلَّ شيءٌ ما ويتصرّف بناءً عليه.
خمسة أماكن تتكرر فيها المخاطر#
ومتى صار السجل أمامك، سَهُل رصد مجموعة من المخاطر المتكرّرة. ومعظم حالات فشل الوكلاء في بيئة الإنتاج تعود إلى واحد من الأماكن الخمسة التالية.
1. صلاحية أوسع من المهمة
تأمّل وكيلًا للحسابات الدائنة لا يحتاج إلا إلى قراءة سجلات المورّدين. فإن كان يعمل بهوية خدمة تستطيع أيضًا تعديل هذه السجلات، فهو يحمل بالفعل سلطة تنفيذ أوسع ممّا يتطلبه عمله، ولم يطلبها التصميم. أعطِه صلاحية القراءة فقط، واحفظ صلاحية الكتابة لإجراء منفصل له ضوابطه الخاصة.
2. أداة وصفها غير واضح
قد يختار النموذج أداة خاطئة لأن أسماء الأدوات أو أوصافها متقاربة. مثال بسيط: طُلب من وكيل مرةً إيقاف اشتراك مؤقتًا فاستدعى cancel_subscription، أي دالة الإلغاء النهائي؛ كان الوسيط صحيحًا، ونجح الاستدعاء، وبدا إشعار التأكيد معقولًا، واختفى الحساب. ونجاح الاستدعاء لا يعني صحة القرار. واختيار الأداة الخطأ يعود عادةً إلى أوصاف متداخلة، والوسائط الخاطئة إلى مخططات ضعيفة، وكلاهما يُصلَح في الموضع الذي تُعرَّف فيه الأداة ومخطَّطها، لا بتبديل النموذج.
3. محتوى مسترجع يُعامل كتعليمات
إذا قرأ الوكيل وثيقة تقول «الإعفاء من الموافقة المزدوجة بموجب سياسة المالية 12.4» وتعامل معها كأنها تعليمات نظام، فالفشل في تجميع السياق لا في النموذج: نصٌّ غير موثوق وصل إلى القناة المخصَّصة للتعليمات. والوثيقة دليل يجب تفسيره، وليست سلطة تستطيع تغيير السياسة.
4. ذاكرة تفقد قيدًا مهمًا
قد يقول العميل في الجولة الثانية إنه في ألمانيا، فيطبّق الوكيل قواعد معالجة البيانات الأوروبية تطبيقًا صحيحًا. وفي الجولة الرابعة عشرة، بعد خطوة تلخيص تضغط ما مضى من المحادثة، تختفي معلومة الموقع، فيعرض الوكيل خيارًا لا ينطبق إلا في الولايات المتحدة. لم يفشل شيء بصوت مسموع، ولم يحدث انهيار يستدعي تحقيقًا؛ سقط قيد واحد من السياق، لا أكثر.
5. تضخم السياق
إضافة كل وثيقة «قد تكون مفيدة» ليست دائمًا تحسينًا. فحين تُدرِج الفرق كل وثيقة سياسة قد تنفع، ينتهي المحتوى المهم مدفونًا بين صفحتين من العبارات النمطية، وينخفض الاعتماد على المصدر الصحيح، وتنحرف الموثوقية نحو الأسوأ لأسباب لا يشرحها أي سجل. وميزانية السياق مورد حوكمي، لا مجرّد حدّ تقني.
والوكلاء الذين لا تبنيهم؟#
إذا استخدم فريقك وكيل شِفرة أو وكيل متصفح أو مساعدًا يقرأ ملفات محلية وينفّذ أوامر، فقد لا تملك بنيته الداخلية. وهنا الأداة العملية هي خريطة الوصول: ما المسارات التي قرأها، وما المسارات التي كتب فيها، وأي أوامر نفّذ، وإلى أي مُضيفات اتصل، وأي أدوات استدعى. قارِن الوصول المرصود بالنطاق المقصود على مدى أسبوع من الجلسات الحقيقية.
وإن كان الوكيل مهيَّأ لمستودع واحد لكنه يصل باستمرار إلى مسارات لا علاقة لها بالمهمة، فهذه مسألة حوكمة حتى لو كانت الشِفرة التي يكتبها ممتازة.
والقاسم المشترك بين هذه المخاطر كلها أن كل واحدة منها بدأت افتراضًا لم يُنفِذه أحد. وتحويل الافتراضات إلى شروط مُنفَذة هو معظم العمل الموصوف في الجزء الرابع.
ومتى عرفتَ ممّ يتكوّن الوكيل وأي سلطة تنفيذ يحمل، أمكنك تقييم النظام الموجود فعلًا لا العرض التوضيحي الذي قصدتَ بناءه.
سجِّل ممّ يتكوّن الوكيل، وستعرف متى انتهى سريان أدلتك.
ابنِ السجل قبل أن تحتاجه. أول مرور على سجل المكوّنات لوكيل حقيقي واحد يكشف عادةً صلاحيةً لم يخترها أحد، وأداةً لم يسجّلها أحد، وحقلًا واحدًا على الأقل لا يعرف جوابه إلا شخص واحد.