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

Представлено Gravitee

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

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

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

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

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

Так где же всё на самом деле начинает разваливаться?

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

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

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

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

Но этого далеко не достаточно.

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

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

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

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

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

Решите проблему сложности — и автономность перестанет быть злодеем. Она станет самой сутью всей затеи.

Рори Бланделл — генеральный директор Gravitee.

Спонсируемые статьи — это материалы, созданные компанией, которая либо платит за публикацию, либо поддерживает деловые отношения с VentureBeat; они всегда имеют соответствующую чёткую пометку. Для получения дополнительной информации свяжитесь с sales@venturebeat.com.