الجاهزية ليست مرة واحدة: التحقق المستمر
الوكيل الذي وافقت عليه قد لا يكون النظام الذي يعمل بعد ثلاثة أشهر.
أكبر خطأ في برامج الحوكمة هو التعامل مع الموافقة كختم دائم. فالبرمجيات التقليدية تبقى مستقرة وظيفيًا بين إصدار وآخر، أما الوكلاء فلا. والوكيل الذي اجتاز قبل ثلاثة أشهر قد لا يكون النظام نفسه الذي يعمل اليوم، حتى لو لم يغيّر فريقك سطرًا واحدًا من الشِفرة.
قد يحدّث المزود النموذج. وقد تتبدّل مجموعة وثائق الاسترجاع. وقد تتراكم الذاكرة. وقد تتوسّع صلاحية من صلاحيات الوكيل. وقد يظهر نمط هجوم جديد في الميدان. لم يتغير سطر واحد في مستودعك، ومع ذلك صارت الأدلة التي قامت عليها موافقتك تصف نظامًا لم يعد موجودًا.
ما الذي يعيد الوكيل إلى الحلقة؟#
المحفِّزات الجيدة ملموسة ويمكن رصدها، وكلٌّ منها حقل في سجل AI-BOM: نموذج جديد أو إصدار نموذج جديد؛ وتغيّر في موجّه النظام أو موجّه السياسة أو توجيه المسار أو تنسيق سير العمل؛ وأداة جديدة، أو مخطط أداة تغيّر، أو صلاحية مُوسَّعة، أو نقطة نهاية خارجية جديدة؛ ومصدر استرجاع جديد أو سياسة استناد تغيّرت؛ وإعداد ذاكرة تغيّر أو دليل على تلوّثها؛ ونتيجة جديدة عالية الخطورة أو حرِجة في بيئة الإنتاج؛ وتغيّر في الاستخدام المقصود أو مجتمع المستخدمين أو مستوى المخاطر أو البيئة؛ وثغرة منشورة حديثًا تمسّ نموذجًا أو أداة أو خادم MCP في السجل؛ وانتهاء سريان نافذة الحداثة التي تحددها السياسة.
وكون المحفِّزات كلها حقولًا في السجل هو ما يجعل الكشف الآلي عن التغيير ممكنًا: كلما كان سجل AI-BOM منظمًا، صار كشف هذه التغييرات أسهل. وهذا هو السبب العملي الذي يجعل عمل الجَرد في الفصل 5 يستحق كلفته.
والسؤال الذي يُطرح على أي تغيير هو: هل ما زالت الأدلة الحالية تصف الوكيل الذي يعمل الآن؟
الحداثة ليست عمرًا زمنيًا فقط#
العمر وحده قاعدة ضعيفة. فإذا قلت إن الموافقة صالحة 30 يومًا ثم غيّرت أداة حساسة بعد ساعة، فالموافقة قديمة عمليًا رغم أنها حديثة زمنيًا. والتشابه وحده ضعيف كذلك، لأن الانحراف البطيء يتراكم دون حدث مُحفِّز واحد واضح.
لذلك اعتبر الدليل حديثًا عندما يتحقق شرطان معًا: لم يمر عليه وقت أطول من نافذة السياسة، والنظام الحالي مكافئ ماديًا للإعداد الذي اختُبر ونُشر. الشرطان معًا يلتقطان النمطين كليهما.
ثلاثة أنواع من الانحراف#
الانحراف السلوكي يظهر في صورة درجات متغيرة أو نتائج تقييم جديدة مقارنةً بخط أساس ثابت عبر تقييمات قابلة للمقارنة. وانحراف السياق يحدث حين تصير البيئة المعلوماتية أكثر ضوضاءً أو أكثر تقادمًا — تنمو مجموعة وثائق، وتتغير سياسة تلخيص، ويظهر مصدر جديد غير موثوق. وانحراف الضوابط يحدث حين لا يعود النظام المنشور مطابقًا للافتراضات التي اختُبر الضابط في ظلها.
ولكل نوع من هذه الأنواع مالك مختلف وتصحيح مختلف، ولهذا لا تحاول إخفاءها كلها في رقم واحد.
الحوكمة تشير، وأنظمتك تنفذ#
في ProofAgent، تحمل السياسة وتيرة خاصة بكل وكيل. وحين يتجاوزها، تُصدِر المنصة تنبيه تقييم متقادم وتبثّ حدثًا موقَّعًا، فيعيد مُشغِّل العميل تشغيل إطار التقييم ويرفع أدلة حديثة.
وحد الثقة هناك مقصود ويستحق النسخ. فالحوكمة تقرر وتُشير؛ وأنظمة CI وبيئة التشغيل لدى العميل هي التي تُنفِذ، بإفشال مسار التسليم، أو بقلب مفتاح ميزة، أو باستدعاء مهندس، أو بإعادة تشغيل التقييم. وطبقة الحوكمة لا تُشغّل الوكيل ولا تنشره ولا توقفه أبدًا، ما يعني أنها لا تحتاج إلى بيانات اعتماد نشر ولا إلى وصول إلى بيئة الوكيل.
ولا تساوِ في التكلفة بين كل الوكلاء. فالتحقق يجب أن يبقى متناسبًا: ليس اختبارًا مستمرًا لكل شيء، بل وعيًا مستمرًا بما إذا كانت الأدلة لا تزال تدعم سلطة التنفيذ الممنوحة. فالوكيل عالي المخاطر يستحق وتيرة أقصر وتقييمًا أعمق وإعادة تقييم سريعة؛ أما مساعد منخفض المخاطر بصلاحية قراءة فقط فيحتاج إلى أقل من ذلك بكثير. والإنفاق على الاثنين بالتساوي هو ما يجعل هذه البرامج تنهار تحت كلفتها، والحوكمة المتناسبة هي ما يجعلها قابلة للتوسع.
وحين يحدث تشغيل جديد بالفعل، قارنه بآخر خط أساس مُوافَق عليه، وسجّل قرارًا جديدًا. ويبقى القرار السابق في السجل، لأن السؤال الذي يطرحه المُدقِّق ليس هل الوكيل مُوافَق عليه، بل ما الذي جرت الموافقة عليه، ومتى، وعلى أي أدلة، ومن وافق عليه.
كل ما سبق إلى هذه النقطة كان المنهج. والجزء التالي يطبّقه من طرف إلى طرف، على وكيل واحد عادي.
الجاهزية تنتمي إلى إصدار من الوكيل، لا إلى الوكيل إلى الأبد.
احسم الآن ما الذي سيُنهي سريان موافقتك الحالية، والأمور هادئة. فسياسة التحقق المكتوبة بعد تحديث نموذج تُكتب دائمًا تحت الضغط.