تقييم مخاطر الذكاء الاصطناعي في تطبيقات الاطراف الخارجية

نُشر في — وقت القراءة 14 دقيقة تقريبًا

سنناقش في هذا المقال تقييم مخاطر الاطراف الخارجية المقدمة التطبيقات الذكاء الصناعي (TPRM AI) وسنركز في هذه المقالة على النقاط التالية

  1. البنية (Architecture): كيف تم بناء ونشر تطبيق الـ AI؟
  2. استخدام بيانات العملاء (Use of Customer Data): كيف تستخدم بيانات العميل (هل تستخدم للتدريب)؟
  3. الثغرات الأمنية السيبرانية (Cybersecurity Vulnerabilities): وش المخاطر السيبرانية الجديدة اللي يجيبها الـ AI؟
  4. بنية التطبيق (App Architecture): فهم بنية التطبيق من Input إلى Output وضوابطها
  5. خصوصية البيانات (Data Privacy): وش البيانات اللي ترسل وتخزن مع تطبيق الـ AI؟
  6. حوكمة الـ AI (AI Governance): وش هي عملية الذكاء الاصطناعي المسؤول (responsible AI)؟
  7. مخاطر النموذج (Model Risks): هل فيه خطر إن المخرجات تنتهك حقوق الملكية الفكرية (IP)؟

البنية (Architecture)

كيف يتم بناء تطبيق الذكاء الاصطناعي ونشره؟

البنية التحتية لتطبيق الذكاء الاصطناعي

في هذه المرحلة حنا نحاول نفهم البنية التحتية للـ AI عند المزود نحاول نعرف وش نوع serving layer و وش base model الي يستخدمه

بعض الاسئلة الي ممكن تساعدنا نفهم البنية التحتية للمزود:

وين تنشر الـ base models حقتك؟ (أين تستضاف النماذج الأساسية؟)

وش نوع ضوابط من الـ model serving layer مفعلة عندك؟

  • الحماية من الـ Jailbreak (كسر قيود النموذج)
  • الحماية من الـ Prompt injection (حقن الأوامر)
  • إخفاء البيانات الشخصية (PII redaction)

وش إجراءاتك لما تغيير النماذج الأساسية المستخدمة في الـ model serving layer؟ زي ما نعرف عندنا طبقتين الطبقة الاساسية (Base model) وطبقة (Serving) يعني المزود راح يعلمك وش serving layer حقة، بس مو ملزم انه يبلغك اذا غير Base model الي تكون تحت serving layer فهنا حنا نسأله عن وش الاجراء الي تسويها لما تغيير الـ Base model، هل راح تاخذ موافقتنا او هل راح تشعرنا بالموضوع ولا لما راح تقولنا ابد اذا غيرته؟

وتقدر تتعمق اكثر بالاسئلة بس هذا الحد الادنى الي لازم تعرفه.


استخدام بيانات العملاء (Use of Customer Data)

كيف يتم استخدام بيانات العملاء (على سبيل المثال تستخدم للتدريب)؟

اول شي لازم تعرف ان المزود بيحاول بكل الطرق انه ياخذ بيانات العميل (انت)، عشان يطور النماذج حقته، لان بكل بساطه هذي هي الطريقة الي يقدر يكسب فيها ميزة تنافسية، يكون عنده بيانات عملاء اكثر عشان يدرب عليها النماذج حقته وتطور.

بياناتنا مو سبهلله اي احد مسموح له ياخذها 😅

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

  • Train global models on your data
  • Training customized models on your data (for your use only)
  • Train on “anonymized” data
  • Train on “aggregated” data
  • Train on “non-proprietary” data
  • Live training with no data retention

Train global models on your data

تدريب النماذج العامة على بياناتك المنظمة A وB يستعملون نفس النموذج (Model v1)، وايضاً يتم تخزين بياناتهم في (org data)، ثم يتم التدريب model v1 على org data وينتج لنا نموذج جديد (fine-tuned(model v2)) متدرب على بيانات المنظمات A وB.

هذا ممكن يكون أسوأ سيناريو ممكن يصير لبياناتك. اول شي تتشارك بنفس النموذج مع منظمات اخرى. ثاني شي يتم تدريب النموذج الجديد على بياناتك و بيانات المنظمات الاخرى ويتم التبديل بين النماذج ليصبح النموذج الجديد هو الرئيسي.

يعني بياناتك الخاصة راح تكون جزء من النموذج الجديد والنموذج الجديد تقدر توصل له المنظمات الاخرى.

ابرز مثال: ChatGPT Plus و Claude Pro افتراضياً يتدربون على بياناتك،

النتيجة: هذه الحالة تعتبر غير مقبولة ولا يوجد اي سيناريو يشرعن أستخدام هذه الحاله في مؤسستك.

Training customized models on your data (for your use only)

تدريب نموذج مخصص على بياناتك في هذه الحالة الـ Base Model يأخذ بيانات Org B ويدمجها، مع بيانات Org A وينتج لنا نموذج مخصص فقط لـ Org A

فلنفترض انك انت المنظمة A في هذه الحالة انت تتشارك التطبيق مع المنظمات الاخرى ولكن انت لا تستعمل (Base Model) الذي يعتبر global model بل تستعمل نوذج خاص فيك و المنظمات الاخرى لا تستطيع ان ترى بياناتك ولا تستعمل النموذج الذي تستخدمه

هذه الحالة تعتبر مقبوله لمنظمة A ولا تشكل خطر ولكن بشرط ان يتعهد المورد بأن في حاله حذف حسابك او الغاء التعاقد يتم تحذف (Model for Org A) و (Org Data A)

ابرز مثال: Azure OpenAI Fine-tuning و AWS Bedrock Custom Models

النتيجة: مقبولة ولا تشكل خطر عليك، ما دام انت المتحكم في Data و تستعمل النموذج خاص فيك، وعندك صلاحية الحذف في حالة الانتهاء

Train on “anonymized” data

يتم “إخفاء هوية” بيانات العميل قبل تدريب النماذج. في هذه الحالة يصير المزود يحجب البيانات السرية في سياق الكلام قبل التدريب النموذج الجديد. إخفاء هوية البيانات قبل التدريب ولكن العيب هنا هو ان كيف المزود يعرف ان البيانات هذي سرية “وش منهجية Anonymized الي يستخدمها؟”

لان زي ما نشوف بالرسم حتى بعد Anonymized ضل في بيانات سرية

النتيجة: غير موصى بهذه الحالة إلا في حال الافصاح عن منهجية Anonymized وكانت متوافقه مع شروطكم

Train on “aggregated” data

التدريب على بيانات “مجمعة” يعني يتم تجميع بيانات العميل قبل التدريب و تحويلها إلى ملخص إحصائي لتدريب النموذج عليها. التدريب على بيانات مجمّعة

النتيجة: غالبا غير موصى به، وفريق TPRM لازم يوضح مع المورد منهجية التجميع (aggregation methodology) بالضبط قبل السماح فيه.

Train on “non-proprietary” data

يزعم المزود أن البيانات “غير المملوكة” فقط هي التي تستخدم لتدريب النماذج.

يقولك المزود ان فقط ادرب نماذجي على البيانات الغير مملوكة لك. البيانات الي غالباً تكون مملوكة للمؤسسة (الخطط و الاستراتيجيات و الاهداف). التدريب على بيانات غير مملوكة

النتيجة: غير موصى به. لان على اي اساس تحدد اذا البيانات مملوكة لي كمنظمة ولا لا وش طريقتك في تحديد الملكية !

Live training with no data retention

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

المزود يقولك انه ما يحفظ البياناتك فقط يدرب عليها النماذج حقته بشكل مباشر. وغالباً ما تستخدم هذه الحالة فقط عشان يقول “ترا انا ما اخزن بياناتك عندي” ولكن في الواقع هي تكون مخزنة في النموذج الجديد

يعني بأختصار يلعب عليك بخدعة تسويقية “انا ما احفظ بياناتك”

تدريب مباشر بدون الاحتفاظ بالبيانات

النتيجة: غير موصى به، وايضاً لا يوجد اي سناريو يشرعن هذه الحالة.

ملخص لانماط التدريب

الرقم نمط التدريب كيف يشتغل الخطر وصف الخطر القرار لبيانات جهة حكومية (NCA/PDPL)
1 Global models بياناتك تدخل نوذج مشترك يستفيد منه كل عملاء المورد حرج تسرب مخرجاتك لعملاء اخرين و تدرب في النموذج العام مرفوض قطعياً
2 Live training, no retention البيانات تدرب لحظة توليد الرد حرج فخ “ما نحتفظ” لكن المعلومة ولكن الحقيقة انها تحفظ في النموذج الجديد مرفوض قطعياً
3 Non-proprietary data المورد يدرب ما يصنفه هو “غير مملوك” عالي قرار التصنيف بيد المزود مرفوض عملياً
إلا لو التصنيف بيدك ومعيارك موثق تعاقدياً
4 Anonymized data حجب البيانات الخاصة قبل التدريب عالي طريقة الحجب بيد المزود مرفوض عملياً
إلا لو حجب حقيقي يستوفي PDPL
5 Aggregated data تحويل السجلات الفردية لملخصات إحصائية متوسط طريقة التجميع بيد المزود مشروط
يعتمد على منهجية التجميع
6 Customized model (for you only) Base model وبياناتك في نموذج مخصص ومعزول لك ضعيف العزل مدعى ويحتاج إثبات؛ حفظ للبيانات المدربة مقبول وشروط
بعزل مثبت و حذف مثبت

ثغرات الذكاء الاصطناعي في الأمن السيبراني (Cybersecurity AI Vulnerabilities)

من ابرز الجهات التي تصنف ثغرات الذكاء الاصطناعي هي OWASP Top 10 وهذي الثغرات التي اثبتت OWASP وجودها في اغلب نماذج الذكاء الاصطناعي OWASP Top 10 لثغرات نماذج اللغة الكبيرة

أبرز هذه الثغرات:

  • LLM01 – Prompt Injection (حقن الأوامر): المهاجم يتلاعب بمدخلات النموذج عشان يتجاوز التعليمات المفروضة عليه ويخليه يسوي أشياء مو مفترض يسويها، وهي أكثر ثغرة شيوعاً في نماذج اللغة.
  • LLM02 – Sensitive Information Disclosure (تسريب البيانات الحساسة): النموذج يكشف في مخرجاته بيانات سرية أو معلومات من بيانات تدريبه، وهذي خطيرة خصوصاً لما تكون البيانات خاصة بالمؤسسة.

بنية التطبيق (App Architecture)

تفكيك بنية تطبيق الذكاء الاصطناعي زي ما نشوف في عندنا اكثر من طبقه في الهيكل خلونا نخذها حبه حبه عشان نقدر نفهم.

مرحلة المدخلات - input level

  1. App-level input controls (accepted input types) هنا input نفسه في الـتطبيق ، وفيه ضوابط الخاصة بالتطبيق غالباً ما تكون هذي الضوابط خاصة بالملفات. على سبيل المثال: التطبيق يقبل بس ملفات PDF ولا يقبل اي نوع ثاني.

  2. Post-input sanitization (at app layer) هذي المرحلة قبل يروح للـ serving layer يتأكد فيها من البيانات ويفلترها مثلاً لو فيها PII يحجبها او يتأكد ان ما فيه اي ملف بأحجام عالية، إلى اخره من الضوابط.

  3. Serving Layer controls - input هنا input يوصل للـ serving layer إلى مستضيف الـ Model في هذه المرحلة الـ serving layer يتأكد من input انه متواقف مع الـ controls إلى هو حاطها ممكن تكون ضوابط على prompt injection او ضوابط اخرى على حسب serving provider

  4. Models-level controls هنا النموذج نفسه في ضوابط زي Bias mitigation، النموذج من الداخل فيه controls

مرحلة المخرجات - output level

  1. Serving Layer controls - output هنا ايضاً serving provider عنده ضوابط بعد ما يرد النموذج (URL redaction، Content filtering)
  2. Output Sanitization هنا التطبيق نفسه لازم يكون فيه ضوابط ايضاً على Output غالباً ما تكون (Profanity stripping، Format sanitization، Toxicity filtering)
  3. App-level output controls هنا ضوابط على انه كيف راح يعرض لك output هل لو كان في صور يعرضها لك في التطبيق او لا، هل يسمح بعرض الملفات داخل التطبيق ولا لازم تحمل الملفات

بعض الاسئلة لتحلل هيكل تطبيقات الذكاء الاصطناعي

  1. What controls do you have in place at the model serving layer to prevent prompt injection attacks?
  2. How do you evaluate base models for jailbreaks and other attacks?
  3. How do you determine permissible actions for agents to take and control the range of inputs and outputs for any tool usage?
  4. What protections do you have in place to mitigate unsafe output handling (e.g. Markdown image and hyperlink rendering)?
  5. How do you mitigate the risk of potentially dangerous input (e.g. hidden text or encodings)?

خصوصية البيانات (Data Privacy)

الخطر في هذه المرحلة يكون حول تخزين (Retention) البيانات. بطبيعة الحال انت لما تتعاقد مع جهة عشان توفر لك حلول لذكاء الاصطناعي راح تتواصل مع الذكاء هذا واحتمال الموظفين يرسلون لها بعض البيانات السرية الخاصة بالمؤسسة، واكيد جزء من هذي البيانات راح يكون سري و خاص وراح ترسل البيانات عبر Prompts تستقبل Completions / Outputs

الفكرة الجوهرية هي و Prompts و Completions / Outputs وين تخزن (Retention)؟ تدفق البيانات وخصوصيتها في التطبيق زي ما نشوف في الرسم السابق ان App لتواصل مع اكثر من اداه

  • Monitoring Tool
  • Third Party Tools
  • Vector Databases بعض المزودين راح يقولون لك حنا نخزن بياناتك على شكل “embeddings” يعني لا تخاف، كل النصوص بالنهاية راح تتحول إلى أرقام ما تفهم اصلاً. تمثيل البيانات على شكل embeddings بس الحقيقة ان embeddings data اثبت انه تقدر تسوي لها inverted وتستخرج النصوص الاصلية منها. المصدر : Transferable Embedding Inversion Attack

النتيجة: لازم تعرف Prompts و Completions / Outputs وين تخزن ووين تروح بالضبط، لان ممكن يكون app يرسلها إلى جهة غير موثوقة وهو اصلاً مو قاصد بس عشان يسوي مهمه معينه

بعض الاسئلة لتفهم خصوصية البيانات

  1. What is your retention policy for prompts and completions?
  2. Do you have a zero-data retention agreement with your third party model providers for all prompts and completions?
  3. Do you have protections in place against embedding inversion attacks?
  4. Do you store any version of prompts and completions, including anonymized, aggregated, or de-identified data? … and many more depending on the application

حوكمة الـ AI (AI Governance)

لازم نفهم الحوكمة الداخلية للمزود عشان انت لما تشتري من مزود خدمه AI انت و بس تشتري الخدمه انت تشتري ايضاً المخاطر الي تجي معها وعشان كذا مهم تفهم الحوكمة الداخلية له وهل خدمته متوافقة مع متطلبات NCA و SDAIA ولا لا

لو الحوكمة عند المزود ضعيفة فأنت الي راح تدفع الثمن لانك ما تحققت

بعض الاسئلة لتفهم الحوكمة عند المزود

  • وش الضوابط الي عندكم؟
  • من الي يقوم بتغيير النموذج؟
  • كيف تعدلون ضابط معين ومن المسؤول عن الضوابط عندكم؟
  • كيف تضمنون قابلية تفسير المخرجات (explainability
  • كيف تحددون أي القرارات تحتاج تدخل بشري (human in the loop
  • كيف تختبرون وتراقبون النوذج ضد التحيز (bias) و من المسؤول عنها؟
  • هل تلتزمون بمبادئ SDAIA لأخلاقيات الذكاء الاصطناعي؟
  • إلخ…

مخاطر النموذج (Model Risks)

مخاطر مستوى النموذج تتعلق بالمخاطر الكامنة في النوذج نفسه، أو طريقة نشره (deployment)، أو طريقة تدريبه (training).

هنا نحاول نفهم المخاطر الي تجي مع النموذج نفسه مو بس مع التطبيق

  • كيف تضمنون إن بيانات تدريب النموذج ما تنتهك ملكية فكرية (IP) معروفة، بحيث تطلع مخرجات النموذج منتهكة للـ IP؟
  • هل تسوّون red-teaming لنماذجكم؟ وش الهجمات والمخاطر اللي تغطّونها؟
  • كيف تقيسون دقة النموذج (benchmark) تحديداً للمهام اللي تطبيقكم/الـ agent مصمم ينجزها؟ وش الـ benchmarks اللي تستخدمونها؟
  • كيف تخففون أنتم أو مزود الـ serving مخاطر هجمات model denial of service؟
  • هل عندكم الية توفر مراقبة للنوذج (model observability