Аварийная остановка — это протокол, а не кнопка

Кнопка остановки необходима. Но сама по себе она не является механизмом остановки. Это различие становится операционным, как только организация разрешает агентам делать больше, чем генерировать текст. Агент может запустить процесс, делегировать подзадачу, поставить сообщение в очередь, вызвать API поставщика, удерживать аренду учётных полномочий или вызвать внешнее действие, заметное людям и значимое финансово. К моменту, когда оператор нажимает «стоп», исходное выполнение уже может превратиться в распределённое дерево работ с разными владельцами, режимами отказа и семантикой завершения.

Рамки управления задают направление. AI RMF NIST требует механизмов и назначенных ответственных для замены, отключения или деактивации ИИ-систем, если их работа или результаты противоречат предусмотренному назначению. В требованиях к мониторингу после внедрения также названы ручное вмешательство, вывод из эксплуатации, реагирование на инциденты и восстановление. Для ИИ-систем, входящих в применимую область высокого риска по EU AI Act, статья 14 требует, чтобы назначенные люди могли вмешаться или прервать работу системы кнопкой остановки либо аналогичной процедурой, переводящей её в безопасное состояние.

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

Остановка — это задача достижения покоя

Неверная модель — элемент управления, который завершает родительский процесс. Верная модель — протокол достижения покоя во всей среде исполнения: управляемый переход от активного выполнения к определённому состоянию, в котором организация способна учесть работу, полномочия и последствия. Это не обещание мгновенного исчезновения всего запущенного. Распределённые системы не дают такого надёжного обещания. AWS документирует, что остановка выполнения Step Functions не гарантирует отмену интегрированной задачи. Отмена выполняется по мере возможности: она может не сработать, если у роли выполнения нет разрешения или сервис недоступен. Следовательно, родительское выполнение может быть остановлено, тогда как инициированная им работа продолжается в другом месте.

Kubernetes показывает ту же границу более предметно. Он различает штатное завершение и принудительное удаление. Особенно важна его оговорка о принудительном удалении stateful-нагрузки: если освободить идентичность, не подтвердив остановку исходного экземпляра, могут появиться два активных экземпляра с одной идентичностью. В системах, опирающихся на семантику «не более одного», сама попытка остановки способна создать новую операционную опасность.

Поэтому автономная организация должна рассматривать статус «остановлено» как утверждение, требующее доказательств, а не как значение, которое выдал интерфейс. Утверждение должно иметь область действия: какая организация, какой процесс, какое дерево выполнений, какой домен полномочий и какой интервал времени? Оно должно быть и уточнено: какая работа предотвращена, какая безопасно завершена, какие последствия компенсированы и что остаётся неразрешённым?

Семь стадий протокола достижения покоя

Практическая управляемая среда исполнения может организовать остановку в семь стадий. Конкретная реализация будет различаться, но эта последовательность задаёт полезный контракт между оркестрацией, идентификацией, инструментами и операционными командами.

1. Заморозить приём новой работы. Пометить соответствующую организацию, процесс или область инцидента как не принимающую новые задания. Планировщики, очереди и пути делегирования должны отклонять новые запуски в этой области. Так восстановление не будет конкурировать со свежей автономной работой.
2. Распространить версионную эпоху отмены. Добавить монотонно растущую эпоху остановки к каждому дочернему выполнению, сообщению и обратному вызову, который способен её переносить. Перед следующей значимой единицей работы исполнитель сравнивает известную ему эпоху. Старое выполнение больше не вправе продолжать работу лишь потому, что исходный запрос когда-то был действителен.
3. Отозвать полномочия или дождаться истечения их аренды. Агенты должны действовать через ограниченные и возобновляемые полномочия, а не через постоянные фоновые учётные данные. Отзыв на сервере авторизации важен, но OAuth 2.0 прямо признаёт задержки распространения на серверах ресурсов. Короткоживущие токены доступа ограничивают оставшееся окно риска, но не отменяют необходимости его наблюдать.
4. Дать безопасно завершаемым операциям дойти до контрольной точки. Некоторые действия в процессе выполнения лучше довести до безопасной точки, а не разрывать посреди записи. Это определение зависит от предметной области и должно быть задано заранее. Штатное завершение — контролируемое решение, а не оправдание продолжать исполнение по умолчанию.
5. Компенсировать обратимые побочные эффекты. Распределённую бизнес-операцию, как правило, нельзя отменить возвратом к прежнему снимку состояния. Компенсация зависит от предметной области, может завершиться ошибкой и должна учитывать параллельные изменения. Среде нужны долговечные записи о ходе процесса, чтобы восстановление можно было продолжить и проверить.
6. Поместить необратимые или неопределённые результаты в карантин. Отправление, переданное перевозчику, внешнее юридически значимое уведомление или действие, чей итоговый статус нельзя подтвердить, нельзя объявлять откатанным. Оно должно попасть в очередь исключений с назначенным владельцем-человеком, подтверждающими данными и определённым путём устранения.
7. Выпустить подписанную запись о достижении покоя. Среда должна засвидетельствовать область и эпоху остановки, предотвращённую работу, безопасно завершённую работу, отозванные или истёкшие полномочия, предпринятые и выполненные компенсации, а также неразрешённые исключения. Это архитектурное предложение, а не дословное требование упомянутых рамок, — но именно такие доказательства нужны управляемой операции.

Классифицируйте инструменты до включения в автономные процессы

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

Такая классификация также устраняет опасную фикцию: будто отмена равна откату. Запрос на отмену способен остановить будущую работу. Но он не отменяет уже доставленное письмо, уже принятое соглашение, уже инициированный физический процесс или решение, которое уже увидел клиент. Некоторые последствия можно компенсировать. Другие можно лишь локализовать, раскрыть или разрешить с участием людей. Среда исполнения должна сохранять это различие, а не прятать его за зелёной меткой «отменено».

Авторизация и достижение покоя относятся к разным моментам

Авторизация в момент фиксации действия остаётся необходимой: она определяет, может ли предложенное действие начаться или быть зафиксировано там, где полномочие действительно важно. Достижение покоя решает более позднюю и иную задачу. Оно управляет локализацией последствий после того, как выполнение уже распространилось по агентам, очередям, инструментам и бизнес-системам. Одно не заменяет другого. Сильная авторизация не возвращает работу, уже запущенную на законных полномочиях. Хороший протокол остановки не делает небезопасные действия допустимыми. Вместе они задают две границы управляемой среды: полномочие перед значимым действием и подотчётная локализация, когда организации необходимо остановиться.

Операционное следствие

Автономной организации не следует оценивать аварийную остановку по скорости смены статуса на панели. Оценивать следует время до подтверждённого достижения покоя для заданных областей и классов риска. Эта метрика включает время на остановку приёма задач, ограничение действующих полномочий, достижение безопасных контрольных точек, классификацию внешних последствий, компенсацию того, что компенсируется, и назначение владельца каждому исключению. Результаты будут неудобными, но полезными. У некоторых процессов путь остановки окажется коротким и надёжным. Другие покажут слишком долгий срок жизни учётных данных, непрозрачные задачи поставщиков, неучтённое делегирование или необратимые действия, поставленные слишком рано. Это не повод ослаблять определение остановки. Это проектные выводы о том, где автономность сейчас превышает управляемость.

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