EDB предложила модель управления ИИ-агентами на уровне данных
VentureBeat опубликовал спонсируемую статью, материал помечен пометкой «Presented by EDB», за авторством Макса Романенко, технического директора EDB. Тезис статьи: управление автономными ИИ-агентами нельзя строить как надстройку поверх самого агента. Инструкции, политики и мониторинг, добавленные на уровень модели, работают ровно настолько надёжно, насколько предсказуемо ведёт себя агент, а автономность, как раз то свойство, из-за которого поведение агента трудно предсказать. Управление, которое требует проверять действие агента до того, как оно произойдёт, не успевает за системой, действующей за миллисекунды и сразу в нескольких системах. Поэтому, по мысли автора, правила должны исполняться там, где агент физически касается данных, на уровне данных, а не выше него.
Тезис иллюстрирует аналогия с автомобильной дверью: простое правило «никогда не открывай дверь машины», если следовать ему буквально, не даст агенту ни сесть в машину, ни выйти из неё. Но стоит изменить контекст, машина только что попала в аварию, начался пожар, кто-то пострадал и должен выбраться, и нужным становится ровно противоположное правило. Контекст в моменте решает всё: раз от агентов требуют разумных действий, то и правила для них нужны разумные, а не статичные инструкции на бумаге.
Механизм, который предлагает статья: относиться к агенту как к полноправному субъекту доступа (principal), со своей идентичностью и с целью, заявленной в момент открытия сессии. После того как заявленная цель привязана к идентичности, движок политик может оценивать её так же, как сегодня оценивает роль или отдел сотрудника, а журнал событий фиксирует не только кто действовал и к чему обращался, но и то, какую цель агент заявил. Ключевая мысль автора, инструменты для этого во многих компаниях уже есть в базе данных: ролевой и атрибутный контроль доступа, разграничение на уровне строк и столбцов, классификация и маскирование, политики как код, полные журналы аудита. Меняется не сам механизм, а то, что теперь он обязан учитывать и агентов, а не только людей-пользователей.
Статья сводит подход к девяти мерам, сгруппированным в три задачи. «Исполнять»: ролевой и атрибутный контроль доступа, применяемый в момент запроса, как для агентов, так и для людей; динамическое маскирование столбцов по тому же маршруту политик; идентичность агента как полноправного субъекта доступа, с целью, заявленной в начале сессии, и сохранённым исходным пользователем. «Видеть и доказывать»: классификация и разметка данных, которая определяет применяемую политику; журналирование на уровне сессии, какой агент, от чьего имени и с какой заявленной целью действовал; прослеживаемость (lineage) по всем конвейерам обработки данных, чтобы результат можно было проследить до запроса, который его породил. «Объединять и укреплять»: централизованное и переносимое управление политиками; шифрование данных в состоянии покоя и при передаче; единообразное применение правил в локальной инфраструктуре, облаке и суверенных или физически изолированных (air-gapped) средах.
«Разницу создаёт заявленная цель, говорит Приянка Джайн, вице-президент EDB по продуктовому управлению в сфере данных и ИИ., Она становится атрибутом, который уровень доступа уже умеет распознавать: её оценивают по тому же маршруту политик, что и роль, и защиту на уровне строк. Сам механизм принуждения не меняется. Меняется то, что цель агента становится частью того, что оценивается, и частью того, что потом подтверждает журнал событий».
Статья прямо связывает изложенный подход с продуктом спонсора: EDB Postgres AI, построенная на Postgres с открытым исходным кодом платформа, которая объединяет транзакционную, аналитическую и ИИ-нагрузку и обеспечивает управление именно на уровне данных. Для регулируемых отраслей, пишет автор, сочетание суверенности данных и принуждения на уровне источника, не опция, а обязательное условие, чтобы вообще допустить агентов до промышленной эксплуатации. За более полным описанием статья отсылает к белой книге EDB «Governing Agentic AI at Enterprise Speed» (в переводе, «Управление агентным ИИ на скорости, нужной бизнесу»), содержание которой в самой статье не раскрывается.
Ключевые факты
- Тезис материала: контроль над автономными ИИ-агентами нельзя строить поверх агента, инструкциями, политиками, мониторингом, потому что проверка действия агента до того, как оно случилось, не поспевает за системой, действующей за миллисекунды сразу в нескольких системах; управление должно исполняться на уровне данных.
- Предлагаемый механизм: агент, полноправный субъект доступа (principal) со своей идентичностью и целью, заявленной в момент открытия сессии; движок политик оценивает эту цель так же, как сегодня оценивает роль или отдел сотрудника.
- Фреймворк сведён к девяти мерам в трёх группах: «Исполнять» (ролевой и атрибутный контроль доступа, динамическое маскирование столбцов, идентичность агента с заявленной целью), «Видеть и доказывать» (классификация данных, журналирование на уровне сессии, прослеживаемость по конвейерам), «Объединять и укреплять» (централизованные политики, шифрование, единообразное применение в разных средах).
- Материал маркирован как спонсируемый EDB («Presented by EDB»), автор, технический директор EDB Макс Романенко, а цитата в тексте принадлежит вице-президенту EDB Приянке Джайн; статья продвигает продукт EDB Postgres AI, построенный на открытом Postgres.
- Для регулируемых отраслей, утверждает автор, сочетание суверенности данных и принуждения на уровне источника, обязательное условие для промышленной эксплуатации агентов; статья отсылает к белой книге EDB «Governing Agentic AI at Enterprise Speed», но не раскрывает её содержание.
Почему это важно
Рост автономности агентов, способности планировать, решать и действовать в нескольких системах без утверждения человеком каждого шага, делает прежнюю модель управления (правила и мониторинг поверх модели) ненадёжной именно потому, что автономность и есть то свойство, из-за которого поведение агента трудно предсказать. Проверка действия до того, как оно случится, физически не успевает за системой, действующей за миллисекунды сразу в нескольких системах. Поэтому автор настаивает: правило должно исполняться там, где агент реально касается данных, а не оставаться политикой на бумаге, это структурный сдвиг в том, где вообще должен жить контроль.
Кому это важно
В первую очередь, компаниям, которые уже дают ИИ-агентам доступ к внутренним данным и системам: командам безопасности и комплаенса, владельцам данных, которым нужно доказывать регуляторам и руководству, что доступ агента к чувствительным данным контролируется и фиксируется. Отдельно материал адресован регулируемым отраслям, по утверждению автора, именно там сочетание суверенности данных и принуждения на уровне источника становится обязательным условием, чтобы вообще допустить агентов до промышленной эксплуатации. Также это прямо касается технических руководителей, которые уже используют Postgres и могут рассматривать EDB Postgres AI как платформу для агентной инфраструктуры.
Как это применить
Практический рецепт статьи: не изобретать новый слой контроля с нуля, а распространить на агентов инструменты, которые в базе данных предприятия обычно уже есть, ролевой и атрибутный контроль доступа, разграничение на уровне строк и столбцов, классификацию и маскирование, политики как код, полные журналы аудита. Для этого агенту при открытии сессии присваивают идентичность и заявленную цель, которые движок политик учитывает наравне с ролью и отделом пользователя, а журнал событий фиксирует не только «кто и к чему обратился», но и «с какой заявленной целью». Девять мер статьи сгруппированы в три задачи: исполнять контроль в момент запроса, видеть и доказывать произошедшее через журналирование и прослеживаемость, и объединять политику в единый, переносимый и зашифрованный слой поверх локальной, облачной и суверенной инфраструктуры.
Можно ли доверять
Материал прямо маркирован как спонсируемый: сама VentureBeat помещает пометку «Presented by EDB» и отдельно поясняет, что такие статьи оплачены компанией или связаны с ней деловыми отношениями. Автор текста, Макс Романенко, технический директор именно EDB, а единственная цитата в статье принадлежит вице-президенту EDB Приянке Джайн. В тексте нет ни одного названного клиента или компании, которая уже использует этот фреймворк, нет даты или номера версии ни для фреймворка, ни для продукта EDB Postgres AI, и нет ни одного внешнего исследования, опроса или отчёта об инцидентах, на которые опирались бы выводы, аргументация целиком держится на рассуждении автора. Не назван и конкретный подход или инструмент, с которым статья спорит: критика адресована обобщённым «инструкциям, политикам и мониторингу поверх модели» без указания на что-то конкретное. Статья отсылает к белой книге EDB «Governing Agentic AI at Enterprise Speed» за более полным описанием, но не цитирует и не пересказывает её содержание сверх того, что уже изложено в самом тексте.
Риски и подводные камни
Аргумент одновременно служит рекламой конкретного продукта: EDB Postgres AI построен на Postgres и, по описанию статьи, сам реализует перечисленные девять мер, так что рекомендованное решение проблемы совпадает с тем, что продаёт спонсор материала. В тексте нет ни одного примера компании, которая уже развернула этот фреймворк в реальной эксплуатации, все девять мер поданы как рекомендация, а не как проверенная практика, и подкреплены только рассуждением автора и цитатой сотрудницы той же компании, без внешних исследований, инцидентов или отчётов. Сама статья ограничивает область действия фреймворка тем, что агент делает с данными, запрашивает, извлекает, преобразует их, то есть контроль на уровне данных по определению не покрывает действия агента, которые не проходят через эту базу: вызовы внешних API, сторонние сервисы, файлы вне управляемого хранилища.
«Разницу создаёт заявленная цель. Она становится атрибутом, который уровень доступа уже умеет распознавать: её оценивают по тому же маршруту политик, что и роль, и защиту на уровне строк. Сам механизм принуждения не меняется. Меняется то, что цель агента становится частью того, что оценивается, и частью того, что потом подтверждает журнал событий.»
— Приянка Джайн, вице-президент EDB по продуктовому управлению в сфере данных и ИИ