Key Takeaways
- يوثّق SOC 2 وISO 27001 ضوابط مؤسستك، وليس أداة — لا تدّعِ أبدًا أن "Ollama متوافق مع SOC 2" أو "vLLM معتمد وفق ISO 27001". اعرض كل شيء كاستعداد للضوابط التي سيتحقق منها المدقق.
- يقيّم SOC 2 وفق خمسة معايير Trust Services (الأمان، التوافر، السرية، سلامة المعالجة، الخصوصية)؛ ويقيّم ISO 27001 وفق ضوابط Annex A ضمن نظام إدارة أمن معلومات (ISMS) موثّق.
- تحتاج نقطة نهاية الاستدلال إلى تحكم بالوصول وتسجيل منظّم للطلبات — معظم محركات الاستضافة الذاتية (Ollama وvLLM وTGI) لا توفر شيئًا من ذلك افتراضيًا وتحتاج إلى بوابة أمامية.
- شفّر أوزان النموذج وسجلات المحادثات/الردود أثناء التخزين (تشفير القرص) وأثناء النقل (TLS) — نفس الضوابط التي تطبّقها بالفعل على أي مخزن بيانات إنتاجي آخر.
- تحتاج النماذج مفتوحة الأوزان أيضًا إلى تقييم موثّق لمخاطر الموردين: هوية الناشر، التحقق من المجموع التدقيقي (checksum)، شروط الترخيص، والثغرات المعروفة في بنية التقديم.
- يمكن لمنصات أتمتة الامتثال (Vanta وDrata وSecureframe) جمع الأدلة تلقائيًا من البنية السحابية، لكن خادم الاستدلال المستضاف ذاتيًا يحتاج عادةً إلى تكامل مخصص أو رفع يدوي للأدلة.
- هذا المقال ليس استشارة قانونية أو امتثالية — القرار النهائي بشأن النطاق والضوابط يعود لمدقق حساباتك.
هل هذه استشارة قانونية أو امتثالية؟
لا — هذا الدليل ليس استشارة قانونية أو امتثالية. يشرح، على المستوى التقني، فئات الضوابط التي عادةً ما يتحقق منها مدقق SOC 2 أو ISO 27001، وكيفية تطبيقها على نشر LLM مستضاف ذاتيًا. يعتمد ما إذا كان ضابط معين يفي بمتطلبات تدقيقك على تقدير مدققك، وتقييم مخاطر مؤسستك، وبيان النطاق الدقيق الذي تقدّمه. استشر مدققًا مؤهلًا أو إدارة الامتثال لديك قبل جدولة أي تدقيق أو تقديم أي ادعاء متعلق بالامتثال.
ماذا تتطلب معايير Trust Services في SOC 2؟
يقيّم SOC 2 المؤسسة وفق خمسة معايير Trust Services (TSC)، وينطبق كل منها على نظام LLM مستضاف ذاتيًا فور تعامله مع بيانات إنتاجية. لا يختبر المدقق النموذج نفسه — بل يختبر ما إذا كانت المؤسسة قادرة على إثبات أن الضابط كان موجودًا وفعّالًا طوال فترة المراجعة.
| المعيار | ما يتحقق منه المدقق | الضابط في بنية LLM |
|---|---|---|
| الأمان | التحكم بالوصول، التسجيل، إدارة الثغرات | RBAC + MFA على بوابة الاستدلال |
| التوافر | وقت التشغيل، التكرار، خطة التعافي | تقديم متعدد العقد + نسخ احتياطية مختبرة |
| السرية | تصنيف البيانات، مبدأ الحاجة للمعرفة | تشفير الأوزان والسجلات أثناء التخزين |
| سلامة المعالجة | الدقة، الاكتمال، التوقيت | نماذج مثبّتة الإصدار + سجلات المخرجات |
| الخصوصية | الإشعار، الموافقة، تقليل البيانات | سياسة موثّقة للاحتفاظ بسجلات المحادثات |
ماذا يتطلب Annex A في ISO 27001؟
يوثّق ISO 27001 نظام إدارة أمن المعلومات (ISMS) للمؤسسة، وAnnex A هو قائمة مرجعية للضوابط التي يستمد منها الـISMS — وليس قائمة تحقق تُطبَّق مباشرة على نظام واحد فقط. يقع نشر LLM المستضاف ذاتيًا ضمن نطاق الـISMS مثل أي أصل آخر: يحتاج إلى تقييم مخاطر، وإدراج في بيان قابلية التطبيق (Statement of Applicability)، وأدلة على أن الضوابط ذات الصلة فعّالة.
| مجال Annex A | التطبيق على بنية LLM |
|---|---|
| A.5 التنظيمي | مراجعة مخاطر الموردين لناشر النموذج |
| A.5.19–22 علاقات الموردين | التحقق من مصدر النموذج والترخيص |
| A.8 التقني | تحصين نقطة النهاية، التشفير، التسجيل |
| A.8.16 أنشطة المراقبة | سجلات تدقيق طلبات/ردود الاستدلال |
| A.8.24 التشفير | TLS أثناء النقل، تشفير القرص أثناء التخزين |
| A.5.29 استمرارية الأعمال | دليل استجابة للحوادث لنظام تقديم النموذج |
ما التحكم بالوصول والتسجيل الذي تحتاجه نقطة نهاية الاستدلال؟
يتوقع المدقق أن يرى من استدعى النموذج، وبأي بيانات اعتماد، ومتى — وهو متطلب لا تحققه أي من محركات الاستضافة الذاتية الشائعة دون بوابة أمامية. يرتبط Ollama افتراضيًا بـ`127.0.0.1:11434` ولا يملك حسابات مستخدمين؛ ويعرض كل من vLLM وHugging Face TGI واجهة برمجة HTTP متوافقة مع OpenAI بلا مصادقة مدمجة.
استخدم بوابة API (Kong أو Envoy أو طبقة إدارة API لدى مزود سحابي) أمام محرك الاستدلال لإضافة مفاتيح API أو OAuth2 لكل مستدعٍ، ثم سجّل كل طلب مع هوية المستدعي والطابع الزمني وإصدار النموذج وعدد الرموز إلى نظام يمكن لـSIEM استيعابه.
- المصادقة: مفاتيح API أو OAuth2 عند البوابة، ولا يُستخدم أبدًا رمز مشترك بين جميع المستدعين
- التفويض: وصول قائم على الأدوار — من يمكنه استدعاء أي نموذج، ومن يرى نقاط نهاية الإدارة/المقاييس
- حقول سجل التدقيق: هوية المستدعي، الطابع الزمني، النموذج والإصدار، نقطة النهاية المستدعاة، حالة الاستجابة
- وصول الإدارة: يجب فرض MFA على أي شخص لديه وصول shell أو إعدادات إلى مضيف الاستدلال
كيف تُشفَّر أوزان النموذج وسجلات المحادثات؟
تحتاج أوزان النموذج وسجلات المحادثات والردود إلى نفس التشفير أثناء التخزين والنقل الذي يتوقعه المدقق بالفعل لأي مخزن بيانات إنتاجي آخر. الأوزان نفسها ليست سرية عادةً، لكن قرص خادم الاستدلال يحتوي غالبًا أيضًا على محادثات مخبأة (cached) ومحوّلات مضبوطة دقيقًا (fine-tuned adapters) وسجلات حساسة فعلًا.
استخدم تشفير القرص الكامل (LUKS على Linux، BitLocker على Windows، FileVault على macOS) على مضيف الاستدلال كخط أساس. أضف إنهاء TLS عند البوابة لكل استدعاء API وارد — لا تعرض منفذ الاستدلال الخام عبر HTTP نصي غير مشفر أبدًا، حتى داخل VPC.
- أثناء التخزين: تشفير كامل للقرص على المضيف، وحدة تخزين مشفرة لقاعدة بيانات سجلات المحادثات
- أثناء النقل: TLS بين المستدعي ← البوابة ← محرك الاستدلال، دون أي قفزة داخلية نصية غير مشفرة
- إدارة المفاتيح: تُخزَّن المفاتيح في KMS/vault وتُدوَّر وفق جدول موثّق
كيف تبدو إدارة التغيير لتحديثات النموذج؟
كل تبديل لإصدار النموذج أو تغيير في التكميم (quantization) أو تعديل في موجّه النظام (system prompt) هو تغيير إنتاجي ويحتاج إلى نفس مسار الموافقة الذي يحتاج إليه نشر الكود. يبحث المدققون تحديدًا عن أدلة على أن التغييرات خضعت للمراجعة والموافقة قبل التفعيل، وليس مجرد وجود سجل تغييرات لاحقًا.
- تثبيت أداة النموذج الدقيقة (checksum) بدلًا من مؤشر قابل للتغيير مثل "latest"
- اشتراط خطوة موافقة موثّقة قبل أي تغيير في النموذج أو موجّه النظام في الإنتاج
- تسجيل كل تغيير مع من وافق ومتى ولماذا
- الحفاظ على مسار تراجع (rollback) إلى الأداة السابقة المثبّتة الإصدار
كيف تُقيَّم مخاطر الموردين للنماذج مفتوحة الأوزان؟
"مفتوح الأوزان" لا يعني "بلا مورّد" — فناشر النموذج طرف في سلسلة التوريد تمامًا مثل مزوّد SaaS، ويتوقع المدقق تقييمًا موثّقًا للمخاطر بهذا الخصوص. هذا أحد الضوابط الأكثر إغفالًا: تتعامل الفرق مع ملف GGUF أو safetensors الذي تم تنزيله كأصل داخلي، وليس كأصل من طرف ثالث، رغم أنه صادر من خارج المؤسسة.
- هوية الناشر: مؤسسة معروفة (Meta وMistral AI وAlibaba/Qwen وMicrosoft) مقابل مصدر مجهول
- التحقق من المجموع التدقيقي: مطابقة SHA-256 مع القيمة التي نشرها الناشر قبل النشر
- مراجعة الترخيص: شروط الاستخدام التجاري، قيود إعادة التوزيع
- ثغرات بنية التقديم: تتبّع الثغرات المعروفة في llama.cpp وvLLM وTGI — وليس فقط ملف النموذج
كيف تبدو الاستجابة للحوادث لنظام تقديم نموذج؟
يحتوي نظام تقديم النموذج على فئات حوادث لا يغطيها دليل تطبيقات الويب القياسي — تسريب النموذج، وحقن الموجّهات (prompt injection) الذي يسرّب بيانات عبر مخرجات النموذج نفسها، واختراق نقطة نهاية الاستدلال — وكل منها يحتاج إلى مسار استجابة محدد بالاسم.
- أمثلة على المحفزات: تغيير غير مصرّح به في ملف الأوزان، ارتفاع مفاجئ في الطلبات على مستوى بيانات اعتماد واحدة، نمط حقن موجّهات في السجلات
- خطوة الاحتواء: القدرة على عزل نقطة نهاية الاستدلال أو إيقافها دون توقف كامل للنظام
- الحفاظ على الأدلة: الاحتفاظ بالسجلات الخام لفترة الحادث دون تدويرها أثناء التحقيق
- وتيرة الاختبار: تمرين نظري مرة سنويًا على الأقل، موثّق بتاريخ ومشاركين
ما الذي يجب أن تغطيه سياسة الاحتفاظ بسجلات المحادثات؟
سجلات المحادثات هي أعلى البيانات خطورة التي تنتجها بنية LLM لديك، لأنها غالبًا ما تحتوي على المحتوى الحساس نفسه الذي قد يكتبه المستخدم في أي نظام أعمال آخر. سياسة احتفاظ مكتوبة — كم من الوقت تُحفظ السجلات، ومن يمكنه الوصول إليها، وكيف تُحذف — ضابط سيطلب المدقق رؤيته تحديدًا، وليس شيئًا يُستنتج من سياسة الاحتفاظ العامة بالبيانات لديك.
- نافذة الاحتفاظ: حدّد عددًا محددًا من الأيام/الأشهر، وليس "إلى أجل غير مسمى"
- التحكم بالوصول: يمتلك مخزن سجلات المحادثات قائمة وصول مقيدة خاصة به
- التقليل: سجّل البيانات الوصفية افتراضيًا؛ تسجيل المحتوى الكامل فقط عند وجود مبرر ولفترة محدودة
- عملية الحذف: موثّقة ويُفضَّل أن تكون آلية
كيف ينبغي تجزئة خادم الاستدلال على الشبكة؟
ينبغي أن يقع خادم الاستدلال في منطقة شبكة خاصة به، لا يمكن الوصول إليه إلا عبر البوابة الموثّقة — وليس على نفس الشبكة الفرعية المسطّحة مع خوادم التطبيقات العامة. يحدّ هذا من نطاق الضرر في حال اختراق خدمة أخرى على الشبكة، ويمنح المدقق مخطط شبكة واضحًا لمراجعته.
ما الأدوات المستضافة ذاتيًا التي توفر ضوابط ذات صلة بالتدقيق؟
لا توفر أي من محركات الاستدلال الشائعة مسار تدقيق جاهزًا — والفرق يكمن في مقدار ما يجب أن تبنيه بنفسك مقابل ما توفره المنصة بالفعل. هذه مقارنة استعداد، وليست ادعاء امتثال بشأن أي من هذه الأدوات.
| الأداة | مصادقة/تسجيل مدمج | التجهيز المطلوب |
|---|---|---|
| Ollama | لا يوجد (يرتبط بـlocalhost) | وكيل عكسي + مصادقة + تصدير إلى SIEM |
| vLLM | مقاييس Prometheus فقط | بوابة API (OAuth2/مفاتيح) + سجل تدقيق |
| Hugging Face TGI | مقاييس Prometheus فقط | بوابة API + سجل تدقيق، مثل vLLM |
| المنصات المؤسسية | RBAC + سجل تدقيق مدمجان | لا تزال توثيق ISMS مطلوبة |
هل يمكن لمنصة أتمتة الامتثال أن تساعد نموذج LLM مستضافًا ذاتيًا؟
منصات أتمتة الامتثال — Vanta وDrata وSecureframe هي الأكثر استخدامًا من بينها — تجمع الأدلة تلقائيًا من البنية السحابية وأنظمة الموارد البشرية ومزودي الهوية، لكن خادم الاستدلال المستضاف ذاتيًا محليًا يقع عادةً خارج قائمة التكاملات الافتراضية لديها.
استخدم منصة أتمتة الامتثال إذا كنت تدير برنامج SOC 2 أو ISO 27001 أوسع عبر الشركة وتريد مراقبة مستمرة لكل شيء باستثناء طبقة LLM المستضافة ذاتيًا.
| المنصة | التركيز |
|---|---|
| Vanta | تغطية واسعة للأطر، شائعة لدى الشركات الناشئة |
| Drata | مراقبة مستمرة للضوابط، تكاملات عميقة |
| Secureframe | سير عمل موحّد لـSOC 2 وISO 27001 |
تُؤتمت هذه المنصات جمع الأدلة لبيئة الضوابط الأوسع لديك — ولا تُوثّق بنية LLM المستضافة ذاتيًا بنفسها، وليس لدى PromptQuorum حاليًا أي علاقة شراكة تسويقية مع أي منها (روابط منتج مُفصح عنها فقط).
ما الأخطاء الأكثر شيوعًا في الاستعداد للتدقيق؟
تنشأ معظم ملاحظات التدقيق على نماذج LLM المستضافة ذاتيًا من التعامل مع خادم الاستدلال كأنه خارج بيئة تحكم تقنية المعلومات المعتادة.
- الخطأ: افتراض أن أداة مفتوحة المصدر "قابلة للتدقيق" (الكود مرئي) تعني أنها خضعت للتدقيق بالفعل. الحل: وثّق تقييمك الخاص لمخاطر الناشر وبنية التقديم.
- الخطأ: ترك واجهة API الخاصة بالاستدلال متاحة دون بوابة "لأنها داخلية فقط". الحل: إمكانية الوصول عبر الشبكة ليست هي نفسها التحكم بالوصول — أضف المصادقة على أي حال.
- الخطأ: تسجيل نص المحادثة كاملًا في نفس سجل الوصول المستخدم لمراقبة التوافر. الحل: افصل بين المخزنين.
- الخطأ: التعامل مع تحديث إصدار النموذج كنشر روتيني بلا مسار موافقة. الحل: طبّق نفس موافقة إدارة التغيير المستخدمة لعمليات نشر الكود.
- الخطأ: عدم وجود خطة استجابة للحوادث خاصة بأنماط فشل تقديم النموذج. الحل: أضف هذه المحفزات إلى خطة الاستجابة الحالية واختبرها مرة واحدة على الأقل.
ما قائمة تحقق الاستعداد للتدقيق لنموذج LLM مستضاف ذاتيًا؟
راجع هذه القائمة قبل بدء عمل مدققك الميداني — يقابل كل بند فئة ضابط تم تناولها أعلاه.
- 1أضف نظام LLM المستضاف ذاتيًا إلى بيان نطاق ISMS/SOC 2 لديك
Why it matters: النظام غير الموثّق ضمن النطاق يُعد ملاحظة تدقيق حتى لو كانت كل الضوابط التقنية قائمة. - 2اربط معايير Trust Services أو ضوابط Annex A ذات الصلة ببنيتك الفعلية
Why it matters: يختبر المدققون وفق الربط الذي تقدّمه؛ والربط الناقص يعني ثغرات غير مختبرة. - 3ضع بوابة موثّقة أمام كل نقطة نهاية استدلال
Why it matters: يزيل أكثر ملاحظة تدقيق شيوعًا: واجهة API لنموذج بلا مصادقة. - 4فعّل تسجيل الطلبات المنظّم مع هوية المستدعي والطوابع الزمنية
Why it matters: هذا هو الدليل الأساسي الذي يطلبه المدقق لمعيار الأمان. - 5شفّر قرص المضيف ومخزن سجلات المحادثات؛ اشترط TLS عند البوابة
Why it matters: يفي بمعيار السرية وضوابط التشفير A.8.24. - 6اكتب واتبع إجراء إدارة تغيير لتحديثات إصدار النموذج
Why it matters: يثبت سلامة المعالجة ويوفر مسار تراجع موثّقًا. - 7وثّق تقييم مخاطر الموردين لكل نموذج مفتوح الأوزان قيد الإنتاج
Why it matters: يغلق أكثر ضابط يُغفَل — مخاطر سلسلة توريد النموذج نفسه. - 8انشر سياسة احتفاظ وحذف لسجلات المحادثات/الردود
Why it matters: مطلوب مباشرة لمعيار الخصوصية عندما تحتوي المحادثات على بيانات شخصية. - 9جزّئ خادم الاستدلال إلى منطقة شبكة خاصة به
Why it matters: يحدّ من نطاق الضرر ويمنح المدقق مخطط شبكة واضحًا. - 10اكتب دليل استجابة للحوادث بمحفزات خاصة بالنموذج واختبره مرة واحدة
Why it matters: يتحقق المدققون من أن الخطة موجودة وتم تمرينها فعليًا، وليس مجرد إعدادها.
الأسئلة الشائعة
هل هذا المقال استشارة قانونية أو امتثالية؟
لا. يشرح هذا الدليل، على المستوى التقني، فئات الضوابط التي عادةً ما يتحقق منها مدقق SOC 2 أو ISO 27001. لا يُغني عن مدقق مؤهل أو إدارة الامتثال لديك — استشر أحدهما قبل جدولة أي تدقيق أو تقديم أي ادعاء امتثالي.
هل استخدام Ollama أو vLLM أو Hugging Face TGI يجعل بنيتنا التحتية للذكاء الاصطناعي متوافقة مع SOC 2؟
لا توجد أداة واحدة تجعل مؤسسة ما متوافقة. الامتثال هو نتيجة تدقيق لمجموعة الضوابط الكاملة لمؤسستك. يمكن لـOllama وvLLM وTGI دعم المتطلبات التقنية (بعد إضافة المصادقة والتسجيل والتشفير)، لكن لا يُعد أي منها "متوافقًا مع SOC 2" أو "معتمدًا وفق ISO 27001" كمنتج برمجي.
ما الفرق بين SOC 2 Type I وType II بالنسبة لبنية الذكاء الاصطناعي؟
يقيّم Type I ما إذا كانت الضوابط مُصمَّمة بشكل مناسب في لحظة زمنية واحدة. أما Type II فيقيّم ما إذا كانت تلك الضوابط قد عملت بفعالية طوال فترة مراجعة، عادةً 6 إلى 12 شهرًا. بالنسبة لنقطة نهاية الاستدلال، يعني Type II أن سجلات الوصول وأدلة إدارة التغيير يجب أن تكون موجودة باستمرار طوال تلك الفترة، وليس فقط يوم التدقيق.
هل تحتاج النماذج مفتوحة الأوزان إلى تقييم مخاطر موردين رغم عدم وجود مورّد برمجي؟
نعم. ناشر النموذج (Meta أو Mistral AI أو Alibaba/Qwen أو غيرهم) هو طرف في سلسلة التوريد تمامًا مثل مزوّد SaaS. ينبغي أن يشمل التقييم الموثّق هوية الناشر، والتحقق من المجموع التدقيقي للأوزان المُنزَّلة، وشروط الترخيص، والثغرات المعروفة في بنية التقديم التي تُحمّل النموذج.
هل تقلل الاستضافة الذاتية لنموذج LLM نطاق التدقيق مقارنة بواجهة برمجة LLM سحابية؟
إنها تغيّر النطاق أكثر من كونها تقلله ببساطة. تُزيل الاستضافة الذاتية علاقة معالج البيانات من طرف ثالث التي تنشئها واجهة برمجة سحابية، لكنها تعني أيضًا أن مؤسستك تتحمل الآن كل ضابط كان يديره سابقًا مزوّد السحابة.
ما التسجيل الذي يتوقعه المدقق عند نقطة نهاية الاستدلال؟
على الأقل: هوية المستدعي (مفتاح API أو مستخدم موثّق)، الطابع الزمني، النموذج والإصدار المستدعى، نقطة النهاية، وحالة الاستجابة، مُصدّرة إلى مخزن سجلات ذي صلاحية كتابة مقيدة. يُحفظ محتوى المحادثات/الردود الكامل عادةً في مخزن منفصل بضوابط وصول أكثر صرامة وسياسة احتفاظ خاصة به.
كم من الوقت ينبغي الاحتفاظ بسجلات المحادثات كدليل تدقيق؟
لا يوجد رقم عام موحّد — يعتمد ذلك على تقييم مخاطر مؤسستك وتوقعات مدققك، موازنةً مع مبادئ تقليل البيانات بموجب أي قانون خصوصية معمول به. حدّد نافذة احتفاظ محددة كتابيًا، وليس "إلى أجل غير مسمى" أبدًا، وكن مستعدًا لتبرير هذه النافذة لمدققك.
هل يمكن لمنصات مثل Vanta أو Drata أو Secureframe مراقبة خادم LLM مستضاف ذاتيًا؟
تُؤتمت هذه المنصات جيدًا جمع الأدلة للبنية السحابية ومزودي الهوية وأنظمة التذاكر، لكن خادم الاستدلال المستضاف ذاتيًا محليًا يقع عادةً خارج قائمة التكاملات الافتراضية لديها. تبني معظم الفرق إما تكاملًا مخصصًا عبر API لذلك النظام أو ترفع الأدلة يدويًا، بينما تُؤتمت المنصة بقية بيئة الضوابط.
ما أكثر ملاحظة تدقيق شيوعًا في بنية الذكاء الاصطناعي المستضافة ذاتيًا؟
واجهة API استدلال متاحة دون مصادقة، تُبرَّر داخليًا بأنها "متاحة فقط داخل شبكتنا". إمكانية الوصول عبر الشبكة والتحكم بالوصول ادعاءان مختلفان — يتوقع المدقق مصادقة عند نقطة النهاية بصرف النظر عن موقعها في الشبكة.
هل ينبغي اختيار vLLM/TGI أو منصة استدلال مؤسسية لتسهيل الاستعداد للتدقيق؟
يمنحك vLLM وHugging Face TGI تحكمًا كاملًا لكنهما يتطلبان أن تبني طبقة المصادقة والتسجيل والتشفير بنفسك. غالبًا ما تتضمن منصات الاستدلال المؤسسية RBAC وسجلات تدقيق مدمجة، مما يقلل عمل التجهيز المخصص — لكنك في الحالتين لا تزال بحاجة إلى توثيق ISMS المحيط وتقييم مخاطر الموردين.
أين يمكنك العثور على مصادر إضافية؟
- AICPA SOC 2 Trust Services Criteria (aicpa-cima.com) — الإطار الرسمي لمعايير Trust Services الذي تُقيَّم مقابله عمليات تدقيق SOC 2
- ISO/IEC 27001:2022 (iso.org) — نص المعيار الرسمي ومرجع ضوابط Annex A
- OWASP Top 10 for LLM Applications (owasp.org/www-project-top-10-for-large-language-model-applications) — مخاطر أمنية خاصة بعمليات نشر LLM، تشمل مخاطر سلسلة التوريد وحقن الموجّهات