Реальный риск корпоративного ИИ — не автономные агенты. А сложность между ними.

Главный риск корпоративного ИИ — сложность между агентами

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

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

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

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

Обычно проблему пытаются свести к контрольному списку: согласовать агента, включить журналирование и перейти дальше. Но такой подход не подходит. Контрольный список фиксирует состояние в один момент, тогда как сложность возникает вдоль всей цепочки. Цепочкой нельзя управлять набором разовых согласований — так же как нельзя считать диету успешной из-за одного съеденного овоща.

Сначала обычно разрастаются права. Кто-то создаёт агента для обобщения заявок в службе поддержки и выдаёт ему широкий доступ к API: правильно ограничить полномочия заняло бы ещё один рабочий цикл. Затем об агенте забывают. Через шесть месяцев у него уже оказывается путь к платёжной системе. Никто не помнит, кто это согласовал. Потому что, возможно, не согласовал никто.

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

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

Исправление такой системы начинается с идентичности. Каждый агент должен существовать как отдельная сущность, а не пользоваться скрытым разрешением человека, который его развернул. У него должны быть собственное имя в реестре, ограниченные полномочия и назначенный человек-куратор, отвечающий за его действия. Это необходимая основа.

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

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

Панель, которая сообщает о нарушении полномочий пять минут назад, — инструмент наблюдения. Система, которая не даёт нарушению произойти, — механизм управления. Компаниям, всерьёз занимающимся ответственностью ИИ-агентов, нужны оба подхода. У большинства пока есть только первый.

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

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

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

Если решить проблему сложности, автономность перестанет быть главным препятствием и станет самой целью.