نشرت شركة خدمات مهنية مساعدًا للذكاء الاصطناعي من مورّد متخصص، وهو منتج يساعد محلليها على صياغة التقارير البحثية وتلخيص المستندات وإعداد المراسلات مع العملاء. وقد قُيّم منتج المورّد عبر عملية التقييم المعيارية للمورّدين لدى الشركة: إذ قدّم المورّد إجاباته على الاستبيان الأمني، وأكّد امتثاله لـ SOC 2، والتزم في اتفاقية معالجة البيانات بالإرسال المشفّر وعدم الاحتفاظ بالبيانات. وكان التقييم شاملًا وفق المعايير التقليدية. أما ما لم يعالجه التقييم فهو الواجهة الخلفية للذكاء الاصطناعي لدى المورّد، أي LLM الأساسي الذي يشغّل المنتج. فقد كان منتج المورّد مبنيًا على GPT-4 API من OpenAI. وكل استعلام أرسله محللو الشركة إلى منتج المورّد، بما في ذلك مستندات العملاء التي رفعوها لتلخيصها، ومسودات التقارير التي كانوا يعملون عليها، وبيانات العملاء التي أشاروا إليها في استعلاماتهم، كان يُعاد توجيهه إلى API لدى OpenAI ضمن طلب الاستدلال عبر LLM. والتزمت DPA المبرمة مع المورّد بعدم احتفاظ المورّد نفسه بالبيانات، لكنها لم تعالج شروط OpenAI للتعامل مع البيانات. وبموجب شروط API المعيارية لدى OpenAI آنذاك، لم تكن مدخلات API تُستخدم للتدريب افتراضيًا، غير أن الفريق القانوني للشركة لم يقيّم شروط OpenAI قط. والأهم من ذلك أن الشركة لم تُجرِ قط تقييمًا لمخاطر OpenAI بوصفها مورّدًا، رغم أن بيانات عملائها كانت تتدفق عبر البنية التحتية لـ OpenAI مع كل استعلام يُجريه محللوها.
ما التعرض للذكاء الاصطناعي القائم على API في حقيقته؟
التعرض للذكاء الاصطناعي القائم على API هو مخاطر البيانات والأمن الناشئة عندما يستخدم منتج الذكاء الاصطناعي لدى المورّد LLM API تابعة لطرف ثالث، مثل GPT-4 من OpenAI، أو Claude من Anthropic، أو Gemini من Google، أو Azure OpenAI، بوصفها محرك الاستدلال الأساسي، مما يجعل بيانات المؤسسة المُرسلة إلى منتج المورّد تتدفق عبر البنية التحتية لمزوّد LLM التابع للطرف الثالث، وتخضع لشروط خدمة ذلك المزوّد وممارساته في التعامل مع البيانات وضوابطه الأمنية. فالمؤسسة تقيّم المورّد، والمورّد يستخدم LLM تابعًا لطرف ثالث، وبيانات المؤسسة تتدفق إلى مزوّد LLM. ومزوّد LLM طرف رابع لم تقيّمه المؤسسة في العادة قط.
يمثل بُعد مخاطر الطرف الرابع مشكلة سلسلة التوريد. فقد تناولت أطر TPRM التقليدية بصورة متزايدة مخاطر الطرف الرابع، أي المخاطر الناشئة عن مورّدي المورّدين. والتعرض للذكاء الاصطناعي القائم على API نمط محدد وسريع الانتشار من مخاطر الطرف الرابع، يكون فيه الطرف الرابع أحد كبار مزوّدي LLM. والتزامات المؤسسة في التعامل مع البيانات، بموجب GDPR وHIPAA وPCI-DSS والالتزامات التعاقدية تجاه عملائها، تنطبق على البيانات أينما تدفقت. وعندما تتدفق تلك البيانات إلى مزوّد LLM بوصفه طرفًا رابعًا، تصبح التزامات المؤسسة في التعامل مع البيانات مرتبطة بعلاقة لم تُنشئها وربما لم تقيّمها.
تمثل مشكلة إقامة البيانات وموقع معالجتها بُعد الامتثال المحدد. فمزوّدو LLM API يشغّلون مراكز بيانات في مناطق متعددة، وقد لا يكون موقع معالجة طلبات الاستدلال عبر API في المنطقة نفسها التي تفرضها متطلبات إقامة البيانات لدى المؤسسة. والمؤسسة الخاضعة لمتطلبات إقامة البيانات بموجب GDPR التي ترسل بيانات شخصية إلى مزوّد LLM API قد تتسبب في معالجة بيانات شخصية خارج الاتحاد الأوروبي دون وجود آليات نقل البيانات الملائمة، بصرف النظر عمّا إذا كانت معالجة المورّد نفسه للبيانات تفي بمتطلبات الإقامة.
يمثل خطر تطور شروط الخدمة بُعدًا زمنيًا. فشروط خدمة مزوّدي LLM تتطور مع تطور نماذج أعمالهم. وقد تكون شروط التعامل مع البيانات التي كانت سارية حين قيّم المورّد واجهته الخلفية قد تغيّرت. والشروط التي كانت تحظر التدريب على مدخلات API في فترة ما ربما تغيّرت في تحديثات لاحقة للشروط. والمؤسسة التي قيّمت المورّد في لحظة زمنية معينة لا تملك رؤية مستمرة لما إذا كانت شروط مزوّد LLM، التي تحكم ما يحدث لبيانات المؤسسة، قد تغيّرت منذ ذلك التقييم.
يمثل خطر الإسهام في تحسين النماذج مصدر القلق المحدد الذي أثاره السيناريو الافتتاحي. فلدى مزوّدي LLM حوافز تجارية لاستخدام البيانات المتدفقة عبر أنظمتهم في تحسين نماذجهم، إذ تجذب النماذج الأفضل مزيدًا من العملاء. وقد تستخدم الإعدادات الافتراضية لعملاء API مدخلات API للتدريب أو لا تستخدمها، تبعًا للمزوّد ونوع الحساب ونسخة الشروط السارية تحديدًا. والمؤسسات التي تتدفق بياناتها الحساسة أو المملوكة لها عبر واجهات LLM البرمجية قد تكون تُسهم بتلك البيانات في تدريب النماذج التأسيسية دون علمها أو موافقتها.
لماذا يهم هذا
يكتسب التعرض للذكاء الاصطناعي القائم على API أهميته في TPRM لأن التبني السريع لمنتجات المورّدين المدعومة بـ LLM أوجد فئة جديدة من مخاطر الطرف الرابع لم تعالجها معظم برامج TPRM بصورة منهجية. فكل مورّد يُبنى منتجه للذكاء الاصطناعي على LLM API تابعة لطرف ثالث يُنشئ تدفقًا للبيانات إلى طرف رابع يتعين على المؤسسة تقييمه بمعزل عن المورّد. وفي بيئة تدمج فيها مئات من مورّدي برمجيات المؤسسات قدرات LLM مدعومة من عدد قليل من مزوّدي LLM، تصبح مخاطر تركّز الطرف الرابع لدى هؤلاء المزوّدين كبيرة.
أين تخطئ معظم الفرق
الإخفاق الأكثر تكرارًا هو إتمام تقييمات منتجات الذكاء الاصطناعي لدى المورّدين دون السؤال عمّا إذا كان المنتج يستخدم LLM API تابعة لطرف ثالث، وإن كان كذلك فأيّها، وما إذا كانت اتفاقية معالجة البيانات المبرمة بين المؤسسة والمورّد تغطي تعامل مزوّد LLM مع البيانات.
- إتمام تقييم المورّد دون الإفصاح عن الواجهة الخلفية لـ LLM
- عدم تقييم مزوّد LLM بوصفه طرفًا رابعًا
- DPA تغطي المورّد دون مزوّد LLM
- عدم تتبّع متطلبات إقامة البيانات عبر البنية التحتية لمزوّد LLM
- عدم مراقبة تطور شروط مزوّد LLM
كيف تبدو الممارسة الجيدة
تطلب تقييمات التعرض للذكاء الاصطناعي القائم على API الناضجة من كل مورّد للذكاء الاصطناعي الإفصاح عن الواجهة الخلفية لـ LLM لديه، وتقيّم مزوّد LLM بوصفه طرفًا رابعًا، وتضمن أن تتضمن DPA المبرمة مع المورّد التزامات بشأن تعامل مزوّد LLM مع البيانات، بما في ذلك مكان إقامة البيانات، وإلغاء الاشتراك في استخدامها للتدريب، والإخطار بتغيير الشروط.
- اشترط الإفصاح عن الواجهة الخلفية لـ LLM في تقييم مورّدي الذكاء الاصطناعي
- قيّم مزوّد LLM بوصفه طرفًا رابعًا
- DPA تغطي تعامل مزوّد LLM مع البيانات: مكان الإقامة، وإلغاء الاشتراك في استخدامها للتدريب
- تتبّع إقامة البيانات عبر البنية التحتية لمزوّد LLM
- اشتراط الإخطار بتغيير الشروط: يُخطر المورّد إذا تغيّرت شروط مزوّد LLM
الأدوات
تقييم مزوّد LLM: شروط OpenAI للمؤسسات، وشروط API لدى Anthropic، وAzure OpenAI Service (مع DPA للمؤسسات)
يقدّم كبار مزوّدي LLM مستويات API للمؤسسات بالتزامات معزّزة للتعامل مع البيانات، وتحديدًا إلغاء الاشتراك في استخدام البيانات للتدريب وضوابط إقامة البيانات غير المتاحة في مستويات API المعيارية. فعلى سبيل المثال، توفر Azure OpenAI Service التزامات Microsoft للمؤسسات بشأن التعامل مع البيانات وضوابط إقامة البيانات في الاتحاد الأوروبي. وبالنسبة لممارسي TPRM، يوفر السؤال عن مستوى مزوّد LLM الذي يستخدمه المورّد، معياريًا كان أم للمؤسسات، وعمّا إذا كانت هناك DPA للمؤسسات تغطي التعامل مع البيانات، سؤالًا محددًا عن تعامل الطرف الرابع مع البيانات.
تحديات الحوكمة
يتمثل تحدي الحوكمة في التعرض للذكاء الاصطناعي القائم على API في التغير السريع في مشهد المورّدين. فمنتجات جديدة لمورّدين مدعومة بـ LLM تظهر باستمرار، والمنتجات القائمة كثيرًا ما تغيّر الواجهات الخلفية لـ LLM لديها. وقد لا يعكس تقييمٌ يُجرى اليوم العلاقةَ مع مزوّد LLM بعد ستة أشهر. ويكمن الحل الحوكمي في إدراج الإفصاح عن الواجهة الخلفية لـ LLM حقلًا معياريًا في تقييمات مخاطر المورّدين، واشتراط الإخطار بتغييرات مزوّد LLM التزامًا تعاقديًا.
- أدرج الإفصاح عن الواجهة الخلفية لـ LLM في التقييم المعياري لمورّدي الذكاء الاصطناعي
- قيّم مزوّد LLM المحدد بوصفه من مخاطر الطرف الرابع
- اشترط DPA تغطي تعامل مزوّد LLM مع البيانات
- اشترط الإخطار بتغيير مزوّد LLM
- تحقق من الاشتراك في مستوى المؤسسات بشروط معزّزة للتعامل مع البيانات
إذا كنت فريقًا صغيرًا
اطرح على كل مورّد للذكاء الاصطناعي سؤالًا واحدًا قبل أي سؤال آخر: هل يستخدم منتجكم LLM API تابعة لطرف ثالث؟ وإن كان كذلك، فما المزوّد وما مستوى الخدمة؟ إذا كانت الإجابة نعم، فلديك تدفق بيانات إلى طرف رابع يلزم تقييمه. تحقق مما إذا كانت DPA المبرمة مع المورّد تغطي تعامل مزوّد LLM مع البيانات، وتحديدًا: هل تتضمن التزامات بشأن مكان إقامة البيانات، وإلغاء الاشتراك في استخدامها للتدريب، واشتراطًا بإخطارك إذا تغيّر مزوّد LLM؟ هذه الالتزامات الثلاثة هي الحد الأدنى من تغطية DPA لمورّد يُعيد منتجه توجيه بياناتك إلى LLM تابع لطرف ثالث.
- اسأل عمّا إذا كان المنتج يستخدم LLM API تابعة لطرف ثالث، وما المزوّد
- تحقق مما إذا كانت DPA المبرمة مع المورّد تغطي تعامل مزوّد LLM مع البيانات
- تحقق من الاشتراك في مستوى المؤسسات مع إلغاء الاشتراك في استخدام البيانات للتدريب
- اشترط الإخطار بتغيير مزوّد LLM
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«هل يستخدم منتج الذكاء الاصطناعي لديكم LLM API تابعة لطرف ثالث؟ وإن كان الأمر كذلك، فما المزوّد وما مستوى الخدمة؟ وهل تغطي اتفاقية معالجة البيانات المبرمة بيننا تعامل مزوّد LLM مع بياناتنا، بما في ذلك مكان إقامة البيانات، وإلغاء الاشتراك في استخدامها للتدريب، والإخطار إذا غيّرتم مزوّد LLM؟»
ما تتوقعه دليلًا
- الإفصاح عن الواجهة الخلفية لـ LLM: المزوّد ومستوى الخدمة
- تغطية DPA لتعامل مزوّد LLM مع البيانات
- تأكيد الاشتراك في مستوى المؤسسات بشروط معزّزة
- الالتزام بالإخطار بتغيير مزوّد LLM
ينبغي أن يُطلب من المورّد الذي يؤكد أمن البيانات الإفصاحُ عن الواجهة الخلفية لـ LLM لديه. فالضوابط الأمنية للمورّد تحمي أنظمة المورّد، أما شروط تعامل مزوّد LLM مع البيانات فتحكم ما يحدث للبيانات في طلب الاستدلال.
كيف تُثبت ذلك
- توثيق الإفصاح عن الواجهة الخلفية لـ LLM
- سجلات تقييم مزوّد LLM بوصفه طرفًا رابعًا
- تغطية DPA لمزوّد LLM
- سجلات الاشتراك في مستوى المؤسسات
الخلاصة الرئيسية
كان لدى المورّد SOC 2. وكانت البيانات مشفّرة أثناء النقل. ولم يحتفظ المورّد بشيء. وتدفقت البيانات إلى API لدى OpenAI مع كل طلب استدلال. ولم تقيّم المؤسسة OpenAI قط. غطّت DPA المبرمة مع المورّد تعامل المورّد مع البيانات، أما شروط OpenAI فحكمت ما حدث في طلب الاستدلال. وظلت التزامات المؤسسة بموجب GDPR مرتبطة بالبيانات الشخصية لعملائها بصرف النظر عن البنية التحتية التي تدفقت عبرها. إن التعرض للذكاء الاصطناعي القائم على API هو مخاطر طرف رابع تتوسطها خيارات المورّد في الواجهة الخلفية لـ LLM. اسأل عن مزوّد LLM. قيّم مزوّد LLM. تأكد من أن DPA تغطي طلب الاستدلال. فأمن المورّد يغطي الغلاف الخارجي، أما شروط مزوّد LLM فتحكم المحتوى.