الحوكمة والمخاطر في وكلاء الذكاء الاصطناعي: ما يجب التحكم فيه قبل منح الاستقلالية

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

إن الحكم ليس طبقة بيروقراطية تضاف لاحقا. إنه جزء من الهندسة المعمارية. تم تصميم إطار عمل AI RMF الخاص بـ NIST على وجه التحديد لمساعدة المؤسسات على إدارة مخاطر نظام الذكاء الاصطناعي أثناء التصميم والتطوير والاستخدام والتقييم، كما أن ملفه التعريفي للذكاء الاصطناعي التوليدي يوسع هذا النهج ليشمل مخاطر نظام توليدية محددة.

1. نموذج المخاطر من خلال الفعل، وليس من خلال "مستوى الذكاء"

لا تعتمد مخاطر الوكيل فقط على النموذج المستخدم. يعتمد ذلك على الإجراءات المتاحة وعواقب الخطأ. يمكن أن يكون النموذج المتوسط ​​الذي يسمح بحذف البيانات أكثر خطورة من النموذج الممتاز الذي يقتصر على تلخيص المستندات.

لكل قدرة، قم بتقييم أربعة أبعاد على الأقل: impacto, reversibilidad, حساسية البيانات y frecuencia. يختلف إرسال مسودة داخلية عن إرسال عرض إلى العميل. تختلف استشارة الملف عن تعديله. إعداد الدفعة يختلف عن تنفيذها.

2. تحديد الاستقلالية بالخطوات

لا يوجد قرار واحد "مستقل أو غير مستقل". يمكنك تصميم المستويات.

1. المساعدة: الوكيل يقترح، والشخص ينفذ.
2. التنفيذ بالموافقة: يقوم الوكيل بإعداد الإجراء وينتظر التأكيد البشري.
3. تنفيذ محدود: يمكن أن يتصرف تلقائيًا ضمن قواعد وعتبات محددة.
4. الحكم الذاتي الخاضع للإشراف: يدير التدفق بالكامل، ولكنه يسجل الإجراءات ويطبق الحدود ويصعد الاستثناءات.

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

3. تطبيق أقل الامتيازات

يجب أن يكون لدى الوكيل الأذونات اللازمة لمهمته فقط. لا تستخدم بيانات اعتماد المسؤول العالمي لأنها "أسهل". قم بإنشاء حسابات أو نطاقات خدمة منفصلة عندما يسمح النظام الأساسي بذلك.

إذا كان الوكيل يحتاج فقط إلى قراءة التقويم، فلن يتمكن من حذف الأحداث. إذا كان يجب عليك إنشاء مسودات، فلن تحتاج إلى إذن للإرسال. إذا قمت بالاستعلام عن قاعدة بيانات، فإنك تفصل القراءة عن الكتابة. إذا كنت بحاجة إلى الكتابة، قم بتقييد الجداول أو العمليات أو نقاط النهاية.

أسرار منفصلة حسب الوظيفة

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

أفضل طريقة لتخفيف الفعل الخطير هو عدم مطالبة النموذج "بتوخي الحذر". الشيء هو أن الهندسة المعمارية لا تسمح بتنفيذها خارج القواعد.

4. تصميم إشراف بشري حقيقي

"الإنسان في الحلقة" لا يعني إظهار شاشة بها زر موافقة. يحتاج الشخص إلى سياق كافٍ لاكتشاف الخطأ.

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

تجنب أتمتة الموافقة

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

5. تقييم النظام بمهام حقيقية

العرض التوضيحي لا يتحقق من صحة الوكيل. قم ببناء مجموعة من الحالات التمثيلية والحالات الصعبة: البيانات غير الكاملة، والتناقضات، والمدخلات المتعارضة، والطلبات خارج النطاق، وأخطاء الأدوات.

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

الاختبار قبل وبعد كل تغيير

يمكن أن يؤدي تغيير النموذج أو المطالبة أو الأداة أو الإصدار إلى تغيير السلوك. الحفاظ على مجموعة الانحدار. إذا أدى التحديث إلى تحسين المتوسط ​​ولكنه أدى إلى كسر حالة حرجة، فستحتاج إلى اكتشافه قبل الإنتاج.

6. يحمي الوكيل من التعليمات غير الموثوقة

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

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

7. تصميم الأعطال الآمنة

فشل الأنظمة: لا تستجيب واجهات برمجة التطبيقات، وتنتهي صلاحية بيانات الاعتماد، وتصل البيانات غير مكتملة، وترجع النماذج تنسيقات غير صالحة. السؤال المهم هو ماذا سيحدث بعد ذلك.

بالنسبة للإجراءات عالية التأثير، يجب أن يؤدي الفشل إلى إغلاق التدفق بأمان بدلاً من الارتجال. إذا كانت هناك معلومة إلزامية مفقودة، فلا تخترعها. إذا قامت واجهة برمجة التطبيقات (API) بإرجاع حالة غامضة بعد تنفيذ إجراء ما، فقم بالتسوية قبل إعادة المحاولة. إذا كان هناك خطر تكرار المنشور أو الدفع أو الأمر، فسيتم تطبيق العجز.

تصنيف الأخطاء

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

8. قابلية الملاحظة: معرفة ما فعلته ولماذا

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

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

9. الاعتماد على الموردين والاستمرارية

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

فهو يحافظ على التنسيقات الداخلية المستقرة، ويلخص عمليات التكامل المهمة، ويمنع منطق الأعمال من الاعتماد بشكل غير ضروري على ميزة خاصة يصعب استبدالها.

10. البيانات والخصوصية

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

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

11. استخدم الإطارات المرجعية دون تحويلها إلى قوائم مرجعية فارغة

El NIST AI إطار إدارة المخاطر يقترح نهجًا منظمًا لإدارة المخاطر والثقة في أنظمة الذكاء الاصطناعي. ويضيف ملف تعريف الذكاء الاصطناعي التوليدي الخاص به اعتبارات محددة للأنظمة التوليدية. تعتبر هذه الأطر مفيدة كمرجع، ولكن يجب ترجمتها إلى ضوابط ملموسة للعملية الفعلية.

السؤال ليس "هل نلتقي بإطار؟" فهو "ما هو الخطر الموجود في هذه الحالة، ومن يملكه، وما هي السيطرة التي تقلل منه، وكيف نعرف أن السيطرة تعمل؟"

12. قائمة مرجعية قبل منح الاستقلالية للوكيل

1. يسرد جميع الأدوات والإجراءات المتاحة.
2. تصنيف كل إجراء حسب التأثير والعكس.
3. تقليل الأذونات إلى الحد الأدنى الضروري.
4. يحدد الإجراءات التي تتطلب الموافقة.
5. تصميم معالجة المدخلات غير الموثوق بها.
6. قم بإنشاء مجموعة تقييم تحتوي على حالات حقيقية وأخرى معادية.
7. تحديد حدود الإنفاق والحجم والتكرار.
8. ينفذ العجز عن الإجراءات المتكررة.
9. تصنيف الأخطاء وإعادة محاولة السياسات.
10. سجلات التصميم دون أسرار.
11. يحدد التصعيد البشري والمسؤولية التشغيلية.
12. اختبار الاسترداد في حالة فشل المورد.
13. يوثق كيفية تعطيل الوكيل بسرعة.

الاستنتاج

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

كلما زاد التأثير المحتمل لإجراء ما، كلما قلت الثقة في النموذج "الذي يتصرف بشكل جيد" وأكثر على الضوابط الحتمية حول النموذج.

En كيف نعمل نوضح كيف يقوم ProjectCore بتصميم العمليات والضوابط والهندسة المعمارية قبل زيادة استقلالية النظام.