تكمن المشكلة الحقيقية مع وكيل الذكاء الاصطناعي عندما ينتقل من اقتراح الخطوات إلى تنفيذها فعليًا: إرسال رسالة، حذف ملف، تعديل سجل، نشر محتوى، إجراء عملية مالية أو تشغيل أمر على النظام. في هذه اللحظة لا يكفي أن تكون التعليمات التي أعطيتها للوكيل واضحة؛ لأن الخطأ قد يحدث بسبب تفسير غير صحيح، أو بيانات ناقصة، أو أداة منحت صلاحية أوسع مما يحتاجه. لذلك يجب أن تُبنى الحماية داخل مسار التنفيذ نفسه، بحيث لا يستطيع الوكيل تجاوز حدود محددة حتى لو قرر أن الإجراء مناسب.
لمنع وكيل الذكاء الاصطناعي من تنفيذ خطوات حساسة دون موافقتك، اجعل الأدوات عالية التأثير تتوقف قبل التنفيذ وتطلب موافقة بشرية صريحة، وامنح الوكيل أقل قدر ممكن من الصلاحيات بدل إعطائه وصولًا مفتوحًا إلى الحسابات والملفات والأنظمة.
ما الخطوات التي يجب اعتبارها حساسة أصلًا؟
لا ينبغي التعامل مع جميع أدوات الوكيل بالطريقة نفسها. قراءة ملف عام تختلف عن حذفه، والبحث عن موعد يختلف عن إلغاء موعد، وصياغة رسالة تختلف عن إرسالها. أفضل نقطة بداية هي تصنيف الإجراءات بحسب أثرها إذا نُفذت بصورة خاطئة.
- إجراءات منخفضة التأثير: البحث، القراءة، التلخيص، الفرز، استخراج معلومات من بيانات مسموح بها.
- إجراءات قابلة للعكس: إنشاء مسودة، إضافة عنصر يمكن حذفه بسهولة، نقل ملف إلى مجلد مؤقت.
- إجراءات حساسة: الإرسال، النشر، تعديل الصلاحيات، مشاركة الملفات، تغيير إعدادات الحساب.
- إجراءات عالية الخطورة: الحذف النهائي، تنفيذ أوامر النظام، تحويل الأموال، تغيير بيانات الاسترداد أو المصادقة.
يشير ملف الذكاء الاصطناعي التوليدي ضمن إطار NIST لإدارة مخاطر الذكاء الاصطناعي إلى أن استخدام الأنظمة التوليدية قد يتطلب مستويات مختلفة من المراجعة البشرية والتتبع والإشراف وفق السياق والمخاطر. وهذا يتوافق مع فكرة عدم منح جميع الأفعال درجة الاستقلالية نفسها.
الفكرة العملية: لا تبدأ بإعداد زر «طلب الموافقة»، بل ابدأ أولًا بقائمة واضحة للأفعال التي لا يجوز تنفيذها تلقائيًا.
كيف تجعل الوكيل يتوقف فعلًا قبل التنفيذ؟
التعليمات النصية من نوع «لا تنفذ إلا بعد سؤالي» مفيدة، لكنها ليست حاجزًا تقنيًا كافيًا بمفردها. الحماية الأقوى تكون عندما تكون أداة التنفيذ نفسها مهيأة بحيث لا تعمل حتى يصدر قرار موافقة مستقل عن تخمين الوكيل.
مثلًا، إذا امتلك الوكيل أداة لإلغاء طلب أو إرسال بريد، فيجب أن يتوقف التنفيذ عند استدعاء هذه الأداة ويعرض عليك اسم العملية والمعلمات المهمة قبل المتابعة. توضح وثائق OpenAI Agents SDK الخاصة بآلية Human-in-the-loop أن الأدوات يمكن إعدادها بحيث تتطلب موافقة، وعندها يتوقف التشغيل قبل تنفيذ الأداة حتى تتم الموافقة أو الرفض.
هذه الآلية أكثر أمانًا من الاعتماد على صياغة البرومبت؛ لأن القرار النهائي ينتقل من النموذج إلى طبقة التنفيذ.
الفكرة العملية: اجعل الموافقة شرطًا تقنيًا في الأداة نفسها، لا مجرد جملة تطلب من الوكيل أن يكون حذرًا.
هل يجب أن يطلب الوكيل الموافقة على كل خطوة؟
لا، لأن كثرة طلبات الموافقة قد تجعل المستخدم يوافق تلقائيًا دون قراءة التفاصيل، وهو ما يضعف قيمة الحماية. الأفضل أن تكون الموافقة مرتبطة بدرجة الخطورة وليس بكل عملية صغيرة.
يمكن مثلًا السماح للوكيل بقراءة التقويم والبحث عن أوقات متاحة دون تدخل، ثم إيقافه فقط عندما يريد إنشاء موعد أو إلغاء موعد موجود. وبالطريقة نفسها يمكنه تحليل الملفات وصياغة تغييرات، لكن يحتاج إلى موافقة قبل الكتابة فوق الملف الأصلي أو حذفه.
من المفيد بناء سياسة من ثلاث حالات: تنفيذ تلقائي للعمليات الآمنة، طلب موافقة للعمليات الحساسة، ومنع كامل للعمليات التي لا يحتاجها الوكيل أساسًا.
| نوع العملية | السياسة المناسبة | مثال |
|---|---|---|
| قراءة فقط | تنفيذ تلقائي غالبًا | البحث داخل ملفات مصرح بها |
| تعديل محدود وقابل للعكس | حسب السياق | إنشاء مسودة |
| إجراء خارجي | موافقة مسبقة | إرسال رسالة أو نشر محتوى |
| إجراء غير قابل للعكس أو مالي | موافقة صريحة ومشددة | حذف نهائي أو تحويل أموال |
الفكرة العملية: اطلب الموافقة عندما يتغير شيء في العالم الحقيقي أو يصبح التراجع عنه صعبًا، لا عند كل عملية قراءة بسيطة.
ما المعلومات التي يجب أن تظهر لك قبل الضغط على موافق؟
نافذة الموافقة التي تقول فقط «هل تسمح للوكيل بالمتابعة؟» ضعيفة؛ لأنك لا تعرف فعليًا ما الذي سيحدث. الموافقة المفيدة يجب أن تعرض العملية النهائية بصورة تسمح لك بفهم أثرها قبل تنفيذها.
- اسم الأداة أو العملية التي سيستخدمها الوكيل.
- الحساب أو الملف أو النظام الذي ستُنفذ عليه.
- القيم المهمة مثل المستلم والمبلغ واسم الملف أو الأمر.
- هل يمكن التراجع عن العملية بعد تنفيذها أم لا.
- أي بيانات سيشاركها الوكيل مع خدمة خارجية.
في أنظمة الموافقة الجيدة، لا ينبغي أن تكون الموافقة تصريحًا عامًا مبهمًا، بل مرتبطة باستدعاء محدد ومعلمات محددة. وتوضح وثائق OpenAI أن طلبات الموافقة يمكن أن تتضمن تفاصيل استدعاء الأداة ومعلماتها قبل استئناف التشغيل.
الفكرة العملية: لا توافق على «السماح للوكيل»؛ وافق على فعل محدد تعرف هدفه ومدخلاته وتأثيره.
لماذا يعتبر تقليل الصلاحيات أهم من الموافقة نفسها؟
حتى مع وجود نافذة موافقة، من الخطأ إعطاء الوكيل صلاحيات لا يحتاجها. إذا كانت مهمته تلخيص رسائل البريد، فلا يحتاج إلى صلاحية حذف البريد. وإذا كان دوره البحث في مستندات، فلا يوجد سبب لمنحه قدرة على مشاركة الملفات خارج المؤسسة.
هذه الفكرة تعرف عمليًا بمبدأ أقل صلاحية: كل مكوّن يحصل فقط على الوصول اللازم لإنجاز المهمة المطلوبة. النتيجة أن أي خطأ في الاستدلال أو التوجيه يبقى محصورًا ضمن مساحة أصغر.
ينسجم هذا النهج مع إطار NIST لإدارة مخاطر الذكاء الاصطناعي الذي يركز على إدارة المخاطر عبر دورة حياة النظام، لا على معالجة الخطأ بعد وقوعه فقط.
ومن الأفضل أيضًا فصل الأدوات حسب الغرض: أداة للقراءة فقط، وأخرى للتعديل، وثالثة للإرسال. بهذه الطريقة تستطيع فرض سياسة موافقة مختلفة على كل واحدة بدل منح الوكيل أداة واحدة واسعة الصلاحيات.
الفكرة العملية: إذا كان الوكيل لا يحتاج صلاحية لإنجاز مهمته الطبيعية، فلا تمنحه إياها حتى لو كان التنفيذ مشروطًا بالموافقة.
كيف تمنع الموافقة القديمة من التحول إلى تصريح مفتوح؟
من الأخطاء الشائعة اختيار «السماح دائمًا» لعملية حساسة حتى لا يظهر الطلب مرة أخرى. هذا مريح، لكنه قد يحول حاجز الموافقة إلى صلاحية دائمة لا تتناسب مع سياقات لاحقة.
الأفضل أن تكون الموافقات الحساسة مرتبطة بالعملية الحالية فقط. إذا وافقت على إرسال رسالة معينة إلى مستلم محدد، فلا ينبغي أن تعني الموافقة أن الوكيل يستطيع إرسال جميع الرسائل القادمة دون سؤال.
وتوضح وثائق OpenAI Agents SDK أن قرارات الموافقة يمكن أن تكون خاصة باستدعاء أداة معين، بينما توجد أيضًا إمكانات للموافقة المستمرة ضمن التشغيل. بالنسبة للعمليات الحساسة، يكون القرار المحدد لكل استدعاء أكثر تحفظًا لأنه يمنع تعميم موافقة صدرت في سياق سابق.
الفكرة العملية: اجعل الموافقة مؤقتة ومحددة بالعملية كلما ارتفع أثر الإجراء، ولا تستخدم «السماح دائمًا» لمجرد تقليل عدد التنبيهات.
ماذا لو حاول الوكيل تنفيذ سلسلة خطوات بدل خطوة واحدة؟
قد تكون الخطوة الأولى آمنة، لكن السلسلة كاملة تنتهي بعمل حساس. مثال ذلك أن يبحث الوكيل عن ملفات، يجمع عناوين بريد، يصيغ رسالة، ثم يرسلها. إذا طلب الموافقة في البداية فقط على «تنظيم الملفات والمعلومات»، فقد لا تدرك أن النتيجة النهائية تتضمن إرسال بيانات إلى جهة خارجية.
لذلك يجب وضع نقاط توقف عند حدود التأثير، وليس فقط عند بداية المهمة. يمكن للوكيل أن ينفذ البحث والتحليل وصناعة المسودة تلقائيًا، ثم يتوقف عند لحظة الإرسال الفعلية.
في أنظمة الوكلاء متعددة المراحل، يجب أن تنتقل سياسة الموافقة مع المهمة حتى عند تحويل العمل إلى وكيل فرعي أو أداة أخرى. وتشير وثائق OpenAI إلى أن الموافقات في Agents SDK يمكن أن تظهر حتى عندما تأتي الأداة المطلوبة من وكيل متداخل أو بعد عملية تحويل بين الوكلاء.
الفكرة العملية: راقب نقطة حدوث الأثر الحقيقي داخل السلسلة، ولا تعتبر موافقة البداية تصريحًا بكل ما قد يقرره الوكيل لاحقًا.
كيف تعرف بعد التنفيذ ما الذي فعله الوكيل بالضبط؟
الموافقة تمنع جزءًا من الأخطاء، لكنك تحتاج أيضًا إلى سجل يمكن مراجعته بعد التنفيذ. السجل المفيد يجب أن يوضح ماذا طلب المستخدم، وما الأداة التي اختارها الوكيل، وما المعلمات المستخدمة، ومن وافق، ومتى نُفذت العملية، وما النتيجة.
يشير NIST في ملف مخاطر الذكاء الاصطناعي التوليدي إلى الحاجة المحتملة لمزيد من المراجعة البشرية والتتبع والتوثيق والإشراف عند استخدام أنظمة الذكاء الاصطناعي التوليدي. وجود السجل يساعد كذلك على اكتشاف الأنماط المتكررة: هل يحاول الوكيل الوصول إلى أداة لا يحتاجها؟ هل تظهر طلبات موافقة غير متوقعة؟ وهل تغير سلوكه بعد تحديث النظام أو التعليمات؟
لكن لا تجعل سجل المراجعة نفسه مخزنًا للأسرار. إذا احتوت معلمات الأدوات على رموز وصول أو بيانات شديدة الحساسية، فيجب حجبها أو تقليل ما يُخزن منها.
الفكرة العملية: أي إجراء حساس يجب أن يترك أثرًا قابلًا للمراجعة يوضح من طلبه ومن وافق عليه وماذا نُفذ فعليًا.
ما الإعداد العملي الأفضل للاستخدام اليومي؟
للاستخدام الشخصي أو داخل فريق صغير، لا تحتاج إلى بنية معقدة. يمكن الوصول إلى مستوى جيد من الأمان بتقسيم صلاحيات الوكيل إلى ثلاث طبقات واضحة.
- اسمح تلقائيًا بالقراءة والتحليل داخل المصادر المسموح بها.
- اطلب موافقتك قبل أي إرسال أو تعديل أو مشاركة أو نشر.
- امنع افتراضيًا العمليات المالية والحذف النهائي وتغيير إعدادات الأمان إلا إذا كانت جزءًا ضروريًا جدًا من المهمة.
- اعرض تفاصيل الفعل قبل الموافقة، وليس اسم الأداة فقط.
- احتفظ بسجل للأفعال الحساسة والموافقات.
- راجع الصلاحيات دوريًا واحذف الأدوات التي لم يعد الوكيل يحتاجها.
وعند إضافة أداة جديدة، لا تبدأ بمنح الوكيل أقصى صلاحية ثم تحاول تقليلها لاحقًا. اختبرها أولًا في بيئة محدودة أو حساب تجريبي، ثم وسّع الصلاحيات تدريجيًا بعد التأكد من السلوك المتوقع.
الفكرة العملية: اجعل الوضع الافتراضي للوكيل «اقرأ وحلّل بحرية، لكن لا تغيّر شيئًا مهمًا دون إذن».
ما الذي يستحق أن تفعله الآن؟
راجع الأدوات التي يستطيع وكيلك استخدامها وحدد منها كل أداة تستطيع الإرسال أو الحذف أو التعديل أو النشر أو تغيير الصلاحيات، ثم اجعل تنفيذها متوقفًا على موافقة صريحة لكل عملية حساسة. هذه الخطوة الواحدة تقلل مساحة الخطأ أكثر من الاعتماد على تعليمات عامة تطلب من الوكيل أن «يتصرف بحذر».
قد يهمك:
- كيف تجعل الذكاء الاصطناعي يراقب مهمة ويبلغك بالتغيير؟
- كيف تحدد صلاحيات وكيل الذكاء الاصطناعي بأمان؟
- كيف تلخّص عدة ملفات بالذكاء الاصطناعي دون خلط المعلومات؟
- كيف تختبر وكيل ذكاء اصطناعي على حساب تجريبي بأمان؟
توضيحات شائعة
هل كتابة «اسألني قبل التنفيذ» في تعليمات الوكيل كافية؟
لا يُفضّل الاعتماد عليها وحدها. التعليمات مفيدة، لكن الإجراء الحساس يجب أن يكون محميًا أيضًا في طبقة الأداة أو النظام بحيث يتوقف التنفيذ تقنيًا إلى أن تصدر الموافقة.
هل أحتاج إلى موافقة بشرية إذا كان الوكيل يعمل داخل حساب تجريبي؟
يمكن تخفيف القيود في البيئة التجريبية إذا لم توجد بيانات أو موارد حقيقية، لكن من المفيد إبقاء الموافقات على بعض العمليات حتى تتأكد من أن سلوك الوكيل مناسب قبل نقله إلى البيئة الفعلية.
هل الموافقة تمنع جميع أخطاء الوكيل؟
لا. هي تقلل خطر التنفيذ غير المرغوب، لكنها لا تمنعك من الموافقة على طلب خاطئ. لذلك يجب أن يعرض النظام تفاصيل الإجراء بصورة واضحة قبل اتخاذ القرار.
هل من الآمن منح الوكيل وصولًا كاملًا إذا كنت أراجع كل خطوة؟
الأفضل عدم ذلك. تقليل الصلاحيات يوفر حاجزًا إضافيًا إذا حدث خطأ في الموافقة أو في التطبيق، ويقلل حجم الضرر الممكن من أي استدعاء غير مقصود.
هل ينبغي تسجيل كل ما يفعله الوكيل؟
ليس بالضرورة تسجيل كل خطوة بسيطة، لكن من المفيد تسجيل الإجراءات الحساسة وطلبات الموافقة والنتائج، مع تجنب تخزين كلمات المرور والرموز السرية داخل السجلات.