قامت مهمة مجدولة (cron job) تم إنشاؤها بواسطة الذكاء الاصطناعي بحذف جميع اشتراكات Stripe النشطة في إحدى الشركات الناشئة في أقل من عشر ثوانٍ، مما أدى إلى خفض الإيرادات الشهرية المتكررة للشركة إلى 38 دولارًا فقط. يوضح هذا الحادث أن الخطر يكمن في مسار النشر (deployment pipeline)، وليس في النموذج اللغوي الذي كتب الكود.
ماذا حدث
في الأسبوع الماضي، استيقظ فريق BridgeMindAI على لوحة بيانات تظهر 38 دولارًا فقط من الإيرادات الشهرية المتكررة (MRR). أنتج نموذج ذكاء اصطناعي سطرًا واحدًا من الكود قام المجدول بتشغيله تلقائيًا. استدعى هذا السطر نقطة نهاية إلغاء الاشتراك (subscription-cancellation endpoint) الخاصة بـ Stripe لكل سجل عميل. انتهت العملية في سبع ثوانٍ ومسحت قاعدة العملاء بالكامل.
أخطأ النص البرمجي (script) في قراءة طابور حذف فارغ واعتبره إشارة لحذف كل شيء. إن نمط "الفراغ = الكل" (empty = all) هذا موجود في كود الإنتاج منذ الثمانينيات، قبل ظهور الذكاء الاصطناعي التوليدي بفترة طويلة.
لماذا ليس النموذج هو المذنب
سارع الناس بإلقاء اللوم على نموذج الذكاء الاصطناعي لعدم موثوقيته. لكن استبدال النموذج لم يكن ليوقف عملية المسح، لأن الخلل كان في المنطق المكتوب بشريًا، وليس في "هلوسة" أو انحياز.
كانت الإخفاقات الحقيقية هيكلية:
- خزّن النص البرمجي مفتاح Stripe API خاص ببيئة الإنتاج الحية، وكان بإمكانه إلغاء الاشتراكات.
- تم تشغيله دون أي إشراف أثناء وقت التشغيل (runtime).
- لم تكن هناك نقطة تفتيش بشرية بين توليد الكود وتنفيذه.
سمحت هذه الثغرات لخطأ برمجى واحد بتدمير تدفق الإيرادات في ثوانٍ.
أسئلة السلامة الثلاثة لأي مسار عمل مستقل
ما هي العمليات غير القابلة للتراجع؟ إلغاء الاشتراك، أو حذف سجل، أو إصدار استرداد نقدي هي أمور لا يمكن التراجع عنها. لذا فهي تحتاج إلى حماية أكبر من استعلامات القراءة فقط.
ما هي صلاحيات الوصول التي يمتلكها الوكيل؟ منح مفتاح Stripe رئيسي لعملية مستقلة يمنحها سلطة غير مقيدة. طبق مبدأ "الحد الأدنى من الصلاحيات": استخدم مفاتيح محددة النطاق (scoped keys) يمكنها فقط تنفيذ المهمة المطلوبة.
أين هي نقطة التفتيش البشرية؟ مراجعة الكود وحدها لا تكفي. يجب وضع بوابة بعد توليد الكود وقبل أي إجراء تدميري.
ضوابط السلامة العملية
- بوابة التجربة الوهمية (Dry-run gate) – قبل أي استدعاء للحذف أو الإلغاء، قم بتسجيل الأهداف المقصودة. إذا كانت القائمة فارغة أو كبيرة بشكل غير معتاد، أوقف العملية ونبه بشريًا.
- صلاحيات محددة النطاق – اعتمد بشكل افتراضي على مفاتيح القراءة فقط. عندما تتطلب المهمة إلغاء اشتراك، أنشئ مفتاحًا مقيدًا يمكنه العمل على معرف عميل واحد فقط في كل مرة.
- تنبيه يتطلب تدخلًا بشريًا – أرسل رسالة قصيرة إلى قناة (مثل Slack) مثل: "أنا على وشك إلغاء 47 اشتراكًا. هل تؤكد؟". التكلفة ضئيلة، لكن مكاسب السلامة هائلة.
تعمل هذه التدابير بغض النظر عن النموذج الذي يكتب الكود، لأنها تحمي بيئة التنفيذ وليس المولد.
قائمة مراجعة للإنتاج للوكلاء المستقلين
- تصنيف كل عملية على أنها قراءة، أو قابلة للتراجع، أو غير قابلة للتراجع.
- اشتراط موافقة بشرية صريحة لجميع الإجراءات غير القابلة للتراجع.
- قصر صلاحيات الوصول على الحد الأدنى من الأذونات اللازمة للمهمة.
- فرض حدود على حجم الحلقات التكرارية (loops) التي تحذف أو تعدل السجلات.
- تشغيل الوكلاء أولاً في بيئة معزولة (sandbox) تحاكي بيانات الإنتاج؛ والتأكد من النتيجة قبل المساس بالبيانات الحية.
- تسجيل خطة الوكيل بلغة بسيطة قبل التنفيذ حتى يتمكن المراجع من فهم القصد بنظرة سريعة.
إن اتباع قائمة المراجعة هذه يحول النص البرمجي من نمط "شغّل وانسَ" إلى سير عمل محكوم يمكن تدقيقه وإيقافه إذا بدا أن هناك خطأ ما.
الدرس واضح: ثق بالعملية، وليس بالنموذج.