Amazon Bedrock Guardrails تحصل على واجهة API جديدة لحماية مرنة لتطبيقات الذكاء الاصطناعي القائمة على الوكلاء

أطلقت Amazon Web Services واجهة API جديدة لمنصة Amazon Bedrock Guardrails باسم InvokeGuardrailChecks. تتيح هذه الواجهة إدراج فحوصات أمان منفصلة في تطبيقات الذكاء الاصطناعي القائمة على الوكلاء في أي نقطة من سير العمل، ودون الحاجة إلى إنشاء موارد guardrail مسبقًا.

ما الذي غيّرته الواجهة الجديدة

حتى الآن، كان استخدام Amazon Bedrock Guardrails يتطلب إعدادًا مسبقًا: ينشئ المطوّر مورد guardrail في وحدة التحكم، ثم يربطه بنموذج أو بنقطة نهاية (endpoint)، ولا يستطيع استخدام آليات الحماية إلا بعد ذلك. وكان هذا يعني نهجًا مركزيًا: guardrail واحد لكامل التطبيق أو لكتلة كبيرة منه.

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

لماذا يهم هذا الأنظمة القائمة على الوكلاء

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

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

تدعم الواجهة الأنواع التالية من الفحوصات:

• اكتشاف بيانات PII (البيانات الشخصية) وإخفاؤها
• تصفية المحتوى وفق فئات قابلة للضبط
• حظر المواضيع المحظورة (topic denial)
• التحقق من موثوقية الإجابات استنادًا إلى المصادر (grounding)
• اكتشاف محاولات prompt injection

التطبيق في سيناريوهات المؤسسات

تتسم الواجهة الجديدة بأهمية خاصة لتطبيقات المؤسسات (enterprise) التي يتعامل فيها الوكيل مع بيانات حساسة أو يملك صلاحية الوصول إلى أنظمة الشركة الداخلية.

ففي روبوتات الموارد البشرية، من المهم التأكد من أن الوكيل لا يكشف البيانات الشخصية لموظف لموظف آخر، حتى لو ظهرت في مخرجات LLM الوسيطة. وتتيح InvokeGuardrailChecks إضافة فحص PII في اللحظة التي يجمع فيها الوكيل الإجابة تحديدًا.

وفي التطبيقات المالية، يُدرج فحص grounding قبل المخرجات النهائية، كي يستند الوكيل إلى مصادر حقيقية ولا يولّد بيانات غير موثوقة.

وفي الأنظمة متعددة الوكلاء، يُضاف فحص prompt injection عند مرحلة استقبال البيانات من وكيل خارجي.

«بفضل هذه الواجهة، يستطيع المطوّرون تطبيق فحوصات أمان فردية في أي نقطة من تطبيقات الذكاء الاصطناعي القائمة على الوكلاء، دون الحاجة إلى إنشاء موارد guardrail»، — AWS

Machine Learning Blog.

ماذا يعني ذلك

تبني Amazon بصورة متسقة بنية تحتية للمؤسسات من أجل نشر وكلاء الذكاء الاصطناعي بأمان. وتأتي InvokeGuardrailChecks امتدادًا منطقيًا لهذه الاستراتيجية: فبدلًا من حاجز مركزي واحد، تقدّم الشركة مجموعة من الأدوات الموضعية التي يدرجها المطوّرون حيث تكون الرقابة مطلوبة فعلًا.

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