یک کرون‌جاب (cron job) تولیدشده توسط هوش مصنوعی، تمام اشتراک‌های فعال Stripe را در یک استارتاپ در کمتر از ده ثانیه حذف کرد و درآمد ماهانه تکرارپذیر (MRR) شرکت را به ۳۸ دلار کاهش داد. این حادثه نشان می‌دهد که خطر در خط لوله استقرار (deployment pipeline) نهفته است، نه در مدل زبانی که کد را نوشته است.

چه اتفاقی افتاد

هفته گذشته، تیم BridgeMindAI با داشبوردی مواجه شد که تنها ۳۸ دلار درآمد ماهانه تکرارپذیر (MRR) را نشان می‌داد. یک مدل هوش مصنوعی تنها یک خط کد تولید کرده بود که توسط زمان‌بند (scheduler) به‌طور خودکار اجرا شد. آن خط کد، نقطه پایانی (endpoint) لغو اشتراک Stripe را برای هر رکورد مشتری فراخوانی کرد. این فراخوانی در هفت ثانیه به پایان رسید و کل پایگاه مشتریان را پاک کرد.

اسکریپت، یک صف حذف خالی را به اشتباه به عنوان سیگنالی برای حذف همه‌چیز تفسیر کرد. الگوی «خالی = همه» از دهه ۱۹۸۰، یعنی مدت‌ها پیش از ظهور هوش مصنوعی مولد، در کدهای عملیاتی وجود داشته است.

چرا مدل مقصر نیست

مردم به‌سرعت مدل هوش مصنوعی را به دلیل غیرقابل اعتماد بودن مقصر دانستند. تعویض مدل مانع از این پاکسازی نمی‌شد، زیرا نقص در منطق نوشته‌شده توسط انسان بود، نه یک توهم (hallucination) یا سوگیری (bias).

شکست‌های واقعی، ساختاری بودند:

  • اسکریپت، یک کلید API فعالِ محیط عملیاتی (production) مربوط به Stripe را ذخیره کرده بود که قابلیت لغو اشتراک‌ها را داشت.
  • اسکریپت بدون هیچ‌گونه نظارت در زمان اجرا (runtime supervision) اجرا شد.
  • هیچ نقطه بازرسی انسانی (human checkpoint) بین تولید کد و اجرا قرار نداشت.

این شکاف‌ها اجازه دادند یک باگ واحد، در عرض چند ثانیه یک جریان درآمدی را نابود کند.

سه سوال ایمنی برای هر خط لوله خودگردان

  1. کدام عملیات‌ها برگشت‌ناپذیر هستند؟ لغو یک اشتراک، حذف یک رکورد یا صدور بازپرداخت (refund) قابل بازگشت نیستند. این موارد نسبت به پرس‌وجوهای (queries) فقط‌خواندنی، به محافظت بیشتری نیاز دارند.

  2. عامل (agent) چه اعتبارنامه‌هایی در اختیار دارد؟ دادن کلید اصلی (master key) Stripe به یک فرآیند خودگردان، قدرت نامحدودی به آن می‌بخشد. اصل «کمترین امتیاز» (least-privilege) را اعمال کنید: از کلیدهای محدودشده (scoped keys) استفاده کنید که فقط می‌توانند وظیفه مورد نظر را انجام دهند.

  3. نقطه بازرسی انسانی کجاست؟ بازبینی کد (code review) به تنهایی کافی نیست. یک دروازه (gate) را بعد از تولید کد و قبل از هر اقدام مخربی قرار دهید.

حفاظ‌های ایمنی کاربردی

  • دروازه اجرای آزمایشی (Dry-run gate) – قبل از هر فراخوانی برای حذف یا لغو، اهداف مورد نظر را ثبت (log) کنید. اگر لیست خالی یا به‌طور غیرعادی بزرگ بود، عملیات را متوقف کرده و به یک انسان هشدار دهید.
  • اعتبارنامه‌های محدودشده (Scoped credentials) – به‌صورت پیش‌فرض از کلیدهای فقط‌خواندنی استفاده کنید. زمانی که یک وظیفه مستلزم لغو اشتراک است، یک کلید محدودشده ایجاد کنید که بتواند در هر بار فقط روی یک شناسه مشتری (customer ID) عمل کند.
  • اعلان با حضور انسان (Human-in-the-loop prompt) – یک پیام کوتاه به یک کانال (مثلاً Slack) ارسال کنید، مانند: «قصد دارم ۴۷ اشتراک را لغو کنم. تایید می‌کنید؟». هزینه این کار ناچیز و میزان ایمنی حاصل از آن بسیار زیاد است.

این اقدامات بدون توجه به اینکه کدام مدل کد را می‌نویسد موثر هستند، زیرا از محیط اجرا محافظت می‌کنند، نه از تولیدکننده.

چک‌لیست عملیاتی برای عوامل خودگردان

  • هر عملیات را به عنوان خواندنی، برگشت‌پذیر یا برگشت‌ناپذیر طبقه‌بندی کنید.
  • برای تمام اقدامات برگشت‌ناپذیر، تایید صریح انسانی را الزامی کنید.
  • اعتبارنامه‌ها را به حداقل مجوزهای مورد نیاز برای آن وظیفه محدود کنید.
  • برای حلقه‌هایی (loops) که رکوردها را حذف یا اصلاح می‌کنند، محدودیت اندازه تعیین کنید.
  • عوامل را ابتدا در یک محیط ایزوله (sandbox) که مشابه داده‌های عملیاتی است اجرا کنید؛ پیش از دستکاری داده‌های واقعی، نتیجه را تایید کنید.
  • برنامه عامل را قبل از اجرا به زبان ساده ثبت (log) کنید تا بازبین بتواند در یک نگاه متوجه هدف شود.

پیروی از این چک‌لیست، یک اسکریپت «یک‌بار اجرا و فراموش» را به یک گردش کار کنترل‌شده تبدیل می‌کند که در صورت بروز مشکل، قابل بازرسی و متوقف شدن است.

درس روشن است: به فرآیند اعتماد کنید، نه به مدل.