Когда агенты действуют самостоятельно, управление должно осуществляться на уровне данных.

Макс Романенко, EDB

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

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

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

Рассмотрим простое правило: никогда не открывайте дверь машины. Если следовать ему буквально, агент вообще не сможет ни сесть в машину, ни выйти из неё. Но если изменить контекст (машина только что попала в аварию, случился пожар, кто-то пострадал и ему нужно выбраться), то на самом деле нужно правило, противоположное первому. Контекст в данный момент решает всё. Мы просим агентов делать разумные вещи; для этого нужны разумные правила.

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

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

Слой данных является точкой контроля.

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

Поведение агентов может быть вероятностным. Управление же не может быть таковым.

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

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

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

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

На практике это сводится к девяти элементам управления, сгруппированным по трем императивам:

Обеспечьте его соблюдение

• Управление доступом на основе ролей и атрибутов обеспечивается во время выполнения запроса как для агентов, так и для пользователей.

• Динамическое маскирование столбцов осуществляется по тому же пути политики.

• Идентификация агента как первоклассного принципала, с заявленной целью, определенной в начале сессии, и сохранением действующего пользователя.

Увидеть и доказать

• Классификация и маркировка, определяющие политику.

• Журнал аудита на уровне сессии, в котором регистрируется, какой агент действовал, для какого пользователя и с какой заявленной целью.

• Отслеживание происхождения данных на разных этапах обработки позволяет отследить результат до запроса, который его породил.

Объединить и укрепить

• Централизованное, переносимое управление политиками

• Шифрование в состоянии покоя и при передаче

• Последовательное применение правил в локальных, облачных и суверенных или изолированных от сети средах.

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

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

Цифровой поводок, а не запертая дверь.

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

Открытость, суверенитет и обеспечение исполнения на уровне источника.

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

Агентные системы будут становиться все более совершенными и автономными. Это повод тщательно продумывать, где будет располагаться контроль, а не замедлять темпы развития. Предприятия, которые обеспечивают управление на уровне данных, могут активно внедрять ИИ, поскольку защита их данных — это не просто пустые мечты.

EDB Postgres AI — это открытая платформа корпоративного уровня для управления суверенными данными и ИИ, которая объединяет транзакционные, аналитические и ИИ-нагрузки, обеспечивая управление там, где хранятся данные. Полное описание платформы см. в техническом документе EDB « Управление агентным ИИ на скорости предприятия» .

Макс Романенко — технический директор EDB.

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

Источник: venturebeat.com