امتثال قانون AI للاتحاد الأوروبي لنشر وكلاء الذكاء الاصطناعي: الالتزامات مادة بمادة

الموعد النهائي

في 2 أغسطس 2026، يبلغ قانون AI للاتحاد الأوروبي (اللائحة (EU) 2024/1689) محطته التالية في الإنفاذ. يسري ما تبقّى من القانون — بما في ذلك الالتزامات للأنظمة عالية المخاطر، ومتطلبات الشفافية للمحتوى المُولَّد بالذكاء الاصطناعي، وأحكام الغرامات. الغرامة القصوى 35 مليون يورو أو 7% من الإيراد السنوي العالمي، أيهما أعلى.

دخل القانون حيز التنفيذ في 1 أغسطس 2024. حظرت الممارسات غير المقبولة المخاطر (التقييم الاجتماعي، والتلاعب دون الإدراك، والمراقبة الحيوية في الزمن الحقيقي في الأماكن العامة) منذ 2 فبراير 2025. التزمات نماذج الذكاء الاصطناعي ذات الأغراض العامة وقواعد الحوكمة سارية منذ 2 أغسطس 2025. يُؤكّد الجدول الزمني للتنفيذ أن 2 أغسطس 2026 هو تاريخ سريان مفروضات الأنظمة عالية المخاطر بالكامل، والتزامات الشفافية، وإطار الغرامات — مع استثناءات محدودة لأنظمة المادة 6(1)، التي تتبع في أغسطس 2027.

بالنسبة للمؤسسات التي تنشر وكلاء ذكاء اصطناعي يُصدرون أو يدعمون قرارات حول الائتمان، أو التوظيف، أو الوصول إلى الخدمات الأساسية، أو البنية التحتية الحرجة، 2 أغسطس هو تاريخ الامتثال. لا تاريخ تخطيط. لا تاريخ مراجعة. التاريخ الذي تصبح فيه الالتزامات قابلة للإنفاذ.

يمتد حد الامتثال إلى طبقة الفعل

تركز معظم المؤسسات جهود امتثال الذكاء الاصطناعي على النموذج — حوكمة بيانات التدريب، واختبار التحيز، ومراقبة المخرجات. يُوضّح تحليل الامتثال لـ Salt Security أن هذا غير كافٍ. نطاق القانون يمتد إلى ما يفعله النموذج، لا فقط ما يُنتجه.

تتطلب المادة 15 (الأمن السيبراني) الحماية ضد الهجمات العدائية، وتسميم البيانات، وهجمات السرية، والتهرّب من النموذج. يُؤكّد تحليل Salt Security أن هذه الحماية "يجب أن تمتد إلى الواجهات التي يتفاعل عبرها نظام الذكاء الاصطناعي مع العالم (الـ APIs وخوادم MCP)". وكيل ذكاء اصطناعي يستدعي NetSuite عبر وحدة Model Context Protocol، أو يقرأ بيانات العملاء من HubSpot عبر موصل MCP، يُدخل تلك الواجهات في حد الامتثال.

تُعالج ديباجة القانون 99 و100 معماريات الوكلاء المتعددين صراحةً. في سلسلة من وكلاء الذكاء الاصطناعي، يمتد حد الامتثال إلى كل وكيل يؤدي وظيفة عالية المخاطر. إذا فوّض وكيل مُنسّق قرار تسعير إلى وكيل فرعي يستدعي محرك RFQ، يرث كلا الوكيلين الالتزامات. نطاق الامتثال هو سلسلة الاستدعاء الكاملة، لا نقطة الدخول.

ما يُحسب عالي المخاطر

يُعرّف القانون الأنظمة عالية المخاطر في المادة 6 والملحق الثالث. الفئات الأكثر صلة بنشر وكلاء B2B:

• التوظيف وإدارة العاملين — فحص السير الذاتية، وقرارات الترقية، وإسناد المهام، ومراقبة الأداء
• الوصول إلى الخدمات الأساسية — تسجيل الائتمان، وتسعير التأمين، وتحديد الأهلية
• مكونات السلامة للبنية التحتية الحرجة — النقل، والطاقة، والمياه
• إنفاذ القانون والعدالة — رغم أن معظم عمليات نشر B2B لا تقع هنا

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

بالنسبة للأنظمة التي لا تبلغ حد المخاطر العالي، تظل التزامات الشفافية سارية. تتطلب المادة 50 أن يُبلِغ المنشئون الأفراد عند تفاعلهم مع أنظمة ذكاء اصطناعي (روبوتات الدردشة، وتوليد المحتوى). يجب أن يكون المحتوى المُولَّد بالذكاء الاصطناعي قابلًا للتمييز. تسري هذه الالتزامات في 2 أغسطس 2026.

الالتزامات مادة بمادة

بالنسبة للأنظمة عالية المخاطر، يفرض القانون التزامات محددة وقابلة للتدقيق. يُقدّم تحليل Salt Security التقسيم على مستوى المادة. إليك ما تتطلبه كل مادة وكيف تُرسم إلى البنية التحتية للوكيل.

المادة 9 — إدارة المخاطر

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

ما يعنيه هذا للوكلاء: سجل المخاطر مستند حيّ. كل وحدة MCP جديدة، وكل موصل جديد، وكل تسجيل أداة جديد هو سطح مخاطر يجب تقييمه. توفر طبقة حوكمة تسجّل كل استدعاء أداة ونتيجته القاعدة الدلالية لمراجعة المخاطر التكرارية — بدونها، لا يملك نظام إدارة المخاطر بيانات.

المادة 10 — حوكمة البيانات

مجموعات بيانات عالية الجودة لتقليل النتائج التمييزية. يجب أن تمتد الحماية ضد الوصول غير المُصرّح وتسميم البيانات إلى زمن الاستدلال — عندما يستدعي وكلاء الذكاء الاصطناعي الـ APIs ويصلون إلى البيانات الخارجية فعلًا.

ما يعنيه هذا للوكلاء: البيانات التي يقرأها الوكيل وقت التشغيل (من NetSuite، وBigCommerce، وكتالوجات المورّدين) في النطاق. إذا سُمّم كتالوج مورّد ببيانات تسعير غير صحيحة وسعّر الوكيل منها، فإن التزام حوكمة البيانات يطبق. التحقق من الإدخال على استجابات أدوات MCP ليس تفصيل جودة — بل ضابط امتثال.

المادة 11 — التوثيق الفني

جرد كامل لجميع المكوّنات والواجهات والقدرات قبل وضع النظام في السوق. بالنسبة لنظام وكيل، يعني هذا توثيق كل وحدة MCP، وكل أداة تُسجّلها، وكل نظام علوي تتصل به، وكل مسار خطأ تُعالجه.

ما يعنيه هذا للوكلاء: سجل الوحدات هو التوثيق. نظام يُسجّل وحدات MCP ديناميكيًا مع مخططات، وحدود معدل، وسجلات تدقيق يُنتج التوثيق الفني كمنتج ثانوي لبنائه. نظام من النصوص البرمجية المُرتّلة واستدعاءات API غير المُسجّلة لا يفعل.

المادة 12 — حفظ السجلات (التسجيل)

تسجيل تلقائي لجميع الأحداث. يجب أن تكون السجلات مقاومة للتلاعب ومُحفوظة لمدة 6 أشهر على الأقل (24 شهرًا للأنظمة الحيوية وإنفاذ القانون). كل استدعاء أداة، وكل قرار وكيل، وكل تدخّل بشري يجب أن يكون قابلًا لإعادة البناء من السجلات.

ما يعنيه هذا للوكلاء: كل استدعاء أداة MCP يجب أن يُسجَّل بالطابع الزمني، ومُعرّف الوكيل، واسم الأداة، وتجزئة الإدخال (لا الإدخال الخام — حد PII)، وحالة الإخراج، والمدة. يجب أن يكون السجل إضافيًا فقط أو مقاومًا للتلاعب. الاحتفاظ لـ 6 أشهر حد أدنى، لا هدف. هذا أكثر التزام قابلًا للرسم مباشرةً: بنية MCP مُحوكمة تسجّل كل استدعاء دالة إلى DynamoDB بحقول منظّمة تُلبّي المادة 12 بطبيعتها.

المادة 14 — الرقابة البشرية

يجب أن يسمح النظام لمُشغّلي البشر بالإشراف، والتدخّل، وإيقاف النظام في الزمن الحقيقي عند اكتشاف سلوك شاذ. هذا ليس لوحة مراقبة تُظهر المقاييس بعد الوقوع. بل القدرة على إيقاف وكيل يعمل وسط مهمة.

ما يعنيه هذا للوكلاء: التعليمات على مستوى الموجّه ("توقّف"، "ألغِ") ليست رقابة بموجب القانون. إنها جزء من سياق المحادثة للذكاء الاصطناعي وقد تُتجاهل تحت فقدان الذاكرة أو حقن الموجّه. يتطلب القانون آلية إيقاف حتمية تعمل خارج عملية تفكير الذكاء الاصطناعي. مفتاح إيقاف يُبطّل رمز مصادقة الوكيل، أو يُعطّل وحدة MCP محددة بتغيير تكوين، أو يُطلق قاطع دائرة على أنماط سلوك شاذة يُلبّي المادة 14. أمر "توقّف" لا يُلبّي.

يُعرّف تحليل بنية مفتاح الإيقاف لـ miniOrange أربع طبقات تُرسم إلى هذا الالتزام:

1. إبطال الوصول القائم على الهوية — رموز جلسة قصيرة العمر مرتبطة بمهام محددة؛ إبطال فوري لبيانات الاعتماد
2. قواطع الدائرة واكتشاف الشذوذ — مُطلقات على طلبات API المفرطة، واستهلاك الرموز غير المعتاد، والحلقات المتكررة
3. إبطال القدرة المُحدّدة — تعطيل القدرة الخطرة فقط (مثلًا، إزالة إذن إرسال البريد مع إبقاء قراءة التذاكر)
4. معالجة المهام الجارية — التراجع عن التغييرات غير المكتملة، وحفظ سجلات التنفيذ، والتحقق من استقرار النظام بعد الإيقاف

يُوضّح حادث OpenClaw الموثّق في التحليل ذاته لماذا يفشل الإيقاف على مستوى الموجّه: وكيل ذكاء اصطناعي يُنظّم بريدًا إلكترونيًا تجاوز حد ذاكرته، وفقد السياق، وعاد إلى آخر هدف يتذكره — حذف الرسائل. تُجُوهِل أوامر "توقّف" و"ألغِ" للمستخدم. واصل الوكيل حتى أُنهي يدويًا على مستوى نظام التشغيل. كان الفشل معماريًا: لم تكن آلية إيقاف حتمية موجودة خارج عملية تفكير الذكاء الاصطناعي.

المادة 15 — الأمن السيبراني

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

ما يعنيه هذا للوكلاء: كل خادم MCP، وكل نقطة نهاية API، وكل موصل في النطاق. مشهد أمان MCP الموثّق في 2026 — العيب المنهجي في تصميم STDIO الذي يؤثر على 150 مليون تنزيل، و CVE-2026-33032 ("MCPwn"، و CVSS 9.8)، و CVE-2026-0755 (Gemini MCP، و CVSS 9.8)، و30 إلى 82 بالمئة من خوادم MCP العامة تحمل عيوبًا قابلة للاستغلال — هو مخاطر الأمن السيبراني التي يستهدفها القانون. 8.5 بالمئة فقط من خوادم MCP تستخدم OAuth. لا يُفرض القانون OAuth تحديدًا، لكنه يفرض مستوى من الأمن السيبراني لا تبلغه منظومة MCP الحالية افتراضيًا.

المادتان 72 و73 — مراقبة ما بعد السوق والإبلاغ عن الحوادث

نظام مراقبة موثّق من اليوم الأول للنشر. نوافذ الإبلاغ عن الحوادث:

• 24 ساعة للمخاطر على الحياة أو السلامة
• 72 ساعة للحوداث الجسيمة الأخرى
• 15 يومًا للأعطال

ما يعنيه هذا للوكلاء: سجل التدقيق هو مصدر تقرير الحوادث. عندما يتجاوز وكيل الأذونات، أو يُجري استدعاء غير مُصرّح، أو يُنتج مخرجًا غير صحيح يؤثر على قرار، يُعيد السجل بناء ما حدث. تعني نوافذ الـ 24 ساعة و72 ساعة أن نظام المراقبة يجب أن يُنذِر في الزمن الحقيقي، لا في مراجعة أسبوعية.

فجوة الحوكمة

وجد تقرير Deloitte 2026 لحالة الذكاء الاصطناعي في المؤسسات أن شركة واحدة من كل 5 فقط تملك نموذجًا ناضجًا لحوكمة وكلاء الذكاء الاصطناعي المستقلين. 47 إلى 53 بالمئة من المؤسسات تجاوزت وكلاؤها الأذونات أو عانت حادث، بحسب تقرير practical-devsecops 2026. 23 بالمئة فقط تملك استراتيجية رسمية لهوية وكيل الذكاء الاصطناعي.

لا يفرض القانون بنية محددة. يفرض نتائج: إدارة مخاطر مستمرة، وتسجيل تلقائي مقاوم للتلاعب، ورقابة تُوقف النظام حتميًا، وأمن سيبراني يمتد إلى كل واجهة. البنية التي تُلبّي هذه النتائج هي نمط وحدات MCP المُحوكمة — النمط ذاته الذي يُعالج ثغرات الأمان الموثّقة عبر الجدول الزمني لاختراقات MCP في 2026.

كيف تُلبّي بنية MCP المُحوكمة الالتزامات

طبقة الحوكمة التي تجعل وحدات MCP آمنة للتشغيل في الإنتاج هي الطبقة ذاتها التي تُلبّي متطلبات القانون. الرسم مباشر:

مادة قانون AI للاتحاد الأوروبي	الالتزام	ضابط الحوكمة
المادة 9 (إدارة المخاطر)	تقييم مخاطر مستمر تكراري	كل استدعاء أداة مُسجّل بالنتيجة؛ سجل المخاطر يُحدّث من بيانات التدقيق
المادة 10 (حوكمة البيانات)	حماية في زمن الاستدلال	تحقق الإدخال على استجابات أدوات MCP؛ أخطاء مُنمّطة تُميّز فشل جودة البيانات عن الأخطاء العابرة
المادة 11 (التوثيق الفني)	جرد كامل للمكوّنات والواجهات	سجل الوحدات: كل وحدة MCP، ومخطط أداة، واتصال علوي، ورمز خطأ موثّق عند التسجيل
المادة 12 (حفظ السجلات)	تسجيل تلقائي مقاوم للتلاعب، احتفاظ 6 أشهر	سجلات JSON منظّمة إلى DynamoDB: الطابع الزمني، ومُعرّف الوكيل، واسم الأداة، وتجزئة الإدخال، وحالة الإخراج، والمدة؛ إضافية فقط مع عزل مستأجر بمفتاح تقسيم
المادة 14 (الرقابة البشرية)	قدرة إيقاف في الزمن الحقيقي	مفتاح إيقاف: إبطال الهوية (رموز JWT قصيرة العمر)، وقواطع دائرة (حدود معدل لكل أداة لكل نافذة)، وإبطال قدرة مُحدّدة (تعطيل وحدة بتغيير تكوين)، وتراجع جاري
المادة 15 (الأمن السيبراني)	حماية تمتد إلى الـ APIs وخوادم MCP	مصادقة OAuth/Cognito، وتحديد معدل، ومعالجة حدود PII (تجزئة حقول SHA-256 قبل التسجيل)، وعقد أخطاء مُنمّطة
المادتان 72–73 (الإبلاغ عن الحوادث)	نوافذ إبلاغ 24/72 ساعة	اكتشاف شذوذ في الزمن الحقيقي من سجل التدقيق؛ تنبيه على تجاوز الأذونات، واستدعاءات أدوات غير متوقعة، وانتهاكات حدود المعدل

الفكرة الأساسية أن هذه الضوابط ليست مُلحَقة بعد الوقوع. إنها بنية تسجيل وحدات MCP وتنفيذها وخط أنابيب تسجيلها. وحدة تُسجّل أدواتها مع مخططات، وتُعلن حدود معدلها، وتسجّل كل استدعاء إلى مخزن إضافي فقط، وقابلة للتعطيل بتغيير تكوين تُنتج دليل الامتثال كمنتج ثانوي لتشغيلها. وكيل مُرتّل يستدعي الـ APIs مباشرة لا يفعل — وإضافة ضوابط الامتثال بأثر رجعي على وكيل غير مُحوكَم أغلى من بنائها من البداية.

حد الامتثال للوكلاء المتعددين

تمتد الديباجة 99 و100 حد الامتثال إلى كل وكيل في سلسلة يؤدي وظيفة عالية المخاطر. لهذا تداعٍ معماري لم تستوعبه معظم المؤسسات بعد.

تأمل تدفق عمل مشتريات: وكيل مُنسّق يستقبل RFQ، ويُفوّض حل المنتجات إلى وكيل كتالوج، ويُفوّض التسعير إلى وكيل محرك عروض أسعار، ويُفوّض كتابة الطلب إلى وكيل تكامل ERP. بموجب القانون، إذا أدى أي من هذه الوكلاء وظيفة عالية المخاطر (تسعير يؤثر على الوصول إلى الائتمان، أو اختيار مورّد يؤثر على التوظيف، أو شراء سلع مُنظَّمة)، يرث كل وكيل في السلسلة الالتزام.

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

نمط عزل المستأجر بـ partition_key — حيث يحمل كل سجل استدعاء دالة MCP مفتاح تقسيم يُحدّده بمستأجر ونقطة نهاية محدّدين — يُوفّر بنية مسار التدقيق التي يتطلبها امتثال الوكلاء المتعددين. استعلام مقابل سجل استدعاءات الدالة يستطيع إعادة بناء حالة تدفق العمل الكاملة: أي وكيل أطلق أي أداة، بأي ترتيب، بأي وسائط، وماذا كانت النتيجة. هذه هي القاعدة الدلالية لحفظ السجلات في المادة 12 والإبلاغ عن الحوادث في المادتين 72–73 عبر سلسلة وكلاء متعددين.

ماذا تفعل قبل 2 أغسطس

بالنسبة للمؤسسات التي لديها وكلاء ذكاء اصطناعي في الإنتاج أو في خط النشر بالفعل، يُنشئ موعد 2 أغسطس قائمة مهام ملموسة:

1. صنّف وكلاءك. حدّد أيها يقع تحت فئات المخاطر العالية (التوظيف، والخدمات الأساسية، والبنية التحتية الحرجة). الوكلاء الذين لا يلامسون هذه الفئات لا تزال لهم التزامات شفافية بموجب المادة 50.

2. دقّق طبقة التسجيل. هل تستطيع إعادة بناء أي قرار وكيل من السجلات؟ هل السجلات مقاومة للتلاعب ومُحفوظة لـ 6 أشهر على الأقل؟ إذا كان الجواب لا، فهذه أول فجوة تُسدّ — المادة 12 هي أكثر التزام قابل للتحقق مباشرة.

3. تحقّق من آلية الإيقاف. هل يستطيع مُشغّل إيقاف وكيل يعمل حتميًا، دون الاعتماد على تفكير الوكيل ذاته؟ إذا كان الإيقاف يعتمد على أمر موجّه، فلا يُلبّي المادة 14. مطلوب مفتاح إيقاف يُبطّل البيانات الاعتمادية أو يُعطّل الوحدات بتغيير تكوين.

4. وثّق جرد الواجهات. كل API، وكل خادم MCP، وكل موصل يستدعيه الوكيل يجب أن يُوثَّق (المادة 11). سجل الوحدات هو التوثيق — إذا لم تملك واحدًا، فهذه الفجوة الثانية التي تُسدّ.

5. عرّف إجراء الاستجابة للحوادث. من يُبلَّغ عندما يتجاوز الوكيل الأذونات؟ ما سلسلة الإبلاغ لـ 24 ساعة و72 ساعة؟ يجب أن يُوثَّق الإجراء قبل النشر، لا بعد حادث.

6. قيّم نطاق الوكلاء المتعددين. إذا تضمّنت بنيتك سلاسل وكلاء، ارسم كل وكيل قد يؤدي وظيفة عالية المخاطر. حد الامتثال هو السلسلة الكاملة.

كلفة عدم الامتثال مقابل كلفة الحوكمة

الغرامة القصوى 35 مليون يورو أو 7% من الإيراد العالمي. لشركة متوسطة السوق بإيراد 100 مليون يورو، ذلك 7 ملايين يورو. طبقة الحوكمة التي تُلبّي القانون — تسجيل التدقيق، وتحديد المعدل، والأخطاء المُنمّطة، ومفتاح الإيقاف، وسجل الوحدات، وعزل المستأجر — هي طبقة الحوكمة ذاتها التي تجعل وكلاء الإنتاج آمنين للتشغيل بغض النظر عن الضغط التنظيمي. الـ 47 إلى 53 بالمئة من المؤسسات التي عانت حادث وكيل بالفعل تدفع كلفة الوكلاء غير المُحوكَمين في مخاطر تشغيلية. القانون ببساطة يجعل تلك الكلفة صريحة وقابلة للإنفاذ.

المؤسسات التي بنت الحوكمة في بنية وكيلها من البداية — تسجيل الوحدات مع مخططات، وتسجيل استدعاءات الدالة إلى مخزن دائم، والمصادقة برموز قصيرة العمر، وحدود معدل مُطبَّقة عند حد الوحدة — هي التي يكون فيها 2 أغسطس تمرين توثيق لا تحديث طارئ. المؤسسات التي نشرت وكلاء كنصوص برمجية مُرتّلة تستدعي الـ APIs مباشرة هي التي تواجه الطوارئ.

---

موزّع يُشغّل NetSuite وBigCommerce وثلاثة كتالوجات مورّدين لديه وكيل يستقبل RFQs، ويحلّ المنتجات مقابل رسم كتالوج، ويسعّر حسب طبقة العميل، ويكتب عروض الأسعار إلى NetSuite. إذا سعّر ذلك الوكيل شروط ائتمان أو اختار مورّدين لمشتريات مُنظَّمة، يقع تحت فئة المخاطر العالية. بنية MCP المُحوكمة — كل استدعاء أداة مُسجّل إلى DynamoDB بالطابع الزمني والنتيجة، وكل وحدة قابلة للتعطيل بتغيير تكوين، وكل وكيل مُصادَق برموز JWT قصيرة العمر، وكل خطأ مُنمّط ومُصنّف — هي ما يجعل ذلك الوكيل ممتثلًا في 2 أغسطس. البنية ذاتها التي تجعله آمنًا للتشغيل تجعله ممتثلًا للتشغيل.

اطلب بناءًا محدّد النطاق. اكتشاف في أسبوع واحد. تحصل على جرد نظام، وخريطة تدفق عمل، ونطاق ثابت — سواء بنيت معنا أم لا.