أمن الذكاء الاصطناعي يبدأ بالحوكمة: من السياسة إلى التطبيق

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

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

فرّق بين أداة تكتب ووكيل يستطيع التنفيذ

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

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

سجل استخدامات صغير أفضل من سياسة لا تعرف الواقع

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

1. اسم الاستخدام والغرض منه، مع مثال واضح للمخرج المتوقع ومن سيعتمد عليه.

2. الأداة أو الخدمة والحساب المستخدم، وهل الاشتراك شخصي أم تابع للمنشأة ومن يدير صلاحياته.

3. أنواع البيانات التي تُدخل أو تُسترجع، ومواقع حفظ الملفات والمخرجات وسجلات المحادثة.

4. الأنظمة المتصلة والأفعال المسموح بها، والفرق بين صلاحية القراءة وصلاحية التعديل أو الإرسال.

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

ماذا يضيف إطار NIST إلى تنظيم القرار؟

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

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

ابدأ بالبيانات قبل صياغة تعليمات الاستخدام

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

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

حقن التعليمات: عندما تتحول مادة القراءة إلى محاولة توجيه

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

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

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

الموافقة البشرية يجب أن تكشف ما سيحدث فعلًا

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

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

اختبارات قبول تتجاوز سؤال هل كانت الإجابة جميلة؟

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

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

1. اطلب معلومة غير موجودة في المصادر المعتمدة، وتحقق هل يوضح النظام حدود معرفته أم يقدم جوابًا جازمًا بلا مرجع.

2. استخدم حسابين بصلاحيات مختلفة، ثم تحقق أن المساعد لا يعرض للحساب الأقل صلاحية مستندات لا يستطيع فتحها في النظام الأصلي.

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

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

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

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

ماذا نراقب بعد انتهاء التجربة؟

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

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

خطة تطبيق متدرجة يمكن تكييفها مع المنشأة

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

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

أسئلة تساعد على تجنب قرارات شكلية

هل نحتاج منع جميع الأدوات حتى تصبح السياسة جاهزة؟

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

هل اعتماد أداة واحدة يلغي المراجعة؟

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

من يملك مسؤولية الحوكمة؟

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

ربط الاستخدام الجديد ببرنامج الأمن القائم

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