Недавние сообщения о внутренней реакции 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), которые интегрируются бесшовно, пожалуйста, оставьте ваши контактные данные ниже и мы к вам обратимся:
