Инфраструктура данных, необходимая для агентного ИИ

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

Автономный агент не может обеспечить результаты промышленного уровня, если он не может безопасно получать доступ к актуальным бизнес-данным, надежно интерпретировать семантическое значение в разрозненных схемах или выполнять запросы без одобрения человеком каждого промежуточного шага. Когда агенты ограничены конкретными источниками данных, им неизбежно не хватает бизнес-контекста для понимания потребностей вашего бизнеса, и это напрямую ведет к большему количеству AI hallucinations and AI production failures.

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

Основные выводы

• Проекты агентного ИИ буксуют в производстве из-за отсутствия контекста. Одна и та же базовая модель демонстрирует точность около 50 процентов при ответах на корпоративные вопросы, которая возрастает до более чем 90 процентов, как только она получает структурированный бизнес-контекст.
• Централизация данных перед тем, как вы предоставите доступ агентам, повторяет шаблон хранилища данных, который не поспевает за агентным доступом. Благодаря федеративному доступу агенты могут запрашивать данные там, где они хранятся; федеративные движки запросов сообщают о повышении скорости запросов до 300 процентов и снижении затрат до 70 процентов.
• Специальный контекстный уровень, агентная плоскость управления, должен обосновывать действия агентов на основе общего бизнес-значения, включая определения таблиц, право собственности и актуальность, прежде чем они начнут рассуждать.
• Управление должно находиться внутри самого уровня доступа, с принудительным применением режима «только чтение», RBAC/ABAC и встроенными журналами аудита с самого начала, а не после того, как агент уже запущен.
• Такие стандарты, как Model Context Protocol (MCP), становятся общим связующим уровнем между ИИ-агентами и корпоративными платформами данных, хотя управление зависит от того, как каждая реализация обеспечивает его соблюдение, а не от самого стандарта.

Почему большинство ИИ-агентов никогда не выходят за рамки демо-версии

Перспективы ИИ высоки, но показатели неудач ИИ часто столь же высоки. Широко цитируемые отраслевые оценки указывают на то, что развертывание агентов застопорилось as high as 88 percent, and even the most positive 2026 estimates put production deployment at just over 30 percent. Gartner называет первопричину, оценивая, что нехватка данных, готовых к использованию ИИ, ставит под угрозу 60 процентов проектов в области ИИ.

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

Контекст — это настоящее «узкое место»

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

Что означает контекст для агента по сравнению с аналитиком-человеком

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

У агента нет такого багажа. Каждый запрос начинается «с чистого листа», если только инфраструктура не предоставляет агенту структурированный бизнес-контекст заранее, включая определения таблиц, право собственности, актуальность и правила доступа. Инженерная команда Snowflake обнаружила, что одна и та же базовая модель достигает примерно 50-процентной точности при ответах на вопросы по корпоративным данным без этого структурированного контекста и более 90-процентной точности с ним. Модель осталась прежней; изменился контекст.

Почему агенты не могут терпеть двусмысленность так, как люди

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

Что требует инфраструктура данных для агентного ИИ

Для решения этой проблемы необходимо совместное действие трех факторов, и ни один из них не является более мощной моделью.

Федеративный доступ вместо очередного проекта по централизации данных

Инстинкт исправления неоднородности данных путем централизации всего в одном хранилище данных повторяет шаблон, который не поспевает за тем, насколько быстрым и широким должен быть агентный доступ сейчас. Это медленно, дорого и не масштабируется до сотен источников, обновляемых ежедневно. Благодаря федеративному доступу агенты могут запрашивать данные там, где они уже живут, через озера данных, хранилища данных и SaaS-приложения, с помощью движка запросов, который отделяет вычисления от хранения. Реальные внедрения движков запросов сообщают о повышении скорости запросов до 300 процентов и снижении затрат до 70 процентов — это общие данные о производительности федерации, а не специфический для агентов бенчмарк, но это направленное доказательство того, что федерация также эффективна.

Контекстный уровень, который обосновывает действия агентов до того, как они начнут рассуждать

Федеративный доступ доставляет агента к данным. Архитектурный контекстный уровень — это то, что говорит агенту, что означают эти данные, прежде чем он начнет рассуждать. Думайте об этом как об агентной плоскости управления, расположенной между агентом и вашими источниками данных, переводящей бизнес-термины в правильные таблицы, столбцы и соединения, чтобы агент не гадал. Команды, которые уже используют семантический уровень, такой как dbt, решили часть этой проблемы внутри одного хранилища данных, но этот уровень обычно достигает своего предела на уровне идентификации между источниками. Та же двусмысленность возвращается в тот момент, когда агенту приходится объединять значения между системами, для охвата которых семантический уровень никогда не создавался. Это работа по обоснованию действий агентов в бизнес-контексте до того, как они начнут рассуждать, и это также то место, где инфраструктура должна поглощать что-то новое — данные, которые генерируют агентные ИИ-системы в процессе работы, включая промежуточные запросы, решения и результаты, которые сами нуждаются в управлении. Gartner прогнозирует, что к 2029 году агентный ИИ будет автономно решать 80 процентов распространенных проблем обслуживания клиентов.

Управляемое, проверяемое подключение с использованием MCP

Обеспечение контекста для агента не поможет, если связь между агентом и данными представляет собой разовую интеграцию без контроля доступа. Стандарты, такие как Model Context Protocol (MCP), становятся общим связующим уровнем между ИИ-агентами и корпоративными платформами данных. MCP стандартизирует само соединение; управление по-прежнему зависит от того, как конкретная реализация обеспечивает его соблюдение, предоставляя каждому агенту согласованный и проверяемый путь к запросу данных вместо лоскутного одеяла из пользовательских коннекторов, когда это управление встроено в систему.

Управление должно быть заложено в фундамент

MIT report found that 95 percent of generative AI pilots show no measurable P&L return, даже как Bain reports that 74 percent of businesses still rank AI a top-three priority. Этот разрыв между амбициями и результатами тесно связан с тем, как предприятия относятся к доступу и управлению — как к отдельным проблемам, решаемым последовательно, а не как к доступу к данным и управлению данными как к параллельным задачам, которые должны решаться совместно на одном и том же уровне.

Принудительное использование режима «только чтение», RBAC/ABAC и журналы аудита для автономных запросов

Управление, внедренное постфактум, почти никогда не работает, когда агент функционирует без присмотра. Оно должно быть частью уровня доступа с самого начала, с принудительным режимом «только чтение», чтобы агенты не могли случайно записать или удалить данные, с управлением доступом на основе ролей и атрибутов (RBAC/ABAC), чтобы агент видел только то, что разрешено видеть запрашивающему его пользователю, и с журналами аудита, которые фиксируют каждый запрос, выполняемый агентом. Подход Starburst Galaxy показывает, как это выглядит в промышленной эксплуатации: размещенный на хостинге управляемый MCP-сервер работает как многопользовательская служба с аутентификацией OAuth 2.1, принудительным применением RBAC/ABAC и элементами управления запросами «только для чтения», встроенными непосредственно в соединение.

Построение архитектуры федерации данных без разрушения существующего стека

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

Сначала федерация, централизация — только там, где это оправдано затратами

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

Как Starburst решает проблему федерации данных

Starburst объединяет федеративные запросы, контекст и управление в одной платформе, поэтому вам не нужно собирать отдельные инструменты для каждой задачи. AIDA от Starburst предоставляет диалоговую альтернативу статическим дашбордам, построенную на том же управляемом фундаменте. Это рабочий пример агентной аналитики на основе управляемых данных: агент, который выполняет запросы к вашим существующим источникам через федеративный доступ, рассуждает в контексте обоснованных бизнес-задач и остается в рамках контроля доступа, которому уже доверяет ваша команда по управлению данными. Именно эта комбинация позволяет перевести проекты с агентным ИИ из стадии демонстрации в промышленную эксплуатацию.

Следующие шаги

Прочитайте электронную книгу «Почему фундамент данных важен для вашей агентной рабочей силы» (Why the Data Foundation for Your Agentic Workforce Matters), чтобы узнать больше об инфраструктуре данных, необходимой для агентного ИИ.

Часто задаваемые вопросы

Что такое инфраструктура данных для агентного ИИ?

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

Почему так много проектов с агентным ИИ не доходят до промышленной эксплуатации?

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

Нужно ли централизовать все данные перед развертыванием ИИ-агентов?

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

Что дает уровень контекста для ИИ-агента?

Уровень контекста преобразует бизнес-логику в правильные таблицы, столбцы и соединения (joins) до того, как агент начнет рассуждать, что сокращает количество выводов, которые ему необходимо сделать, и повышает точность. Это дисциплина обоснования действий агентов бизнес-контекстом до начала их рассуждений, и она также должна учитывать данные, которые генерируют агентные ИИ-системы в процессе работы, включая промежуточные запросы и решения, которые агент вырабатывает по пути.

Как управление вписывается в инфраструктуру агентного ИИ?

Управление должно быть встроено в уровень доступа с самого начала, а не добавлено после того, как агент уже запущен. Это означает принудительный режим «только чтение», чтобы агенты не могли случайно записать или удалить данные, RBAC/ABAC, чтобы агент видел только то, что разрешено видеть запрашивающему его пользователю, и журналы аудита для каждого запроса. Размещенный на хостинге управляемый MCP-сервер показывает, как это выглядит в виде управляемой многопользовательской службы с аутентификацией OAuth 2.1, встроенной непосредственно в соединение.

Какую роль играет Starburst в инфраструктуре данных для агентного ИИ?

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