أمن الذكاء الاصطناعي المولّد: مقدمة لمصفوفة تقييم المخاطر الأمنية

استحوذ الذكاء الاصطناعي المولّد في السنوات الأخيرة على اهتمام المؤسسات الخاصّة والعامّة حول العالم، وهو بصدد إحداث تحوُّلٍ جذريٍّ في تجربة العملاء عبر مختلف القطاعات والصناعات. هذه النقلة النوعية في قدرات الذكاء الاصطناعي، والتي عزَّزتها النماذج اللغوية الكبيرة (LLMs) – Large Language Models – ذات المعايير المليارية و المبنيّة من الشبكات العصبية العميقة من نوعيّة المُحوّل – Transformer، فتحت آفاقاً جديدة لتحسين الإنتاجية وتعزيز القدرات الإبداعية في مُختلف المجالات.

ومع توجه المؤسسات نحو تبنّي الذكاء الاصطناعي المولّد لخدمة موظفيها وعملائها، بات لزاماً على المختصين في الأمن السيبراني تقييم المخاطر ووضع أطر الحوكمة والضوابط اللازمة لهذه التقنية سريعة التطوّر. ومن منطلق خبرات القادة الأمنيين في Amazon Web Services (AWS) الذين يعملون مع كبرى المؤسسات وأكثرها تعقيداً ، والذين تتم استشارتهم بانتظام حول التوجهات التقنيّة وأفضل الممارسات والتطورات المتسارعة في مجال الذكاء الاصطناعي المولّد وما يرتبط به من تحديات أمنية وخصوصية، نود مشاركتكم الاستراتيجيات الرئيسية التي تمكنكم من أخذ القرارات المُناسبة في رحلتكم نحو تأمين الذكاء الاصطناعي المولّد.

يُعدّ هذا المقال الأول ضمن سلسلة مقالات حول أمن الذكاء الاصطناعي المولّد، حيث نقدم إطاراً منهجياً يساعدكم في التعامل مع الجوانب الأمنية والمخاطر المحتملة وفقاً لنوع التطبيق الذي تعتزمون نشره. كما نسلط الضوء على أهم الاعتبارات التي ينبغي على القادة والمختصين الأمنيين مراعاتها عند تأمين تطبيقات الذكاء الاصطناعي المولّد. وستتناول المقالات القادمة بالتفصيل كيفية تطوير حلول تلبي المتطلبات الأمنية للعملاء، وأفضل ممارسات نمذجة التهديدات، وسبل تقييم متطلبات الامتثال والخصوصية – compliance & privacy، إضافة إلى استكشاف طرق توظيف الذكاء الاصطناعي المولّد لتحسين عمليّاتكم الأمنية.

من أين تبدأ؟

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

قد تظن، إذا كنت في بداية رحلة استكشاف الذكاء الاصطناعي المولّد أو تبنّيه، أنه يتطلب تخصصاً أمنياً جديداً كلياً. ولكن الخبر السار أنه رغم وجود اعتبارات أمنية خاصة، فإن تطبيقات الذكاء الاصطناعي المولّد هي في جوهرها مجرد أعباء حَوسبية تعتمد على البيانات، وتخضع لمعظم المتطلبات الأمنية التقليدية. فإن كنت قد استثمرت في أفضل ممارسات الأمن السيبراني السحابي على مرّ السنين، واتبعت الإرشادات من مصادر مثل نصائح ستيف ال10 لتحسين أمن حساب AWS الخاص بك، وركيزة الأمن في إطار عمل التصميم الجيّد، والتصميم الجيّد من منظور التعلّم الآلي ، فأنت تسير بالفعل على الطريق الصحيح!

تظل التخصصات الأمنية الأساسية مثل إدارة الهويات والصلاحيات – identity and access management، وحماية البيانات، والخصوصية والامتثال، وأمن التطبيقات، ونمذجة التهديدات، ذات أهميّة حيوية لتطبيقات الذكاء الاصطناعي المولّد، تماماً كما هي لأي تطبيق آخر. فعلى سبيل المثال، إذا كان تطبيق الذكاء الاصطناعي المولّد يتعامل مع قاعدة بيانات، فستحتاج إلى معرفة تصنيف بياناتها، وكيفية حمايتها، ومراقبة تهديداتها، وإدارة الوصول إليها. ومع أهمية الالتزام بممارسات الأمن المعتمدة، من الضروري أيضاً فهم المخاطر الفريدة والاعتبارات الأمنية الإضافية التي تفرضها تطبيقات الذكاء الاصطناعي المولّد. يستعرض هذا المقال العديد من العوامل الأمنية، سواءً الجديدة منها أو المعروفة، التي يجب أخذها في الاعتبار.

والآن، دعونا نناقش الخطوة الأولى وهي تحديد النطاق.

تحديد النطاق

لنفترض أنّ مؤسستك اتخذت قراراً بتبني حلّ للذكاء الاصطناعي المولّد، فما هي خطواتك التالية كمسؤول أو مختص في الأمن السيبراني؟ كما هو الحال مع أي مشروع أمني، عليك أولاً فهم نطاق المهمة الأمنية الموكلة إليك. وبناءً على متطلبات استخدام الحلّ في المؤسسة، قد تختار خدمة مُدارة يتولى فيها مزود الخدمة الجزء الأكبر من مسؤولية إدارة الخدمة والنموذج، أو قد تفضل بناء خدمتك ونموذجك الخاص.

دعونا نستعرض كيفية استخدام حلول الذكاء الاصطناعي المولّد المختلفة في سحابة AWS. في AWS، يُعدّ الأمن أولوية قصوى، ونؤمن بأهمية تزويد العملاء بالأدوات المناسبة لاحتياجاتهم. فعلى سبيل المثال، يمكنك استخدام Amazon Bedrock الذي يعمل بدون خوادم – serverless – ويتمّ استخدامه عبر واجهات برمجة التطبيقات، حيث يوفر نماذج أساس (FMs) Foundation Models – جاهزة للاستخدام ومدربة مسبقاً من شركات AI21 Labs وAnthropic وCohere وMeta وstability.ai وبالإضافة إلى نماذج Amazon الخاصة Amazon Titan و Amazon Nova. كما يوفر Amazon SageMaker JumpStart مرونة إضافية مع إمكانية استخدام نماذج الأساس مفتوحة المصدر المدرّبة مسبقاً، مما يساعدك على تسريع رحلتك في مجال الذكاء الاصطناعي بشكل آمن. كما يمكنك بناء وتدريب نماذجك الخاصة باستخدام Amazon SageMaker. وقد تخطط لاستخدام تطبيق ذكاء اصطناعي مولّد موجه للمستخدمين من خلال واجهة ويب أو واجهة برمجة تطبيقات، مثل روبوت الدردشة أو ميزات الذكاء الاصطناعي المولّد المدمجة في تطبيق تجاري قامت مؤسستك بشرائه. لكل من هذه الخدمات بنية تحتية وبرمجيات وأذونات وصول مُعيّنة ونماذج بيانات مختلفة، وبالتالي متطلبات أمنية متباينة. ولتسهيل التعامل مع هذه الخدمات، قمنا بتصنيفها في مجموعات منطقية أطلقنا عليها اسم النطاقات – scopes.

ولتبسيط جهود تحديد النطاق الأمني، قمنا بتطوير مصفوفة تلخص التخصصات الأمنية الرئيسية التي يجب مراعاتها، وفقاً لحل الذكاء الاصطناعي المولّد الذي تختاره. أطلقنا على هذه المصفوفة اسم مصفوفة تحديد نطاق أمن الذكاء الاصطناعي المولّد – Generative AI Security Scoping Matrix، كما هو موضح في الشكل 1.

الخطوة الأولى هي تحديد النطاق الذي تندرج تحته حالة استخدامك. تم تقسيم النطاقات من 1 إلى 5، حيث يتدرج مستوى المسؤولية من الأقل إلى الأعلى، وهي كالآتي:

شراء الذكاء الاصطناعي المولّد – Buying generative AI:

• النطاق 1: تطبيقات المستخدم النهائي – Consumer app – تستخدم مؤسستك خدمة ذكاء اصطناعي مولّد عامة من طرف ثالث مزوّد للخدمة، سواء كانت مجانية أو مدفوعة. في هذا النطاق، لا تملك حق الاطلاع على بيانات التدريب أو النموذج، ولا يمكنك تعديله أو تحسينه. يقتصر دورك على استخدام واجهات برمجة التطبيقات أو التطبيق مباشرة وفقاً لشروط الخدمة المقدمة.
  مثال: يتفاعل موظف مع تطبيق محادثة ذكي لتوليد أفكار لحملة تسويقية قادمة.
• النطاق 2: تطبيقات الشركات – Enterprise app – تستخدم مؤسستك تطبيقاً مؤسسياً من طرف ثالث مدمجاً به ميزات الذكاء الاصطناعي المولّد، مع وجود علاقة تجارية رسمية بين مؤسستك والشركة المزودة.
  مثال: استخدام تطبيق جدولة مؤسسي من مُزوّد ما يتضمن قدرات ذكاء اصطناعي مولّد لصياغة جداول أعمال الاجتماعات.

تطوير الذكاء الاصطناعي المولّد – Building generative AI:

• النطاق 3: النماذج الجاهزة – Pre-trained models – تقوم مؤسستك ببناء تطبيقها الخاص باستخدام نموذج أساس جاهز، مُدرّب مُسبقًا، للذكاء الاصطناعي المولّد من مزوِّد ما. يتم دمجه مباشرة مع تطبيقاتك من خلال واجهات برمجة التطبيقات (API).
  مثال: بناء تطبيق روبوت محادثة لدعم العملاء يستخدم نموذج الأساس Anthropic Claude عبر واجهات برمجة تطبيقات Amazon Bedrock.
• النطاق 4: النماذج المحسّنة – Fine-tuned models – تقوم مؤسستك بتحسين نموذج أساس جاهز للذكاء الاصطناعي المولّد عن طريق إعادة تدريبه باستخدام بيانات خاصة بعملك، مما ينتج نموذجاً محسناً مخصصاً لاحتياجاتك.
  مثال: استخدام واجهات برمجة التطبيقات للوصول إلى نموذج أساس لبناء تطبيق يمكّن فرق التسويق من إنشاء محتوى تسويقي خاص بمنتجاتك وخدماتك.
• النطاق 5: النماذج المطوّرة داخلياً – Self-trained models – تقوم مؤسستك ببناء وتدريب نموذج ذكاء اصطناعي مولّد من الصفر باستخدام بيانات تملكها أو تحصل عليها. تمتلك المؤسسة كافة جوانب النموذج.
  مثال: رغبة مؤسستك في إنشاء نموذج مدرب حصرياً على بيانات متخصصة في مجال معين لترخيصه للشركات العاملة في نفس المجال، ممّا يؤدي إلى إنشاء نموذج لغوي متقدم جديد كلياً.

في مصفوفة تحديد نطاق أمن الذكاء الاصطناعي المولّد – Generative AI Security Scoping Matrix، نحدد خمسة مجالات أمنية تغطي مختلف أنواع حلول الذكاء الاصطناعي المولّد. تختلف متطلبات كل مجال أمني حسب نطاق تطبيق الذكاء الاصطناعي المولّد. من خلال تحديد نطاق التطبيق، يمكن لفرق الأمن تحديد الأولويات وتقييم نطاق كل مجال أمني بكفاءة.

دعونا نستعرض كل مجال أمني ونتعرف على تأثير تحديد نطاق التطبيق على المتطلبات الأمنية:

• الحَوكمة والامتثال – Governance and compliance – السياسات والإجراءات والتقارير اللاّزمة لتمكين المؤسسة من استخراج قيمة مُضافة مع تقليل المخاطر.
• الجوانب القانونية والخصوصية – Legal and privacy – المتطلبات التنظيمية والقانونية وضوابط الخصوصية المتعلقة باستخدام أو إنشاء حلول الذكاء الاصطناعي المولّد.
• إدارة المخاطر – Risk management – تحديد التهديدات المحتملة وإجراءات التخفيف الموصى بها.
• الضوابط الأمنية – Controls – تطبيق الإجراءات الأمنية اللاّزمة للحد من المخاطر.
• المرونة – Resilience – تصميم حلول الذكاء الاصطناعي المولّد بما يضمن استمرارية الخدمة وتلبية متطلبات مستوى الخدمة.

خلال سلسلة مدوناتنا حول أمن الذكاء الاصطناعي المولّد – Securing Generative AI، سنستند إلى مصفوفة تحديد نطاق أمن الذكاء الاصطناعي المولّد لمساعدتك في فهم كيفية تغيّر المتطلبات. نشجعك على تبنّي واستخدام هذه المصفوفة في عملياتك الداخلية الخاصة، بما في ذلك عمليّات الشراء و تقييم الخيارات وتحديد نطاق الهندسة الأمنية للحلول.

تحديد الأولويات الرئيسية

بعد تحديد نطاق العمل، تحتاج إلى اختيار الحلول المُناسبة لتمكين مؤسستك من الاستفادة منها بسرعة وأمان. دعونا نستعرض أهم الأولويات التي يجب التركيز عليها عند الاختيار.

الحَوكمة والامتثال والجوانب القانونية والخصوصية

في النطاقين الأول والثاني (تطبيقات المستخدم النهائي وتطبيقات الشركات)، يجب إيلاء اهتمام خاص لشروط الخدمة، والترخيص، وسيادة البيانات، والإفصاحات القانونية الأخرى. حدد المتطلبات المهمة لإدارة البيانات في مؤسستك، وتأكد من العمل عن كثب مع الأقسام القانونية وقسم المشتريات إن وُجدت. قيّم كيفية تطبيق هذه المتطلبات على تطبيقات النطاق الأول والثاني.

تُعد حوكمة البيانات عنصراً أساسياً، ويمكن الاستفادة من استراتيجيات الحَوكمة القائمة وتوسيع نطاقها لتشمل تطبيقات الذكاء الاصطناعي المولّد. حدد مستوى تقبّل المخاطر في مؤسستك والوضع الأمني المنشود لتطبيقات النطاق الأول والثاني، ثم ضع السياسات التي تحدد أنواع وتصنيفات البيانات المسموح باستخدامها. على سبيل المثال، قد تضع سياسة تمنع استخدام المعلومات الشخصية المُعرِّفة (PII) – Personally Identifiable Information أو البيانات السرية أو الملكيّة الفكرية عند استخدام تطبيقات النطاق الأول.

إذا كان النموذج المقدم من مُزوِّد ما يُلبّي جميع احتياجاتك من البيانات والوظائف، فقد تكون تطبيقات النطاقين الأول والثاني مناسبة لك. أما إذا كنت بحاجة إلى تلخيص وتحليل بيانات مؤسستك الخاصة، وتوليد رؤى جديدة، أو أتمتة المهام المتكررة، فستحتاج إلى تطبيق من النطاق الثالث أو الرابع أو الخامس.

على سبيل المثال، قد تختار مؤسستك استخدام نموذج مُدرَّب مسبقاً (النطاق الثالث). وقد ترغب في الذهاب خطوة أبعد بإنشاء نسخة معدّلة من نموذج طرف ثالث مثل Amazon Titan أو Amazon Nova مع دمج بيانات مؤسستك، وهو ما يُعرف بـالضبط الدقيق أو تخصيص النموذج والذّي يُنتج نموذجًا مُحسّنًا (النطاق الرابع). أو قد تقرر إنشاء نموذج جديد كلياً من الصفر، مُدرَّب على بياناتك الخاصة (النطاق الخامس).

في النطاقات الثالث والرابع والخامس، يمكن توظيف بياناتك في ثلاث مراحل: تدريب النموذج، أو ضبطه، أو كجزء من مخرجاته. وهذا يستدعي فهماً دقيقاً لتصنيف وطبيعة البيانات التي سيُتاح للنظام الوصول إليها. وفي النطاق الثالث تحديداً، يمكنك الاستفادة من تقنية التوليد المُعزّز بالاسترجاع – Retrieval Augmented Generation (RAG) التي تتيح للنموذج البحث واسترجاع المعلومات المناسبة من قواعد بيانات مؤسستك بشكل ذكي وتوظيفها في تحسين مُخرجات النموذج، وذلك باستخدام وكلاء Amazon Bedrock على سبيل المثال كوسيط لتغذية النموذج بالمدخلات المناسبة. بهذه الطريقة، يُوفّر RAG بديلاً عن التدريب والضبط الدقيق من خلال الاستعلام عن البيانات المُناسبة وإضافتها كجزء من السياق – context – ضمن الأمر – prompt – المُرسل إلى النموذج. هذا يتيح للنموذج اللغوي الكبير (LLM) تقديم إجابات تستفيد من بيانات مؤسستك دون الحاجة إلى تضمينها مباشرة في النموذج نفسه. يوضح الشكل 3 مثالاً على كيفية استخدام بيانات العملاء في عملية التوليد والاستجابة باستخدام RAG.

أما في النطاقين الرابع والخامس، فيجب تصنيف النموذج المُعدّل وفقاً لأعلى مستوى حساسية موجود في البيانات المستخدمة في تدريبه أو ضبطه. فعلى سبيل المثال، إذا استخدمت معلومات شخصية مُعرِّفة (PII) في تدريب النموذج، فسيحتوي النموذج الجديد على هذه المعلومات الحساسة. ومن المهم الإشارة إلى أنّه لا تتوفر حالياً آليات سهلة لتصفية مخرجات النموذج بناءً على صلاحيات الولوج إلى البيانات، ممّا قد يتيح للمستخدم استرجاع بيانات لا يُفترض أن يصل إليها.

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

الجوانب القانونية والخصوصية

من المنظور القانوني، من الضروري فهم اتفاقية ترخيص المستخدم النهائي (End-User License Agreement – EULA) وشروط الخدمة (Terms of Services – TOS) وأي اتفاقيات تعاقدية أخرى لازمة لاستخدام الخدمة في النطاقات من الأول إلى الرابع. أما في النطاق الخامس، فيجب أن يقوم فريقك القانوني بوضع شروط الخدمة الخاصة بك لأي استخدام خارجي لنماذجك.

وبالنسبة للنطاقين الثالث والرابع، تأكد من مراجعة الشروط القانونية لكل من مزود الخدمة ومزود النموذج. كما يجب إيلاء اهتمام خاص لمتطلبات الخصوصية، وخاصة متطلبات “الحق في المحو” أو “الحق في النسيان” المنصوص عليها في اللائحة العامة لحماية البيانات (GDPR) للاتحاد الأوروبي إذا كانت تنطبق على مؤسستك. ادرس بعناية تبعات تدريب النماذج أو ضبطها باستخدام بيانات قد تضطر لحذفها بناءً على طلب المستخدمين. واعلم أن الطريقة الوحيدة الفعّالة لإزالة البيانات من النموذج بشكل كامل هي حذفها من مجموعة التدريب وإعادة تدريب النموذج من جديد – وهو إجراء قد يكون غير عملي وباهظ التكلفة، خاصة عندما تشكل البيانات المطلوب حذفها جزءاً صغيراً من مجموع بيانات التدريب، أو عندما يكون النموذج كبير الحجم.

إدارة المخاطر

رغم أن التطبيقات المعتمدة على الذكاء الاصطناعي قد تبدو وتعمل مثل التطبيقات التقليدية، إلاّ أنّ الطبيعة المرنة للتفاعل مع نماذج اللغة الكبيرة (LLM) تتطلب مستوىً إضافياً من الفحص والضوابط الوقائية. لذا من الضروري تحديد المخاطر المرتبطة بتطبيقات الذكاء الاصطناعي المولّد وكيفية الحد منها.

تتعدد طرق تحديد المخاطر، لكن أشهرها آليتان: تقييم المخاطر – Risk Assessment – ونمذجة التهديدات – Threat Modeling. في النطاقين الأول والثاني، يتمحور دورك حول تقييم مخاطر مزودي الخدمات الخارجيين لفهم المخاطر المحتملة في خدماتهم، وكيفية إدارتهم للمخاطر التي تقع ضمن مسؤولياتهم. كما يجب عليك أيضاً فهم مسؤولياتك في إدارة المخاطر كمستخدم لهذه الخدمات.

أما في النطاقات الثالث والرابع والخامس – حيث يتم تنفيذ نمذجة التهديدات – فسنتناول في مقال لاحق التهديدات المحددة وكيفية نمذجتها في سياق تطبيقات الذكاء الاصطناعي المولّد بشكل مفصّل. لكن دعونا نستعرض مثالاً على تهديد فريد يواجه نماذج اللغة الكبيرة: قد يلجأ المهاجمون إلى تقنية تُعرف باسم حقن الأوامر (prompt injection)، وهي عبارة عن مدخلات مصمّمة بعناية لدفع النموذج اللغوي الكبير للاستجابة بطرق غير متوقعة أو غير مرغوب فيها. يمكن استغلال هذا التهديد لاستخراج خصائص النموذج (وهي السمات المميزة للبيانات المستخدمة في تدريب النموذج)، أو التشهير، أو اختراق الأنظمة الداخلية، وغير ذلك. وقد أصدرت، في الأشهر الأخيرة، كل من NIST وMITRE وOWASP إرشادات خاصة بتأمين حلول الذكاء الاصطناعي ونماذج اللغة الكبيرة. حيث صنّفت كل من MITRE وOWASP حقن الأوامر (أو تجاوز النموذج) كأول التهديدات في قوائمها. ورغم أن تهديدات حقن الأوامر قد تبدو جديدة، إلا أنها مألوفة لخبراء الأمن السيبراني، فهي في جوهرها تَطوّر لهجمات الحقن التقليدية مثل حقن SQL وحقن JSON/XML وحقن سطر الأوامر – command injection.

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

الضوابط

تمكّننا الضوابط الأمنية من تطبيق متطلبات الامتثال – compliance – والسياسات والأمن للحد من المخاطر. ولنتناول مثالاً مهماً على هذه الضوابط وهو إدارة الهويات والصلاحيات – identity and access management. فخلال عملية التوليد (أي إنتاج النموذج للمخرجات بناءً على المدخلات)، تكون نماذج الأساس – سواء من الطرف الأول، كالنماذج المُدرّبة في مؤسستك أو من طرف ثالث ،كالنماذج الجاهزة من مُزوّد ما، (النطاقات 3-5) – غير قابلة للتعديل. فواجهة برمجة التطبيقات (API) للنموذج تستقبل المدخلات وتُرجع المخرجات فقط. وبمجرد إصدار النماذج، تصبح ثابتة لا تتغير. فالنموذج بحد ذاته لا يستطيع تخزين بيانات جديدة أو تعديل نتائجه مع مرور الوقت أو دمج مصادر بيانات خارجية مباشرة دون تدخل من أنظمة معالجة البيانات الخارجية.

تتشارك قواعد البيانات الحديثة ونماذج الأساس في مفهوم استخدام هوية الكيان الذي يقوم بالاستعلام. لكن بينما تتيح قواعد البيانات التقليدية تطبيق ضوابط أمنية على مستويات متعددة (الجدول، الصف، العمود، أو حتى العنصر)، لا تسمح نماذج الأساس حالياً بالتحكم الدقيق في الوصول إلى التضمينات (embeddings) المحددة التي تحتويها. في النماذج اللغوية الكبيرة، التضمينات هي تمثيلات رياضية يُنشئها النموذج أثناء التدريب لتمثيل العناصر المختلفة – كالكلمات والأصوات والصور – ووصف سياقها وعلاقاتها بالعناصر الأخرى. فإما أن يُمنح الكيان حق الوصول الكامل للنموذج ومُخرجاته، أو لا يُمنح أي وصول على الإطلاق. فلا يمكن تقييد الوصول على مستوى التضمينات المحددة في قاعدة بيانات المتجهات – vector database. وبعبارة أخرى، في ظل التقنيات الحالية، عندما تمنح كياناً ما حق الوصول المباشر إلى نموذج، فإنك تمنحه تلقائياً حق الوصول إلى جميع البيانات التي تدرب عليها النموذج. وعند الوصول، تتدفق المعلومات في اتجاهين: من المستخدم إلى النموذج (الأوامر والسياقات)، ومن النموذج إلى المستخدم (الاستجابات المُولّدة من النموذج). وعند التصريح بالوصول إلى نموذج، فإنك تصرح ضمنياً بكلا الاتجاهين، وقد يحتوي أي منهما على بيانات سريّة.

على سبيل المثال، لنفترض أن مؤسستك طورت تطبيقاً على Amazon Bedrock في النطاق الرابع (حيث قمت بتحسين نموذج أساس) أو النطاق الخامس (حيث قمت بتدريب نموذج على بياناتك الخاصة). تمنح سياسة AWS Identity and Access Management (IAM) تطبيقك صلاحيات استدعاء نموذج معين، لكنها لا تستطيع تقييد الوصول إلى مجموعات فرعية من البيانات داخل النموذج. فعند التفاعل المباشر مع النموذج، يقتصر دور IAM على التحكم في الوصول إلى النموذج ككل:

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "AllowInference",
        "Effect": "Allow",
        "Action": ["bedrock:InvokeModel"],
        "Resource": "arn:aws:bedrock:*::*<foundation-model>*/*<model-id-of-model-to-allow>*"
    }
}

كيف يمكن تطبيق مبدأ أقل الصلاحيات – least privilege – في هذه الحالة؟ في معظم السيناريوهات، يقوم التطبيق باستدعاء نقطة وصول Endpoint على Amazon Bedrock للتفاعل مع النموذج. ويمكن للتطبيق استخدام حلول إدارة الهوية مثل Amazon Cognito أو AWS IAM Identity Center للمصادقة وتفويض المستخدمين – authenticate and authorize، وتقييد الإجراءات والوصول إلى البيانات وفقاً للأدوار والسمات ومجموعات المستخدمين. فمثلاً، يمكن للتطبيق اختيار النموذج المناسب بناءً على صلاحيات المستخدم.

كما يمكن للتطبيق استخدام تقنية RAG للاستعلام من مصادر بيانات خارج النموذج وتوفير السياق المناسب لاستجابات الذكاء الاصطناعي المولّد، وذلك باستخدام خدمات مثل Amazon Kendra أو Amazon OpenSearch Serverless. وفي هذه الحالة، تُستخدم طبقة تفويض لتصفية الوصول إلى المحتوى بناءً على دور المستخدم وصلاحياته. وكما نرى، فإن مبادئ إدارة الهويات والصلاحيات تظل كما هي في التطبيقات الأخرى التقليدية، مع ضرورة مراعاة الخصائص والاعتبارات المعمارية الفريدة لتطبيقات الذكاء الاصطناعي المولّد.

المرونة – Resilience

يُعد التوافر – availability – عنصراً أساسياً في الأمن كما يؤكد ثالوث C.I.A، لذا فإن بناء تطبيقات مرنة أمر ضروري لتلبية متطلبات التوافر واستمرارية الأعمال. في النطاقين الأوّل والثاني، يجب التأكد من توافق مستوى توافر مزود الخدمة مع احتياجات مؤسستك وتوقعاتها. وينبغي دراسة تأثير انقطاع الخدمة – سواء في نموذج الأساس أو واجهة برمجة التطبيقات أو طبقة العرض – على سير العمل. كما يجب مراعاة تأثير الاستعلامات المعقدة على حصص الاستخدام والتكاليف المترتبة على التطبيق.

أما في النطاقات الثالث والرابع والخامس، فيجب ضبط المُهل الزمنية المناسبة للتعامل مع الاستعلامات والإجابات المعقدة، مع مراعاة حدود الرموز المسموح بها في النموذج. كما ينبغي تطبيق أفضل ممارسات التصميم المرن مثل التراجع وإعادة المحاولة – backoff and retries ونمط قاطع الدائرة – circuit breaker patterns لتحسين تجربة المستخدم. وعند استخدام قواعد بيانات المتجهات، يُنصح بتبني تصميم عالي التوافر مع خطة للتعافي من الكوارث للتعامل مع مختلف أنماط الفشل.

تُعد مرونة الخوادم المُستخدمة في عمليات التوليد والتدريب من الاعتبارات المعمارية المهمة، إضافة إلى إمكانية حجز موارد الحَوسبة مسبقاً للعمليات الحساسة. وعند استخدام خدمات مُدارة مثل Amazon Bedrock أو SageMaker، يجب التحقق من توافر – availability – مناطق AWS الجُغرافية المنُاسبة لمؤسستك وتكافؤ الميزات بين المناطق عند تنفيذ استراتيجية نشر متعددة المناطق – multi-region deployment. كما يجب، في النطاقين الرابع والخامس، مراعاة توافر بيانات التحسين والتدريب عبر المناطق المختلفة. وإذا كنت تستخدم SageMaker لتدريب نموذج في النطاق الخامس، فاحرص على استخدام تقنية الحفظ الدوري لنقاط التدقيق – checkpoints لحفظ التقدم أثناء التدريب، مما يتيح استئناف العملية من آخر نقطة تدقيق عند الحاجة.

تأكد من مراجعة وتطبيق أفضل ممارسات المرونة المعتمدة في مركز المرونة في AWS وفي ركيزة الموثوقية – Reliability Pillar وركيزة التميُّز التشغيلي – Operational Excellence Pillar ضمن إطار عمل التصميم الجيّد – AWS Well-Architected Framework.

الخاتمة

استعرضنا في هذا المقال كيف تُشكّل مبادئ أمن السحابة – Cloud Security– الراسخة أساساً متيناً لتأمين حلول الذكاء الاصطناعي المولّد. ورغم اعتمادنا على العديد من ممارسات وأنماط الأمن القائمة، إلا أنه من الضروري الإلمام بأساسيات الذكاء الاصطناعي المولّد وفهم تهديداته الفريدة ومتطلباته الأمنية الخاصة.

نوصي باستخدام مصفوفة تحديد نطاق أمن الذكاء الاصطناعي المولّد – Generative AI Security Scoping Matrix – لمساعدتكم في تحديد نطاق تطبيقاتكم وما يرتبط بها من أبعاد أمنية. وبمجرد تحديد النطاق المناسب، يمكنكم البدء في معالجة المتطلبات شديدة الأهمية – Critical Security Requirements – لضمان الاستخدام الآمن لتطبيقات الذكاء الاصطناعي المولّد في مؤسستكم.

ندعوكم لمتابعة سلسلة مقالاتنا حول تأمين الذكاء الاصطناعي المولّد – Securing Generative AI، حيث سنواصل استكشاف المزيد من الجوانب الأمنية المهمة في هذا المجال.

للتعليق على هذا المقال، يرجى استخدام قسم التعليقات أدناه. وإذا كانت لديكم أية استفسارات، يمكنكم التواصل مع جهات الدعم في AWS المعتادة الخاصة بك.

لمتابعة آخر مستجدات أمن AWS، تابعونا على تويتر.

بتصرّف عن المقالة الاصلية