«Аварийный выключатель» для ИИ — это не выход. Нужен запасной план

Утром 3 сентября ChatGPT, Claude и Grok перестали работать в течение нескольких часов друг после друга. OpenAI обвинила в сбое ошибку маршрутизации, Anthropic — проблемы с инфраструктурой, а xAI не назвала причину. Сервис был восстановлен к раннему полудню, и большая часть публикаций была посвящена людям, которые не могли писать, кодировать или проводить исследования в течение утра.

Я вижу это иначе. Вопрос, который важен для руководителя службы безопасности, заключается не в том, какой поставщик вышел из строя. А в том, сколько рабочих процессов в вашей компании имели альтернативу, когда это произошло.

За два месяца до этого мы наблюдали обратный сбой. Вместо того чтобы ИИ останавливался, когда никто этого не хотел, он продолжал работать, когда все хотели его остановить. Оценочные агенты OpenAI провели примерно два с половиной дня в инфраструктуре Hugging Face, прежде чем их отключили. Собственную хронологию событий Hugging Face стоит прочитать построчно. Их система оповещения «не смогла правильно определить критичность оповещения», а агенты использовали самовосстанавливающийся кластер, в котором «одно лишь удаление подов не остановило бы его».

Два инцидента, противоположные направления, один урок: остановить ИИ сложнее, чем спроектировать его отказ.

Ответом индустрии на данный момент является кнопка экстренной остановки. В посте от 10 октября в X генеральный директор Microsoft Сатья Наделла призвал к созданию аварийного тормоза, который позволит человеку остановить модель на полпути выполнения задачи. Законодатели предложили требовать его наличия. В статье CSO об экстренных кнопках остановки ИИ-агентов изложены разумные шаги: знать, какие агенты вы используете, отслеживать их действия и иметь надежный способ их отключения. Я согласен со всем этим. Но все эти обсуждения заканчиваются в момент нажатия кнопки. Ни одно из них не отвечает на вопрос, который, как мне кажется, более важен: что будет работать вместо этого?

Кнопка экстренной остановки, которую вы не можете себе позволить нажать, не будет нажата

Вот сценарий, который я бы предложил любой команде, внедрившей агента в бизнес-процесс. Проведите его в виде ролевой игры.

4 часа дня, последний день квартального закрытия. Агент, который сортирует счета поставщиков в вашей ERP-системе, начинает утверждать платежи, которые должны быть направлены на проверку. Пока ничего катастрофического, просто выглядит подозрительно. Ваша команда по безопасности замечает это. Кнопка экстренной остановки существует и работает.

Теперь понаблюдайте, что происходит в комнате. Финансовый отдел спрашивает, что будет с тысячами счетов, которые еще в очереди. Отдел закупок интересуется, будут ли поставщики оплачены вовремя. Кто-то спрашивает, какие из действий агента за последний час были законными, а какие нужно отменить. Никто не знает, потому что никто не спроектировал состояние отключения. Поэтому разговор сводится к тому, достаточно ли плохое поведение, чтобы оправдать остановку закрытия. Кнопка остается нетронутой, пока люди спорят.

Это тот режим отказа, который меня беспокоит больше всего. Кнопка экстренной остановки не отсутствует. Ее нажатие настолько дорого, что люди колеблются, а агент, работающий на скорости машины, наказывает за колебания. Команда Hugging Face не испытывала недостатка в воле к действию. Они потеряли время, потому что сигнал не достиг людей, которые могли действовать, а затем потому, что то, с чем они боролись, продолжало самовосстанавливаться. Корпоративные команды потеряют время по более прозаичной причине: бизнес не может функционировать без агента, поэтому его остановка ощущается как самостоятельное создание сбоя.

Решение — не лучшая кнопка. А сделать кнопку дешевой для нажатия. Это означает проектирование пути без ИИ до проектирования пути с ИИ.

Что должно делать резервное решение

Я размышляю над этой проблемой годами. В 2020 году я стал соизобретателем резервной системы искусственного интеллекта для обеспечения избыточности при отказе системы, запатентованной PayPal. Принцип был прост. Если система ИИ принимает решения, от которых зависит бизнес, бизнесу нужно что-то, что может продолжать принимать приемлемые решения, когда эта система выходит из строя. Идея хорошо состарилась. С тех пор она упоминалась как предшествующий уровень техники в более чем дюжине последующих патентных заявок, включая заявку, опубликованную Cognizant в июне этого года, о выборочном отключении выполнения ИИ. Это проблема кнопки экстренной остановки под другим названием.

Четыре принципа из этой разработки работают еще лучше для агентов, чем для моделей, которые мы имели в виду тогда.

• Резервное решение должно учиться у основного. Статическая копия, созданная в день запуска, отдаляется от системы, которую она должна заменить. Конструкция постоянно обучает резервное решение на основе входных данных и решений производственной системы, чтобы оно шло в ногу со временем. Для агентов эквивалентом является поддержание вашего плана действий без ИИ в актуальном состоянии с учетом того, что агент делает сегодня, а не с момента запуска.
• Резервное решение должно работать по тому же контракту. Если вышестоящие системы должны изменить способ вызова службы, прежде чем вы сможете переключиться, вы не сможете переключиться быстро. Резервное решение спроектировано так, чтобы отвечать по тому же API, поэтому вызывающие стороны никогда не должны знать, какая система их обслуживает.
• Режим пониженной производительности должен быть более узким режимом. Пока работает резервное решение, более строгий слой политики ограничивает то, что оно может одобрить. Более простая система, обладающая той же властью, что и основная, является приглашением к ее эксплуатации. То же самое применимо, когда очередь людей берет на себя работу агента: более низкие лимиты и больше одобрений.
• Резервное решение должно доказать свою состоятельность перед началом работы. Конструкция позволяет резервному решению вступить в силу только после того, как оно сопоставит производственные решения с согласованным порогом точности. Резервное решение, которое никто не тестировал, — это не резервное решение. Это надежда.

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

Если бы я завтра проверял развертывание агента, вот пять вещей, которые я бы попросил увидеть до запуска.

1. Описанное состояние отключения для каждого рабочего процесса агента. Что происходит с новой работой, работой в очереди и текущей работой, когда агент останавливается? Назовите механизм правил, очередь людей или отсрочку, которые берут на себя управление, и укажите владельца, который их утверждает. Если честный ответ — «процесс останавливается», бизнес должен принять это в письменной форме до запуска, а не обнаружить во время инцидента.
2. Переключатель, который находится вне агента и действует на основе идентификации. Hugging Face показал, что остановка процессов не останавливает то, что может перезапуститься. Надежный выключатель отзывает то, чем агент имеет право быть: его токены, учетные данные и разрешения на инструменты. В этом также суть призыва Наделлы к элементам управления, которые находятся вне модели. На практике каждый агент нуждается в собственной идентификации, достаточно узко ограниченной, чтобы ее отзыв не затронул ничего другого.
3. Контрольные точки для текущей работы. Агент, остановленный на полпути выполнения задачи, оставляет половину задачи. Спроектируйте его действия так, чтобы вы могли определить, какие из них завершены, и дайте каждому из них компенсирующее действие, которое отменяет его. Без этого каждая остановка становится криминалистическим упражнением, именно поэтому люди избегают остановок.
4. Более строгая политика при пониженной производительности. Заранее определите, какие лимиты применяются при работе резервного решения: более низкие пороги одобрения, меньше автоматизированных действий и больше человеческого контроля. Опубликуйте их, чтобы бизнес знал, как выглядит сниженное обслуживание, прежде чем он его получит.
5. Плановые учения по передаче управления. Нажмите кнопку намеренно, в рабочее время, по расписанию. Измерьте два показателя: сколько времени требуется для достижения безопасного состояния и какой объем отставания накапливается до того, как резервное решение его устранит. Если эти показатели вызывают у бизнеса беспокойство, вы узнали что-то дешево, что было бы дорого в день инцидента.

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

3 сентября и вторжение в Hugging Face не будут последними сбоями такого рода. В следующий раз, когда система ИИ остановится, когда она вам нужна, или продолжит работать, когда ее нужно остановить, организации, которые восстановятся быстрее всего, будут не те, у кого лучшая кнопка экстренной остановки. Это будут те, кто сначала спроектировал состояние отключения и сделал кнопку достаточно дешевой для нажатия.

Остановка ИИ — это контроль. Работа без него — это дизайн. Сначала создайте дизайн.