ISO/IEC 27090: كشف التهديدات الأمنية لأنظمة الذكاء الاصطناعي وتقييمها والسيطرة عليها

من انطلاق المشروع عام 2022 إلى النشر عام 2026

تمت الموافقة على المشروع في 15/09/2022، وبدأت المشاورة حول مسودة اللجنة (Committee Draft) في يناير 2024، وبدأ تصويت DIS في 16/04/2025. وجرى التصويت على المسودة النهائية (Final Draft) من 23/06 إلى 19/08/2026 وانتقلت في يوم انتهاء التصويت نفسه إلى حالة «under publication»؛ وفي 14/10/2026 تلا ذلك النشر برمز المرحلة 60.60. نتيجة التصويت غير علنية، لكن الانتقال دون إحالة للمراجعة يثبت القبول. وتغيّر العنوان في الأثناء: من «Guidance for addressing security threats and failures» إلى «Addressing security threats and compromises to AI systems»، فتحوّلت الإخفاقات (failures) إلى اختراقات (compromises)، وتوسّع الحجم من 46 إلى 56 صفحة مع 115 مدخلًا في قائمة المراجع.

الجهة المصدِرة واللجان

أعدّت المعيارَ اللجنةُ ISO/IEC JTC 1/SC 27 «Information security, cybersecurity and privacy protection» التي تتولى أمانتها هيئة DIN (الرئيس د. Andreas Wolf)؛ وكان فريق العمل المختص هو WG 4 «Security controls and services» بقيادة المنسّق (Convenor) Faud Khan من هيئة SCC الكندية، ولا يذكر أي مصدر علني محرّري المشروع. وتصف نشرة SC 27 Journal لشهر سبتمبر 2026 المعيار 27090 بأنه أول معيار للجنة الفرعية مخصّص تحديدًا لأمن أنظمة الذكاء الاصطناعي. وفي ألمانيا، يعكس فريق العمل ⁦NA 043-04-27-04⁩ «تدابير أمن تقنية المعلومات وخدماتها» أعمال WG 4؛ ولا تتضمن قائمة مشاريعه بتاريخ 22/10/2026 لا مشروعَ تبنٍّ وطني ولا تعليقًا على 27090.

الحصول على المعيار واللغة والنسخ الوطنية

يصدر المعيار باللغة الإنجليزية حصرًا. تطلب ISO مقابله 204 فرنكات سويسرية (CHF)، وتبيع DIN Media الأصل الصادر عن ISO تحت التسمية ⁦ISO/IEC 27090:2026-10⁩ بسعر 218,32 يورو صافي، ويُدرج في متجر IEC الإلكتروني بوصفه المنشور 117332. ولا توجد نسخة ألمانية: فـ DIN Media وSNV تبيعان الأصل الإنجليزي الصادر عن ISO فقط، ولا يُعرف تبنٍّ من ÖNORM، أما التبنّي البريطاني BS ISO/IEC 27090:2026 فمعلن ليوم 31 أكتوبر 2026. ويمكن الاطلاع مجانًا على معاينات تتضمن جدول المحتويات والمقدمة والبنود من 1 إلى 4 ومن 5.1 إلى 5.3 وقائمة المراجع؛ أما البنود من 5.4 إلى 7 والجدول 1 والملاحق فلا تتوفر إلا في النسخة الكاملة، ويستند ما تورده هذه الصفحة بشأنها إلى جدول المحتويات وتحليلات FDIS وهو موسوم بذلك.

معيار إرشادي لا معيار نظام إدارة

ISO/IEC 27090 معيار دولي ذو طابع إرشادي. ويتحدث الشرح التوضيحي الصادر عن ISO نفسها عن مبادئ توجيهية أمنية لا عن متطلبات لنظام إدارة الذكاء الاصطناعي؛ فلهذه يحيل البند 5.2 إلى ISO/IEC 42001. ولا توجد شهادة «ISO 27090» ولا تدقيق «وفق 27090» ولا افتراض مطابقة بموجب قانون الذكاء الاصطناعي الأوروبي (AI Act) أو قانون المرونة السيبرانية (Cyber Resilience Act). ومع ذلك ليس المعيار مجرد مجموعة توصيات: فالبند 5.1 يتضمن جملتين موثّقتين بصيغة الإلزام («shall»)، تقضيان بتنفيذ ضوابط أمن المعلومات، مثل تلك الواردة في ISO/IEC 27002، على أساس المخاطر، وبمراعاة الاختراقات الخاصة بالذكاء الاصطناعي على امتداد دورة الحياة بأكملها. وفي الممارسة العملية يعني ذلك: لا متطلبات قابلة لمنح الشهادات، لكن توقّعًا واضحًا بمعالجة التهديدات الواردة في البند 6 ضمن إدارة المخاطر الخاصة بكم.

النطاق: التطوير أو الاستخدام

يصف البند 1 الموضوع على النحو التالي: التهديدات والاختراقات ذات الصلة بالأمن والخاصة بأنظمة الذكاء الاصطناعي، وعواقبها، وكشفها والتخفيف منها على امتداد دورة الحياة بأكملها — بما ينطبق على الشركات والجهات الحكومية والمنظمات غير الربحية التي تطوّر أنظمة ذكاء اصطناعي أو تستخدمها. وتتحدث المقدمة عن التطوير أو النشر، والبند 5.1 عن الفاعلين على امتداد سلسلة التوريد. ولا يعرّف البند 3 دورَي المزوّد والمشغّل الواردين في قانون الذكاء الاصطناعي الأوروبي (AI Act) ولا أدوار أصحاب المصلحة الواردة في ISO/IEC 22989؛ ولذلك فإن أي إسناد للتدابير إلى الأدوار يبقى تفسيرًا. والنطاق غير مقتصر على الذكاء الاصطناعي التوليدي.

المراجع المعيارية والإعلامية

يستشهد المعيار معياريًا بوثيقتين فقط: ISO/IEC 22989 دون تاريخ، أي بما يشمل التعديلات المستقبلية مثل التعديل الجاري بشأن الذكاء الاصطناعي التوليدي، وISO/IEC 23053:2022. أما ISO/IEC 27001 و27002 و42001 و23894 و5338 و38507 فترد في قائمة المراجع فقط، لكنها تُذكر صراحةً في 5.1 و5.2 بوصفها أساس العمل. ويأخذ البند 3 أهداف الحماية من المعيار الجديد ISO/IEC 27000:2026، ومفاهيم التهديد والهجوم والثغرة من ISO/IEC 27002:2022.

ما ليس موضوعًا للمعيار

• متطلبات نظام إدارة الذكاء الاصطناعي: يحيل البند 5.2 إلى ISO/IEC 42001.
• مخاطر حماية البيانات في أنظمة الذكاء الاصطناعي: موضوع المعيار الشقيق ISO/IEC 27091.
• الذكاء الاصطناعي كأداة دفاع، وكذلك التهديدات التي تكتفي باستخدام الذكاء الاصطناعي، مثل التزييف العميق (Deepfakes) أو التصيّد المدعوم بالذكاء الاصطناعي.
• هجمات الذكاء الاصطناعي على الذكاء الاصطناعي، وكذلك السلامة الوظيفية (Safety) التي يختص بها ISO/IEC TR 5469.
• افتراض المطابقة بموجب قانون الذكاء الاصطناعي الأوروبي (AI Act) أو قانون المرونة السيبرانية (Cyber Resilience Act): فـ 27090 ليس معيارًا منسّقًا، ولا يوجد ربط رسمي بـ prEN 18282 أو ETSI TS 104 223.

27090 و27091: الأمن وحماية البيانات كثنائي

لم يُنشر بعد ISO/IEC 27091 «Cybersecurity and Privacy — Artificial Intelligence — Privacy protection»؛ ولم يكن تصويت FDIS قد بدأ بتاريخ 22/10/2026. ووفق ملخصات مبنية على DIS، يتناول المعيار تحليل حماية البيانات، وخصوصية نماذج الذكاء الاصطناعي، وهندسة الخصوصية (Privacy Engineering) في دورة الحياة. والتداخل واضح: فـ Membership Inference وModel Inversion يردان في كلا المعيارين، في 27090 كتهديد أمني لسرية بيانات التدريب، وفي 27091 كخطر على حماية البيانات. وصدوره في مطلع عام 2027 أمر معقول، لكنه ليس تاريخًا مستهدفًا من ISO.

البند 5: البند 5.1 إطارًا، وست ممارسات

يضع البند 5.1 الإطار: أنظمة الذكاء الاصطناعي مكوّنات برمجية مدمجة تنطبق عليها ضوابط ISO/IEC 27002 على أساس المخاطر، ويجب مراعاة الاختراقات الخاصة بالذكاء الاصطناعي، بما فيها تلك الواردة في الجدول 1، على امتداد دورة الحياة وفق ISO/IEC 22989 و5338. ويذكر المعيار كنقطة انطلاق فعّالة تحصين حزمة البرمجيات (Software Stack) ضد السرقة المباشرة للنموذج، وكأمثلة ETSI EN 304 223 وإطار NIST Secure Software Development Framework. ويصف البند 5.2 برنامج حوكمة يتضمن الجرد وتحليل المخاطر ومعالجتها، ويقسّم البند 5.5 إدارة سلسلة التوريد إلى خمسة أقسام فرعية من التهديدات العامة مرورًا بالتهديدات الخاصة بالذكاء الاصطناعي وصولًا إلى الاستراتيجيات المضادة. ويعتمد البند 5.3 مبادئ انعدام الثقة (Zero Trust) الستة من البند 8.27 في ISO/IEC 27002، ويوضّحها بخمسة أمثلة تصل إلى التحقق من إجراءات الوكلاء، ويعلن أنها تتخلل جميع أقسام التخفيف في البند 6.

البند 6: تسعة أنواع وفق نسق موحّد

يُشار إلى الجدول 1 في البند 5.1 لكنه لا يرد هناك؛ ووفق قراءتنا فهو موضوع في 6.1 ويسرد، بحسب تحليل FDIS، اثني عشر نوعًا من الهجمات: تسعة من البند 6 وثلاثة من الملحق B.

البند 7 والملاحق

البند 7 قصير بأربع صفحات، لكنه في تقديرنا أهم موضع في المعيار لقرارات التدابير. يتناول البند 7.2 التفاعلات المتعارضة، ويذكر تحليل FDIS مثالًا على ذلك تدريبًا عدائيًا (Adversarial Training) زاد القابلية للتأثر بهجمات الرقع (Patch)، ويوصي باختبار جميع التدابير معًا قبل النشر. ويتناول البند 7.3 استمرارية التدابير على امتداد دورة الحياة، ويصف البند 7.4 تدهور النموذج والتدابير مع المراقبة وإعادة التدريب عند الحاجة وإعادة التحقق قبل الإعادة إلى التشغيل؛ ويفصل البند 7.7 المدخلات الخارجة عن التوزيع (Out-of-Distribution)، التي ليست بالضرورة هجمات، عن المدخلات العدائية. ويربط الملحق A الهجمات بدورة الحياة والأصول، ويصف الملحق B النسخ الخاصة بالذكاء الاصطناعي من الهجمات التقليدية، والملحق C التعلّم الموحّد.

المصطلحات والاختصارات وقائمة المراجع

يعرّف البند 3 ما مجموعه 30 مصطلحًا، من بينها التقسيم الثلاثي لمعرفة المهاجم إلى هجمات بمعرفة معدومة وجزئية وكاملة (Zero-, Partial-, Perfect-Knowledge) بدلًا من استعارة الصندوق الأسود والرمادي والأبيض (Black-, Grey-, White-Box). وترد أنواع الهجمات في المصطلحات من 3.13 إلى 3.24، مع تعريف لحقن الموجّهات (Prompt Injection) واسع بما يكفي ليشمل المحتوى الذي يعمل كتعليمة إدخال أو ضمنها، وبذلك النسخة غير المباشرة أيضًا. ولم تُعرَّف مصطلحات وكيل الذكاء الاصطناعي والاختراق (compromise) والذكاء الاصطناعي التنبؤي. ويسرد البند 4 ما مجموعه 15 اختصارًا من AI مرورًا بـ DP وJIT وOOD وRAG وصولًا إلى RT؛ ويغيب MCP، وهو وفق توجيهات ISO/IEC مؤشر قوي على أن Model Context Protocol لا يرد في نص المعيار. ولا يُستشهد بـ NIST AI RMF ولا ⁦NIST AI 100-2⁩ ولا OWASP Top 10 for LLM Applications ولا OWASP Agentic Top 10 ولا Model Context Protocol — وهي تحديدًا الوثائق التي تكمّل بها هذه الصفحة المعيار.

الأطروحة الأساسية في المقدمة

تصوغ المقدمة أربع أفكار يقوم عليها بقية المعيار. أولًا، تبقى الممارسة وفق ISO/IEC 27001 و27002 موصى بها، لأن أنظمة الذكاء الاصطناعي برمجيات وتشترك في جميع الثغرات المعروفة. ثانيًا، يمكن أن تتحول بيانات التشغيل في حالة التعلّم المستمر إلى بيانات تدريب، فيصبح التشغيل ناقلًا للتسميم. ثالثًا، يمكن أن تنجح عملية تسريب نموذج عبر استعلامات مشروعة رغم سلامة جميع الضوابط القياسية؛ ويساعد هنا تحديد معدل الطلبات (Rate Limiting). رابعًا، الكشف صعب لكنه لا غنى عنه، ولذلك يضع المعيار الدفاع في العمق (Defence-in-Depth) مبدأً موجّهًا ويخصص لكل نوع هجوم قسمًا للكشف.

الأصول وأهداف المهاجم

وفق التحليل المبني على FDIS للجدول 1، يرتّب المعيار أنواع هجماته الاثني عشر بحسب الأصل المتأثر أولًا: النموذج، وبيانات التدريب، وبيانات الاختبار، والمخرجات، والخدمة. ويُضاف إلى ذلك من البند 5.1 حزمة البرمجيات التي يُدمج فيها نظام الذكاء الاصطناعي، ومن البند 5.5 سلسلة التوريد التي تشمل، وفق تحليل FDIS، النماذج المدرّبة مسبقًا ومجموعات البيانات المشتراة ومنصات الدفاتر (Notebooks) وأدوات MLOps. ولذلك ينبغي لجرد الذكاء الاصطناعي وفق البند 5.2 أن يسجّل لكل نظام: عنصر النموذج، والبيانات، ومصادر الاسترجاع، وموجّهات النظام (System Prompts)، والواجهات، وصلاحيات الأدوات، وخط المعالجة (Pipeline). ووفق قراءتنا تقف وراء الأنواع التسعة ستة أهداف للمهاجم.

معرفة المهاجم والمراحل الزمنية

يميّز البند 3 في المصطلحات من 3.10 إلى 3.12 بين هجمات دون معرفة بالنموذج، وبمعرفة جزئية، وبمعرفة كاملة، وفي كل الحالات دون بيانات اعتماد للوصول. ويكشف ذلك تركيز الطبعة الأولى: فالمهاجم النموذجي هو طرف خارجي يتصرف بشكل موجّه. وقد انتقد Gary Hinson أن التهديدات العرضية والمطّلعين الداخليين (Insider) والعواقب خارج نطاق المنظمة نفسها ممثَّلة تمثيلًا ناقصًا؛ ومع ذلك يصنّف الجدول 1 وفق تحليل FDIS كل نوع كسيناريو مهاجم أو سيناريو حادث عرضي. أما المطّلعون الداخليون ذوو الصلاحيات المشروعة والإعدادات الخاطئة فعليكم إضافتهم إلى سجل المخاطر بأنفسكم. وزمنيًا يرتّب البند 5.1 الهجمات بحسب ما إذا كانت تبدأ أثناء التطوير والتدريب، أو أثناء الاستدلال والتشغيل، أو في كلتا المرحلتين.

يذكر المعيار في 5.1 دورة الحياة وفق ISO/IEC 22989 و5338 من الفكرة حتى الإخراج من الخدمة، ويربط في الملحق A الهجمات بمراحل دورة الحياة والأصول؛ غير أن أعمدة هذا الملحق غير مرئية في المعاينات. أما المراحل الست في هذه الصفحة، مع المحورين العرضيين سلسلة التوريد والحوكمة، فهي نموذج عمل من VamiSec يسترشد بهذين المعيارين دون أن يستنسخ أي تسمية مراحل من 27090.

1. 1
   المرحلة 01 · التطوير/التدريبالبيانات واقتناؤها

   Data Poisoning (6.2) ونوعا الملحق B: Direct Training Data Leak وModel Input Leak؛ وتُعدّ مجموعات البيانات المقتناة جزءًا من سلسلة التوريد وفق 5.5. المرتكزات: تتبّع المنشأ (6.11.4)، والحدّ من البيانات (6.11.2).

2. 2
   المرحلة 02 · التطوير/التدريبالتطوير والتدريب

   يستهدف Direct Model Poisoning (6.7) والأبواب الخلفية Backdoors (3.24) ملفات النموذج وخط الإنتاج. المرتكزات: بيئة التطوير (7.6)، وهندسة البرمجيات (5.4)، وانعدام الثقة (Zero Trust) لبيانات التدريب (5.3).

3. 3
   المرحلة 03 · الانتقالالتحقق والتثبّت

   هنا تصبح القابلية للتأثر بهجمات Evasion وMembership Inference وModel Inversion قابلة للقياس قبل أن يستغلها المهاجمون. المرتكزات: Red Teaming (5.7)، ونمذجة التهديدات Threat Modelling (5.6)، والاختبار المشترك لجميع التدابير (7.2).

4. 4
   المرحلة 04 · الاستدلال/التشغيلالنشر والتكامل

   مع الربط بالتطبيقات ومصادر الاسترجاع والأدوات تنشأ أسطح الهجوم لـ Prompt Injection (6.9) والمخرجات الحاملة لهجمات حقن (6.10). المرتكزات: حدود التطبيق والوصول إلى النموذج بما في ذلك RAG (5.3)، وترشيح المدخلات (7.7)، وتقييد المعدّل (7.8).

5. 5
   المرحلة 05 · الاستدلال/التشغيلالتشغيل والمراقبة

   تجري هجمات Evasion (6.3) وMembership Inference (6.4) وModel Exfiltration (6.5) وModel Inversion (6.6) وSensitive Model Output (6.8) عبر استعلامات مشروعة. المرتكزات: التسجيل والمراقبة (7.5)، وأقسام الكشف ⁦6.x.3⁩، وسلوك النموذج غير المرغوب فيه أثناء التشغيل (6.11.3).

6. 6
   المرحلة 06 · الطبقتان معًاإعادة التقييم والإخراج من الخدمة

   يتقادم النموذج والتدابير مع مرور الوقت (7.4): مراقبة، وإعادة تدريب عند الحاجة، وإعادة تثبّت قبل إعادة الإدخال في الخدمة. وتفتح إعادة التدريب ببيانات التشغيل من جديد متجه التسميم الوارد في 6.2. أما الإخراج من الخدمة فلا تتناوله النسخة المتاحة للعموم؛ ويخصّص له ETSI EN 304 223 مبدأً مستقلًا.

التعلّم المستمر: حين يصبح التشغيل مرحلة تدريب

تؤكد المقدمة وصفحة كتالوج ISO النقطة نفسها: تحتاج إعادة التدريب والتحديثات إلى عناية أمنية، لأن مدخلات التشغيل قد تتحول إلى بيانات تدريب. ينص القسم 6.7 على Model Poisoning المباشر في التطوير أو التشغيل، ويتناول 7.3 استمرارية التدابير، ويصف 7.4 تقادم النموذج والتدابير، ويمدّ 5.3 مبدأ انعدام الثقة (Zero Trust) من إدارة بيانات التدريب حتى تشغيل الوكلاء. وبالنسبة إلى مسؤولي أمن المعلومات (CISOs) يعني ذلك: كل تغذية راجعة لبيانات المستخدمين إلى نموذج، ولو عبر وظائف التغذية الراجعة أو مخازن الذاكرة أو فهارس RAG، هي انتقال إلى مرحلة التدريب وتستلزم الموافقات نفسها التي استلزمها الاقتناء الأصلي للبيانات.

6.2 Data Poisoning: سلامة بيانات التدريب

يتلاعب Data Poisoning بالبيانات التي يتعلّم منها النموذج، وينطلق من مرحلتي التطوير والتدريب، وعند التعلّم المستمر من مرحلة التشغيل أيضًا. تُفسد الأشكال الموجّهة سلامة بيانات التدريب والمخرجات، بينما تصيب الأشكال غير الموجّهة التوافر؛ ويورد المعيار هجمات الأبواب الخلفية (Backdoor) مصطلحًا عامًا لا نوع اختراق مستقلًا. ويصف تحليل FDIS قسم الكشف بأنه بمثابة إقرار: فالأساليب الآلية لا تفصل البيانات المسمومة عن القيم الشاذة بموثوقية. لذلك ينتقل التخفيف إلى مرحلة أبكر: تتبّع المنشأ، وفحوص السلامة على امتداد خط الإنتاج، والحدّ من البيانات التي تصل أصلًا إلى النموذج (6.11.4، 6.11.2). ولا يتناول المعيار تسميم قاعدة استرجاع بوصفه نوعًا مستقلًا؛ ويورد OWASP لذلك LLM05 وLLM09 وASI06، ويورد MITRE ATLAS التقنية AML.T0080، ويذكر الدليل التوجيهي الصادر عن BaFin صراحةً تسميم معرفة قاعدة RAG. توصية VamiSec: إخضاع فهارس RAG ومخازن الذاكرة وبيانات التغذية الراجعة لإجراءات الموافقة نفسها المطبّقة على بيانات التدريب.

6.7 Direct Model Poisoning: التلاعب بالنموذج نفسه

لا ينطلق Model Poisoning المباشر وفق 3.18 من البيانات، بل من النموذج مباشرةً، في التطوير أو في التشغيل؛ والمتضرر هو سلامة النموذج. وتشمل عائلة التدابير، وفق قراءتنا، حماية بيئة التطوير وفق 7.6، والتوقيعات ومجاميع التحقق لملفات النموذج، والتنفيذ داخل بيئة تنفيذ موثوقة (Trusted Execution Environment) التي يستعيرها البند 3 من ISO/IEC 27071. وتوضح حالتان الآلية: PoisonGPT من يوليو 2023، وهو نموذج GPT-J-6B جرى التلاعب به عبر تحرير النموذج ونُشر على Hugging Face تحت الاسم المقلَّد (Typosquat) «EleuterAI»، وnullifAI من فبراير 2025، وهما نموذجان بملفات Pickle تالفة وReverse Shell. وكلتاهما في معظمهما إثبات مفهوم. والحدّ الفاصل مع سلسلة التوريد غير قاطع، ولذلك يتناول الفصل 13 من هذه الصفحة الحصول على النماذج من مصادر خارجية على نحو مستقل.

6.8 والملحق B: البيانات التي يفشيها النموذج

يعني Sensitive Model Output وفق 6.8 أن النموذج يكشف عبر مخرجاته بيانات تدريب سرية، أو وفق 3.22 مدخلات سابقة أيضًا، وذلك أثناء الاستدلال؛ ويتكوّن التخفيف، وفق قراءتنا، من مرشّحات المخرجات والحدّ من البيانات وفق 6.11.2. ويضيف الملحق B المسارات التقليدية إلى النتيجة نفسها: السرقة المباشرة لبيانات التدريب وتسريب مدخلات النموذج، المعرّفان في 3.20 و3.21. والمثال الأبرز على 6.8 هو EchoLeak، وهي ثغرة دون نقرة (Zero-Click) في Microsoft 365 Copilot أتاحت تسرّب بيانات داخلية عبر المخرجات (CVE-2025-32711، أُصلحت في مايو 2025). أما Membership Inference وModel Inversion فيتناولهما الفصل 7 من هذه الصفحة.

Evasion: الخداع بدل التلاعب

Evasion هو الهجوم الكلاسيكي على النماذج التنبؤية: تُعدَّل صورة أو معاملة أو نص تعديلًا طفيفًا فينقلب التصنيف. ويُدرج المعيار الكشف ضمن 7.7 الذي يفصل المدخلات الخارجة عن التوزيع (Out-of-Distribution) عن المدخلات العدائية. ويندرج ضمن التخفيف التدريب العدائي (Adversarial Training)؛ وتشير الاختصارات EOT وRT وIDBT في البند 4 إلى تحويلات المدخلات بوصفها تقنية إضافية، غير أن ربطها بـ 6.3.4 هو قراءتنا الخاصة. والحاسم هو التنبيه الوارد في 7.2: يذكر المعيار، وفق تحليل FDIS، حالة تدريب عدائي زاد القابلية للتأثر بهجمات الرقع (Patch)، ولذلك يوصي باختبار جميع التدابير معًا قبل إدخال النموذج في التشغيل. ولم يُنشر حتى الآن أي حادث Evasion إنتاجي موثّق.

Model Exfiltration: السرقة عبر الاستعلام

تورد المقدمة Model Exfiltration مثالًا نموذجيًا على أن جميع الضوابط القياسية قد تكون سليمة ومع ذلك يُفقد النموذج، لأن كل استعلام على حدة مشروع. ويستند الكشف والدفاع إلى التسجيل والمراقبة وفق 7.5، حيث يذكر المعيار صراحةً ISO/IEC 27002 8.15 و8.16، وإلى تقييد استخدام النموذج وفق 7.8، وتحسين حجم النموذج وفق 7.9. ويضع الملحق B إلى جانب ذلك السرقة المباشرة للنموذج وفق 3.19، التي يذكرها 5.1 سببًا لتقوية حزمة البرمجيات أولًا. وأشهر الحالات اتهام: فقد صرّحت OpenAI اعتبارًا من 28/01/2025 بأن DeepSeek ربما قطّرت نماذجها (Distillation) بصورة غير مشروعة؛ ولم تُنشر أدلة على ذلك.

Membership Inference وModel Inversion: سرية بيانات التدريب

يستغل الهجومان كون النماذج تخزّن جزءًا من بيانات تدريبها وتفشيه عبر الاحتمالات أو قيم الثقة أو الصياغات. وينطلق التخفيف، وفق قراءتنا، من ثلاثة مواضع: الخصوصية التفاضلية (Differential Privacy) في التدريب، التي يورد البند 4 اختصارها DP، وقصر المخرجات على الضروري، والحدّ من البيانات وفق 6.11.2. ولا يوجد حادث إنتاجي موثّق علنًا للفترة من 2024 إلى 2026؛ وتحيل قائمة المراجع، بعمل Carlini حول استخراج بيانات التدريب من النماذج اللغوية، إلى الأساس البحثي. ويُدرج قانون الذكاء الاصطناعي الأوروبي (AI Act) هذه الهجمات تحت Confidentiality Attacks، ويُدرجها الدليل التوجيهي الصادر عن BaFin تحت المصطلح الجامع Inference Attacks ويوصي بالخصوصية التفاضلية ضد الاستنتاجات المستخلصة من الاستعلامات المتكررة.

ما يقوله المعيار عن الذكاء الاصطناعي التوليدي

يعرّف البند 3 كلًا من Foundation Model وLLM والذكاء الاصطناعي التوليدي (3.27 إلى 3.29)، ويصوغ Prompt Injection في 3.23 بحيث يشمل المحتوى الذي يعمل بوصفه تعليمات إدخال أو ضمنها، وبذلك يندرج فيه الحقن غير المباشر عبر المستندات أو صفحات الويب أو رسائل البريد الإلكتروني. ويُدرج القسم 6.9 الهجوم ضمن الاستدلال؛ والمتضرر هو سلامة المخرجات وسرية معلومات النظام الداخلية مثل موجّهات النظام (System Prompts). ويشمل التخفيف، وفق قراءتنا، ترشيح المدخلات وفق 7.7، والفصل بين التعليمات والبيانات، والموافقة البشرية على الإجراءات ذات العواقب. ويتناول القسم 6.10 الحالة التي تحمل فيها مخرجات النموذج نفسها هجمات حقن ضد الأنظمة اللاحقة؛ ويكمن الدفاع، وفق قراءتنا، في ترميز المخرجات وقوائم السماح لدى الجهة المستقبِلة. ويرد RAG في البند 4 ومرتين في 5.3، حيث ينبغي أن يُصادَق على كل استعلام مستند ويُصرَّح به على حدة.

ما يقوله المعيار عن الوكلاء وما لا يقوله

تظهر كلمة Agent ثلاث مرات في الأجزاء المتاحة للعموم، وحصرًا في 5.3: في مثال التحقق من إجراءات الوكلاء، حيث يُتحقَّق من كل إجراء ويُصرَّح به على حدة، ويُمنح الوصول في الوقت المناسب (Just-in-time) بنطاق محدود، وتنقضي الصلاحيات بعد إتمام المهمة، وفي صيغة دورة الحياة الممتدة حتى تشغيل الوكلاء. أما كلمة Tool فغائبة عن الأجزاء المتاحة للعموم، وMCP غائب عن قائمة الاختصارات وقائمة المراجع، ووكيل الذكاء الاصطناعي غير معرَّف، ولا يُستشهد بـ OWASP Top 10 for LLM Applications ولا بـ Agentic Top 10 ولا بـ NIST AI 100-2. وتلخّص Heise الأمر بأن الإصدار الأول لا يتناول الأنظمة الوكيلية ذات الوصول إلى الأدوات إلا هامشيًا. وهذا نتيجة لإيقاع التقييس: فمسودة اللجنة (Committee Draft) تعود إلى يناير 2024، بينما بدأت موجة الحوادث الوكيلية في 2025.

حالات واقعية من 2025 إلى 2026: Prompt Injection أصبح عمليًا

قائمة الحالات الخاصة بـ 6.9 و6.10 طويلة وواقعية في معظمها: EchoLeak في Microsoft 365 Copilot (دون نقرة، أُصلحت في مايو 2025)، وForcedLeak في Salesforce Agentforce، حيث تسرّبت بيانات CRM على هيئة طلب صورة إلى نطاق منتهي الصلاحية في قائمة السماح (CVSS 9.4)، وShareLeak في Copilot Studio (CVE-2026-21520)، والعرض البحثي Comment and Control من أبريل 2026، حيث دفع حقن في عنوان طلب سحب (Pull Request) وكيل برمجة إلى نشر مفتاح API الخاص به، والثغرة في Claude Code GitHub Action (أُصلحت في 05/05/2026). وأحصت Unit 42 في مارس 2026 اثنتي عشرة حالة Prompt Injection غير مباشر في العالم الحقيقي بـ 22 تقنية حمولة (Payload). وبالنسبة إلى 6.10 فإن Amazon Q Developer 1.84.0 حالة تعليمية: كان يُفترض أن تشغّل شيفرة مُحقَنة وكيلًا دون استئذان بكامل صلاحيات الأدوات وتحذف البيانات، لكنها فشلت بسبب خطأ نحوي (CVE-2025-8217).

الجملتان الإلزاميتان في 5.1 — وما تعنيانه

بحسب مراجعتنا، تتضمن الأجزاء المتاحة للعموم من المعيار جملتين مصوغتين بصيغة إلزامية في النص الفني، كلتاهما في 5.1 — دون احتساب العبارات الشكلية النمطية في التمهيد (Foreword): يجب تطبيق ضوابط أمن المعلومات كما يصفها ISO/IEC 27002 على أساس المخاطر، ويجب مراعاة الاختراقات الخاصة بالذكاء الاصطناعي، ومنها تلك المدرجة في Table 1، على امتداد دورة الحياة بأكملها. وكل ما عدا ذلك في الأجزاء المتاحة ذو طابع إرشادي؛ ولا يمكن تحديد عدد إجمالي للوثيقة كاملةً لأن الصفحات من 8 إلى 50 لا تتوفر إلا في النسخة الكاملة. ولا يتضمن المعيار بأي حال متطلبات قابلة للاعتماد. الرسالة واضحة: نظام إدارة أمن المعلومات (ISMS) أولًا، ثم الامتداد الخاص بالذكاء الاصطناعي. ويتعامل 5.1 مع أنظمة الذكاء الاصطناعي بوصفها مكوّنات برمجية متكاملة، ويذكر تحصين حزمة البرمجيات ضد السرقة المباشرة للنموذج نقطةَ انطلاق فعّالة.

5.2 برنامج الحوكمة: الجرد وتحليل المخاطر والتحكم

يصف القسم 5.2 ثلاث لبنات: جرد أنظمة الذكاء الاصطناعي، وتحليل المخاطر، والتحكم في المخاطر المحددة. ويحيل المعيار في شأن الحوكمة إلى ISO/IEC 38507، وفي شأن التطبيق كنظام إدارة إلى ISO/IEC 42001. وما لا يقدّمه المعيار: لا يعرّف البند 3 أدوار قانون الذكاء الاصطناعي الأوروبي (AI Act) للمزوّد (Provider) والناشر (Deployer)، ولا أدوار أصحاب المصلحة الواردة في ISO/IEC 22989. ومن يُسند المسؤوليات فإنما يفعل ذلك بوصفه تفسيرًا خاصًا به، وينبغي له الإشارة إلى ذلك في وثيقة الحوكمة.

ما الذي ينتمي إلى جرد أنظمة الذكاء الاصطناعي

• مصدر النموذج وإصداره: مدرَّب داخليًا، أو نموذج مفتوح المصدر من مستودع، أو نموذج أساس (Foundation Model) في المستأجر (Tenant) الخاص، أو واجهة برمجية خارجية (API) — فطريقة الحصول على النموذج هي ما يحدد سطح الهجوم.
• مصادر بيانات التدريب والضبط الدقيق (Fine-Tuning) والاسترجاع مع المنشأ والاعتماد والمالك؛ ويتناول 6.11.4 منشأ النظام والبيانات موضوعًا مستقلًا.
• الوصول للاستعلام وعبر الواجهة البرمجية (API): من يحق له استعلام النموذج وبأي حدود — وهو الأساس في مواجهة الاستخراج (6.5) وهجمات الاستدلال (6.4، 6.6).
• أدوات المكوّنات الوكيلية (Agentic) وإجراءاتها وصلاحياتها؛ ويذكر التحليل القانوني في arXiv 2604.04604 جردًا كاملًا للإجراءات الخارجية وتدفقات البيانات بوصفه الواجب الأول.
• المالك ودرجة الحرجية والتصنيف التنظيمي: عالي المخاطر وفق قانون الذكاء الاصطناعي الأوروبي (AI Act)، أو وظيفة حرجة أو مهمة وفق DORA، أو منتج ذو عناصر رقمية وفق CRA.

النقطة العمياء اسمها الذكاء الاصطناعي الظلّي (Shadow AI): في استطلاع CSA/Token Security الصادر في 21.04.2026 أفاد 82 في المائة من 418 مشاركًا بوجود وكلاء ذكاء اصطناعي غير معروفين، ووفق تقرير IBM الصادر في 30.07.2025 غابت ضوابط الوصول الخاصة بالذكاء الاصطناعي في 97 في المائة من الخروقات الأمنية المرتبطة بالذكاء الاصطناعي. الدراسات ممولة من جهات مصنّعة، لكن الاتجاه واضح: من دون جرد يبقى تحليل المخاطر وفق 5.2 ناقصًا، ولا يصيب أي تدبير إلا الأنظمة المعروفة.

تنبيه للاقتباس: يُشار إلى Table 1 في 5.1 لكنه لا يرد هناك؛ ولا يمكن الاطلاع على موضعه ومحتواه إلا في النسخة الكاملة. وتَعُدّ هذه الصفحة الأنواع التسعة من 6.2 إلى 6.10.

هندسة البرمجيات للذكاء الاصطناعي (5.4): لا مسار استثنائي

ينقل القسم 5.4 الممارسات الراسخة في تطوير البرمجيات إلى أنظمة الذكاء الاصطناعي؛ ويحيل المعيار إلى إطار NIST Secure Software Development Framework (⁦SP 800-218⁩)، كما تورد قائمة المراجع إرشادات NCSC لتطوير الذكاء الاصطناعي الآمن. والموقف براغماتي: نظام الذكاء الاصطناعي هو برمجية أولًا، ومن لا يحصّن حزمته التقنية يفقد النموذج عبر الطرق التقليدية — ويورد الملحق B السرقة المباشرة للنموذج بوصفها نسخة خاصة بالذكاء الاصطناعي من هجوم كلاسيكي. وفي ISO/IEC 42001 يقع المقابل، بحسب قراءتنا، في A.6.2.3، أي توثيق التصميم والتطوير، الذي يستشهد به 27090 في 5.1.

الدفاعات المتعلقة بالبيانات: المنشأ والسلامة والتحديد

الكشف: مسألة بحثية مفتوحة

في ما يخص كشف تسميم البيانات (6.2.3) يبدو المعيار متحفظًا على نحو لافت: فبحسب التحليل المستند إلى FDIS يصف الموضوع بوصفه مسألة بحثية مفتوحة، لأن الأساليب الآلية لا تفصل البيانات المسمومة عن القيم الشاذة بشكل موثوق. ويترتب على ذلك ترجيح نشاركه: الوقاية عبر المنشأ والاعتماد والتحكم في الوصول أثقل وزنًا من الكشف اللاحق، وتصبح مراقبة تدهور النموذج في 7.4 خط الدفاع الثاني. وتذكر المقدمة (Introduction) الآلية التي تنقل الموضوع إلى مرحلة التشغيل: في التعلم المستمر تتحول بيانات التشغيل إلى بيانات تدريب، وتغدو كل جولة إعادة تدريب متجهًا جديدًا للتسميم.

وينطبق المبدأ نفسه على جانب المعرفة في التوليد المعزَّز بالاسترجاع (Retrieval Augmented Generation): يصف 5.3 في المثال الخاص بحدود التطبيق أن كل استعلام عن مستند يُصادَق عليه ويُصرَّح به على حدة، ويتحدث الدليل التوجيهي لهيئة BaFin عن تسميم المعرفة في قاعدة RAG (ص. 29). ومن يحمّل مستندات المؤسسة دون فحص في فهرس متجهات فإنما يبني متجه التسميم بنفسه.

ما يقوله المعيار عن الاختبار

يضع البند 5 نمذجة التهديدات في 5.6 وRed Teaming في 5.7 إلى جانب الحوكمة وسلسلة التوريد بوصفها ممارسات أساسية؛ ويحمل كل نوع اختراق في البند 6 قسمًا فرعيًا عن الكشف. ويعلّل البند 7 لماذا لا يكفي الاختبار لمرة واحدة: يصف 7.2 التفاعلات المتبادلة بين التدابير ويذكر مثالًا أن التدريب العدائي (Adversarial Training) زاد القابلية للتأثر بهجمات الرقع (Patch Attacks) — ويوصي المعيار باختبار جميع التدابير معًا قبل النشر. ويضيف 7.4 التدهور بمرور الوقت مع المراقبة، وإعادة التدريب عند الحاجة، وإعادة التحقق قبل العودة إلى التشغيل.

متى نختبر: محفّزات بدل التقويم

• قبل النشر: اختبار جميع تدابير التخفيف معًا، لأنها قد تُضعف بعضها بعضًا (7.2).
• بعد تغيير النموذج أو موجّه النظام (System Prompt) أو مصدر الاسترجاع — وهي المحفّزات الثلاثة التي تذكرها Kertos لتكرار Red Teaming.
• بعد كل جولة إعادة تدريب: إعادة التحقق قبل العودة إلى التشغيل (7.4).
• بعد تحديثات النموذج من جانب المزوّد: ولذلك تنتمي الإشعارات بالتحديثات إلى متطلبات المورّدين — تذكرها Kertos بندًا تعاقديًا، ويذكر الدليل التوجيهي لهيئة BaFin للنماذج المشتراة العناية الواجبة (Due Diligence) واتفاقيات مستوى الخدمة (SLAs) ممارسةً معتادة (الفصل IV.2).
• بشكل متكرر للتدابير التي تتراجع فعاليتها: مرشّحات المدخلات وعتبات الشذوذ تشيخ مع تطور مشهد التهديدات.
• في الأنظمة الوكيلية بعد كل تغيير في الأدوات أو الصلاحيات أو الربط بالأنظمة الأخرى (توصية VamiSec تتجاوز ما ورد في 5.3).

الصلة التنظيمية وثيقة: يشترط قانون الذكاء الاصطناعي الأوروبي (AI Act) للذكاء الاصطناعي عالي المخاطر في المادة 9 الفقرات 6 إلى 8 إجراء اختبارات ضمن إدارة المخاطر؛ ويشترط DORA في المادتين 24 و25 برنامج اختبار يشمل اختبارات الاختراق ومراجعات الشيفرة المصدرية، وتصف BaFin كممارسة بحسب درجة الحرجية الاختبار العدائي، واختبارات الاختراق العدائية بالتعاون مع مزوّد السحابة، واختبارات الضغط. يوفّر ISO/IEC 27090 مصطلحات الهجوم ومنطق الاختبار — لا الالتزام.

Red Teaming في ISO/IEC 27090 ليس فحصًا إلزاميًا ولا فحص اعتماد. ويحدد النطاقَ والدورية تحليلُ المخاطر ودرجة الحرجية، وحيثما ينطبق، قانون الذكاء الاصطناعي الأوروبي (AI Act) أو DORA أو CRA.

5.3 انعدام الثقة (Zero Trust): خمسة أمثلة تتدفق في جميع تدابير التخفيف

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

يتطابق هذا الخط مع الأوراق الصادرة عن الجهات الرسمية منذ 2025: يصف BSI وANSSI في مبادئ التصميم للأنظمة القائمة على النماذج اللغوية الكبيرة (LLM) الصادرة في 11.08.2025 ستة مبادئ تمتد من المصادقة والتصريح مرورًا بالعزل (Sandboxing) والمراقبة وصولًا إلى التوعية، ويؤكدان أنه لا يجوز للنموذج اللغوي الكبير أبدًا أن يقوم بالمصادقة بنفسه؛ وتثبت NSA في دراستها الأمنية لبروتوكول MCP الصادرة في مايو 2026 أن التصريح في البروتوكول اختياري. وبحسب تقييمنا، ليس ISO/IEC 27090 الصياغة الأكثر تفصيلًا لهذا الإجماع، لكنه الصياغة الأكثر قابلية للربط بنظامي ISMS وAIMS.

تدابير التشغيل لكل نوع اختراق

الكشف والحوادث: ما يقوله المعيار وما يجب أن يوفّره نظام إدارة أمن المعلومات

تصوغ المقدمة (Introduction) الجوهر: الكشف صعب لكنه جوهري، وتسريب النموذج (Model Exfiltration) ينجح عبر استعلامات مشروعة رغم سلامة الضوابط القياسية — ويساعد تحديد معدل الطلبات (Rate Limiting). ولذلك يحمل كل نوع اختراق قسمًا للكشف، ويجمع 7.5 التسجيل والمراقبة. ولا يتضمن هيكل المعيار قسمًا مستقلًا لمعالجة الحوادث؛ ومن وجهة نظرنا تحتاج إدارة الحوادث في نظام إدارة أمن المعلومات إلى ثلاث إضافات: وسم الحوادث المرتبطة بالذكاء الاصطناعي، وقنوات الإبلاغ إلى مزوّدي النماذج، وقواعد كشف لأنماط الاستعلام واستدعاءات الأدوات وشذوذ المخرجات.

تُظهر الحالات الحقيقية في مرحلة التشغيل أن مسار المخرجات سطح هجوم: أتاح EchoLeak (⁦CVE-2025-32711⁩، CNA-CVSS 9.3) عبر حقن بدون نقرة (Zero-Click) تسريب بيانات داخلية من M365 عبر مخرجات Copilot — وجرى إصلاحه في مايو 2025 دون استغلال معروف؛ واستغل ForcedLeak في Salesforce Agentforce نطاقًا منتهي الصلاحية في قائمة السماح لتسريب بيانات CRM؛ وقرأ Claude Code GitHub Action بعد حقن في نصوص Issues متغيرات البيئة خارج بيئة العزل. وفي الحالات الثلاث جميعها كان من شأن مرشّحات المخرجات وقوائم السماح وتسجيل استدعاءات الأدوات الواردة في 6.8.4 و6.10.4 و7.5، بحسب تقييمنا، أن تصعّب التسريب أو تجعله مرئيًا. وفي القطاع المالي تُضاف خطة العمل التي تتوقعها الرقابة المصرفية للبنك المركزي الأوروبي (ECB) من المؤسسات المهمة حتى 31.10.2026 — ومنها التسجيل والتحقق المستمر من الواجهات البرمجية (APIs) وحسابات الخدمة، لكن بالنظر إلى الذكاء الاصطناعي كأداة هجوم، لا إلى تهديدات 27090.

التسجيل وفق ISO/IEC 27002 8.15 وRTS RMF المادة 12 يخدم الأمن؛ أما التزامات حفظ السجلات وفق المادتين 12 و26 من قانون الذكاء الاصطناعي فهي نظام قانوني مستقل — ويجب توثيق المتطلبين بشكل منفصل.

وفقاً للتقييم المستند إلى مسودة FDIS، يذكر البند 5.5 ضمن عناصر سلسلة التوريد النماذج المدرَّبة مسبقاً ومجموعات البيانات المشتراة وأدوات MLOps ومنصات Notebook. وفيما يخص الجهات الفاعلة على امتداد السلسلة، يحيل البند 5.1 إلى الضابطين A.6.2.3 وA.6.2.6 في ISO/IEC 42001، كما يورد الملحق B بحسب العرض المستند إلى مسودة DIS هجمات سلسلة التوريد بوصفها صيغة خاصة بالذكاء الاصطناعي من الهجمات التقليدية. وبذلك يصف المعيار السلسلة من مصدر البيانات مروراً بالنموذج وصولاً إلى بيئة الأدوات، دون تفضيل شكل بعينه للحصول على النموذج.

ثلاثة خيارات للحصول على النموذج، وثلاثة ملفات مخاطر

قائمة AI-BOM: ما الذي ينبغي أن تتضمنه قائمة المكوّنات

• النماذج مع المصدر والإصدار والتجزئة (Hash) أو التوقيع والترخيص، بما في ذلك النماذج الأساسية الكامنة خلف عمليات Fine-Tuning.
• مجموعات البيانات مع المنشأ والاعتماد والغرض من الاستخدام (التدريب، Fine-Tuning، الاسترجاع، الاختبار).
• الحزم والمكتبات مع تثبيت الإصدارات (Version Pinning) والتحقق من التجزئة والمطابقة مع التنبيهات الأمنية (Advisories).
• الأدوات والموصّلات وخوادم MCP للأنظمة الوكيلة مع صلاحياتها.
• أوامر النظام (System Prompts) وقوالب الأوامر ومصادر الاسترجاع — كل تغيير فيها يُعدّ محفّزاً لإعادة الاختبار.
• التزامات المزوّد وفق ISO/IEC 27002 5.19/5.20: استخدام المدخلات للتدريب، والتحقق من المكوّنات المدرَّبة مسبقاً، والإعلان المسبق عن التحديثات، والاختبارات ضد Evasion وInjection.

توصي ورقة المعلومات المشتركة للأمن السيبراني (Cybersecurity Information Sheet) حول مخاطر سلسلة توريد الذكاء الاصطناعي/تعلّم الآلة، التي أدرجتها NSA بتاريخ 13/03/2026، باعتماد AI-BOM مكمّلاً لقائمة SBOM. ويذكر الدليل التوجيهي لهيئة BaFin للشركات المالية كممارسات: العناية الواجبة (Due Diligence)، واتفاقيات مستوى الخدمة، والخروج مع تصدير النماذج وبيانات التدريب والبيانات الوصفية (الفصل IV.2)؛ وتتوقع EIOPA في رأيها الصادر في 06/08/2025 من شركات التأمين الحصول على معلومات وضمانات من مزوّدي الطرف الثالث. ويوفّر ISO/IEC 27090 مصطلحات الهجوم التي يمكن من خلالها صياغة هذه المتطلبات بشكل ملموس تجاه المزوّد.

حالات واقعية 2024–2026: سلسلة التوريد بوصفها المسلك المفضّل

درسان: أولاً، البنية التحتية تستجيب — إذ يرفض PyPI منذ 22/07/2026 إضافة ملفات جديدة إلى الإصدارات التي يزيد عمرها على 14 يوماً. ثانياً، هذا لا يكفي: فحادثة أكتوبر جرت مع وسم Git سليم ومع تفعيل النشر الموثوق (Trusted Publishing). ويعني ذلك للمشغّلين تثبيت الإصدارات مع التحقق من التجزئة، ومرآة داخلية مع مهلة تأخير قبل الاعتماد، وأسراراً قصيرة العمر بنطاق محدود — وإدراك أن بيانات اعتماد أدوات الذكاء الاصطناعي نفسها باتت هدفاً.

ثلاثة معايير وثلاثة أدوار — والمعيار الشقيق 27091

آلية بيان قابلية التطبيق: 27090 كمصدر للضوابط

يسمح ISO/IEC 27001 في البند 6.1.3 بتحديد التدابير من أي مصدر؛ فالملحق A قائمة تحقق لا حدّ. وهنا تحديداً يصبح 27090 قابلاً للربط: إذ يمكن الاستشهاد بتدابير التخفيف الواردة في ⁦6.x.4⁩ والبند 7 كمصدر في بيان قابلية التطبيق — مثل 6.8.4 لمرشّحات المخرجات أو 6.9.4 ضد Prompt Injection — دون نظام إدارة ثانٍ. وللتوسيم تصلح سمات الضوابط وفق ISO/IEC 27002 4.2. لم يُسجَّل أي تعديل خاص بالذكاء الاصطناعي على 27002:2022، ولا أي مراجعة لـ 42001:2023؛ والجديد فقط هو ISO/IEC AWI 42003 بوصفه دليل تنفيذ لـ 42001.

1. 1
   ISO/IEC 27002 5.9 · 42001 A.4.3جرد أنظمة الذكاء الاصطناعي بوصفها أصولاً

   تسجيل مصدر النموذج وبيانات التدريب وFine-Tuning ومصادر الاسترجاع وصلاحيات الاستعلام والصلاحيات الوكيلة لكل نظام.

2. 2
   ISO/IEC 27001 6.1.2 · 27090 البند 6إدراج الأنواع التسعة في تقييم المخاطر

   تقييم أنواع الاختراق وصيغ الملحق B الواقعية لكل نظام — بالإحالة إلى خيار الحصول على النموذج ومرحلة دورة الحياة.

3. 3
   ISO/IEC 27001 6.1.3اختيار التدابير والاستشهاد بـ 27090 في بيان قابلية التطبيق

   توثيق تدابير التخفيف المختارة مع رقم البند، وتبرير المستبعَد منها، وتدوين التفاعلات المتبادلة وفق 7.2.

4. 4
   ISO/IEC 27002 5.19/5.20 · 42001 A.10.3توسيع تقييم المورّدين ليشمل مزوّدي النماذج

   تطبيق قائمة الأسئلة الواردة في الفصل 13 من هذه الصفحة، وحفظ الإجابات في AI-BOM، وتثبيت الالتزامات بشأن التحديثات والاختبارات تعاقدياً.

5. 5
   ISO/IEC 27090 5.7 · 42001 A.6.2.4الاختبار وتكراره عند كل تغيير

   Red Teaming قبل النشر وبعد تغيير النموذج أو أمر النظام أو مصدر الاسترجاع؛ وإعادة إدراج التقارير في سجل المخاطر وبيان قابلية التطبيق.

ما سيسأله المدققون مستقبلاً

وبشأن مشهد الشهادات: أساس اعتماد جهات منح شهادات 42001 هو ISO/IEC 42006:2025. ولم يُعثر في قاعدة بيانات DAkkS بتاريخ 22/10/2026 على أي جهة إصدار شهادات معتمدة لـ ISO/IEC 42001، في حين أُدرجت 37 جهة لـ ISO/IEC 27001؛ وعلى المستوى الدولي حصلت جهات منها BSI Group (ANAB وUKAS وRvA) وDQS (ANAB) على اعتمادات في مارس 2026. وعلى من يسعى إلى شهادة 42001 أن يتحقق من جهة اعتماد الهيئة المختارة على حدة.

صياغات مثل «شهادة ISO 27090» أو «متوافق مع 27090» أو «تدقيق وفق 27090» خاطئة من حيث الجوهر؛ والصحيح هو: تدابير وفق ISO/IEC 27090 منفَّذة ضمن ISMS وفق 27001 أو ضمن AIMS وفق 42001.

المادة 15 الفقرة 5 من قانون الذكاء الاصطناعي: مصطلحات يملؤها 27090

يستحق مسار الافتراض عبر المادة 42 نظرة دقيقة: فالفقرة 2 تحيل إلى شهادات ضمن مخطط بموجب قانون الأمن السيبراني (Cybersecurity Act)، لكن ENISA لا تدير حتى اليوم أي مخطط مرشّح للذكاء الاصطناعي. أما القابل للاستخدام عملياً فهو الفقرة 3 التي أُدرجت بموجب لائحة Omnibus — إذ يُعدّ الذكاء الاصطناعي عالي المخاطر الواقع في نطاق CRA مطابقاً للمادة 15 متى استُوفيت المتطلبات وفق المادة 12 الفقرة 1 من CRA وأُثبتت في إعلان المطابقة الأوروبي. وبذلك يحمل تنفيذ CRA الجانب الخاص بالأمن السيبراني من قانون الذكاء الاصطناعي؛ و27090 بحسب تقييمنا هو الأداة التي يمكن من خلالها تجسيد متطلبات الملحق I من CRA لمكوّن الذكاء الاصطناعي.

النقطة الثانية تخص الأدوار: فبموجب المادة 25 من قانون الذكاء الاصطناعي يتحول المشغّل (Deployer) إلى مزوّد (Provider) إذا سوّق نظاماً عالي المخاطر باسمه أو عدّله جوهرياً أو غيّر غرضه؛ وقد يتجاوز Fine-Tuning لنماذج الغير هذه العتبة، ولأن 27090 لا يعرّف الأدوار، يجب أن يتم ربط التدابير بالدور الخاص بالمؤسسة صراحةً في وثيقة الحوكمة. وبشأن الوضع في منطقة DACH: لا توجد نسخة ألمانية، وتوزّع DIN Media وSNV النص الإنجليزي الأصلي، ولا يُعرف عن تبنٍّ من ÖNORM، ولا يذكر BSI المعيار في أي منشور؛ أما التبنّي البريطاني BS ISO/IEC 27090:2026 فمُعلن عنه بتاريخ 31/10/2026. ونصح TÜV Rheinland في مايو 2026 بعدم انتظار المعايير المنسّقة — وبعد رفض مرحلة الاستقصاء لـ prEN 18282 يصحّ ذلك من باب أولى.

لا يُنشئ ISO/IEC 27090 افتراض مطابقة بموجب قانون الذكاء الاصطناعي الأوروبي أو قانون المرونة السيبرانية؛ فالمخصص لذلك هو prEN 18282 الصادر عن CEN/CENELEC JTC 21، وما زال في مرحلة المسودة. ويحل تكليف التقييس M/613 محل M/593؛ وليس مثبتاً علناً ما إذا كان يلغيه رسمياً أو يعدّله.

1. 1
   الأيام 1–14 · 27090 5.2 · 27001 6.1توضيح التفويض والنطاق والمستوى المستهدف

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

2. 2
   الأيام 15–45 · 27002 5.9 · 27090 5.6الجرد ونموذج التهديدات (Threat Model)

   بناء جرد الذكاء الاصطناعي مع AI-BOM؛ ونموذج تهديدات لكل نظام على امتداد الأنواع التسعة والملحق B؛ وتسجيل الوكلاء مع أدواتهم وصلاحياتهم بشكل منفصل.

3. 3
   الأيام 46–90 · 27001 6.1.2/6.1.3 · 27090 البند 6تقييم المخاطر وبيان قابلية التطبيق

   تقييم المخاطر، واختيار تدابير التخفيف من ⁦6.x.4⁩ والبند 7، والاستشهاد بـ 27090 في بيان قابلية التطبيق؛ التدابير الفورية: حصص الاستعلام، وتسجيل المدخلات والمخرجات واستدعاءات الأدوات، وتثبيت الإصدارات مع التحقق من التجزئة.

4. 4
   الأشهر 4–6 · 27090 5.3، 5.5، 7.5–7.8التحصين: Zero Trust وسلسلة التوريد والتشغيل

   إعادة هيكلة الوصول إلى النماذج والبيانات وفق 5.3، وصلاحيات الوكلاء في الوقت المناسب (Just-in-Time) بنطاق ومدة انتهاء؛ وتوسيع تقييم المورّدين ليشمل مزوّدي النماذج؛ وتشغيل مرشّحات المدخلات والمخرجات والتقييد (Throttling) وكشف الشذوذ.

5. 5
   الأشهر 7–9 · 27090 5.7، 7.2، 7.4الاختبار: Red Teaming والتفاعلات المتبادلة

   Red Teaming للأنظمة ذات الأولوية، واختبار تدابير التخفيف مجتمعةً، وقياس أداء النموذج بالتوازي؛ وترسيخ محفّزات الاختبار لتغييرات النموذج والأوامر ومصادر الاسترجاع في إدارة التغيير.

6. 6
   الأشهر 10–12 · 42001 A.6.2.6 · 27001 مراجعة الإدارةإثبات الفعالية وإغلاق الدورة

   تحليل تقارير المراقبة والانحراف، وإعادة إدراج نتائج الاختبار في سجل المخاطر وبيان قابلية التطبيق، ورفع المؤشرات إلى الإدارة العليا، واشتقاق خارطة طريق السنة التالية من فحص الفجوات.

مؤشرات يفهمها مجلس الإدارة

الاعتراضات — وما نردّ به

يصلح نموذج النضج ثلاثي المستويات من Abilene Academy كفحص معقولية: حد أدنى بعد 30 يوماً مع الجرد ونماذج التهديدات وتسجيل استدعاءات الاستدلال والأدوات؛ ومستوى راسخ بعد 90 يوماً مع أدلة المنشأ واختبارات Red Team ومتطلبات المورّدين والاستجابة لحوادث الذكاء الاصطناعي؛ ومستوى متقدم مع مراقبة مستمرة ومراجعة تغييرات النموذج وفحص صلاحيات الوكلاء. والمبدأ المصاغ هناك — معاملة كل أثر نموذجي (Model Artifact) وكل مجموعة بيانات وكل قالب أوامر وكل صلاحية أداة كسطح هجوم — يتطابق مع قراءتنا للمعيار.

ISO/IEC 27090 معيار إرشادي دون متطلبات قابلة للحصول على شهادة. والملزم هو الالتزامات الناشئة عن ISMS أو AIMS الخاص بالمؤسسة، إضافة إلى قانون الذكاء الاصطناعي الأوروبي (AI Act) وCRA وNIS2 وDORA. وخارطة الطريق توصية من VamiSec وليست استشارة قانونية.