في كل محادثة أجريها مع قادة المؤسسات، يقولون الشيء نفسه. إنهم يريدون أن يقوم الوكلاء بالمزيد، لكنهم لا يثقون في أن يفعلوا ذلك بشكل صحيح في كل الأوقات.
وهذا أمر عادل. الإبداع والاستقلالية نفسها التي تجعل الوكلاء مفيدين تجعلهم يصعب الوثوق بهم. أعطِ الوكيل مهمة وسيجد طريقه الخاص لإنجازها، مختاراً أدوات وتسلسل خطوات لم يبرمجها أي مطور. شغّل المهمة نفسها مرتين وقد يسلك مساراً مختلفاً في كل مرة. الاختبار الذي ينجح اليوم لا يخبرك الكثير عما سيفعله الوكيل غداً.
الإجابة المعتادة هي وجود شخص في الحلقة، يوافق على كل ما يفعله الوكيل. هذا ينجح على نطاق صغير، لكن مع تولي الوكلاء مزيداً من العمل، تتراكم الموافقات البشرية ويظهر إجهاد المراجعة. الأشخاص المُطالَبون بفحص كل شيء يتوقفون عن رصد الأمور المهمة. يصبح الحذر عنق زجاجة، ويجلس وكلاء قادرون على أشياء أكبر بكثير عاطلين بلا عمل على المهام القيّمة التي كان يمكن أن تحدث أثراً أكبر.
الحل هو السماح للوكيل بالتصرف بشكل مستقل عندما يمكن التحقق من أفعاله، وحجز الحكم البشري للقرارات التي تتطلبه. ومع تولي الوكلاء أعمالاً ذات مخاطر أعلى، مثل المعاملات المالية، يصبح الفعل الخاطئ ضاراً على نحو متزايد. تحتاج المؤسسات إلى الثقة لتسليم عمل مهم إلى وكيل ذكاء اصطناعي، على علم بأنه سيبقى ضمن الحدود المحددة، حتى عندما لا يراقبه أحد. يجب بناء تلك الثقة.
يخدم كل من تصفية المحتوى والاختبار والمراقبة غرضاً مهماً، لكن لا واحدة من هذه القدرات بمفردها تستطيع أن تضمن أن الوكيل سيتصرف بشكل صحيح في المرة القادمة التي يعمل فيها. الثقة تأتي من طبقات مستقلة تعزز بعضها بعضاً، وهو النظام متعدد الطبقات نفسه الذي مارسته الصناعة لمدة عقدين باسم الدفاع في العمق، لكنه اتجه نحو غرض جديد. حيث يقيّد الدفاع في العمق ما يمكن أن يسوء، هذا يوسّع ما يمكنك السماح به بأمان. تسميه AWS الثقة في العمق.
الثقة في العمق: ثقة يمكنك التحقق منها
أنت تبني الثقة من خلال الإجابة عن مجموعة من الأسئلة في لحظات مختلفة من دورة حياة الوكيل:
- النطاق، قبل تشغيله: ما الغرض من هذا الوكيل، وما القدرات التي تتطلبها المهمة، وما الذي يجب ألا يفعله أبداً؟
- المعرفة، عند النشر: من خوّله، وما الهوية التي يحملها، وهل يمكنك حساب كل وكيل يتصرف نيابة عنك؟
- الحدود، أثناء تشغيله: هل تبقى أفعاله ضمن الحدود التي وضعتها، وهل يمكنه مع ذلك إنجاز المهمة؟
- الملاحظة، بعد كل تشغيل: هل يمكنك إعادة بناء ما فعله الوكيل ولماذا، والتعلم منه؟
عبر هذه الأسئلة، يمكن التعبير عن بعض المتطلبات كقواعد دقيقة، بينما يتطلب البعض الآخر حكماً. قد تتطلب الشركة أن المدير وحده هو من يوافق على منح الوصول، أو أن يجب حظر تسجيل دخول الموظف قبل إمكانية مشاركة صندوق بريده. أما التوقعات الأخرى، مثل الحفاظ على نبرة ودية أو التعامل بشكل مناسب مع موقف حساس، فتعتمد على السياق والحكم البشري.
بالنسبة للقواعد المحددة بدقة، يُظهر الاختبار ما إذا كانت الضوابط تعمل في الحالات التي تتوقعها، لكن الوكيل يسلك مسارات لم تتوقعها. التقنية التي تتجاوز ذلك هي الاستدلال الآلي، وهو المنطق الرياضي الذي يتحقق مما إذا كانت القاعدة صحيحة في كل حالة ممكنة. يمكنه إثبات أن القاعدة تنطبق على كل مسار يغطيه وصف دقيق للنظام وافتراضاته، أو الكشف عن الحالة المحددة التي تفشل فيها. تلك النتيجة إثبات، وهي لا تكون جيدة إلا بقدر جودة القواعد والافتراضات الكامنة وراءها، ولهذا فإن أصعب الأعمال تأتي قبل تشغيل الوكيل.
لقد طوّرت AWS شغّلت الاستدلال الآلي في بيئة الإنتاج لأكثر من عقد من الزمان، من إدارة الهوية والوصول (IAM) بأكثر من 2.1 مليار طلب في الثانية إلى أنظمة حرجة مثل AWS Nitro Hypervisor وAmazon S3 Block Public Access وVPC Reachability Analyzer. والآن نحن نأتي بها إلى الوكلاء. أينما أمكن التعبير عن قواعد الوكيل بدقة، يمكن للاستدلال الآلي التحقق منها.
مع ذلك، لا يمكن التعبير عن كل قاعدة بدقة. "المدير وحده هو من يوافق على منح الوصول" يمكن إثباتها. "حافظ على نبرة ودية" لا يمكن. حيث لا ينطبق الإثبات، قيّد وصول الوكيل وأفعاله، وقيّم سلوكه، وأرسل الغموض الحقيقي إلى شخص ليطبّق حكمه. امنح مزيداً من الاستقلالية عندما تُثبت أن القواعد ذات الصلة مفروضة، وأن الوكيل يؤدي المهمة بموثوقية، وأن الإخفاقات يمكن اكتشافها والتعامل معها.
فيما يلي ما تتطلبه كل طبقة من طبقات الثقة في العمق منك، وكيف تساعدك AWS في الإجابة عنها.
حدّد نطاق وكيلك بما تتطلبه المهمة فقط
تبدأ الثقة قبل تشغيل الوكيل، وهذا هو المكان الذي يجب أن تستثمر فيه أكبر جهد. المشكلات التي تُكتشف هنا رخيصة الإصلاح. تحديد النطاق يعني أن تقرر ما العمل الذي يملكه الوكيل، وما الأدوات والبيانات والخدمات التي يمكنه الوصول إليها، وما القواعد التي يجب أن يتبعها، وما القرارات التي تبقى لشخص.
"حل مشكلة العميل" يحدد ما يجب تحقيقه، لا كيف يمكن للوكيل أن يتصرف لتحقيقه. لا يزال الوكيل يحتاج إلى حدود على ما يمكنه رؤيته، وما يمكنه فعله، ومتى يجب أن يتوقف ويسأل. امنحه الوصول الذي تتطلبه مهمته فقط، ولا أكثر. راقب القدرات التي لم يمنحها أحد عن قصد، تلك المرفقة مع أداة أو دور. امنح دور مسؤول لمهمة واحدة، ويمكن للوكيل أن يرث أذونات في بيئتك بأكملها.
يبدأ تحديد النطاق من مرحلة البناء، مع الطريقة التي تُعرّف بها الوكيل. Kiro، وهو نظام البرمجة الوكيلية، يُدخل الدقة والممارسات الهندسية الناضجة في مرحلة بناء الوكلاء. فهو يحوّل النية عالية المستوى إلى متطلبات منظمة قائمة على المواصفات، ويستخدم الاستدلال الآلي للكشف عن التناقضات والغموض والفجوات قبل كتابة أي كود. كما يشتق Kiro اختبارات قائمة على الخصائص تتحقق من مطابقة التنفيذ لتلك المتطلبات عبر مجموعة واسعة من المدخلات، ملتقطًا أخطاء يصعب اكتشافها. Strands يوفّر مجموعة أدوات مفتوحة المصدر لتعريف نموذج الوكيل وتعليماته وأدواته، وبيئة تشغيل مُدارة لتشغيله. وأيًا كان الإطار الذي تختاره، فإن مسؤولية تحديد مهمة الوكيل وحدوده هي نفسها.
الخطوة التالية هي تحويل تلك الحدود إلى قواعد يمكنك محاسبة الوكيل عليها. Amazon Bedrock AgentCore يوفّر ضوابط حوكمة لتوسيع نطاق الوكلاء بأمان ويحكم فيما يفعله الوكيل. باستخدام السياسات (Policies) في Bedrock AgentCore، تصف بلغة بسيطة الأدوات وواجهات API والبيانات التي يُسمح للوكيل بالوصول إليها، ويتحقق الاستدلال الآلي من السياسات بحثًا عن فجوات، مثل اكتشاف قاعدة تمنح صلاحيات زائدة عن اللزوم، ويفحص التناقضات التي تجعل القاعدة غير قابلة للتحقيق أبدًا، قبل أن تدخل حيّز التنفيذ.
تحديد نطاق وكيلك هو الجزء الأصعب، لأن تحويل النية البشرية إلى سياسة متينة وقابلة للتنفيذ يتطلب الدقة والاكتمال. لكنه أيضًا الجزء الأكبر عائدًا. فكل ما يُبنى على ما تضعه هنا يستند إليه، وكلما كانت السياسة أدق، زاد ما يستطيع وكيلك القيام به بأمان من تلقاء نفسه.
اعرف كل وكيل يتصرف نيابةً عنك وتحت سلطة مَن
لا يمكنك حوكمة ما لا تستطيع رؤيته. الفرق تُنشئ الوكلاء أسرع مما يستطيع أحد تتبعها، والوكيل الذي لا يعلم به أحد هو وكيل لا يتحكم فيه أحد. كل وكيل يحتاج إلى هوية خاصة به، تُتحقق منها في كل مرة يتصرف فيها. لا ينبغي أن يكون أي إجراء يتيمًا. وعندما يحدث خطأ ما، يمكنك معرفة أي وكيل فعل ماذا، ومن أذن بذلك.
AWS Agent Registry يوفّر كتالوجًا مُدارًا ومعتمدًا للوكلاء وخوادم بروتوكول Model Context Protocol (MCP) والأدوات والمهارات عبر مؤسستك. يستخدم المسؤولون سير عمل الموافقة لتنظيم ما يصبح قابلاً للاكتشاف وإزالة ما لم يعد يلبّي معايير الأمان والامتثال والجودة. ويمكن للأشخاص والوكلاء على حد سواء العثور على ما هو موجود أصلًا وإعادة استخدامه بدلاً من إعادة بنائه. لكن الكتالوج يخبرك فقط بما هو موجود. وبمجرد معرفة الوكلاء، يُصدر AgentCore لكل وكيل هوية خاصة به ويتحقق منها في كل طلب، بحيث يعود كل إجراء إلى وكيل محدد يعمل تحت سلطة معروفة. هكذا تعرف كل وكيل يتصرف نيابةً عنك.
حدّد ما يقوله وكيلك ويفعله ضمن الحدود التي تضعها
وضع الحدود أمر مهم لأن الوكيل قد يتخذ 10 خطوات وافقت عليها ومع ذلك يصل إلى نتيجة لم يقصدها أحد. فقد يكشف بيانات حساسة، أو ينحرف عن الموضوع، أو يجمع بين إجراءات مسموح بها بطرق تحظرها سياساتك. يمكن أن تفشل الحدود في الاتجاهين: فهي إن كانت فضفاضة جدًا استطاع الوكيل فعل ما لا ينبغي، وإن كانت ضيقة جدًا عجز عن أداء مهمته أصلًا. لذا اترك للوكيل حرية اختيار كيفية متابعة مهمته لكن لا تعتمد أبدًا عليه في فرض حدوده الذاتية. تلك الحدود تحدد حدود الوكيل وتنتمي إلى البيئة المحيطة بالوكيل، وتُفرض بشكل حتمي وتُقيّم عبر كامل تسلسل الإجراءات، لا خطوة واحدة في كل مرة.
هنا تدخل حيّز التنفيذ السياسة التي حددتها في مرحلة تحديد النطاق. Policy in AgentCore يفرضها على كل استدعاء أداة يُوجَّه عبر AgentCore Gateway، وهي نقطة دخول آمنة للوكلاء والأدوات والنماذج. ولأن التنفيذ يقع خارج استدلال الوكيل، يمكن أن تظل الفحوصات نفسها سارية حتى إذا كان الوكيل معيبًا أو مُتلاعبًا به أو تعرّض لهجوم حقن الأوامر: فلا يمكنه إيقاف تشغيل عنصر تحكم لا يشغّله هو. كما لا يلزم أن تبقى السلطة ثابتة. ولأن مخاطر المهمة تتغير مع تقدّمها، temporal policies تزن ما حدث بالفعل في الجلسة وتعدّل الأذونات مع استمرار العمل. Amazon Bedrock Guardrails يحكم فيما يقوله الوكيل وما يُقال له. فهو يرشّح المحتوى الضار أو الخارج عن الموضوع ويحجب البيانات الحساسة. Automated Reasoning checks تتجاوز ذلك إلى إثبات أن الاستجابة متسقة مع السياسة التي وضعتها، وليس مع تفسير النموذج لها.
كما تحكم الحدود فيما يستطيع الوكيل الوصول إليه في المقام الأول: الملفات التي يمكنه لمسها، والخدمات التي يمكنه استدعاؤها، وبيانات الاعتماد التي يمكنه استخدامها. Strands Box، وهو صندوق حماية (sandbox) مفتوح المصدر، يفرض تلك الحدود من خارج تعليمات الوكيل، بحيث يستطيع الوكيل العمل بأدوات وبيانات حقيقية لكن يصل فقط إلى ما تسمح به. وتظل الحدود نفسها سارية من أول جلسة محلية للمطوّر حتى الإنتاج، بحيث لا يستطيع الوكيل أن يفعل في الإنتاج ما لم يستطع فعله في بيئة التطوير.
راقب ما فعله وكيلك، ثم حسّنه
حتى مع وجود تحديد النطاق والهوية والحدود، يمكن لوكيل ذكي أن يستجيب في أجزاء من الثانية، دون أي أخطاء وبكل لوحات المعلومات خضراء، ومع ذلك يقوم بالعمل الخاطئ. قد يكون قد استرجع معلومات خاطئة، أو اختار الأداة الخاطئة، أو اتبع مساراً لم يتوقعه أحد. النظام السليم لا يعني بالضرورة مهمة ناجحة. وللتمييز بين الأمرين، يجب عليك إعادة بناء ما قام به الوكيل فعلياً: السياق الذي تلقاه، والأدوات التي استدعاها، وقرارات السياسات المطبقة، والنتيجة. ويظل الاختبار قبل النشر أمراً أساسياً. أما الإنتاج فيضيف أدلة حول السلوك في ظل الظروف الحقيقية، ويمنح المشغلين ما يحتاجونه للتحقيق والتدخل والتحسين.
Amazon CloudWatch Omni مبني للمراقبة المستمرة. فهو يلتقط كل أثر ويعرض كل خطوة اتخذها الوكيل، من استدعاءات النموذج إلى استدعاءات الأدوات، على خط زمني يمكن للفريق التحقيق فيه. ويقيم مقيّماته المدمجة استجابات الوكيل وفق معايير تفوتها المراقبة القياسية، مثل الصحة والدقة وما إذا كان الوكيل قد اختار الأداة الصحيحة. وتصبح الآثار التي أخطأ فيها الوكيل هي مجموعة البيانات التي تختبر الإصلاح ضدها، بحيث يعتمد تشغيل الوكيل وتحسينه على الأدلة نفسها.
كيف يبدو الثقة المتعمقة في الممارسة العملية
يطلب مدير من وكيل مكتب المساعدة تسريح موظف يدعى سام، وهو مدير حسابات سيغادر الشركة. يحتاج الوكيل إلى إزالة صلاحيات وصول سام، ونقل بريده الإلكتروني إلى خليفته، وتحرير الترخيص الذي لم تعد الشركة بحاجة إليه. لكن رسائل سام الإلكترونية قد تحتوي أيضاً على أدلة مطلوبة لنزاع مع أحد العملاء. والتسلسل الخاطئ قد يترك سام بصلاحيات وصول بعد مغادرته أو يعرّض تلك الأدلة للخطر. ولكل من الأمن والمراسلة والشؤون القانونية والمالية متطلبات يجب على الوكيل اتباعها، رغم أن أحداً لم يكتب سير العمل الكامل مسبقاً.
قاعدتان تحكمان التسلسل. يجب منع تسجيل دخول سام قبل تحويل بريده الإلكتروني ومشاركته مع خليفته. وقبل تغيير ترخيص بريده الإلكتروني، يجب على الوكيل التحقق من وجود حجوزة قانونية، وهي اشتراط بالاحتفاظ بالسجلات لنزاع ما، والتأكد من أن التغيير يحافظ على حماية تلك السجلات.
النطاق. قبل تشغيل الوكيل، يكتب الفريق هذه القواعد كسياسات في AgentCore. تتطلب كل سياسة أن تكون الخطوة السابقة قد نجحت بالفعل لحساب سام قبل تشغيل الخطوة التالية. يحصل الوكيل على ست أدوات بالضبط: منع تسجيل الدخول، والتحقق من الحجوزات القانونية، وفرض حجوزة، وتحويل صندوق بريد، ومنح الخليف حق الوصول، وتغيير ترخيص. ولا يحصل على أداة لحذف الحساب، لأن صندوق البريد المشترك يحتاج إلى بقاء الحساب قائماً.
المعرفة. يحمل الوكيل هويته الخاصة، بحيث يعود كل تغيير على حساب سام إليه يمكن تتبعه.
الحدود. يحاول الوكيل تحويل صندوق بريد سام إلى صندوق مشترك لبريا، الخليفة. لكن سياسة في AgentCore، مفروضة عند AgentCore Gateway، تمنع الاستدعاء: فسام لا يزال قادراً على تسجيل الدخول، وتحويل صندوق البريد لن يغيّر كلمة مروره، بحيث ستظل بيانات اعتماده القديمة تفتحه. يمنع الوكيل تسجيل دخول سام، ثم يحوّل صندوق البريد ويعطي بريا حق الوصول. بعد ذلك ينتقل إلى الطلب الفعلي للمدير، وهو تحرير الترخيص، لكن البوابة تمنع ذلك أيضاً، لأن أحداً لم يتحقق من قائمة الحجوزات الخاصة بالشؤون القانونية. يتحقق الوكيل فيجد أن الشؤون القانونية تشترط الاحتفاظ برسائل سام الإلكترونية لنزاع مع أحد العملاء. فيفرض الحجوزة، ويؤكد أنها سارية، ثم يغيّر ترخيص سام إلى ترخيص يدعم تلك الحماية. وبهذا تستطيع الشركة استعادة الترخيص الأوسع مع الحفاظ على الأدلة سليمة.
المراقبة. تُسجَّل كل خطوة: ما حاول الوكيل فعله، وما قررته القواعد، والحجوزة، والنتيجة.
أكمل الوكيل المهمة دون موافقة شخص بشري على كل خطوة. حدّت صلاحياته مما يمكنه تغييره، وجعلت هويته تلك التغييرات قابلة للتتبع، وأوقفت السياساته عن التصرف قبل توفر الضمانات المطلوبة. ومكّنت الخطوات المسجلة الفريق من التحقق من أن وصول سام قد مُنع، وأن خليفه يستطيع استخدام صندوق البريد، وأن الأدلة المطلوبة ظلت محمية.
ما يصبح ممكناً عندما تُوثق بالوكلاء
تجمع AWS هذه الطبقات معاً حتى تتمكن من تحديد نطاق الوكيل وفق مهمته، ومعرفة الوكلاء الذين يعملون نيابة عنك، وتقييد ما يفعلونه ويقولونه، ورؤية ما فعلوه وتحسينه بمرور الوقت، وإثبات أن قواعدك تصح أينما يمكن صياغتها بدقة. لا تربح طبقة واحدة تلك الثقة منفردة. فهي معاً تشكل الثقة المتعمقة، وهي ما يحوّل الوكيل القادر إلى وكيل يمكن الوثوق به للقيام بأعمال مهمة.
أنت من يرسم الخطوط: ما يمكن للوكيل فعله من تلقاء نفسه، وما يحتاج إلى موافقة شخص بشري، ومتى يجب أن يتوقف. ذلك يحرّر موظفيك لما لا يستطيعه سوى البشر: الموازنة بين القرارات الصعبة، وحل المناطق الرمادية، وامتلاك القرارات التي تختار إبقاءها بين أيدي البشر. ومع تراكم الأدلة على أن الوكيل يبقى داخل تلك الخطوط، يمكنك توسيع مسؤولياته أو تضييقها.
في AWS، نعتقد أن كل مؤسسة تنشر وكلاء، على أي منصة، يجب أن تكون قادرة على الإجابة عن هذه الأسئلة الأربعة بالأدلة، وبالإثبات أينما انطبق. هذا هو المعيار الذي تبنيه AWS لعملائنا، وهو المعيار الذي ندعو الصناعة إلى أن تحاسب نفسها عليه. لقد جعلت الدفاع المتعمق ربط الأنظمة بالعالم آمناً. والثقة المتعمقة تجعل من الآمن السماح للوكلاء بالتصرف باستقلالية داخله.
ابدأ بوكيل واحد، وسير عمل واحد، وحدٍّ واحد يمكنك إثباته. ثم توسّع كلما تحققت الثقة.
للبدء في تنفيذ قواعد قابلة للفرض، استكشف Policy في Amazon Bedrock AgentCore و Automated Reasoning checks في Amazon Bedrock Guardrails.