نشرت Google Cloud مخططًا جديدًا يوضح كيف ينبغي للمؤسسات تأمين أعباء عمل الذكاء الاصطناعي التي تعمل على Google Kubernetes Engine، بحجة أن التحول من النموذج الأولي إلى الإنتاج قد تجاوز نماذج الأمان التقليدية. تحدد الوثيقة، التي كتبها جلين ماسنجر وشانون كولراثنا، نهجًا ثلاثي الطبقات يغطي البنية التحتية وسلامة النماذج وأمن التطبيقات، وتستهدف كبار مسؤولي أمن المعلومات وفرق هندسة المنصات.
كتب Messenger، وهو مدير منتجات جماعي في فريق أمان GKE، أن الفرق “تحتاج إلى حماية أوزان النماذج الخاصة، والدفاع ضد تهديدات طبقة التطبيقات الجديدة مثل الحقن الفوري، وفرض الامتثال التنظيمي الصارم، كل ذلك دون إبطاء مطوري الذكاء الاصطناعي لديك.” ويرى المخطط أن تحقيق هذه الأهداف يتطلب أكثر من مجرد مكان لتشغيل الحاويات ويدعو إلى إنشاء منصة “تعمل على تركيب طبقات من الأمان خارج الصندوق”.
بالنسبة للبنية التحتية، يقترح المخطط استخدام عقد GKE السرية، والتي توسع تشفير الذاكرة على مستوى الأجهزة لتشمل المسرعات بما في ذلك وحدات معالجة الرسومات Nvidia H100 وTPU. كما أن استخدام Workload Identity Union (الذي يتيح لقرنات الاستدلال جلب أوزان النموذج من التخزين السحابي بدون مفاتيح طويلة الأمد) وعناصر التحكم في خدمة VPC تتيح للمسؤولين إنشاء محيط حول البيانات المنظمة.
لا يمكن أن يكون لديك عبء عمل آمن للذكاء الاصطناعي على مجموعة غير آمنة.
– فريق Google Cloud GKE، تأمين الذكاء الاصطناعي على مستوى المؤسسة: مخطط محرك Google Kubernetes
بالنسبة لأمان النموذج، تشير Google إلى أن فواتير المواد الخاصة بالبرامج التقليدية لا تلتقط المصنوعات الخاصة بالذكاء الاصطناعي مثل مجموعات البيانات والأطر، لذا يقدم المخطط k8s-aibom، وهي وحدة تحكم Kubernetes مفتوحة المصدر تعمل على إنشاء فواتير مواد الذكاء الاصطناعي تلقائيًا. في طبقة التطبيق، يقوم Model Armor بفحص المطالبات والاستجابات لمحاولات الحقن، والتعرض للبيانات الحساسة والمحتوى الضار، في حين يوصى باستخدام GKE Sandbox، المبني على تقنية العزل gVisor، لاحتوائه على عوامل الذكاء الاصطناعي التي تنفذ التعليمات البرمجية التي تم إنشاؤها أو تستدعي أدوات غير موثوقة.
توصي Google بالطرح التدريجي على ثلاث مراحل، كما هو موضح في المخطط بالنشر والتشغيل والإدارة. تغطي المرحلة الأولى عناصر التحكم الأساسية مثل تمكين معرف حمل العمل وتشغيل أحمال العمل الحساسة على العقد السرية. ينتقل الثاني إلى تعزيز الإنتاج من خلال سياسات الصور الموقعة وتجميع السجلات، ويقدم الثالث حواجز حماية على مستوى المؤسسة والاستجابة الآلية للحوادث. تشير تغطية SecurityBrief للإعلان إلى أن الإصدار يسلط الضوء على “كيفية قيام موفري الخدمات السحابية بتجميع البنية التحتية الحالية والهوية ومنتجات المراقبة في نماذج تشغيل خاصة بالذكاء الاصطناعي للعملاء الذين يقومون ببناء التطبيقات على الأنظمة الأساسية المُدارة.”
جوجل ليست وحدها في نشر هذا النوع من الإرشادات. اتخذت Amazon Web Services نهجًا متعدد الطبقات مماثلاً مع AWS AI Security Framework، وقامت بإقران ذلك بمبادرة مفتوحة المصدر تسمى AI on EKS والتي توفر مخططات Terraform لنشر أعباء عمل الذكاء الاصطناعي على خدمة Kubernetes المُدارة من Amazon. قامت AWS أيضًا بتوسيع نطاق اكتشاف تهديدات Amazon GuardDuty ليشمل مجموعات EKS، باستخدام وكيل eBPF المُدار لاكتشاف عمليات تسريب بيانات الاعتماد وعكس الأصداف مباشرة على مستوى بيانات Kubernetes، وفقًا لما ذكرته InfoQ في يونيو 2025.
نشر بائع الأمان ARMO نقدًا تفصيليًا للمكان الذي توقفت فيه أدوات AWS الأصلية عن كونها مفيدة لتهديدات الذكاء الاصطناعي المحددة. في دليل التنفيذ حول تأمين وكلاء الذكاء الاصطناعي على EKS، كتب يوسي بن نعيم، نائب رئيس إدارة المنتجات في ARMO، أن “أدوات AWS الأصلية تتعامل مع الهوية والتشفير وتسجيل مستوى التحكم بشكل جيد، لكنها تتوقف عند حدود عبء العمل، مما يترك نقطة عمياء بالضبط حيث تحدث تهديدات الذكاء الاصطناعي الوكيل: داخل حاوياتك، في وقت التشغيل، حيث يتخذ الوكلاء قرارات مستقلة حول الأدوات التي يجب الاتصال بها والبيانات التي يجب الوصول إليها.” الحجة المركزية لبن نعيم هي أن أدوات الهوية والتدقيق مثل أدوار IAM لحسابات الخدمة وتسجيل CloudTrail تجيب على أسئلة حول ما يُسمح للوكيل بالقيام به، ولكن ليس ما إذا كان الإجراء المسموح به طبيعيًا بالفعل لهذا الوكيل المحدد. وهو يقترح دورة من أربع مراحل لمراقبة سلوك الوكيل، وتقييم الفجوة بين الأذونات الممنوحة والمستخدمة، واكتشاف الانحرافات عن خط الأساس المحدد، وعندها فقط يتم فرض سياسة مشددة.
لقد تعاملت مايكروسوفت مع المشكلة من زاوية مختلفة، مع التركيز على هوية وسلوك عملاء الذكاء الاصطناعي أنفسهم بدلاً من منصة الحاوية الأساسية. تصف سلسلة Agent Factory الخاصة بها، والمستضافة على مدونة Azure، كيف يمنح Microsoft Entra Agent ID الوكلاء الفرديين بيانات اعتمادهم الخاصة وقصيرة الأجل، وكيف يتم استخدام الفريق الأحمر الآلي من خلال أداة تسمى PyRIT لاستكشاف نقاط الضعف لدى الوكلاء قبل الإصدار.
تشير مدونة Cloud Native Computing Foundation المنفصلة، والتي غطتها InfoQ في أبريل 2026، إلى نقطة تشمل جميع بائعي السحابة: يفهم Kubernetes نفسه التنسيق والعزل، لكنه ليس لديه مفهوم مدمج حول ما إذا كان يجب تنفيذ المطالبة أو أن الاستجابة تسرب معلومات حساسة، مما يعني أن عناصر التحكم التقليدية مثل التحكم في الوصول القائم على الدور وسياسات الشبكة تظل ضرورية ولكنها ليست كافية في حد ذاتها.
