عندما تصبح السياسة قابلة للتنفيذ

كيف تتلاقى الأدلة والسياسة والمساءلة في قرار يملكه شخص.

تتعثر كثير من سياسات الذكاء الاصطناعي عند الانتقال من النص إلى مسار التسليم. تقول الوثيقة: «الوكلاء عاليو المخاطر يحتاجون إشرافًا بشريًا». الجملة صحيحة، لكن نظام CI لا يعرف ماذا يفعل بها.

أما إذا كُتب المتطلَّب نفسه في صورة تستطيع بوابةٌ تقييمها، فيصير شيئًا آخر تمامًا.

IF risk_tier = high
AND required_signoff != approved
THEN BLOCK
الشكل 13-1من نص السياسة إلى قاعدة يمكن لبوابة النشر تنفيذها.

والهدف من «السياسة كقواعد برمجية قابلة للتنفيذ» ليس تحويل الأخلاق إلى شِفرة، ولا تحويل كل حكم أخلاقي إلى عبارة شرطية. الهدف هو جعل الأجزاء القابلة للحسم صريحة ومختبرة وخاضعة لإدارة الإصدارات، وترك الحكم البشري تمامًا في الموضع الذي تريده السياسة فعلًا — مع سجل يثبت أنه حدث.

ما الذي ينبغي أن تعرفه السياسة؟#

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

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

مثال لملف حوكمة#

يُعلن ملف الحوكمة في ProofAgent سياق مخاطر الوكيل، ويترك لمُصنِّف حتمي أن يستنبط الباقي — مستوى المخاطر، والالتزامات، والأطر المشمولة بالنطاق، وضوابط الحماية.

agent_governance_profile:
  name: "Vendor Payment Exception — production"
  fail_on: block
  intake:
    use_case: creditworthiness
    autonomy_level: L3
    data_sensitivity: pii
    region: eu
    human_oversight: false
    takes_consequential_actions: true

ست إجابات تُنتج مستوى مخاطر عاليًا مع أسبابه مرفقة، وحدًا أدنى للدرجة، وخطورة موجِبة للحجب، ومتطلَّب اعتماد نهائي، ووتيرة إعادة تقييم، والأطر المنطبقة.

الشكل 13-2مثال لسياسات محفوظة مع العتبات وقواعد الحجب، والأطر التي تتحقق منها كل سياسة. ProofAgent Governance Portal؛ بيانات متخيَّلة.

والملف على جانب المنصة أدقّ تفصيلًا، وشكله يستحق النسخ أيًّا كانت الأدوات التي تستخدمها.

العنصرمثالالقراءة
min_final_score8.5الحد الأدنى الإجمالي
min_<metric>min_safety: 9.0الحد الأدنى لكل مقياس
hard_metrics["safety"]خرق هنا يُوجب BLOCK؛ وما عداه REVIEW
block_rulesphantom_tool_call, pii_leak, unsafe_actionأنواع نتائج التقييم التي تُوجب BLOCK
block_severitycriticalالخطورة التي تنطبق عندها تلك القواعد
review_severities["high", "critical"]نتائج التقييم التي تُوجب REVIEW
max_metric_regression1.5التراجع المسموح به مقابل خط الأساس

والمعنى العملي لهذا المثال بعبارة بسيطة: نطلب 8.5 إجمالًا، ونطلب 9.0 في السلامة ونتعامل مع أي نقص هناك حجبًا لا مراجعة، ونرسل أي درجة منخفضة في استخدام الأدوات إلى المراجعة، ونحجب مباشرة عند أي استدعاء أداة وهمي حرِج، أو تسريب بيانات شخصية، أو إجراء غير آمن.

ولا ينبغي أن تكون هناك عتبة واحدة موحَّدة للمؤسسة كلها؛ فهي تكاد لا تكون صحيحة أبدًا. أما وراثة خط أساس وإضافة متطلبات مع ارتفاع المخاطر — جولات خصومية أكثر، وعتبات سياق أعلى، وضوابط إلزامية، ونوافذ حداثة (freshness) أقصر، ومُوافِقون إضافيون — فهي ما يحوّل مستوى المخاطر من تسمية إلى قيد.

اختبر السياسة مثلما تختبر الشِفرة#

إذا كانت السياسة منطق تشغيل في بيئة الإنتاج، فهي تستحق حالات اختبار مثل أي شِفرة أخرى: بحزمة أدلة نظيفة، توقّع اجتيازًا؛ وبإخفاق ضابط حرِج، توقّع حجبًا؛ وبموافقة مفقودة، توقّع مراجعة أو حجبًا بحسب ما تقوله السياسة.

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

بوابة النشر تقول ثلاثة أشياء فقط#

لبوابة قرار النشر مهمة واحدة: تحويل الأدلة والسياسة إلى قرار مُسجَّل.

الشكل 13-3البوابة تستهلك الأدلة والسياسة وتنتج PASS أو REVIEW أو BLOCK.

الاجتياز (PASS) يعني أن الأدلة والضوابط المطلوبة استوفت سياسة النشر — لهذا الإصدار، وهذه البيئة، ومجتمع المستخدمين هذا، وصنف البيانات هذا، ومجموعة الأدوات هذه. وهو ليس شهادة بأن الوكيل لن يخطئ أبدًا، والاجتياز في مشروع تجريبي لا يأذن بالنشر في المؤسسة كلها.

والمراجعة (REVIEW) تعني أن السياسة تستلزم حكمًا بشريًا. فيقبل شخصٌ مُسمّى يملك سلطة القرار مخاطرَ متبقية محددة، كتابةً، ولها تاريخ انتهاء. وهي ليست إخفاقًا ولا إجراءً شكليًا.

والحجب (BLOCK) يعني أن شرطًا من شروط النشر أخفق. والقرار الجيد يسمّي السبب بالضبط، ويذكر المعالجة أو الأدلة الناقصة التي ترفع الحجب.

الشكل 13-4تعريف PASS وREVIEW وBLOCK بطريقة تمنع الاستخدام المتراخي.

كيف تقرر البوابة؟#

من الداخل، يقيّم محرك البوابة في ProofAgent خمسة فحوص ويأخذ أعلى أثر، حيث يتقدّم BLOCK على REVIEW، ويتقدّم REVIEW على PASS.

الفحصمتى يقعالنتيجة
قاعدة حجبتقع نتيجة من نوع مُدرَج عند الخطورة الموجِبة للحجب أو أعلى منهاBLOCK
العتبة الإجماليةالدرجة النهائية مفقودة أو دون الحد الأدنىBLOCK
عتبة المقياسدرجة مقياس مفقودة أو دون حدها الأدنىBLOCK إذا كان المقياس قاطعًا، وإلا REVIEW
نتائج بحسب الخطورةأي نتيجة تقييم تقع عند خطورة مُوجِبة للمراجعةREVIEW
التراجعتراجع مقياس مقابل خط الأساس بما يتجاوز الحد المسموحBLOCK إن كان مُهيَّأً لذلك، وإلا REVIEW

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

الشكل 13-5قرار بوابة مع القواعد التي أدت إليه: تطابقت قاعدتا حجب، ولم يُستوفَ الحد الأدنى الإجمالي، وخُرق حدّان أدنيان لمقياسين قاطعين. ProofAgent Governance Portal؛ بيانات متخيَّلة.

القرار سجل، لا ضوء أخضر#

أربع خصائص تجعل قرار النشر مفيدًا بعد أشهر. فهو مُحدَّد النطاق، يسمّي البيئة، ومجتمع المستخدمين، وأصناف البيانات، والأدوات التي يأذن بها. وهو مرتبط بإصدارات محددة: إصدار الوكيل، وسجل AI-BOM، والسياسة. وهو مدعوم بالأدلة، مرتبط بالتشغيل الذي أهّله. وهو مُسجَّل بمُقدِّم الطلب، والمُوافِق، والوظيفة، والطابع الزمني، والتعليقات، والقواعد التي انطبقت.

الشكل 13-6طابور اعتماد نهائي يوضح من يحتاج إلى قرار بشري، ومن هو المكلَّف به، ومستوى المخاطر، ونتيجة البوابة. ProofAgent Governance Portal؛ بيانات متخيَّلة.

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

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

والاختبار الجدير بالتطبيق على هذا الترتيب كله بسيط. هل يستطيع مراجع مستقل أن يُعيد بناء السبب الذي أُذِن بموجبه لهذا الإصدار بعينه من الوكيل بالعمل، يوم نشره؟

يجب أن يكون قرار النشر قابلًا دائمًا للتتبُّع إلى الأدلة والسياسة التي أنتجته.

Apply This Chapter

حوّل نيّتك في النشر إلى قواعد تستطيع بوابةٌ تنفيذها، ثم اختبر مسار الإبطال. الأمران سريعان، وكلاهما يكشف عادة أن العملية الحالية تعتمد على أن يتذكر أحدهم شيئًا.

Get these as working templates