Управляемость агентов: почему ИИ-ассистенты не масштабируются без контроля

Автономный агент без управляемости масштабируется ровно до первого инцидента. Сначала это удобно: агент сам ходит по инструментам, сам решает, что делать дальше, сам исправляет ошибки. Потом он отправляет письмо не тому, меняет данные, которые менять не должен был, или зацикливается на дорогом инструменте — и выясняется, что объяснить, почему он так сделал, никто не может. Управляемость — это инженерное требование, а не надстройка для отчётности.

Чем больше автономии, тем дороже её отсутствие границ

Соблазн понятен: чем больше агенту разрешено, тем меньше кода и тем «умнее» он выглядит на демо. Но автономия без границ — это не гибкость, это неопределённое поведение, помноженное на права доступа.

Неограниченный набор инструментов. Если агент может вызвать любой инструмент, пространство его возможных действий не описуемо и не тестируемо. Один и тот же запрос в двух прогонах может пойти разными путями, и оба раза это «нормально» с точки зрения агента.

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

Решения нетрассируемы. Если нельзя восстановить, на основании какого контекста и какого шага агент принял конкретное решение, инцидент невозможно разобрать. «Перепромптим и понадеемся» — это не разбор инцидента.

Нет терминального обработчика. Если у процесса нет точки, в которой неуверенный или рискованный случай гарантированно уходит человеку, агент будет принимать такие решения сам — молча и до первого громкого промаха.

Из чего состоит управляемость

Узкие зоны ответственности. У каждого агента — одна задача, типизированный вход и выход, ограниченный набор инструментов. Это не бюрократия, это то, что делает поведение воспроизводимым и тестируемым.

Политики доступа к контексту. Агент получает ровно тот контекст, который нужен его шагу, а не всё подряд. Доступ — это конфигурируемый слой, а не побочный эффект архитектуры «дадим всё, разберётся».

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

Настраиваемые пороги эскалации. Уверенность ниже порога, шаг с высокой ценой ошибки, нестандартная ситуация — всё это уходит человеку по явному правилу, а не по решению агента «справлюсь сам». Эскалация — это терминальный обработчик, а не аварийный выход.

Практические ориентиры

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

Вывод

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