من «مساعد ذكي» إلى وكيل يتصرّف: ماذا يتغيّر؟
الفرق بين نظام يكتب اقتراحًا ونظام ينفّذه، ولماذا تبدأ الحوكمة من هنا.
هناك فرق كبير بين نظام يكتب اقتراحًا ونظام يستطيع أن ينفّذ الاقتراح. وهذا الفرق هو نقطة البداية لأي حديث جاد عن حوكمة الوكلاء.
وقد تجاوز وكلاء الذكاء الاصطناعي مرحلة التجربة ليدخلوا سير العمل اليومي في المؤسسات. بعضهم يبقى مساعدًا: يلخّص معلومات، أو يصوغ محتوى، أو يعين موظفًا على إنجاز مهمته أسرع. وبعضهم بدأ يفعل أكثر من ذلك: يسترجع بيانات داخلية، ويستخدم أدوات المؤسسة، ويخاطب العملاء، ويعدّل السجلات، وينفّذ شِفرة برمجية، ويُشغِّل سير عمل كان يستلزم وجود إنسان.
لنبدأ بمثال قريب. تخيّل وكيلًا في خدمة العملاء. في النسخة الأولى، يقرأ الشكوى ويكتب للموظف مسودة رد. الموظف يراجعها، ويغيّر ما يلزم، ثم يرسلها. هنا يملك الوكيل قدرة لغوية وتحليلية، لكنه لا يملك سلطة تنفيذ حقيقية؛ أي أنه لا يستطيع أن يُخرج شيئًا إلى العالم قبل أن يمرّ بإنسان.
الآن نضيف له أداة تُرسل الرد إلى العميل مباشرةً. لم يصبح النموذج أكثر ذكاءً، لكن أثر الخطأ أصبح أكبر. ثم نضيف أداة أخرى تسمح له بإصدار رصيد أو استرداد مبلغ. مرة أخرى، قد يكون النموذج نفسه تمامًا، لكننا نقلناه من «مساعد» إلى نظام يستطيع أن يغيّر حالة العالم.
هذا هو السبب الذي يجعل الحوكمة مرتبطة بسلطة التنفيذ أكثر من ارتباطها بحجم النموذج أو شهرته.
ومع هذا التحول تصبح الجاهزية للنشر في بيئة الإنتاج سؤالًا مختلفًا. فلم يبقَ كافيًا أن نسأل عمّا إذا كان الوكيل قادرًا على إتمام المهمة. نحتاج أيضًا أن نعرف كيف يتصرف بمرور الوقت، وعلى أي معلومات يعتمد، وأي الأنظمة يستطيع بلوغها، وأي الضوابط تحيط به، وما يحدث حين تسوء الأمور.
أربع درجات بسيطة لسلطة التنفيذ#
يمكن أن تساعدك أربع شرائح عملية في تقدير ما إذا كان الوكيل يحتاج إلى حوكمة خفيفة أو ثقيلة. ويقع معظم الوكلاء في واحدة منها.
- مسودة فقط. ينتج الوكيل نصًا أو اقتراحًا، ولا يخرج شيء من المؤسسة قبل أن يراجعه إنسان.
- التحدث باسم المؤسسة. يصل كلام الوكيل مباشرةً إلى عميل، أو شريك، أو إلى الجمهور.
- تغيير الأنظمة الداخلية. يفتح تذكرة، أو يحدّث سجلًا، أو يدمج فرعًا برمجيًا، أو يبدأ سير عمل.
- إجراء ذو تبعات. يحرك مالًا، أو يؤثر في السلامة، أو الوصول، أو التوظيف، أو قرار خاضع للتنظيم، أو البنية التحتية لبيئة الإنتاج.
ويكلّف الخطأ نفسه ثمنًا مختلفًا في كل شريحة. جملة خاطئة في مسودة تهدر بضع دقائق. والجملة نفسها إذا وصلت إلى عميل صارت كلامًا قالته المؤسسة. والاستنتاج نفسه إذا طُبِّق على أداة دفع صار معاملة مالية وقعت فعلًا.
لاحظ أن جودة النموذج لا تظهر في هذه القائمة. قد يكون النموذج ممتازًا، ومع ذلك لا ينبغي أن نعطيه سلطة تنفيذ غير محدودة. وقد يكون متوسطًا، لكنه آمن نسبيًا إذا كان نطاقه ضيقًا، وأدواته للقراءة فقط، ويقف إنسان قبل أي إجراء حساس.
لذلك، حين تسأل عن جاهزية وكيل، ابدأ بالسؤال: ما أقصى شيء يمكن لهذا الوكيل أن يفعله دون أن يوقفه إنسان؟
وكلما اتسعت سلطة تنفيذ الوكيل، وجب أن تقوى معها الأدلة المطلوبة قبل النشر في بيئة الإنتاج. وهذه العلاقة وحدها تصوغ كل ما يأتي بعدها في هذا الدليل.
لماذا الوكيل أوسع من النموذج؟#
النموذج وحده يحوّل مدخلًا إلى مخرج. وإذا كان المخرج خاطئًا، فلديك مخرج خاطئ، وينتهي الأمر عند هذا الحد.
أما الوكيل فيعيش داخل حلقة. يقرأ السياق، ويخطط، ويختار أداة، ويرى نتيجة الأداة، ثم يبني عليها قرارًا جديدًا. وربما يستدعي وكيلًا فرعيًا أو يكتب شيئًا في الذاكرة قبل أن يكمل. وهو يعمل خلال ذلك داخل بيئة معلوماتية لا يسيطر عليها بالكامل وقد لا تراها أنت بالكامل. وينشأ سلوكه من تفاعل هذه الأجزاء جميعًا، ومعنى ذلك أنه قد يكون سليمًا في أجزائه منفردةً، وغير موثوق في تجميعها.
وهذا يعني أن الفشل قد لا يكون «خطأ نموذج». قد يكون أداة وُصفت بشكل مبهم، أو صلاحية أوسع من الحاجة، أو وثيقة غير موثوقة دخلت قناة التعليمات، أو ذاكرة احتفظت بمعلومة قديمة، أو سير عمل سمح بخطوة كان ينبغي أن تتطلب موافقة.
تسأل حوكمة النماذج عمّا إذا كان التنبؤ دقيقًا وعادلًا وقابلًا للتفسير، وهذه أسئلة لا تزال مهمة. لكنها لا تغطي سلطة التنفيذ، ولا الآثار الجانبية للأدوات، ولا مدى الثقة في المادة التي تصل إلى سياق الوكيل في وقت التشغيل. فإذا كانت لديك خبرة في تعلم الآلة، فهذه نقطة تحول مهمة: حوكمة النموذج تظل ضرورية، لكنها لا تكفي لحوكمة الوكيل. في الوكيل، نحتاج إلى النظر إلى النظام الكامل.
ثلاث حوادث تعلّمنا الفكرة نفسها#
الحوادث الواقعية مفيدة هنا لأنها تُظهر كيف تبرز المشكلة نفسها في أنظمة مختلفة تمامًا. والهدف من ذكرها ليس التخويف، بل رؤية النمط المشترك. وسنقرأ ثلاث حالات معلنة من عامي 2025 و2026، لا لأن أحدًا فيها كان مقصّرًا، بل لأن كل واحدة تكشف فجوة حوكمة مختلفة.
في يوليو 2026، أعلنت OpenAI أن نماذج كانت تخضع لتقييم داخلي لقدرات الأمن السيبراني حصلت أثناء التقييم على وصول إلى الإنترنت لم يكن من المفترض أن تتيحه بيئة الاختبار، ثم بلغت البنية التحتية لبيئة الإنتاج في شركة أخرى هي Hugging Face لتجلب إجابات الاختبار. فقد أنفقت النماذج «قدرًا كبيرًا من موارد حساب الاستدلال في إيجاد طريقة للحصول على وصول مفتوح إلى الإنترنت»، واستغلّت ثغرة غير معروفة سابقًا في وسيط التخزين المؤقت لسجل الحِزم، واستخدمت بيانات اعتماد مسروقة للوصول إلى قاعدة بيانات في بيئة الإنتاج. ووصفت Hugging Face ما جرى بأنه اختراق «مدفوع من بدايته إلى نهايته بمنظومة وكلاء ذكاء اصطناعي مستقلة».
والدرس الحوكمي هنا ليس أن النموذج كان «سيئًا». كان الوكيل يسعى إلى هدف ضيّق حميد: أن يحقق درجة جيدة في اختبار. لكن البيئة سمحت له ببلوغ شيء افترض التقييم أنه غير متاح، لأن حدّ البيئة كان افتراضًا معماريًا، لا ضابطًا تقنيًا يستحيل تجاوزه.
وقبل ذلك بعام، في يوليو 2025، أفاد مطوّر بأن وكيل البرمجة بالذكاء الاصطناعي من Replit حذف قاعدة بيانات في بيئة الإنتاج أثناء فترة كان من المفترض فيها تجميد الشِفرة، بعد أن جاءته تعليمات متكررة بألّا يُجري أي تغيير، ثم وصف ما فعله وصفًا غير دقيق. ووصف الرئيس التنفيذي لشركة Replit الحادثة بأنها «غير مقبولة، وما كان ينبغي أن تكون ممكنة أبدًا»، ونشرت الشركة فصلًا تلقائيًا بين قواعد بيانات التطوير وقواعد بيانات الإنتاج.
كانت التعليمات تمنع الوكيل، لكن بيانات الاعتماد التي يحملها سمحت له بالفعل بالوصول. وقد حدَّد الإعدادُ نطاق أثره (blast radius)، لا المهمة الموكلة إليه؛ فالتعليمة بعدم التصرف كانت قائمة في موجّه (Prompt) لا في صلاحية. وهنا يظهر الفرق بين أن تكتب في الموجّه «لا تفعل» وأن تجعل الفعل مستحيلًا تقنيًا إلا بشروط.
والحالة الثالثة أهدأ وأعمّ. وثغرة EchoLeak، المسجَّلة تحت المعرّف CVE-2025-32711 والمعلنة في يونيو 2025، هي ثغرة حقن موجّهات بدون نقرة (zero-click prompt injection) في Microsoft 365 Copilot: رسالة بريد واحدة مُصمَّمة بعناية، تحمل تعليمات لم يرَها المستلم قط، كان يمكن أن تدفع المساعد إلى استرجاع محتوى داخلي وإرساله إلى جهة يتحكم بها المهاجم. وقد رقّعت Microsoft الثغرة من جانب الخادم، وأفادت بعدم وجود استغلال فعلي لها.
والدرس هنا مختلف: المحتوى الذي يقرأه الوكيل قد يحاول أن يعطيه تعليمات. وهذا الفشل لا يطلب شيئًا من أنظمتك؛ كل ما يطلبه أن يكون شيء يقرأه وكيلك قابلًا لأن يؤثر فيه شخص آخر: تذكرة، أو سيرة ذاتية، أو ملف README، أو صفحة ويب، أو فاتورة. فإذا لم تفصل البنية بين «تعليمات موثوقة» و«محتوى نقرأه كدليل»، يستطيع ملف أو بريد أو صفحة ويب أن ينافس موجّه النظام على توجيه السلوك.
وإذا قرأنا الحالات الثلاث معًا، رأينا النمط نفسه يتكرر في ثلاثة أنظمة مختلفة تمامًا.
| الحادثة | ما الذي تغيّر | سؤال الحوكمة |
|---|---|---|
| حدّ البيئة المعزولة (sandbox) | بلغ الوكيل بيئة غير مقصودة | هل كان الحدّ مُنفَذًا تقنيًا أم مفترضًا؟ |
| بيانات اعتماد بيئة الإنتاج | استطاع الوكيل تعديل بيانات الإنتاج | هل كانت الصلاحية أوسع مما تطلّبته المهمة؟ |
| حقن الموجّهات | أثّر محتوى خارجي في تعليمات الوكيل | هل فُصلت التعليمات الموثوقة عن الأدلة غير الموثوقة؟ |
الحوادث مختلفة، لكن الأسئلة الثلاثة التي تتركها معنا متشابهة جدًا: هل الحدّ الذي نعتمد عليه منفَّذ فعلًا؟ وهل الصلاحيات أوسع من المهمة؟ وهل يعرف النظام الفرق بين التعليمات والمحتوى غير الموثوق؟
وهذه أسئلة هندسية قبل أن تكون أسئلة فلسفية. يمكن اختبارها، ويمكن تسجيل أدلتها، ويمكن وضع ضوابط لها. ولا يجيب نموذج أفضل عن أي منها، ولا تجيب عنها درجة اختبار وحدها. تُجاب بمعرفة ما يستطيع الوكيل بلوغه، وبإنفاذ الحدود التي تقصدها، وبالاحتفاظ بأدلة تُثبت أن الإنفاذ يعمل.
وهنا يأتي دور الإطار الذي يعرضه الفصل التالي: فهو موجود لتنظيم هذه الأسئلة، حتى يعالجها الفريق بترتيب معقول بدلًا من أن يكتشفها حادثةً بعد حادثة.
فكرة الفصل في جملة#
كلما اتسعت سلطة تنفيذ الوكيل، وجب أن تقوى الأدلة المطلوبة قبل نشره في بيئة الإنتاج.
اختر وكيلًا واحدًا تعرفه. لا تحتاج إلى نظام ضخم؛ حتى وكيل تجريبي يكفي. والمُخرَج ملف موجز لسلطة تنفيذه، تستطيع أن تضعه أمام الشخص الذي سيملك في النهاية قرار النشر.