Почему аварийные выключатели ИИ теперь в приоритете у крупных компаний
- Исследование Splunk за 2026 год оценивает ежегодные потери Global 2000 от простоев в 600 млрд долларов; 68% технологических руководителей обеспокоены поведением ИИ-агентов.
- При сбое Google Cloud в июне 2025 года глобальное включение функции затронуло несколько регионов и сервисов; Google отметила отсутствие флага функции.
- Гендиректор Unleash Эгил Эстхус описывает управление функциями во время работы: ограничивать доступ к ИИ, отключать его или переключать на резервный вариант без нового развертывания.
Почему это важно: Такие механизмы помогают ограничивать последствия сбоев и немедленно останавливать проблемное поведение ИИ в производственных системах.
Искусственный интеллект всё глубже проникает в корпоративную инфраструктуру, расширяя вместе с этим горизонт рисков. По мере того как ИИ переходит от генерации текста в изолированных средах к инициированию транзакций, влиянию на решения и участию в создании программного кода для производственных сред, последствия ошибки могут распространяться на взаимосвязанные системы.
Согласно исследованию Splunk за 2026 год, опубликованному Cisco совместно с Oxford Economics, незапланированные простои обходятся компаниям из списка Global 2000 в общей сложности в 600 млрд долларов в год, а средняя стоимость простоя достигает 15 000 долларов в минуту.
Недавние сбои облачных сервисов показывают, как способ внедрения изменений может повлиять на масштаб инцидента. Во время крупного сбоя Google Cloud в июне 2025 года новую функцию активировали по всему миру, а не внедряли постепенно, согласно последующему отчёту Google об инциденте. Когда изменение привело к сбоям, из-за масштабного развертывания последствия сразу затронули несколько регионов и сервисов, включая сторонние платформы, зависящие от инфраструктуры Google Cloud.
Позже Google указала, что постепенное развертывание было одной из мер защиты, которые следовало применить. Этот инцидент наглядно иллюстрирует общий принцип устойчивости: ограничение первоначального охвата изменений может уменьшить потенциальный масштаб последствий и дать командам возможность вмешаться до того, как проблема распространится на производственную среду.
Этот риск также становится частью более широкой дискуссии о корпоративном управлении. В том же исследовании Splunk выяснилось, что 68% опрошенных руководителей технологических подразделений обеспокоены непредсказуемым поведением ИИ-агентов, а все участники опроса сообщили о той или иной форме простоя, связанного с ИИ. Пример Google особенно актуален в контексте стремительных изменений, которые ИИ привносит в разработку программного обеспечения.
Недавно генеральный директор Google Сундар Пичаи заявил в годовом отчёте Alphabet: «Сегодня ИИ генерирует почти 75% всего нового кода в Google, после чего инженеры его проверяют и одобряют. Осенью прошлого года этот показатель составлял 50%». По мере того как ИИ увеличивает объём и ускоряет темп изменений в программном обеспечении, такие инциденты, как сбой Google, показывают, почему механизмы контроля за внедрением этих изменений в производственную среду могут приобретать всё большее значение.
Эти данные позволяют предположить, что одной лишь наблюдаемости может быть недостаточно для решения всех операционных задач. Мониторинг способен выявлять необычное поведение или ухудшение производительности, а механизм вмешательства даёт командам возможность остановить определённый процесс при наступлении заранее заданных условий.
Таким образом, вопрос всё чаще заключается не только в том, как организации наблюдают за системами ИИ, но и в том, как сохраняют над ними операционный контроль. По мере того как автоматизированное программное обеспечение становится более функциональным и теснее интегрируется с производственными средами, возможность приостанавливать, отключать или отменять работу функций на базе ИИ может стать важной частью планирования устойчивости наряду с мониторингом и реагированием на инциденты.
Теперь вопрос заключается не столько в том, могут ли компании внедрять ИИ, сколько в том, как им контролировать, ограничивать и отменять поведение систем на его основе, когда такие системы становятся частью повседневной работы.
Эгил Эстхус, генеральный директор Unleash, рассматривает этот вопрос в контексте эволюции управления выпусками программного обеспечения. Unleash — это платформа управления функциями с открытым исходным кодом, которая разделяет развертывание кода и решение о том, когда активировать или изменить поведение программного обеспечения в производственной среде, позволяя организациям управлять приложениями, сервисами и возможностями на базе ИИ во время выполнения.
Это различие становится особенно важным по мере того, как разработка с помощью ИИ увеличивает поток изменений кода, направляемых в производственную среду. «Тормоза гоночного автомобиля нужны для того, чтобы ехать быстрее, а не медленнее, — говорит Эстхус. — Команды могут работать быстрее, если знают, что способны мгновенно отменить проблемное изменение, не дожидаясь, пока исправление пройдёт весь путь до производственной среды».
В этой модели Unleash служит уровнем управления, определяющим поведение программного обеспечения после его развертывания в производственной среде. Вместо того чтобы считать развертывание последним этапом контроля, организации могут ограничивать охват новой функции и немедленно вмешиваться, если её поведение выходит за допустимые рамки.
Именно этой меры защиты, как выяснила Google после сбоя в 2025 году, и не хватало. В отчёте по итогам инцидента Google указала, что в проблемном участке кода «не было надлежащей обработки ошибок, а также защиты с помощью флага функции», добавив: «Если бы этот участок был защищён флагом, проблему обнаружили бы на этапе тестирования».
В приложениях на базе ИИ такой контроль во время выполнения может уменьшить масштаб последствий проблемного поведения и обеспечить возможность немедленно локализовать проблему или переключиться на резервный вариант, не дожидаясь нового развертывания.
«Например, команда может предоставить доступ к функции ИИ ограниченной группе пользователей, отслеживать её поведение, расширить доступ при выполнении заранее заданных условий или отключить её, если установленный порог будет превышен, — объясняет Эстхус. — Так решение о запуске функции ИИ отделяется от неизменности кода, в котором она реализована».
Такое разделение также превращает абстрактное требование к управлению в конкретный операционный инструмент. Согласно Закону ЕС об искусственном интеллекте, системы ИИ высокого риска должны обеспечивать надлежащий человеческий контроль, в том числе возможность вмешиваться в их работу или прерывать её с помощью кнопки «стоп» либо аналогичной процедуры, переводящей систему в безопасное состояние.
Для финансовых организаций DORA уже устанавливает ещё одно требование: о крупных инцидентах в сфере ИКТ необходимо сообщать первоначально в течение четырёх часов после их классификации как крупных и не позднее чем через 24 часа после обнаружения. В таких условиях важно не просто наличие политики, согласно которой человек может вмешаться.
Важно и то, есть ли у этого человека техническая возможность немедленно остановить проблемное поведение ИИ, по возможности сохранить работу базового сервиса и зафиксировать для аудита, что именно и когда было изменено.
Для организаций, использующих ИИ в критически важных для бизнеса системах, сам механизм контроля тоже должен быть устойчивым. Unleash может выполнять логику принятия решений для аварийного отключения ИИ в собственной среде клиента, рядом с контролируемыми приложениями и сервисами. Это означает, что для вмешательства не нужно ждать, пока новое развертывание распространится по системам, или поддерживать связь с внешней службой управления.
Если функцию ИИ необходимо остановить, ограничить или перенаправить на предусмотренный резервный вариант, изменение вступает в силу немедленно в среде, где работает программное обеспечение. Благодаря этому контроль во время выполнения становится частью самой архитектуры устойчивости, а не ещё одной внешней зависимостью во время инцидента.
Более широкий тезис Эстхуса связывает эту возможность с меняющейся экономикой разработки программного обеспечения. Инструменты ИИ упрощают и ускоряют генерацию кода, потенциально увеличивая число изменений, которые разработчики вносят в производственные среды.
Такое ускорение может повысить потребность в механизмах, способных с той же скоростью справляться с ошибками. С этой точки зрения роль управления функциями развивается вместе с самим программным обеспечением. Цель — определить, как вводить, ограничивать, отслеживать и отключать конкретные функции по мере изменения условий.
По мере того как ИИ всё глубже интегрируется в критически важные для бизнеса системы, возможность быстро вмешаться может стать неотъемлемой частью операционной устойчивости, корпоративного управления и готовности к регулированию. Масштаб расходов на простои, охват облачной инфраструктуры и опасения по поводу автономного поведения ИИ — всё это говорит о том, что механизмы контроля стоит рассматривать наряду с самими системами.
