Нещодавні повідомлення про внутрішню реакцію Amazon на серію інцидентів, пов’язаних із ШІ, часто подаються як історія про код, згенерований ШІ. Однак ширше висвітлення в новинах (і особливо гострі реакції) свідчать про дещо важливіше. Ця ситуація швидко перетворюється на дискусію про те, як індустрія програмного забезпечення контролює та перевіряє зміни, на які вплинув ШІ.
Нижче наведено стислу хронологію інцидентів навколо Amazon:
- Липень 2025: Amazon запустила Kiro – IDE на базі агентного ШІ. За повідомленнями, всередині компанії була встановлена мета досягти щотижневого використання інженерами на рівні 80%.
- Середина грудня 2025: зміна у продакшні, виконана за допомогою Kiro, за повідомленнями, спричинила 13-годинний збій AWS Cost Explorer у материковому Китаї після того, як інструмент видалив і повторно створив середовище.
- Кінець 2025: окремий інцидент за участю Amazon Q Developer, за повідомленнями, спричинив внутрішній збій сервісу за подібних обставин.
- 20 лютого 2026: Financial Times опублікувала розслідування щодо інциденту з Kiro. В Amazon причиною назвали «помилку користувача» та неправильно налаштований контроль доступу, а не сам ШІ.
- 5 березня 2026: сайт роздрібної торгівлі Amazon і мобільний застосунок для покупок були недоступні приблизно шість годин. Причиною компанія назвала помилкове розгортання програмного коду.
- 10 березня 2026: за даними Financial Times, після чотирьох інцидентів рівня Sev-1 протягом одного тижня в Amazon провели обов’язковий поглиблений аналіз. Внутрішня службова записка (згодом видалена) пов’язувала «зміни, виконані за участю Gen-AI», із ширшою тенденцією інцидентів.
Публічна позиція Amazon полягає в тому, що ці інциденти є наслідком помилок користувачів і неправильно налаштованих механізмів контролю доступу, а не роботи ШІ.
Однак така відповідь викликала значний скепсис. Водночас головні висновки не пов’язані з деталями будь-якого окремого інциденту.
Набагато важливішим є те, як організації, що створюють програмне забезпечення, розширюють використання ШІ швидше, ніж розвиваються механізми контролю та перевірки, необхідні для безпеки цього використання.
Асистенти для написання коду – лише частина цієї картини. До неї також належать агентні робочі процеси, автоматизовані рекомендації щодо змін та системи, здатні діяти з широкими дозволами у середовищах розробки й продакшну. Спільна фундаментальна проблема полягає не у фактичній наявності та використанні ШІ. Проблема в тому, що надто багато організацій ігнорують перевірку змін, надаючи пріоритет швидкості розгортання.
Такий підхід був слабким ще до появи ШІ. Коли ШІ тепер інтегрований практично всюди, захищати подібну модель стає ще складніше. У деяких випадках вона може бути відверто небезпечною.
Прискорення змін у програмному забезпеченні посилює наслідки недостатньої перевірки
Історія з Amazon важлива (як і реакції на неї), тому що обидва явища відображають все поширенішу тенденцію в індустрії. Команди активно впроваджують ШІ, щоб усунути «зайві» перешкоди у процесі розробки та впровадження ПЗ. Однак поступово з’являється усвідомлення, що частина цих «зайвих» перешкод фактично виконувала корисні функції контролю.
Перевірка коду сповільнює роботу, але водночас дозволяє виявити помилкові припущення. Обмежені дозволи можуть здаватися неефективними під час розробки, але вони здатні зменшити масштаб наслідків у продакшні. Незалежне тестування потребує часу та зусиль, але саме воно показує, чи створила зміна реальну проблему у робочому середовищі.
Коли організації починають використовувати ШІ для прискорення генерації коду, пропонування виправлень, створення змін інфраструктури або виконання дій у різних системах, значення цих механізмів контролю зростає. Питання вже не обмежується тим, чи здатен інструмент ШІ створити небезпечний код. Питання полягає в тому, чи здатна організація перевіряти якість і вплив змін, виконаних за участю ШІ, протягом усього життєвого циклу програмного забезпечення.
Цей повний цикл охоплює не лише функціональність. До нього також належать надійність, доступність і безпека. Кожен із цих аспектів може порушитися, якщо перевірка розглядається як другорядний елемент.
Це не лише про асистентів програмування
Один із ризиків цієї дискусії полягає в тому, що «кодування за допомогою ШІ» може стати зручним ярликом для ширшого набору проблем контролю. Якщо команда розробки покладається на код, створений ШІ, без належної перевірки – це проблема валідації. Якщо агент ШІ отримує надмірні дозволи на зміну систем або робочих процесів – це проблема нагляду. Якщо команди довіряють автоматизованим результатам, не перевіряючи, що фактично працює у продакшні – це проблема підтвердження. Жодна з цих ситуацій не є унікальною або виключною для коду, згенерованого ШІ.
Крім того, усі ці сценарії пов’язані між собою і можуть легко переходити з однієї категорії в іншу. Помилка функціональності може перетворитися на проблему доступності. Проблема надійності може створити прогалину в безпеці. Агент із надмірними повноваженнями може сформувати погану рекомендацію, виконати неправильну дію і зробити це з машинною швидкістю. Для цього не потрібні футуристичні припущення. Подібні наслідки безпосередньо випливають із неконтрольованої автоматизації, яка надає системам надмірну автономію, залишаючи рівень нагляду на pre-AI рівні або навіть нижче.
Саме тому технологічній індустрії варто уникати спокуси перетворювати кожну історію, де згадуються ШІ та програмне забезпечення, на чергову суперечку про те, чи «добре» або «погано» ШІ пише код. Це справді важливе питання для обговорення. Однак набагато нагальнішим є інше: чи створили організації достатньо надійний шар перевірки для всіх завдань, які покладаються на ШІ.
Індустрія намагається автоматизувати прийняття рішень без перевірки результатів
Багато організацій використовують ШІ не лише для швидшої доставки коду. Водночас скорочується можливість перевірки, перевантажуються досвідчені команди. Попри це очікується досягнення таких самих або навіть кращих результатів.
Коли людський нагляд послаблюється саме в той момент, коли автоматизація та автономність ШІ посилюються, перевірка повинна ставати точнішою, щоб компенсувати цей ефект. Інакше виникнуть збої.
Недостатньо просто стверджувати, що остаточне рішення залишається за людьми. Це звучить розумно та відповідально. Однак на практиці така теза часто має мало значення, якщо розробники, які перевіряють код, перевантажені, дозволи надто широкі або тестування не встигає за швидкістю релізів.
У програмному забезпеченні результат важливіший за наміри. Миттєва пропозиція коду, що створює дефект, усе одно залишається дефектом. Ефективний робочий процес із використанням ШІ, який спричинив збій, усе одно впливає на доступність. Повністю автоматизована зміна, що відкриває додаток або API для атаки, усе одно створює ризик. Якщо кінцевим результатом стає великий глобальний інцидент, ефективність досягнення цього результату не має значення.
Саме тому перевірка є ключовою. Заяви про підвищення продуктивності робити легко. Заяви про безпеку, стійкість і надійність потребують реального підтвердження.
Команди безпеки мають тримати дискусію прив’язаною до реальності виконання
Хоча історія з Amazon безпосередньо не пов’язана з безпекою, вона підкреслює дуже практичні уроки для команд AppSec. Коли ШІ збільшує темп і масштаб змін, безпека повинна бути тісно пов’язана з тим, що додатки та API фактично роблять під час роботи. Це означає, що, окрім інтеграції тестування безпеки в ШІ-асистентів у межах IDE, що може забезпечити рішення Mend.io (SAST, SCA), важливо перевіряти поведінку під час виконання за допомогою DAST (наприклад, від Invicti), щоб підтвердити фактичну відкритість системи.
Це особливо важливо, тому що збої безпеки, пов’язані з ШІ, можуть мати багато різних проявів. Іноді ШІ справді може створити відверто небезпечний код. Але значно частіше він може різко посилювати звичайні операційні помилки.
За швидкості, характерної для систем із підтримкою ШІ, часто неможливо заздалегідь передбачити й перекрити всі можливі сценарії провалу. Тому особливо важливо постійно перевіряти, що є реальним, що доступним і що потребує уваги саме зараз.
Саме тут автоматизоване тестування безпеки та безперервна перевірка відіграють чітку роль у ширшій дискусії про безпеку ШІ. Йдеться не про гальмування інновацій і не про формальну відповідність вимогам, що обмежує продуктивність розробників. Йдеться про спосіб змусити організації розробки програмного забезпечення чесно оцінювати реальні результати.
Висновок
Amazon може виглядати зручним об’єктом для критики як черговий приклад зіткнення ажіотажу навколо ШІ з операційною реальністю. Однак деталі цієї історії менш важливі, ніж головний урок: подібні ситуації виникають тоді, коли механізми нагляду та перевірки не встигають за темпами впровадження ШІ.
Проблема не обмежується однією компанією, одним асистентом програмування або одним типом інцидентів. Вона відображає ширшу тенденцію в індустрії – надмірну довіру до результатів ШІ, рекомендацій ШІ та дій, виконаних за допомогою ШІ, ще до формування достатньої дисципліни щодо того, як ці швидко створені результати перевіряються, тестуються та обмежуються.
У міру того як організації дедалі глибше й ширше інтегрують ШІ у створення та експлуатацію програмного забезпечення, перевірка має зайняти центральне місце в процесі. Зрештою, питання полягає в забезпеченні відповідності якості програмного забезпечення темпу релізів, посиленому ШІ. Компанії, які впораються з цим завданням, навряд чи потраплятимуть у новини через забезпечення надійності, доступності та безпеки. Проте саме вони матимуть значно більше шансів уникнути заголовків про чергові злами або масштабні збої.
Якщо ви хочете безкоштовно протестувати Invicti (DAST) і Mend.io (SAST, SCA), які безшовно інтегруються, будь ласка, залиште ваші контактні дані нижче і ми до вас звернемося:
