اعتبارات أمن أنظمة الذكاء الاصطناعي: دليل عربي تطبيقي استنادًا إلى إرشادات PCI SSC

لماذا يحتاج أمن الذكاء الاصطناعي إلى مقاربة مختلفة؟

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

لهذا لا يكفي تقييم أمن النموذج منفردًا. يجب تقييم النظام الكامل: النموذج، والبيانات، والذاكرة، والأدوات، وطبقة التنسيق، والهوية، والصلاحيات، والاتصال الخارجي، والبنية التي تستضيفه.

يشدد PCI SSC على أن أنظمة AI يجب أن تخضع لضوابط تحد من الوصول، وتحمي البيانات الحساسة، وتتيح المراقبة والعزل والتراجع عند الحاجة.

نطاق إرشادات PCI SSC وحدودها

الوثيقة الأصلية هي Information Supplement إرشادي، وليست معيارًا جديدًا ولا تحل محل متطلبات PCI SSC القائمة.

تتناول الوثيقة محورين رئيسيين:

• أمن استخدام أنظمة الذكاء الاصطناعي داخل بيئات الدفع.
• حماية الأنظمة التقليدية من مهاجمين يستخدمون قدرات الذكاء الاصطناعي.

ولا يعني ورود ممارسة أمنية في الوثيقة أنها أصبحت متطلبًا مستقلًا في PCI DSS ما لم ينص معيار PCI الساري على ذلك.

تنبيه منهجي

هذه المادة قراءة عربية تحليلية وتطبيقية أعدتها سيادة AI استنادًا إلى الوثيقة الأصلية:

Security Considerations for AI Systems — Information Supplement Version 1.0 — September 2026 PCI Security Standards Council.

هذه النسخة ليست ترجمة رسمية صادرة عن PCI SSC، ولا تحل محل الوثيقة الأصلية أو أي معيار رسمي. تمت إضافة شروحات وأمثلة وأطر تطبيقية من سيادة AI، ويجب الرجوع إلى المصدر الرسمي عند التطبيق أو التحقق من المتطلبات.

المفاهيم الأساسية

نظام الذكاء الاصطناعي AI System

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

وكيل الذكاء الاصطناعي AI Agent

نظام ذكاء اصطناعي يتمتع بدرجة من الاستقلالية لتنفيذ مهام محددة أو ضمن نطاق معرف مسبقًا.

AI-BOM

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

الحد الأدنى من الوكالة Least Agency

منح النظام أقل قدر ممكن من الوصول والقدرة على التنفيذ اللازمين فقط لتنفيذ المهمة.

تحيز الأتمتة Automation Bias

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

انجراف النظام AI Drift

تغير سلوك النظام أو مخرجاته بمرور الوقت أو بعد تغير النموذج أو البيانات أو البيئة التشغيلية.

الذكاء الاصطناعي الظل Shadow AI

استخدام قدرات ذكاء اصطناعي خارج القنوات المعتمدة أو دون معرفة أو موافقة المؤسسة.

حقن التعليمات Prompt Injection

محاولة التأثير في سلوك النموذج عبر تعليمات مباشرة أو غير مباشرة موجودة داخل المحتوى الذي يعالجه النظام.

القواعد الأساسية لتأمين استخدام الذكاء الاصطناعي

يوصي المصدر بعدم السماح لأنظمة الذكاء الاصطناعي بالوصول إلى الأسرار عالية الأثر أو توليدها أو إدارتها مباشرة.

كما يجب:

• حماية البيانات الحساسة.
• تقييد الوصول وفق Least Agency.
• توفير سجلات ومراقبة كافية.
• تسهيل عزل أو تعطيل النظام عند الحاجة.
• حماية النظام من المدخلات الخبيثة والمخرجات غير الموثوقة.
• فرض الضوابط الأمنية خارج النموذج كلما أمكن.

تحديد حدود استخدام أنظمة الذكاء الاصطناعي

يجب تحديد ما يستطيع النظام فعله وما لا يستطيع فعله قبل النشر.

ومن الحدود المهمة:

• عدم الوصول إلى أنظمة لا تتطلبها المهمة.
• عدم استخدام صلاحيات أوسع من الحاجة.
• عدم تخزين أو إدارة أسرار حساسة داخل Prompt أو Context أو Logs.
• عدم اتخاذ قرارات عالية الأثر دون مسؤولية بشرية واضحة.
• عدم استخدام هوية مشتركة تمنع تتبع الفعل إلى مصدر محدد.

قراءة سيادة: Intended Access ليس كافيًا

لا يكفي أن تنص إعدادات Agent على أنه “يُسمح له فقط” بتنفيذ وظيفة معينة.

القياس الأهم هو Effective Access: ما الذي يستطيع فعله فعليًا بناءً على IAM والشبكة وواجهات API والأدوات وCredentials المتاحة له.

دورة حياة نشر نظام ذكاء اصطناعي آمن

يجب أن يبدأ الأمن من مرحلة تحديد المتطلبات لا بعد اكتمال النظام.

يشمل المسار:

1. تحديد حالة الاستخدام والنطاق.
2. تحديد البيانات والأنظمة التي يحتاجها النظام.
3. Threat Modeling.
4. تحديد الضوابط والحدود.
5. اختيار النموذج والأدوات والاستضافة.
6. التحقق من مصادر البيانات ومكوناتها.
7. Adversarial Testing قبل التشغيل.
8. Functional Validation.
9. تشغيل مراقبة مستمرة.
10. إعادة التحقق عند حدوث تغييرات جوهرية.

أنظمة الذكاء الاصطناعي لا تعتبر “منتهية” أمنيًا بعد أول اختبار، لأن سلوكها قد يتغير مع البيانات أو الإصدارات أو الإعدادات أو مزود الخدمة.

الأنظمة الداخلية والخارجية

استخدام External AI يقلل مستوى السيطرة المباشرة على البيانات والبيئة التشغيلية.

لكن Internal AI لا يعني تلقائيًا أن النظام آمن؛ فالخطر قد يأتي من:

• الصلاحيات الواسعة.
• الوصول إلى بيانات حساسة.
• Prompt Injection.
• ضعف العزل.
• Credential misuse.
• اتصال غير منضبط بالأنظمة الأخرى.

AI Inventory وAI-BOM وShadow AI

يجب أن تعرف المؤسسة جميع أنظمة الذكاء الاصطناعي المستخدمة لديها وحالات استخدامها.

ويُفضّل أن يحتوي AI-BOM على:

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

اكتشاف Shadow AI

لا يقتصر Shadow AI على استخدام مواقع Chatbot غير معتمدة.

قد يظهر أيضًا في:

• Browser Extensions.
• IDE Plugins.
• AI features مدمجة في SaaS.
• APIs يستخدمها فريق تقني دون مراجعة.
• Local models.
• Automations تحتوي AI steps.
• MCP Servers.
• قدرات AI تم تفعيلها بعد تحديث منتج قائم.

الوصول والصلاحيات وLeast Agency

من المفيد التعامل مع AI Agent كما لو كان Potential Malicious Insider من منظور هندسة الصلاحيات.

إذا كان النظام يمتلك Shell أو Console Access، فالمقياس الأمني ليس ما يُطلب منه فعله فقط، بل ما يستطيع الوصول إليه فعليًا.

يجب أن تفرض القيود عبر:

• IAM.
• Network Segmentation.
• API scopes.
• Time-bound credentials.
• Device-bound credentials.
• Authorization brokers.
• Independent policy enforcement.

قراءة سيادة: هوية مستقلة لكل Agent

ينبغي أن يمتلك كل Agent هوية تشغيلية يمكن:

• تتبع أفعالها.
• تقييد صلاحياتها.
• إلغاؤها بصورة مستقلة.
• ربطها بمسؤول بشري.

الإشراف البشري

Human-in-the-Loop

يتطلب كل إجراء أو قرار محدد موافقة بشرية قبل التنفيذ.

Human-over-the-Loop

يُسمح للنظام بتنفيذ بعض الإجراءات ضمن نطاق معتمد مسبقًا، مع بقاء الإنسان مسؤولًا عن المراقبة والتدخل.

اختيار النموذج الصحيح يعتمد على:

• حساسية البيانات.
• مستوى الصلاحية.
• أثر الإجراء.
• سرعة العملية.
• قابلية التراجع.
• وجود ضوابط مستقلة عن النموذج.

الاعتمادية والتعامل مع الفشل

قد تنتج أنظمة الذكاء الاصطناعي مخرجات خاطئة تبدو مقنعة.

لذلك يجب:

• اعتبار المخرجات غير موثوقة حتى يتم التحقق منها عند الحاجة.
• إجراء Validation مستقل.
• توفير Rollback.
• عدم تنفيذ تغييرات عالية الأثر بلا آلية تراجع.
• تصميم الأنظمة بحيث تفشل بصورة آمنة.

قراءة سيادة: قابلية العكس

يمكن تصنيف الأفعال إلى مستويات:

R0 — معلوماتية ولا تغير حالة النظام. R1 — قابلة للعكس بسهولة. R2 — قابلة للتراجع بإجراء تشغيلي. R3 — قابلة للعكس جزئيًا فقط. R4 — غير قابلة للعكس عمليًا.

كلما زادت الاستقلالية وانخفضت قابلية العكس، زادت الحاجة للموافقة البشرية المسبقة.

البيانات الحساسة والأسرار

يجب عدم استخدام AI لتوليد أو إدارة الأسرار عالية الأثر مثل المفاتيح التشفيرية وكلمات المرور.

كما يجب عدم وضع Credentials داخل:

• Prompt.
• Source Code.
• Context.
• Agent Memory.
• Vector Store.
• Logs.

إذا ظهر Credential في أحد هذه المواقع، يجب التعامل معه باعتباره معرضًا للخطر واتخاذ إجراءات الإلغاء والتدوير والتحقيق.

التشفير ليس كافيًا إذا كان AI يستطيع فك التشفير

إذا كانت البيانات مشفرة لكن Agent يستطيع الوصول أيضًا إلى KMS أو HSM أو عملية فك التشفير، فيجب اعتبار النظام قادرًا فعليًا على الوصول إلى البيانات الواضحة.

Lethal Trifecta وتقييم المخاطر

يناقش المصدر حالة تتجمع فيها ثلاثة عناصر:

1. الوصول إلى بيانات حساسة.
2. التعرض لمحتوى أو مدخلات غير موثوقة.
3. القدرة على التواصل أو الاتصال الخارجي.

وجود العناصر الثلاثة معًا يشكل Architecture Red Flag مهمًا.

لكن المصدر يؤكد أن هذا الفحص ليس بديلًا عن Risk Analysis أو Threat Modeling كامل.

قراءة سيادة

يمكن استخدام Lethal Trifecta كفحص معماري سريع:

0/3 — لا توجد إشارة مرتفعة من هذا الاختبار وحده. 1/3 — ضوابط متناسبة. 2/3 — مراجعة معمارية وعزل أقوى. 3/3 — إعادة تصميم افتراضية ما لم توجد ضوابط قوية ومبررة.

الدفاع ضد المهاجمين المدعومين بالذكاء الاصطناعي

يمكن للذكاء الاصطناعي أن يقلل تكلفة اكتشاف الثغرات واستغلالها وإنشاء المحتوى الاحتيالي وسلسلة الهجمات.

لذلك يصبح التركيز أكبر على:

• تقليل Attack Surface.
• Patch Management السريع.
• Vulnerability Triage.
• Segmentation.
• Strong Authentication.
• Data Protection.
• Incident Detection.
• تقليل Blast Radius.

الضوابط التي يصعب تجاوزها حسابيًا

عندما يصبح المهاجم قادرًا على أتمتة المحاولات بكثافة، فإن الضوابط المبنية فقط على صعوبة العمل اليدوي تصبح أقل فعالية.

لذلك يُفضّل الاعتماد على ضوابط ذات أساس تقني قوي مثل:

• التشفير الصحيح.
• Segmentation.
• Strong Identity.
• Cryptographic Authentication.
• Hard authorization boundaries.

نطاق PCI DSS عند استخدام AI

استخدام AI لا يغير مبادئ تحديد نطاق PCI DSS.

إذا كان نظام AI يخزن أو يعالج أو ينقل بيانات الحساب أو يستطيع التأثير على أمن Cardholder Data Environment، فقد يدخل ضمن النطاق.

يجب أيضًا الانتباه إلى أن Sensitive Authentication Data لها متطلبات خاصة، ولا يجوز افتراض أن وجودها داخل AI system مسموح فقط لأنها مشفرة.

الهوية والمصادقة

AI ليس مستخدمًا بشريًا.

لذلك لا يمكن تطبيق بعض مفاهيم MFA البشرية عليه بالطريقة نفسها.

للـMachine Identity يفضل استخدام:

• Device-bound credentials.
• Certificates.
• mTLS.
• Cryptographic credentials.
• Short-lived credentials.
• Scoped tokens.

ولا ينبغي الالتفاف على متطلبات MFA البشرية عبر استخدام Agent.

تطوير البرمجيات باستخدام AI

يمكن استخدام AI في:

• Code generation.
• Code review.
• Vulnerability analysis.
• Testing.

لكن يجب التحقق باستمرار من جودة هذه الأدوات وقدرتها على تنفيذ المهمة المطلوبة.

كما يجب:

• استخدام مصادر Packages موثوقة.
• فحص الأسرار داخل الكود.
• مراجعة المخرجات.
• اختبار التغييرات.
• منع Agent من تجاوز CI/CD controls.

حوكمة أنظمة الذكاء الاصطناعي

الحوكمة تبدأ من البيانات.

يجب رسم Data Flow وتحديد:

• Prompts.
• Responses.
• Transcripts.
• Retrieved Context.
• Caches.
• Temporary memory.
• Tool outputs.
• Orchestration data.

ويجب تعيين Human Owner واضح لكل نظام.

كما يجب إجراء مراجعات دورية وإعادة التحقق عند حدوث تغييرات جوهرية في النموذج أو الإعدادات أو الأدوات أو المزود.

قراءة سيادة: Model Change حدث حوكمي

تغير النموذج ليس بالضرورة تحديثًا برمجيًا عاديًا.

قد يتغير معه:

• السلوك.
• اختيار الأدوات.
• احتمالية Prompt Injection.
• بنية المخرجات.
• مستوى القدرة.
• مكان معالجة البيانات.

خدمات AI الخارجية والطرف الثالث

عندما يستضيف طرف خارجي جزءًا من نظام AI ويتعامل مع بيانات حساسة، يجب التعامل معه ضمن Third-Party Risk Management المناسب.

تشمل المراجعة:

• Data use.
• Retention.
• Training.
• Subprocessors.
• Model changes.
• Breach notification.
• Responsibility allocation.
• Data location.
• Exit requirements.

أمثلة تطبيقية من PCI SSC

إدارة الثغرات بالوكلاء

يعرض المصدر نموذجًا يقسم العمل بين عدة Agents بدل منح Agent واحد دورة كاملة من التحليل إلى النشر.

يمكن فصل:

Discovery / Triage Development Testing Deployment

وتختلف الصلاحيات والاتصال والبيانات لكل Agent.

البيانات المشفرة أو المرمزة

قد يقل النطاق إذا كان AI لا يستطيع الوصول إلى البيانات الواضحة ولا إلى خدمات فك التشفير.

أما إذا استطاع الوصول إلى البيانات وإلى KMS أو عملية فكها، فيجب تقييمه بناءً على الوصول الفعلي.

AI-Assisted Coding

يجب فصل بيئات التطوير والاختبار والنشر، والتحقق من التغييرات، ومنع الوصول المباشر غير الضروري إلى Production.

البيانات الواضحة

عند التعامل مع Cleartext Cardholder Data يجب تطبيق عزل قوي، وصلاحيات محدودة، ومراقبة، وضوابط DLP مناسبة.

التشفير والأرقام العشوائية

ينبغي أن يستدعي AI وظائف موثوقة للتشفير وتوليد العشوائية دون أن يرى المفاتيح أو القيم الحساسة نفسها.

قراءة سيادة: أمن الأنظمة الوكيلة

Authority Boundary

يجب تحديد ما إذا كان Agent يستطيع:

• القراءة.
• التوصية.
• اتخاذ القرار.
• التنفيذ.
• تعديل Production.
• إجراء Transaction.
• حذف البيانات.
• رفع الصلاحيات.
• استدعاء Agents أخرى.

Effective Access

الصلاحية الحقيقية هي ما تسمح به البنية التقنية، وليس ما تقوله التعليمات.

Kill Switch

لا يكفي أن نطلب من Agent التوقف.

يجب أن تكون آلية الإيقاف خارج سيطرته، مثل:

• Revoke credentials.
• Block network route.
• Disable orchestration.
• Freeze write access.
• Preserve logs.

Agentic Segregation of Duties

يمكن فصل المهام الحساسة بين Agents مختلفين:

Discovery Agent Decision Agent Execution Agent Validation Agent

لكن يجب أيضًا منع Prompt Propagation أو تعاون عدة Agents بطريقة تحقق صلاحية لم يمنحها أي Agent منفردًا.

MCP Governance

MCP لا يمثل مجرد تكامل تقني؛ قد يمنح Agent وصولًا مباشرًا إلى:

• Filesystems.
• Databases.
• SaaS.
• Internal APIs.
• Repositories.
• Email.

لذلك يجب جرد MCP Servers وتحديد الأدوات والبيانات والصلاحيات المتاحة عبرها.

Baseline أمني عملي لأنظمة AI

قبل تشغيل نظام أو Agent ذي صلاحيات مؤسسية، تحقق من وجود:

• Approved use case.
• Human owner.
• AI Inventory.
• AI-BOM.
• Data classification.
• Access map.
• Least Agency.
• Machine Identity.
• Threat model.
• Prompt injection testing.
• Logging.
• Tool-call monitoring.
• Human oversight model.
• Disable mechanism.
• Rollback.
• Incident triggers.
• Model-change revalidation.
• Third-party review عند الحاجة.

الأخطاء الشائعة

من الأخطاء المتكررة:

• اعتبار Private LLM آمنًا تلقائيًا.
• استخدام System Prompt كحاجز أمني.
• منح Agent Service Account واسعًا.
• مشاركة Credentials.
• إهمال Tool Calls.
• تخزين أسرار داخل Context.
• الاعتماد على Human Review بصورة شكلية.
• اعتبار Shadow AI مجرد مواقع غير مصرح بها.
• تجاهل Model Updates.
• منح Agent الإنترنت والبيانات الحساسة والمدخلات غير الموثوقة في الوقت نفسه.

خطوات عملية للمؤسسات

ابدأ من Use Case، ثم حدد Owner والبيانات والصلاحيات والاتصالات.

أنشئ AI Inventory وAI-BOM، وطبق Least Agency، وافصل الأسرار عن Context، ونفذ Threat Modeling واختبارات هجومية قبل التشغيل.

راقب Tool Calls والإجراءات الفعلية، وصمم Kill Switch وRollback، وأعد التحقق عند كل Material Change.

أسئلة شائعة

هل يمنع PCI استخدام الذكاء الاصطناعي؟

لا. الوثيقة تقدم إرشادات أمنية ولا تحظر استخدام AI، كما أنها لا تنشئ متطلبات PCI جديدة.

هل كل AI System يدخل ضمن PCI DSS؟

لا. يعتمد الأمر على البيانات التي يخزنها أو يعالجها أو ينقلها، وعلى قدرته على التأثير في بيئة بيانات حامل البطاقة.

هل البيانات المشفرة خارج النطاق دائمًا؟

لا. إذا كان النظام يستطيع فكها بصورة مباشرة أو غير مباشرة، فإن التشفير وحده لا يلغي الوصول الفعلي.

هل Human-in-the-Loop كافٍ دائمًا؟

لا. يجب تحديد نوع الإشراف بناءً على الأثر والصلاحيات والسرعة وقابلية التراجع.

هل تكفي مراقبة Prompt وResponse؟

لا، خصوصًا مع Agents. يجب مراقبة Tool Calls وAPI calls والإجراءات والهوية والأنظمة المستهدفة.

هل Model Update يحتاج إعادة تقييم؟

نعم عندما يكون التغيير جوهريًا وقد يؤثر في السلوك أو القدرة أو الأمن أو معالجة البيانات.

المراجع

المرجع الأساسي:

PCI Security Standards Council. Security Considerations for AI Systems — Information Supplement. Version 1.0 — September 2026.

مراجع مرتبطة وردت في الوثيقة الأصلية تشمل:

• ISO/IEC 42001.
• NIST AI Risk Management Framework.
• NIST Generative AI Profile.
• PCI SSC guidance on integrating AI in PCI assessments.
• OWASP GenAI Security Project.
• MITRE ATLAS.
• Cloud Security Alliance resources.
• CUSTODY Framework.