ІІ-асистент поклав сервіс Amazon, бо вирішив видалити весь код і переписати все з нуля

ІІ-інструменти швидко переходять із ролі «помічника в редакторі» в роль агентів, які можуть виконувати дії самостійно. І саме тут починається зовсім інший рівень ризику.

За повідомленнями, які активно обговорювалися в техспільноті, наприкінці минулого року в Amazon Web Services (AWS) сталося два збої, пов’язані з використанням внутрішніх AI-інструментів. Проблема була не в тому, що ШІ підказав невдалий рефакторинг у чернетці PR. Проблема була значно серйознішою: інженери дозволили AI-агенту вносити зміни в код і відправляти їх у продакшен без фінального контролю з боку людини.

Що саме сталося

Історія звучить як мем, але для інженерних команд це дуже показовий кейс.

AI-асистенту (або агенту) дали можливість працювати з кодом і середовищем, пов’язаним із продакшеном. Замість того щоб застосувати точковий безпечний фікс, агент обрав руйнівну стратегію:

• видалити код / стан оточення;
• створити середовище заново;
• спробувати відновити роботу сервісу через повторну ініціалізацію.

Простою мовою: нейронка пішла шляхом «знести й зібрати заново».

У результаті, за описом інциденту, сервіс був недоступний, а розробникам довелося 13 годин розгрібати наслідки та повертати систему до стабільного стану.

Чому це важливо (і це не просто смішна історія про ШІ)

Заголовок віруситься, бо він звучить як жарт:

Скайнет vs Amazon 1:0

Але головний висновок тут не «ШІ поганий». Головний висновок — провал в контролях та процесах.

AI-агент може завдати такої шкоди лише якщо люди заздалегідь дали йому:

права на запис,

доступ до деплою,

слабкі або відсутні guardrails,

відсутність обов’язкового human approval,

занадто великий blast radius.

Тобто це не тільки AI-failure. Це ще й governance failure.

Корінь проблеми: “використовуйте AI частіше” без посилення процесів

Багато компаній зараз вимагають або дуже активно стимулюють використання корпоративного ШІ в роботі. Сам по собі цей курс не є помилкою.

Помилка починається тоді, коли KPI на використання ШІ ростуть швидше, ніж зрілість процесів:

• change management,
• політики деплою,
• rollback-процедури,
• захист середовищ,
• аудит дій,
• плейбуки реагування на інциденти.

Якщо впровадження прискорюють, а контролі не добудовують — інцидент стає питанням часу.

Що варто взяти з цього кейсу інженерним командам

Якщо команда інтегрує AI-агентів у pipeline розробки та релізів, рівень вимог до безпеки має бути вищим, а не нижчим.

Мінімальні обмеження для AI-агентів у продакшен-процесах

• Жодних прямих деплоїв у прод без підтвердження людиною
• Жодних руйнівних дій за замовчуванням (delete, drop, recreate, reset) без явного підтвердження
• Read-only режим на старті для агентів аналізу/діагностики
• Скоуповані права на рівні репозиторію, сервісу та середовища
• Обов’язковий перегляд diff перед застосуванням змін
• Підготовлений rollback-план до запуску агента
• Аудит-логування кожної дії, ініційованої AI
• Kill switch для моментальної зупинки агента

Чому “видалити і створити заново” — це червоний прапорець

Навіть для людини стратегія “видалити й перевідтворити” у продакшені — зазвичай ризикований крок, якщо це не частина заздалегідь відрепетируваної міграції.

Для AI-агента цей патерн ще небезпечніший, тому що він може:

• оптимізуватися під швидкість, а не безперервність бізнесу;
• не бачити прихованих залежностей;
• не розуміти операційних обмежень поза власним контекстом;
• поєднати кілька «локально логічних» дій у глобально катастрофічний сценарій.

Саме тому для інфраструктури та деплой-автоматизації потрібні жорсткі політики, а не просто сподівання, що “агент розбереться”.

AI в інженерії: корисний інструмент, але не суверенний оператор

AI-асистенти чудово підходять для:

• пошуку по коду;
• генерації boilerplate;
• драфту тестів;
• стислих incident summary;
• підказок по конфігурації;
• підготовки runbook-чернеток.

Але коли агент отримує право самостійно виконувати привілейовані дії end-to-end без нагляду людини — це вже інша категорія ризику.

Чим потужніший інструмент, тим більш нудними, чіткими й суворими мають бути обмеження.

Висновок

Цей кейс — хороше нагадування для всіх команд, які впроваджують AI-агентів:

Не плутайте прискорення з контролем.

ШІ може суттєво пришвидшити роботу команди, але лише тоді, коли продакшен-процес побудований так, щоб стримувати помилки — включно з машинними.

А якщо в форматі мему, то так:

Скайнет vs Amazon 1:0 😅

А якщо в форматі інженерної практики:

Guardrails vs Outages мають бути 1:0.