Предприятия переходят от ИИ-копилотов, которые отвечают на вопросы, к ИИ-агентам, которые предпринимают действия: обновляют записи, запускают рабочие процессы и принимают решения практически без участия человека. Этот переход возможен только в том случае, если агент имеет доступ к доверенным корпоративным данным, понимает их бизнес-контекст и действует в рамках правил, уже утвержденных человеком. Агентная инфраструктура данных — это уровень управления данными, охватывающий доступ и контекст. Благодаря ей ИИ-агенты могут анализировать доверенные корпоративные данные и действовать на их основе без необходимости создания отдельного хранилища, куда копируется всё подряд.
Вы получите четкое определение агентной инфраструктуры данных, а также узнаете, почему платформы данных, которые уже используют большинство предприятий, с трудом поддерживают автономных агентов. Вы также увидите конкретные компоненты, которые необходимо добавить, включая управляемый федеративный доступ, обоснование (grounding) агентов и готовые к использованию ИИ продукты данных, а также поймете, чем этот подход отличается от традиционной платформы данных. Наконец, вы узнаете, как выстроить такую инфраструктуру, работая с уже имеющимся у вас озером данных (data lakehouse) или хранилищем данных.
Основные выводы
- Агентная инфраструктура данных объединяет управляемый доступ к данным, обоснование агентов и готовые к использованию ИИ продукты данных.
- Большинство проектов с использованием агентов сегодня останавливаются на этапе до внедрения в производство из-за проблем с доступом к данным и доверием к ним.
- Агенты не могут мириться с двусмысленностью, которую люди обычно разрешают с помощью негласных знаний, поэтому бизнес-контекст необходимо кодировать явно.
- Вы можете расширить уже используемые вами озеро данных и уровень федерации для обслуживания агентов; вам не нужно сначала всё централизовать.
Что такое агентная инфраструктура данных?
Агентная инфраструктура данных формируется за счет совместной работы трех возможностей. Благодаря управляемому доступу к данным агент может запрашивать данные напрямую из хранилищ, озер данных и других источников. Обоснование и контекст предоставляют агенту бизнес-определения вашей организации. Таким образом, конкретные технические термины, такие как «отток» или «активный клиент», означают для агента то же самое, что и для вашего финансового отдела. Продукты данных упаковывают доверенные, повторно используемые представления этих данных для потребления агентами, вместо того чтобы заставлять каждого агента заново создавать запрос с нуля.
Традиционные платформы данных создавались для людей — с дашбордами, отчетами и аналитиками, которые могли самостоятельно разрешать двусмысленности. ИИ-агенты не могут делать это таким же образом. Например, если агент не может определить, какая таблица содержит авторитетную версию «выручки», он будет угадывать и действовать на основе этой догадки. Агентная инфраструктура данных существует для решения этой проблемы. С ее помощью вы можете расширить уже имеющуюся платформу данных, а не заменять ее.
Почему традиционные стеки данных не подходят для ИИ-агентов
Большинство предприятий полагали, что готовность к ИИ означает централизацию всего: копирование данных из каждого источника в одно хранилище или озеро данных перед началом любого ИИ-проекта. Это предположение перестает работать по мере масштабирования агентов.
Ловушка централизации
Среднестатистическое предприятие имеет несколько источников данных, и их количество обычно растет с каждым годом. Гетерогенность — это норма. В таких условиях копирование всех данных в одно место перед тем, как агенты смогут их использовать, — это постоянно меняющаяся цель, потому что новые источники данных появляются быстрее, чем проекты по миграции успевают их поглотить. Это одно из главных препятствий в области ИИ и одна из ключевых причин, по которой большинство агентных проектов никогда не доходят до производства. И даже самые оптимистичные прогнозы на 2026 год оценивают реальное внедрение лишь немногим более чем в 30 процентов. Неудача связана с доступом к данным и доверием к ним, которые стоят выше качества моделей.
Агенты не могут мириться с двусмысленностью так, как это делают люди
Аналитик-человек, столкнувшись с неоднозначным определением метрики, спрашивает коллегу или проверяет вики-страницу. У ИИ-агента нет такой возможности, если вы ее не предусмотрите. Допустим, в вашей организации есть три разных определения «активного клиента», распределенных между отделами продаж, маркетинга и финансов. Агент, запрашивающий эту метрику, выберет одно и будет действовать на его основе, не сигнализируя о конфликте. Именно эту проблему решает обоснование агента (agent grounding), превращая двусмысленный бизнес-контекст в нечто, на что агент может положиться. Без этого запрос по «оттоку» может обратиться к неверной таблице, поскольку не существует согласованного бизнес-определения, которое могло бы выявить ошибку.
Основные компоненты агентной инфраструктуры данных
Вы создаете три основных компонента агентной инфраструктуры данных вместе, как единое целое.
Управляемый федеративный доступ к данным
Агентам необходимо запрашивать данные там, где они уже находятся — в хранилищах, озерах данных, lakehouse-системах и облачных платформах, не дожидаясь миграции. Уровень федеративного доступа означает, что агенты запрашивают те же управляемые данные, что и пользователи-люди. Он обеспечивает соблюдение тех же разрешений и элементов управления, которые были бы у человека, поэтому каждый запрос остается проверяемым. Этот же уровень должен иметь разговорный, управляемый интерфейс доступа. Таким образом, агент может задать вопрос на обычном языке и получить управляемый ответ. Разработчику не нужно вручную писать запрос для каждого нового сценария использования. Такой объем запросов также имеет ценовое измерение. Уровень федерации, отвечающий на запросы агентов тысячи раз в день, обычно нуждается в кэшировании или повторном использовании результатов, чтобы контролировать расходы на запросы.
Уровни обоснования и контекста агента
Одного управляемого доступа недостаточно, чтобы агент неверно истолковал то, что ему разрешено видеть. Агентам также нужен управляемый контекстный уровень бизнес-определений и политик доступа. Этот уровень кодирует то, что означают «выручка» или «отток» в вашей организации, а также кто и что может видеть и почему. Благодаря этому агент может рассуждать о данных так же, как хорошо обученный аналитик, а не угадывать смысл по названиям столбцов.
Готовые к использованию ИИ продукты данных
Третий компонент упаковывает управляемые, четко определенные данные в повторно используемые продукты, которые агент может потреблять напрямую. Вместо создания индивидуального конвейера для каждого агента, вы один раз превращаете вопросы на обычном языке в управляемые ответы, а затем повторно используете этот продукт данных для каждого агента, которому он нужен. Здравые принципы создания готовых к использованию ИИ продуктов данных также проясняют, как агенты потребляют эти продукты во время выполнения запроса. Оба варианта используют управляемый, документированный источник, а не источник данных, который никто в команде не может отследить.
В совокупности эти три компонента также объясняют, почему готовые к использованию ИИ продукты данных важны с экономической точки зрения. Исследование Mavvrik 2025 года показало, что 84 процента компаний сообщают, что расходы на ИИ уже снижают валовую прибыль более чем на 6 процентов. Повторно используемые продукты данных — это один из способов предотвратить накопление таких затрат на переделку, вместо того чтобы команды заново выполняли одну и ту же работу по доступу и контексту для каждой новой ИИ-инициативы.
Чем агентная инфраструктура данных отличается от традиционной платформы данных
Традиционная платформа данных предполагает, что человек участвует в процессе принятия решений. Она создана для дашбордов, специальных запросов и отчетов, которые человек читает перед тем, как решить, что делать дальше. Компании часто внедряют управление через контроль доступа на основе ролей, разработанный с учетом должностей и отделов. Такой подход предполагает, что обсуждение вопросов безопасности или соответствия требованиям происходит до любого необычного запроса.
Агентная инфраструктура данных предполагает обратное. Автономный процесс сам решает, что и когда запрашивать, потенциально совершая тысячи запросов в день. Это означает, что механизмы защиты должны работать автоматически при каждом запросе, а не проходить проверку постфактум. Проверки разрешений для каждого отдельного запроса также не полностью устраняют риски, связанные с агентами. Агент может объединить несколько индивидуально разрешенных запросов, чтобы восстановить совокупные данные, которые человек с тем же уровнем доступа не увидел бы ни в одном из отдельных запросов, поэтому уровень контекста должен учитывать этот паттерн. Платформа также должна отвечать на вопрос, почему агент предпринял те или иные действия. Это означает, что происхождение данных и журналы аудита важны не меньше, чем сам результат запроса.
Вот почему попытка направить ИИ-агента на существующее хранилище данных или бакет Amazon S3 часто приводит к обратным результатам. Без промежуточного уровня обоснования и управления агент либо не может найти то, что ему нужно, либо находит не то и все равно использует это в работе.
Создание агентной инфраструктуры данных без перестройки вашего стека
Все это не означает, что нужно удалять существующее озеро данных (data lakehouse), хранилище данных или уровень федерации и начинать все сначала. Самый практичный путь — расширить то, что у вас уже есть, с помощью уровня управляемого доступа и обоснования, а не создавать параллельный стек специально для агентов.
Начните с уровня доступа, который вы, вероятно, уже используете. Если ваша платформа данных уже объединяет запросы к хранилищам данных, озерам данных и облачным платформам, расширьте этот уровень для аутентификации и авторизации агентов так же, как вы это делаете для людей. Сделайте это вместо создания отдельного конвейера, который копирует данные для использования ИИ. Таким образом, вы добавите агентов, ограничив необходимость копирования данных в новую систему, созданную исключительно для ИИ.
Затем добавьте уровень контекста, прежде чем добавлять новых агентов. Задокументируйте свои основные бизнес-метрики, решите, кому и что разрешено видеть, и закодируйте все это в виде политики, которую агент должен проверить, прежде чем сможет выполнить запрос. Также полезно отделить агентную инфраструктуру данных — описанный здесь управляемый уровень — от цифровых следов, которые оставляют ИИ-агенты после начала работы. Этот второй тип данных все равно должен поступать обратно в вашу управляемую платформу, чтобы вы могли проводить аудит. Это задача, отличная от той инфраструктуры, которая нужна агентам для выполнения действий в первую очередь.
Наконец, упакуйте свои наиболее ценные варианты использования в виде продуктов данных, прежде чем создавать специализированные конвейеры для каждого нового агента. Повторное использование управляемого продукта данных для каждого агента, которому он нужен, — это то, что позволяет избежать роста затрат на ИИ.
С чего начать
Агентная инфраструктура данных — это непрерывная практика, которая строится со временем, а не покупается один раз. Начните с источника данных, которому ваши агенты должны доверять больше всего. Добавьте управляемый доступ и задокументированное бизнес-определение для важных метрик, и только после этого позвольте агенту действовать на их основе. Наслоение возможностей агентов на платформу, которую вы уже понимаете и можете проверять, продвинет вас дальше и быстрее, чем ожидание централизации всего и вся.
Дальнейшие шаги
Хотите узнать больше о создании агентной инфраструктуры данных? Начните бесплатную пробную версию Starburst Galaxy, чтобы увидеть ее в действии.
Часто задаваемые вопросы
Что такое агентная инфраструктура данных?
Агентная инфраструктура данных — это управляемый уровень данных, где ИИ-агенты запрашивают, понимают и используют доверенные корпоративные данные без необходимости каждый раз создавать их отдельную копию. Она сочетает в себе управляемый федеративный доступ, обоснование агентов и готовые к использованию ИИ продукты данных, чтобы агент мог рассуждать о ваших данных так же, как это делал бы хорошо обученный аналитик.
Чем агентная инфраструктура данных отличается от озера данных или хранилища данных?
Озеро данных или хранилище данных хранят и организуют данные для запросов людей. Агентная инфраструктура данных добавляет поверх этой платформы уровень управляемого доступа, уровень обоснования, который кодирует бизнес-определения, и повторно используемые продукты данных. Благодаря такому сочетанию автономные агенты могут безопасно выполнять запросы без участия человека, проверяющего каждый из них.
Почему ИИ-агентам нужен управляемый доступ к данным, а не просто более совершенная модель?
Более мощная модель все равно не сможет определить, какая таблица содержит авторитетную версию «выручки» или «оттока», если вы не предоставите ей управляемый доступ и четкие бизнес-определения. Проблемы с доступом к данным и доверием мешают большинству агентских проектов выйти на стадию эксплуатации, независимо от качества модели.
Что такое обоснование агента (agent grounding) и почему это важно для агентной инфраструктуры данных?
Обоснование агента — это дисциплина кодирования бизнес-определений и политики доступа вашей организации, чтобы агент интерпретировал данные так же, как ваши команды. Без этого агент, столкнувшись с неоднозначным определением метрики, выберет одно самостоятельно и будет действовать на его основе, вместо того чтобы спросить коллегу, как это сделал бы аналитик-человек.
Нужно ли перестраивать стек данных для поддержки ИИ-агентов?
Нет. Вы можете расширить озеро данных, хранилище данных и уровень федерации, которые уже используете. Добавьте уровень управляемого доступа и обоснования, вместо того чтобы создавать параллельный стек специально для агентов. Такой подход ограничивает необходимость копирования данных в новую систему, созданную исключительно для ИИ.
Как меняется управление данными, когда ИИ-агенты, а не только люди, запрашивают корпоративные данные?
Команды должны обеспечивать управление автоматически при каждом запросе, вместо того чтобы полагаться на проверку постфактум, поскольку автономный процесс может запрашивать ваши данные тысячи раз в день без проверки каждого запроса человеком. Платформа также должна регистрировать, почему агент предпринял то или иное действие, поэтому происхождение данных и журналы аудита важны не меньше, чем сам результат запроса.
