Триггеры, которые стоит назвать заранее
Без явных триггеров старые агентные системы почти всегда живут дольше, чем безопасно и полезно:
- среда исполнения или модель устарели;
- контракт возможности больше не считается безопасным;
- стоимость сопровождения стала слишком высокой;
- потолок качества достигнут, дальше нужна замена;
- новый платформенный путь вытесняет старый (Architecture Governance);
- изменились регуляторные или управленческие требования;
- продуктовая задача больше не существует.
Последний пункт — самый частый и самый незамечаемый: задача ушла, а агент остался, потому что его никто не выключал.
Вывод и замена — разные сценарии
Вывод из эксплуатации — система или возможность просто снимается. Замена — старая снимается, но её место занимает новая, до или параллельно.
Разница не терминологическая: при замене возникает период, когда обе системы имеют право действовать, и именно в нём случаются двойные побочные эффекты. Поэтому замена делается поэтапно, а не бинарным переключением, с явным ответом на вопрос, кто владеет действием в переходном окне (Canary Release LLM).
Уход идёт по слоям
Отключение точки входа — не вывод из эксплуатации. Слои снимаются отдельно, и порядок важен: сначала право действовать, потом доступ, потом данные.
- Право на действие — политики, подтверждения, контракты возможностей;
- Идентичность и доступы — токены, сервисные учётки, подписки на события (Agent Identity);
- Память и контрольные данные — отдельная дисциплина: записи, влиявшие на решения, нельзя просто удалить, если по ним ещё может понадобиться разбор (Memory Boundaries);
- Возможности и схемы — объявляются устаревшими по процедуре, как публичный API (API As Product);
- Пользовательский переход — то, что видит человек, тоже часть жизненного цикла.
Дешевле не снимать права, а выдавать их так, чтобы они снимались сами. Стандарт формулирует это для привилегированного доступа: он выдаётся точно в срок, с заданной предельной длительностью сессии и автоматическим истечением, а желаемое состояние названо нулевым постоянным доступом (AISVS C5.2.6); к этому добавляется ротация учётных данных агента по расписанию (C9.4.3). Смысл для вывода из эксплуатации прямой: у системы с нулевым постоянным доступом «тихо оставленного права действовать» не бывает по построению — забытая учётка истекает сама, а не ждёт, пока о ней вспомнят.
Отдельная строка для аварийного пути: останов обязан оставаться под управлением человека и жить вне рантайма агента — ручной аварийный выключатель (C9.6.1) и команды останова по каналу, изолированному от самого агента (C9.6.3). Выключатель, живущий внутри выводимой системы, выводится вместе с ней.
Почему это вопрос безопасности, а не уборки
Осиротевший агент сохраняет доступ к системам и данным, но теряет владельца — то есть никто не отвечает за его поведение и никто не заметит, если оно изменится. Для контура безопасности это хуже, чем работающий агент с известными рисками (Agent Registry).
Связано с
- ADLC — конец цикла, который обычно не проектируют
- Agent Registry — учёт, из которого видно кандидатов на вывод
- Agent Governance — управление парком и уровнями автономии
- Agent Identity — какие субъекты нужно погасить
- Memory Boundaries — почему память удаляется не сразу
- API As Product — процедура объявления устаревшим
- Canary Release LLM — поэтапность замены