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

При поддержке EDB

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

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

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

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

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

Уровнем принудительного исполнения данных является уровень самих данных

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

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

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

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

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

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

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

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

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

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

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

Видьте и доказывайте

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

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

• Происхождение данных (лайнедж) в конвейерах, позволяющее проследить результат до породившего его запроса

Унифицируйте и укрепляйте

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

• Шифрование данных при хранении и передаче

• Согласованное применение в локальных (on-prem), облачных и суверенных или изолированных (air-gapped) средах

«Заявленная цель — это то, что меняет всё. Она становится атрибутом, который уровень доступа уже понимает, и оценивается по тому же пути политик, что и ролевая безопасность на уровне строк. Сам механизм принудительного исполнения не меняется. Меняется то, что цель агента становится частью того, что оценивается, и частью того, что запись подтверждает впоследствии», — говорит Приянка Джайн (Priyanka Jain), вице-президент по управлению продуктами в сфере данных и управления ИИ в EDB.

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

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

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

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

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

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

EDB Postgres AI — это открытая платформа корпоративного класса для суверенных данных и ИИ, которая объединяет транзакционные, аналитические и ИИ-рабочие нагрузки с обеспечением контроля там, где хранятся данные. Полное описание концепции см. в белой книге EDB Governing Agentic AI at Enterprise Speed.

Макс Романенко (Max Romanenko) — технический директор (CTO) в EDB.

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