تتلقى المؤسسات التي تبني على نموذج لغوي مستضاف من المورّد نموذجًا مدرّبًا على السلامة ومنصةً، وتظل مسؤولة عن التطبيق المحيط به. وتقسّم كل من Microsoft وCloud Security Alliance وقانون الذكاء الاصطناعي الأوروبي العمل بين مزوّد النموذج والجهة التي تنشره، بمفردات مختلفة وثقل قانوني مختلف. تقارن هذه المذكرة بين الثلاثة، وتعرض تقسيمًا عمليًا للحالة الشائعة لنموذج يُستهلك عبر API. وهي مرافقة لمقالة كيف تختبر Anthropic نموذج Claude بالفريق الأحمر، وما الذي تتركه لك، التي تتناول جانب المزوّد من الخط في حالة منشورة واحدة.
خلفية: النموذج السحابي ممتدًّا إلى الذكاء الاصطناعي
يُسند نموذج المسؤولية المشتركة السحابية كل ضابط إلى المزوّد أو العميل بحسب نوع الخدمة: البرمجيات كخدمة (SaaS)، أو المنصة كخدمة (PaaS)، أو البنية التحتية كخدمة (IaaS). وتمدّ كل من Microsoft وCloud Security Alliance (CSA) هذه الفكرة إلى الذكاء الاصطناعي التوليدي. ويغيّر هذا الامتداد المفردات أكثر مما يغيّر المنطق: فكلما بنى العميل في طبقة أدنى من المكدّس، امتلك عددًا أكبر من الضوابط.
نماذج المورّدين
Microsoft: المنصة والتطبيق والاستخدام
يصف نموذج المسؤولية المشتركة للذكاء الاصطناعي لدى Microsoft التطبيقَ المدعوم بالذكاء الاصطناعي بثلاث طبقات: منصة الذكاء الاصطناعي، وتطبيق الذكاء الاصطناعي، واستخدام الذكاء الاصطناعي. وتوفّر طبقة المنصة النموذج عبر واجهات API وتتضمن نظام سلامة يرشّح المدخلات والمخرجات الضارة. وطبقة التطبيق هي الواجهة التي يستهلكها المستخدم، مع التأريض (grounding) والإضافات وموصّلات البيانات، وتحتاج إلى نظام سلامة خاص بالتطبيق. وتغطي طبقة الاستخدام طريقة استهلاك الناس لهذه القدرة، وتشير Microsoft إلى ضوابط الهوية والوصول، وسياسات الاستخدام المقبول، وتثقيف المستخدمين. [1]
يتوقف مقدار ما يملكه العميل من كل طبقة على نوع النشر. وتنص الصفحة على أن المسؤوليات تختلف بين SaaS وPaaS وIaaS، وتوصي بالبدء بعروض SaaS مثل Copilot، والانتقال إلى خدمات PaaS مثل Azure OpenAI Service فقط حين لا تلائم القدرات الجاهزة، وقصر بناء النماذج المخصّصة على المؤسسات ذات الخبرة العميقة. وتضيف الصفحة أن هذه الإرشادات توضيحية، وتُستخدم بمعنى الحوكمة، ولا تعدّل أي اتفاقية مع Microsoft. [1]
Microsoft: الامتداد إلى الوكلاء
تتناول صفحة ثانية لـ Microsoft الوكلاء، وتميّزهم عن النموذج المجرد لأن الوكيل يتصرف دون أن يوافق إنسان على كل خطوة، ويخطّط ويكرّر، ويحتفظ بذاكرة، وله هويته الخاصة، ويمكن أن يتركّب مع وكلاء آخرين. وتضيف ثلاث طبقات: تنسيق الوكيل، والأدوات والإجراءات، والذاكرة والحالة. وفي مصفوفة المسؤوليات الخاصة بها، يحتفظ العميل في حالة PaaS بتعليمات الوكيل ونطاقه، وأذونات كل أداة، والموافقة البشرية على الإجراءات عالية الأثر، بينما تعود بيئة التشغيل ومنصة التنسيق إلى Microsoft. [2]
تسرد الصفحة المسؤوليات التي يحتفظ بها العميل دائمًا: البيانات، والهوية والحد الأدنى من الصلاحيات، وتفويض الإجراءات، والإشراف البشري، والاستخدام المقبول والحوكمة. وتنص أيضًا على أن الاستقلالية لا تقلّل المساءلة أبدًا. [2]
Cloud Security Alliance: مقترح من عام 2023
في تدوينة مؤرخة في 28 يوليو 2023، اقترح أحد زملاء CSA نموذجًا بثلاثة أطراف: مزوّد خدمة الذكاء الاصطناعي، ومستخدم خدمة الذكاء الاصطناعي الذي يبني تطبيقًا، والمؤسسة أو المستخدم النهائي لذلك التطبيق. وبموجب المقترح، يوفّر مزوّد IaaS البنية التحتية والنماذج التأسيسية بينما يتولى المستخدم التدريب والتحقق من البيانات وترشيح التعليمات وأمان التطبيق؛ وفي حالة PaaS يوفّر المستخدم السياق وأمان التطبيق؛ وفي حالة SaaS يدير المستخدم التأريض وترشيح التعليمات وحماية الملكية الفكرية. وتعرض التدوينة ذلك بوصفه مقترحًا يفصل الواجبات، لا معيارًا. [3]
القانون: قانون الذكاء الاصطناعي الأوروبي يقسّم الالتزامات بحسب الدور
يُسند قانون الذكاء الاصطناعي الأوروبي الواجبات بحسب الدور. فوفقًا للأسئلة الشائعة حول إرشادات المفوضية الأوروبية، فإن مزوّد نموذج الذكاء الاصطناعي العام الغرض هو الجهة التي تطوّر النموذج، أو تكلّف بتطويره، وتطرحه في السوق باسمها. وتشمل التزامات المزوّد التوثيق التقني، وتوثيقًا للمطوّرين اللاحقين عن القدرات والقيود، وسياسة للامتثال لحقوق النشر، وملخصًا عامًا لمحتوى التدريب. وقد سرت هذه الالتزامات اعتبارًا من 2 أغسطس 2025. وتخضع النماذج المفترض أنها تنطوي على مخاطر نظامية، أي التي تبلغ قدرة حوسبة تدريبها 10^25 عملية فاصلة عائمة أو أكثر، لواجبات إضافية تشمل الاختبار العدائي وضمانات الأمن السيبراني. [4]
تحدّد الأسئلة الشائعة نفسها 2 أغسطس 2026 تاريخًا يبدأ منه الإنفاذ، بما في ذلك الغرامات، على هؤلاء المزوّدين، و2 أغسطس 2027 موعدًا نهائيًا للنماذج المطروحة في السوق قبل 2 أغسطس 2025. وتنص أيضًا على أن المطوّر اللاحق الذي يعدّل نموذجًا لا يصبح مزوّدًا إلا في ظروف استثنائية، مثل استخدام أكثر من ثلث قدرة حوسبة التدريب الأصلية، بحيث لا ينقل معظم الضبط الدقيق دور المزوّد. [4]
أما الجهات المستخدمة (deployers)، أي المؤسسات التي تستخدم أنظمة الذكاء الاصطناعي، فتتحمل مجموعة منفصلة من الواجبات. ويسرد تحليل لمكتب محاماة مؤرخ في 24 يوليو 2026 الإفصاح عن التزييف العميق، وإشعار الأفراد بالتعرّف على المشاعر والتصنيف البيومتري، ضمن واجبات الجهات المستخدمة اعتبارًا من 2 أغسطس 2026. وبالنسبة إلى الأنظمة عالية المخاطر، يسرد الإشراف البشري الكفء، وإخطار الأفراد باستخدام الذكاء الاصطناعي، واستشارة العاملين. [6] وتضيف صفحة الجدول الزمني للمفوضية أن على الجهات المستخدمة ضمان الإشراف البشري والرصد، والإبلاغ عن الحوادث الخطيرة بعد طرح الأنظمة في السوق. [5]
تأجيل Digital Omnibus
تغيّرت المواعيد النهائية للأنظمة عالية المخاطر. فصفحة الجدول الزمني للمفوضية تذكر 2 ديسمبر 2027 للأنظمة عالية المخاطر في المجالات الحساسة مثل القياسات الحيوية والتوظيف وإنفاذ القانون، و2 أغسطس 2028 للأنظمة عالية المخاطر المضمّنة في منتجات خاضعة للتنظيم، وتنسب ذلك إلى Digital Omnibus on AI، الذي تصفه بأنه يدخل حيز النفاذ في يوليو 2026. [5] ويذكر تحليل Norton Rose Fulbright التاريخين نفسيهما، وينص على أن الـ Omnibus نُشر في السجل التشريعي للاتحاد الأوروبي. [6] ومن ثم يتفق مصدران مستقلان على أن التأجيل اعتُمد ولم يكن مجرد مقترح. ولا يغيّر هذان التاريخان واجبات المزوّدين الخاصة بالنماذج العامة الغرض ولا واجبات الشفافية المذكورة أعلاه.
تقسيم العمل حين يُستخدم النموذج عبر API
في حالة PaaS، التي يستدعي فيها تطبيقٌ نموذجًا مستضافًا، تدعم المصادر التقسيم التالي. وتتبع صفوف Microsoft طبقتي المنصة والتطبيق الموصوفتين أعلاه؛ أما صفوف اختبار المخاطر الحدّية وتوثيق النظام وقنوات الإفصاح فتعكس واجبات المزوّد في إرشادات الاتحاد الأوروبي والممارسات التي ينشرها مورّدو النماذج. والجدول تركيب أعدّه FireAI، وليس نصًا من أي من المصادر.
| المجال | جانب المزوّد | جانبك |
|---|---|---|
| سلوك النموذج | تدريب النموذج على السلامة ومواءمته | تعليمات النظام وضوابط التطبيق الحمائية |
| اختبار المخاطر | اختبار المخاطر الحدّية للنموذج نفسه | اختبار تطبيقك، بما في ذلك تعليماته وبياناته وأدواته |
| المنصة | أمان المنصة ومرشّحات المدخلات والمخرجات الأساسية | فحوص سلامة التطبيق للمحتوى والإضافات والموصّلات |
| التوثيق | بطاقة النظام والتوثيق للمطوّرين اللاحقين | قراءته، وتسجيل النموذج والإصدار اللذين نشرتهما |
| البيانات والأدوات | لا شيء يتجاوز عقد API | بيانات RAG، والأدوات، والوكلاء وأذوناتهم |
| المخرجات | يُرجع النص المولَّد | معالجة المخرجات لاحقًا: التحقق، والتهريب (escaping)، والموافقة البشرية |
| العمليات | قناة الإفصاح عن الثغرات الخاصة بالنموذج | التسجيل والرصد والاستجابة للحوادث الخاصة بالتطبيق |
| الأشخاص | شروط سياسة الاستخدام | سياسة الاستخدام الخاصة بك وتدريب المستخدمين |
مجالان مشتركان بالمعنى الدقيق. الأول هو حقن التعليمات (prompt injection): إذ يدرّب المزوّد النموذج على مقاومة التعليمات المحقونة، وتحدّ الجهة المستخدمة مما يمكن أن تحققه التعليمة المحقونة عبر أذونات الأدوات والوصول إلى البيانات. وتصف صفحة Microsoft الخاصة بالوكلاء التقسيم نفسه، إذ تطلب من العملاء معاملة المحتوى المسترجع ومخرجات الأدوات ورسائل الوكلاء الآخرين بوصفها غير موثوقة، وإخضاع الإجراءات عالية الأثر لبوابة موافقة. [2] والثاني هو خصوصية البيانات: إذ يحدّد المزوّد شروط الاحتفاظ والتدريب، وتقرّر الجهة المستخدمة أي البيانات تدخل التعليمات أو فهرس الاسترجاع في الأساس.
التوصيات
- حدّد نوع النشر أولًا (SaaS أو PaaS أو استضافة ذاتية)، ودوّن صفوف التقسيم أعلاه التي تملكها المؤسسة.
- اختبر جانب الجهة المستخدمة مباشرةً: تعليمات النظام، وبيانات الاسترجاع، وأذونات الأدوات، ومعالجة المخرجات. فاختبار المورّد للنموذج لا يغطيها.
- قبل اعتماد نموذج، اقرأ بطاقة النظام الخاصة بالمزوّد، وشروط الاحتفاظ بالبيانات والتدريب، وحدّد قناة الإفصاح عن الثغرات لديه.
- قيّد ما يمكن أن تفعله التعليمة المحقونة: أدوات بالحد الأدنى من الصلاحيات، ووصول محدود النطاق إلى البيانات، وموافقة بشرية على الإجراءات التي لا رجعة فيها.
- قرّر البيانات التي يجوز أن تدخل التعليمات، واحتفظ بسجلات كافية لإعادة بناء أي حادثة.
- للمواد التعليمية عن الأطر والفريق الأحمر، راجع دورة FireAI University عن أطر أمان الذكاء الاصطناعي والفريق الأحمر.
صلة الموضوع بـ FireAI
التطبيق أو الوكيل المحلي الذي يستدعي API لنموذج هو تطبيق على جهاز Mac، ووجهاته مرئية لـ FireAI. ويسرد النشاط التطبيقات التي اتصلت بالإنترنت، وتتيح القواعد للمستخدم السماح لتطبيق أو وجهة محددة أو حظرهما. وهذا ضابط واحد على جانب الجهة المستخدمة، على جهاز Mac واحد. ولا يفحص FireAI التعليمات، ولا يحكم على مخرجات النموذج، ولا يكتشف حقن التعليمات، ولا يقيّم ما إذا كان المزوّد يفي بأي التزام قانوني.
حدود الدراسة
- صفحات Microsoft إرشادات من المورّد لمنتجات Azure، تصف نفسها بأنها توضيحية ولا تغيّر شروط العقود. ونص CSA مقترح من عام 2023.
- هذه المذكرة ليست استشارة قانونية. فكون المؤسسة مزوّدًا أو جهة مستخدمة أو مشغّلًا لنظام عالي المخاطر بموجب قانون الذكاء الاصطناعي الأوروبي يتوقف على وقائع لا تقيّمها هذه المذكرة، وقد تفسّر السلطات الوطنية القانون تفسيرات مختلفة.
- تأتي تواريخ Digital Omnibus من صفحة الجدول الزمني للمفوضية ومن تحليل واحد لمكتب محاماة. ولم يُراجَع نص اللائحة نفسها لهذه المذكرة.
- جدول API تركيب، وبعض المزوّدين يضعون بعض الصفوف على نحو مختلف في شروطهم.
دور FireAI وHisnLabs
يشمل جانبك من الخط ما يغادر جهاز Mac. ويُظهر FireAI ذلك ويترك لك القرار.
FireAI هو منتج HisnLabs نفسها: جدار حماية بذكاء اصطناعي يعمل على جهاز Mac مباشرة. يعرض بلغة واضحة كل اتصال تجريه تطبيقاتك، ويترك لك القرار فيما يخرج من جهازك — ذكاؤه الاصطناعي يعمل محليًا، فلا يُرسَل ترافيكك إلينا ولا إلى أي جهة أخرى أبدًا. فريق أبحاث الأمن في HisnLabs هو من يحافظ على دقة هذه القرارات: يصنّف النطاقات بين قياس عن بُعد عادي وخدمة حقيقية، ويتتبّع بلد وشبكة كل اتصال، ويدرّب النموذج المحلي (ميزة FireAI Pilot) على حركة اتصال حقيقية، دون أن يغادر أي شيء جهاز Mac.
يمكنك الاطلاع على القرارات التقنية وراء ذلك، أو تجربة FireAI لمدة 17 يومًا، على FireAI من HisnLabs.