أقل قدر من الصلاحيات لوكلاء الذكاء الاصطناعي: فكرة عمرها خمسون عامًا يتجاهلها مشروعكم التجريبي
مخاطر الوكيل الذكي ليست سؤالًا عن القدرات تنتظرون إجابته من مزوّد التقنية. إنها سؤال عن الصلاحية أجبتم عليه بأنفسكم بالفعل، يوم سلّمتموه بيانات الاعتماد.
معظم المشاريع التجريبية لوكلاء الذكاء الاصطناعي عالقة عند سؤال خاطئ: هل النموذج جيد بما يكفي بعد؟ مبدأ أقل قدر من الصلاحيات لوكلاء الذكاء الاصطناعي يحسم من المخاطر الحقيقية في بعد ظهر واحد أكثر مما يحسمه عام كامل من انتظار تحسّن جودة النموذج. ما يستطيع الوكيل تدميره تحدده ثلاثة عناصر تقع أصلًا تحت سيطرتكم: المفاتيح التي يحملها، ومسارات الكتابة التي تفتحها تلك المفاتيح، وهل اختبر أحد فعليًا عملية الاستعادة من النسخ الاحتياطي.
تتبّعوا الآلية عبر حادثة موثّقة. رواية شركة Replit الرسمية للحادثة تؤكد أن وكيلها الذكي حذف بيانات من قاعدة بيانات تطبيق جيسون ليمكين، الشريك المؤسس لـ SaaStr، وتذكر أن عملية الاستعادة أعادت البيانات بالكامل دون أي فقدان نهائي. لاحظوا أي طبقة أنقذت الموقف هنا. الوكيل نفّذ الحذف. النسخة الاحتياطية هي ما حوّل عملية حذف كارثية إلى مجرد إزعاج عابر، ولو غابت تلك النسخة لكان السلوك ذاته أنتج عنوانًا مختلفًا تمامًا في الأخبار.
النسخ الاحتياطية هي بالضبط الطبقة التي يفترضها الجميع ولا يختبرها أحد. حين حذف أحد مهندسي GitLab المجلد الخاطئ من قاعدة البيانات في يناير 2017، سجّل التقرير الرسمي الذي نشرته الشركة أنه من بين خمس آليات نسخ احتياطي وتكرار كانت مفعّلة نظريًا، لم تكن أي منها تعمل بشكل موثوق، وأن عملية الاستعادة اعتمدت على نسخة بيئة اختبار كانت موجودة صدفة من قبل ست ساعات، فُقدت بيانات تلك الساعات الست نهائيًا. لا وكيل ذكاء اصطناعي هنا، ولا تقنية جديدة، مجرد أمر إتلاف واحد التقى بمسار استعادة غير مختبر. هذا بالضبط الخطر الذي يتحمّله مشروعكم التجريبي بصمت، مع مشغّل أسرع وأقل إرهاقًا خلف لوحة المفاتيح.
لماذا لا يكفي أن تُخبروا وكيل الذكاء الاصطناعي ببساطة ألا يحذف شيئًا؟
لأن التعليمة مجرد نصيحة، والوكيل يحمل صلاحياتكم بالفعل لحظة قراءتها. للأمن السيبراني اسم لهذا النمط، يسبق الموجة الحالية بعقود. وصف نورم هاردي مفهوم «الوكيل المرتبك» عام 1988: برنامج يتصرف بصلاحية مفوَّضة من طرف، بناءً على تعليمات يقدّمها طرف آخر، دون وسيلة موثوقة لتحديد أي من صلاحياته ينبغي أن يطولها الطلب الحالي. الوكيل ليس عدائيًا، إنه مرتبك فحسب، وارتباكه يعمل عند مستوى الصلاحية الممنوحة لمن سلّمه المفاتيح أصلًا. لاحظوا ما لا تعتمد عليه هذه المشكلة إطلاقًا: كفاءة الوكيل، أو نواياه، أو مدى الثقة به.
ولهذا لم تكن إجابة هذا التخصص يومًا «حسّنوا الوكيل». وضع سالتزر وشرودر مبدأ أقل قدر من الصلاحيات عام 1975، في مسحهما المرجعي حول حماية أنظمة الحاسوب المنشور في Proceedings of the IEEE، وجوهر الفكرة التصميمية هو جعل النية غير ذات أهمية أصلًا. امنحوا كل مكوّن الحد الأدنى من الصلاحية التي تتطلبها مهمته، وحين يسيء أي مكوّن التصرف لأي سبب، حتى الأسباب التي لم يتوقعها أحد، يبقى مداه محصورًا في نطاق ضيق محدد سلفًا. صلاحيات أنظمة التشغيل وأدوار قواعد البيانات وإدارة الهوية والوصول السحابية (IAM) كلها تقوم على هذه الفكرة. مشاريع الوكلاء الذكية تعيد فتح هذا الملف اليوم، وحجّة إعادة الفتح هي أن هذا الوكيل تحديدًا يبدو ذكيًا بما يكفي لتجاوز القاعدة.
فملف مكتوب فيه «ممنوع لمس بيئة الإنتاج» ليس ضابط أمان، إنه مجرد ملاحظة تُركت لعملية تستطيع أصلًا الوصول إلى بيئة الإنتاج. الضوابط الحقيقية هي ما يجعل تلك الملاحظة غير ذات جدوى: هوية بلا صلاحية حذف، بيانات اعتماد لم تظهر يومًا في ذلك الملف، نسخة احتياطية لا يملك الوكيل مفتاح الدخول إليها. عندها لن تحتاجوا أصلًا إلى السؤال عمّا إذا كان النموذج سيلتزم بالملاحظة في يوم معيّن، وهذه بالضبط قيمة هذا النهج.
وثائق السلامة من مزوّدي التقنية تصف السلوك، ولا تُقيّده
بطاقات النظام وتقارير التقييم تستحق القراءة، وينبغي أن ينشر القطاع مزيدًا منها. لكن اقرؤوها على حقيقتها: إنها تسجّل كيف تصرّف النموذج على منصة اختبار المزوّد، في مهام اختارها المزوّد، في لحظة زمنية واحدة. هذا وصف، والوصف لا يُلزم أحدًا. لا توجد وثيقة سلامة منشورة تدخل إلى حسابكم السحابي وتلغي صلاحية حذف بعينها، ولا يوجد مزوّد يعرض تعويضكم عمّا يفعله نموذجه ببيانات اعتماد اخترتم أنتم منحها. حين تعامل الجهة المشترية الإفصاح على أنه ضمانة، تكون قد قلبت اتجاه الوثيقة: ما تسرده هو تحديدًا ما ستتحملونه أنتم.
درجات اختبارات القياس تقع في الفئة نفسها. إنها تقيس السلوك المعتاد على مهام منتقاة بعناية، بينما تعرّضكم الحقيقي هو السلوك في أسوأ حالاته على بنيتكم التحتية الخاصة، ولا يقيّد أي ترتيب في لوحة الصدارة ذلك. الأسئلة المفيدة عمليًا في مرحلة التعاقد أقل بريقًا: ماذا تفعل الأداة حين يتعذّر تنفيذ تعليمة كما وردت؟ هل تتوقف وتسأل، أم تستبدلها بشيء مقارب؟ ماذا يُسجَّل حين يحدث ذلك؟ وما الإجراءات التي يستطيع الوكيل اتخاذها دون تأكيد ثانٍ؟ إجابات هذه الأسئلة هي ما يغيّر طريقة تحديد الصلاحيات. درجة الاختبار لا تفعل ذلك.
كيف يبدو تطبيق مبدأ أقل قدر من الصلاحيات لوكلاء الذكاء الاصطناعي عمليًا؟
توقفوا عن التعامل مع الوكلاء الذكية بوصفها موظفين يستحقون الثقة، وابدؤوا بالتعامل معها كمقاولين يحملون مفاتيح. السؤال الحاكم: ما الإجراء الذي لا يمكن التراجع عنه ويستطيع هذا الوكيل تنفيذه اليوم لو أخطأ خلال الساعة القادمة؟ ثم أغلقوا تلك المسارات: هوية مستقلة لكل وكيل بدل حساب خدمة مشترك، وصلاحية قراءة فقط كإعداد افتراضي مع صلاحية كتابة محصورة في مسار أو مخطط بيانات محدد بالاسم، وعدم وجود بيانات اعتماد إنتاجية في أي ملف بيئة يستطيع الوكيل قراءته، ونسخ احتياطية تخضع لهوية لا يستطيع الوكيل انتحالها، واختبار استعادة فعلي جرى هذا الربع لا افتراض قائم منذ سنوات. لا شيء من هذا جديد. كل إدارة تقنية معلومات طبّقت هذا المبدأ على المقاولين وأنظمة التكامل المستمر والتكاملات الخارجية منذ عشرين عامًا. يجري تجاوزه اليوم لأن فرق المنتج، لا فرق البنية التحتية، هي من تدير هذه المشاريع التجريبية، على افتراض أن المشروع صغير الحجم. نطاق الضرر لا يهتم بتسميتكم للمشروع «تجريبيًا». لمزيد من التفصيل، طالعوا تصميم أنظمة وكلاء ذكية تفشل بأمان.
ثمة طبقة مسؤولية قانونية نادرًا ما تصل إلى دراسة الجدوى التجارية، وقد اختُبرت فعليًا في المحاكم. في فبراير 2024، أمرت هيئة تسوية المنازعات المدنية في كولومبيا البريطانية شركة Air Canada بتعويض راكب تصرّف بناءً على معلومات مختلقة عن تذكرة حِداد قدّمها روبوت المحادثة الخاص بموقع الشركة. دفعت Air Canada بأن الروبوت كيان قانوني مستقل مسؤول عن أفعاله بنفسه. وصفت الهيئة هذا الدفع بأنه «غير معقول» ورفضته. المبلغ المتنازع عليه كان زهيدًا، لكن المبدأ ليس كذلك: أيًا كان ما يفعله وكيلكم الذكي بالصلاحيات التي منحتموها له، فإنه يفعله بصفتكم أنتم، ولن يهتم أحد خارج مؤسستكم بمعرفة أي طبقة في المنظومة اتخذت القرار. يصنّف OWASP هذا ضمن فئة الصلاحية المفرطة، والإجراءات الوقائية التي يوصي بها بسيطة وغير براقة: حدود دنيا للصلاحيات وإنسان يقف في مسار أي إجراء ذي أثر جوهري. المؤسسات التي تحقق قيمة حقيقية هنا صمّمت نقطة التحقق البشرية عمدًا بدل اكتشاف الحاجة إليها أثناء عطل فعلي.
والآن الاختبار المنصف لحجّتي نفسها: ألا يقتل تقييد الصلاحيات القيمة المرجوة؟ جزئيًا، نعم. الوكيل بلا مسار كتابة يوفر وقتًا أقل من وكيل يملك وصولًا كاملًا لبيئة الإنتاج، وتجاهل ذلك هو تحديدًا كيف تُباع هذه المشاريع ثم تُهجر بصمت لاحقًا. ضعوا أسوأ إجراء لا رجعة فيه مقابل كل وحدة صلاحية ممنوحة على كفّة، ومكاسب الإنتاجية المتوقعة على الكفّة الأخرى، وكونوا صريحين بأن معظم دراسات الجدوى الحالية تنمذج المنفعة فقط، دون أي تقدير للسيناريو المتطرف. حين يتجاوز أسوأ سيناريو قدرتكم الفعلية المثبتة على الاستعادة، فأنتم لا تملكون أداة إنتاجية، بل التزامًا ماليًا غير مسعّر يرتدي عرضًا تجريبيًا لامعًا. ترتيب هذا التسلسل بشكل صحيح قرار معماري قبل أن يكون قرار أدوات.
فلا تنتظروا ملاحظات الإصدار القادمة. مراجعة الصلاحيات واختبار استعادة موقّت زمنيًا لا يتجاوزان أسبوعين من عمل بنيوي غير لافت لا تتوقف عنده أي خارطة طريق، وهما كفيلان بتحديد سقف خسارتكم أيًا كان ما يصدر لاحقًا من تحديثات. جدولوا هذين الأسبوعين قبل أن يحصل المشروع التجريبي على بيانات الاعتماد، لأن القيام بذلك لاحقًا عادة ما يحدث الساعة الثالثة فجرًا مع أحد ممثلي الإدارة القانونية على الخط.
أسئلة شائعة
هل تكفي تعليمات النص لمنع وكيل الذكاء الاصطناعي من حذف البيانات؟
لا، ليس بشكل موثوق. التعليمات تُقلّل الاحتمالية ولا تُلغي القدرة، والوكيل يحمل بيانات الاعتماد بالفعل قبل أن يقرأ التعليمة أصلًا. عاملوا التعليمات المكتوبة كتفضيل، والصلاحيات كضابط حقيقي: إذا كان كل ما يفصل بين الوكيل وقاعدة بيانات الإنتاج جملة واحدة بالعربية أو الإنجليزية، فقاعدة البيانات فعليًا غير محمية.
ما بيانات الاعتماد التي يجب ألا يحملها وكيل ذكاء اصطناعي مخصص للبرمجة؟
أي بيانات اعتماد قادرة على حذف أو الكتابة فوق حالة لا يمكنكم استعادتها ضمن نافذة التعافي لديكم. عمليًا: صلاحيات كتابة على قاعدة بيانات الإنتاج، وأدوار وحدة التحكم السحابية القادرة على حذف التخزين أو الحوسبة، وإدارة النسخ الاحتياطية واللقطات، والوصول إلى مدير الأسرار (secrets manager) بما يتجاوز السر الواحد الذي تتطلبه المهمة تحديدًا، وأي حساب خدمة مشترك تستخدمه أنظمة أخرى. إن احتاج الوكيل بيانات إنتاجية، امنحوه نسخة مستعادة في بيئة منفصلة بدلًا من ذلك.
كيف تُختبر منطقة الضرر المحتمل لوكيل ذكاء اصطناعي قبل نشره؟
احصروا كل الإجراءات المدمّرة التي يمكن الوصول إليها بالهوية التي تخططون لمنحها للوكيل، ثم جرّبوا كل إجراء منها فعليًا من تلك الهوية في بيئة اختبار منفصلة. أي إجراء ينجح هو شيء يستطيع الوكيل فعله في يوم سيء. أنهوا الاختبار بقياس زمن استعادة كامل من النسخة الاحتياطية بعد إلغاء هوية الوكيل، لأن تعرّضكم الحقيقي هو الفجوة بين ما يستطيع الوكيل تدميره وما تستطيعون فعليًا إعادته.
مواضيع ذات صلة
- احتكار الذاكرة الذي يقف وراء تضخم تكاليف الذكاء الاصطناعي
- هاوية دعم الذكاء الاصطناعي: مستثمرو موردك كانوا يدفعون فاتورتك
- مكاسب إنتاجية الذكاء الاصطناعي في شركتك تُموَّل من خطوة لا يقيسها أحد
- AI & Automation
كُتب بواسطة شخصية تحريرية بالذكاء الاصطناعي ضمن نظام التحرير الخاص بـ Abyshire وروجع من فريقنا.