هل الكود الذي يكتبه الذكاء الاصطناعي آمن؟ ما تفحصه قبل الإطلاق

هل الكود الذي يكتبه الذكاء الاصطناعي آمن؟ الجواب الصريح

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

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

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

«يعمل» و«آمن» سؤالان مختلفان، والذكاء الاصطناعي يجيب عن الأول تلقائياً فقط.

أين يخطئ الكود المولّد عادة؟

هذه الأنماط تتكرر في التطبيقات المبنية بسرعة، سواء كتبها ذكاء اصطناعي أو مبرمج مستعجل. الفرق أن الذكاء الاصطناعي يكررها بثقة إن لم تُطلب منه الحماية:

لماذا تظهر هذه الثغرات؟

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

الخبر الجيد: كل هذه الأسباب يمكن التحكم فيها. الوكلاء الأحدث يخططون ويختبرون ما يبنونه، والمنصات الجيدة تضع حواجز (Guardrails) افتراضية، وأنت تستطيع أن تجعل الأمان جزءاً من كل وصف تكتبه.

ماذا تتكفل به المنصة، وماذا يبقى عليك؟

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

اختبارات تجريها بنفسك قبل الإطلاق

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

1. 1
   اختبار الحسابين

   أنشئ حسابين (أ) و(ب). اطلب من الحساب (أ)، ثم ادخل بالحساب (ب) وحاول فتح رابط طلب (أ) نفسه. يجب أن ترى رسالة رفض، لا الطلب.

2. 2
   اختبار تغيير الرقم

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

3. 3
   اختبار الزائر

   سجّل خروجك وافتح روابط لوحة الإدارة وصفحات الطلبات مباشرة. يجب أن تُحوَّل لتسجيل الدخول.

4. 4
   اختبار الدور

   ادخل بحساب موظف عادي وحاول فتح صفحات المالك: التقارير، الإعدادات، المستخدمين.

5. 5
   اختبار السعر

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

6. 6
   اختبار الرمز

   اطلب رمز التحقق خمس مرات متتالية. يجب أن يفرض التطبيق انتظاراً بين الطلبات.

7. 7
   اختبار الرفع

   جرّب رفع ملف ضخم أو بصيغة غريبة بدل الصورة. يجب أن يُرفض بأدب.

اجعل الوكيل يراجع نفسه

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

متى تحتاج مراجعة أمنية متخصصة؟

الاختبارات الذاتية تكشف المشكلات الشائعة، لكنها لا تغني عن خبير في حالات معينة:

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

أسئلة شائعة

مصطلحات في هذا المقال