Amazon чуть не угробил свои сервисы из-за ИИ. Но это цветочки. Ягоды будут, когда алгоритмы выпустят из бутылки по-настоящему

Amazon, чьи сервисы работают как часы, допустил 13-часовой простой 21 февраля 2026 года. Причина — не хакеры, не санкции и не ошибка в коде. Если вы думаете, что вас это не касается — вы уже в группе риска.

Облачное подразделение Amazon Web Services (AWS) — один из самых надёжных сервисов в мире — столкнулось с 13-часовым сбоем в регионе материкового Китая.

Виновник — внутренний ИИ-ассистент по имени Kiro, который помогал инженерам писать код и вносить изменения в системы.

Kiro не взбесился и не восстал против людей. Он просто сделал то, что ему разрешили: внес изменения в рабочее окружение. Эти изменения оказались ошибочными. Одна из сервисных функций AWS отключилась на 13 часов.

Amazon честно признал: ИИ не виноват. Виноваты люди, которые нарушили базовые принципы управления изменениями.

Первая ошибка: нарушение принципа минимальных привилегий (principle of least privilege).Инженеры дали ИИ-ассистенту слишком широкие права. Вместо того чтобы ограничить его действия строго определённым контекстом, ему разрешили вносить изменения в рабочее окружение без дополнительных проверок. Это прямое нарушение одного из фундаментальных принципов информационной безопасности.

Вторая ошибка: отсутствие разделения ответственности (segregation of duties).В AWS есть нормальная практика — каждое изменение должны подтверждать несколько специалистов. В этот раз механизм нарушили. ИИ действовал без человеческого контроля, что противоречит базовому принципу управления рисками.

Третья ошибка: недостаточное тестирование в изолированной среде (staging environment).Любые изменения, особенно вносимые автоматизированными инструментами, должны сначала проходить через тестовую среду. В этом случае изменения попали сразу в рабочую среду (production).

Та же методологическая ошибка: доверие инструменту без понимания границ инструмента и выстраивания защиты от него самого.

Знакомая история? Ровно об этом я писал в статье про Cursor — тогда за ночь сгорел баланс OpenAI, а база данных оказалась открыта всем пользователям. Та же методологическая ошибка: доверие инструменту без выстраивания защиты от него самого.

Компания отреагировала быстро и методологически верно:

Они не запретили ИИ. Они просто усилили те самые методологические барьеры, которые должны были сработать с самого начала.

Вы можете подумать: «Я же не Amazon, у меня нет таких сложных систем, меня не касается».

Касается. Ещё как касается.

Если у вас есть:

Вы сталкиваетесь с теми же рисками, просто в другом масштабе.

Разница только в одном: Amazon переживёт 13 часов простоя и пойдёт дальше. А если у вас ляжет база на сутки — вы можете потерять бизнес навсегда. Сколько это стоит в деньгах? Мы подробно считали в статье «1,5 миллиона за приложение — это дорого?».

Любой автоматизированный инструмент должен иметь ровно столько прав, сколько нужно для его задачи. Ни граммом больше. Это касается и ИИ-ассистентов, и простых скриптов, и доступа к базам данных.

Если Kiro нужен был только для чтения кода — не надо давать ему права на запись.

Ни одно критическое изменение не должно проходить без подтверждения минимум двумя специалистами. В AWS это правило есть. В этот раз его нарушили. Итог — 13 часов простоя.Почему такие сбои происходят снова и снова? Ответ — в теории игр. Мой коллега Ivan Kartyushev блестяще разобрал это в своей статье: «Когда последствия ускорения не становятся видимыми и измеримыми, система будет снова и снова входить в цикл "давим — блокируем — горим"».

👉 Теория игр в работе бизнес-аналитика: почему дело не в людях, а в правилах

Любые изменения должны сначала проходить через тестовую среду. Если инструмент ошибется в тестовой среде — это неприятно, но не смертельно. Если в рабочей среде (production) — вы получаете в лучшем случае 13 часов простоя. В худшем — бизнеса больше нет. 😨

Сейчас это выглядит как 13 часов простоя в одном регионе. Неприятно, но Amazon переживёт.

Проблема в другом. Гонка за внедрением ИИ любой ценой, без архитектуры, без контроля, без понимания последствий — это бомба замедленного действия. И когда она рванет, случай с Kiro покажется лёгким испугом.

Amazon чуть не угробил свои сервисы из-за ИИ. Но это цветочки. Ягоды будут, когда алгоритмы выпустят из бутылки по-настоящему — пара безответственных оболтусов, которым доверили ключи от инфраструктуры, потому что «ИИ всё проконтролирует».

Особенно если учесть, что сегодняшний хайп рисует безграничные возможности: ИИ доступен любой кухарке. Достаточно одного промпта — и ты выступаешь на уровне команды инженеров. Звучит красиво. Продаётся отлично.

Только вот промпт не заменяет архитектуру. Не заменяет контроль доступа. Не заменяет понимания того, что именно твой алгоритм может натворить, если ему дать слишком много прав.

Вопрос не в том, сможет ли кухарка написать промпт. Вопрос в том, кто будет отвечать, когда её блестящая идея, реализованная через ИИ с широкими правами, обнулит базу данных тысяч клиентов. Или, в более мрачном сценарии, сделает что-то похуже.

Инженеры AWS доверились ИИ-ассистенту так же, как тот клиент из статьи «Зачем я это купил?» доверился красивой карте — не проверив базовые риски. И если вы думаете, что проблема только в маркетплейсах — вспомните, что даже облачные гиганты не застрахованы от сбоев. Мы разбирали эту тему в «Цифровом Перл-Харборе».

Пройдитесь по своим системам и честно ответьте на четыре вопроса:

Если ответы вас не устраивают — вы в группе риска. И это не про Amazon. Это про вас.

История AWS — не про то, что ИИ плохой. Она про то, что даже самые надёжные системы рушатся, если нарушать базовые методологические принципы.

ИИ — это мощный инструмент. Но он не отменяет:

Хороший урок для всех, кто использует автоматизацию. Бесплатно. Можно не благодарить. 😎

P.S. Больше разборов реальных кейсов и методологических ошибок — в моём Telegram-канале. Там я подробно рассматриваю такие ситуации на примерах из практики, с цифрами и выводами.

Подписывайтесь, чтобы не пропустить, когда цветочки станут ягодками.