عن الخدمة ونطاق العمل

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

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

تجهيز طلب الخدمة

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

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

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

تصنيف حالات الاستخدام والمخاطر

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

البيانات والصلاحيات والشفافية

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

التدقيق والمراقبة بعد التشغيل

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

أمن تطبيقات الذكاء الاصطناعي وتكاملات النماذج اللغوية الكبيرة

لماذا اختلفت متطلبات أمان تطبيقات الذكاء الاصطناعي

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

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

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

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

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

منهجية العمل ونطاق التطبيق وما يجب رسمه أولاً

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

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

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

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

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

حقن الأوامر المباشر وغير المباشر

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

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

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

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

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

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

تسريب سياق البيانات وسجلات المحادثة

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

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

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

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

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

استدعاء الأدوات والصلاحيات المفرطة والإنفاق غير المحدود

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

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

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

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

وتُسلَّم كل هذه الضوابط في جدول صلاحيات الأدوات والاستدعاءات: اسم الأداة، والنطاق الممنوح، ومن يحق له تحفيزها، والحدود المفروضة، والأحداث المسجّلة، ونتيجة اختبار التجاوز لكل منها. الجدول ليس وصفًا رسميًا؛ فهو يُستخدم في مراجعة الكود وفي اختبارات ما قبل الإطلاق، ويُحدَّث مع كل أداة تُضاف أو كل توسعة في صلاحياتها أو تغيير في مالكها.

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

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

الإخراج غير الآمن والوصول غير المصرح إلى قواعد المعرفة

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

الضوابط ترميز مخرجات حسب سياق العرض، وتنقية بقائمة سماح تُزيل الوسوم الخطرة، وسياسة محتوى صارمة في المتصفح تمنع السكربتات غير المتوقعة، ومنع التنفيذ الآلي للشيفرة التي يولّدها النموذج، وعزل البيئات المؤقتة التي تُستخدم للتشغيل. تُختبر هذه الضوابط بمخرجات مصممة تحمل وسومًا وسلاسل تشغيل، وتُقاس النتيجة على النموذج وعلى المسار الذي يستهلكها لاحقًا.

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

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

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

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

ضوابط التصميم ثم الفحص ثم الاختبار

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

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

ثم يأتي الفحص الساكن والمراجعة: أدوات تحليل الشيفرة، وفحص الاعتماديات والأسرار المكشوفة، ومراجعة قوالب التعليمات وحقول التسجيل كما لو كانت شيفرة، ومراجعة بشرية لمنطق التنسيق الذي يبني الطلب ويفسّر الرد. الفحص سريع ويُشغَّل باستمرار، لكنه لا يقرأ النية ولا يحاكي المهاجم، ولهذا لا يُعد بديلًا عن اختبار الهجوم الفعلي.

ثم الاختبار ببطارية محددة: حالات حقن الأوامر المباشر وغير المباشر، وتحقق من صلاحيات مصادر الاسترجاع، وتجاوز صلاحيات الأدوات، وتجاوز حدود النفقات، ومعالجة المخرجات غير الآمنة، والتسريب من سياق المحادثة. لكل حالة نص وخطوات إعادة إنتاج ونتيجة ودرجة خطورة، لأن تقريرًا بلا تفاصيل قابلة للتكرار يتحوّل إلى أرشيف لا يقرأه أحد.

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

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

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

مراقبة الإنتاج والثغرات ومواقيت الإصلاح

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

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

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

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

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

اختبارات ما بعد الإطلاق تعتمد على دورية متفق عليها: إعادة بطارية حقن الأوامر، وفحص صلاحيات مصادر الاسترجاع بحسابات متعددة، وتمرين للنفقات يحاكي حلقة استدعاءات مفرطة في بيئة معزولة للتأكد من عمل الحدود ومفتاح الإيقاف، وقياس ما يلتقطه التنبيه فعلًا. التمرين الواقعي هو ما يثبت أن خطة المراقبة تعمل، لا مجرد وجودها في وثيقة.

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

حدود الخدمة وما لا تقدّمه

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

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

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

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

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

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

مراجع للاطلاع: أبرز مخاطر تطبيقات النماذج اللغوية الكبيرة — OWASP · مبادئ أخلاقيات الذكاء الاصطناعي — هيئة الحكومة الرقمية

مراجعة الجودة واستلام العمل

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

• تحديد المسؤول عن مراجعة المخرج قبل استخدامه
• منع إدخال بيانات مصنفة دون ضابط مناسب
• قابلية تتبع مصدر المعلومة وتحديثها

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

أسئلة شائعة عن أمن تطبيقات الذكاء الاصطناعي

كيف تحدد مدة الخدمة وتكلفتها؟

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

هل يمكن تنفيذ جزء من المشروع أولًا؟

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

ما الذي يشمله التسليم؟

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

خدمات مرتبطة

مراجع للاطلاع

• أبرز مخاطر تطبيقات النماذج اللغوية الكبيرة — OWASP

المراجع للاطلاع العام، وليست وعدًا بنتيجة أو ترتيب محدد.