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

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

Ставки высоки как никогда, поскольку теперь от ИИ-агентов ожидается, что они будут автономно обнаруживать корпоративные данные, получать к ним доступ и анализировать их. Модель, которая не может найти нужные данные, ограничена в возможностях. Агент, который не может найти нужные данные или получает доступ к тем данным, к которым не должен, представляет собой угрозу.

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

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

3 измерения стратегии работы с данными

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

Фундамент: Подключение, обнаружение, понимание, отслеживание

Нельзя использовать данные, которые нельзя найти, и нельзя доверять данным, происхождение которых нельзя отследить. Это измерение является самым неброским и самым критически важным. Оно охватывает 4 возможности: автоматическое обнаружение, каталогизацию метаданных, стандартные прикладные программные интерфейсы (API) и сквозное отслеживание происхождения данных (lineage).

Что особенно важно, этот фундамент должен охватывать как структурированные аналитические данные, так и огромные объемы неструктурированных данных — таких как PDF-файлы, внутренние вики и коммуникации, — которые обеспечивают работу генеративного ИИ и рабочих процессов дополненной генерации (RAG).

• Обнаружение и каталогизация: Проблема знакома каждому: данные разбросаны по дюжинам источников, схемы не документированы или устарели, метаданные отсутствуют или хранятся в головах отдельных сотрудников. То, что работает — это автоматическое обнаружение схем с помощью коннекторов, которые анализируют источники и централизованно каталогизируют метаданные. Доступные для поиска API каталогов позволяют любой команде или системе находить существующие данные, понимать их структуру и узнавать, как к ним получить доступ. Для неструктурированных данных это означает эффективную тегировку метаданных и интеграцию с векторными базами данных, которые позволяют ИИ-моделям выводить на поверхность релевантный контекст.
• Происхождение и прослеживаемость: Происхождение данных — это не то, что добавляется задним числом. Оно требует инструментирования на границе каждого компонента — от конвейеров и трансформаций до обучения моделей и использования агентами. Отслеживание происхождения на этапе выполнения предотвращает превращение изменений исходных данных в скрытые сбои на последующих этапах. Работающий подход заключается в модели генерации независимых событий: каждый компонент генерирует собственные события происхождения, а общий сервер сопоставляет их. Это масштабируется лучше, чем централизованный обход, и обеспечивает прозрачность происхождения без жесткой связи компонентов вашего конвейера.

На практике эти базовые возможности соотносятся с многоуровневой архитектурой, которая простирается от источников данных до ИИ-приложений:

Рисунок 1: Сквозной поток возможностей фундамента данных.

• Интеграция и подключение обеспечивают поступление данных из корпоративных источников с помощью пакетной обработки, потоковой передачи и паттернов захвата измененных данных (CDC).
• Вычислительные движки обрабатывают и трансформируют данные в масштабе, от синтаксического анализа документов до разработки признаков (feature engineering).
• Абстракция данных и каталогизация отделяют «сырые» данные от ИИ-приложений, обслуживая как прогнозные рабочие нагрузки (хранилища признаков), так и извлечение знаний (векторные базы данных, RAG).
• Оркестрация, прослеживаемость и управление обеспечивают сквозную прослеживаемость и контроль доступа по всему конвейеру.
• Единый интерфейс ИИ предоставляет эти возможности разработчикам, агентам и приложениям через стандартные API / серверы протокола контекста моделей (MCP).

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

Доверие: Управляемое, контролируемое, готовое к работе с агентами

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

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

Устранение этого пробела требует рассмотрения управления как уровня трансляции — преобразования документов с политиками на уровне бизнеса в машиночитаемые правила доступа, которые поступают в существующие точки принудительного контроля. Однако традиционная детерминированная логика безопасности, такая как ролевой контроль доступа (RBAC), недостаточна для недетерминированных больших языковых моделей (LLM). Агент может иметь стандартный доступ к набору данных, но это не предотвращает атаки путем внедрения промптов (prompt injection) и не мешает LLM непреднамеренно обобщать конфиденциальные данные в чат-интерфейсе. Настоящая стратегия доверия к ИИ требует системного контроля доступа в сочетании с семантическим контролем вывода, таким как защитные барьеры LLM (guardrails) и фильтрация промптов (например, TrustyAI).

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

Экосистема: Расширяемая по дизайну

Предприятия не начинают с нуля. У них уже есть инфраструктура данных: конвейеры интеграции, платформы потоковой передачи, хранилища в облаке и на собственной инфраструктуре (on-premise), аналитические платформы «программное обеспечение как услуга» (SaaS) и настроенные хранилища данных. Платформа данных ИИ, требующая полной замены существующей инфраструктуры («rip-and-replace»), застревает еще на этапе закупки. Вопрос не в том, может ли ваша платформа делать все, а в том, может ли ваша платформа работать с тем, что у вас уже есть.

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

• Стандартные API как уровень интеграции: Реализуйте 1 поверхность API, и каждый крупный поисковый движок подключится к ней с помощью своего встроенного клиента. Тот же принцип применим ко всему стеку для обеспечения совместимости происхождения и читаемости между платформами.
• Меr-платформенная совместимость: Основные движки должны иметь возможность считывать данные, хранящиеся в открытых форматах, без использования специализированных для конкретной платформы коннекторов. К открытой таблице, управляемой одной платформой, можно делать запросы из другой без перемещения данных. Контракт API является стабильным, а лежащая в его основе реализация может изменяться без нарушения работы потребителей.
• Федерация, а не замена: Правильная модель интеграции обеспечивает возможности управления, каталогизации и оркестрации, позволяя при этом партнерам и существующей инфраструктуре брать на себя специализированное перемещение и хранение данных. Тем не менее, крайне важно признавать физические ограничения федерации для тяжелых рабочих нагрузок ИИ. Хотя федерация отлично подходит для обнаружения и легких запросов, обучение моделей машинного обучения и ресурсоемкие задачи с векторными эмбеддингами часто требуют локализованного высокоскоростного доступа к данным, чтобы избежать критических задержек и расходов на исходящий трафик.

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

Что мы наблюдаем в сфере открытого ПО

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

• Форматы хранения устоялись, а каталоги — нет: Открытые стандарты для базовых форматов хранения данных в основном определились (например, формат таблиц Apache Iceberg). Конкуренция полностью сместилась на уровень каталогов с открытым исходным кодом. Организации все чаще ищут решения для каталогов, которые обеспечивают гибкость бэкенда без привязки к API одного поставщика (например, Iceberg REST Catalog Spec).
• Стек движков меняется: Наблюдается сильное движение индустрии в сторону безопасных для памяти высокопроизводительных языков и столбцовых форматов данных. Кроме того, встроенные аналитические движки, которые работают непосредственно там, где находятся данные, а не требуют выделенного тяжелого вычислительного кластера, являются одними из самых быстро растущих архитектурных шаблонов с открытым исходным кодом.
• Оркестрация фрагментирована по задумке: Оркестрация — это единственная категория, в которой не появляется какого-то одного универсального решения. С учетом множества архетипов (ориентированные на воркфлоу, учитывающие данные, событийно-ориентированные, нативные для ИИ) эта фрагментация отражает разнообразные и сложные реалии современных корпоративных конвейеров данных.
• Инфраструктура данных для ИИ становится самостоятельной категорией: Такие возможности, как обработка документов для неструктурированных данных, наблюдаемость больших языковых моделей (LLM), а также нативные для ИИ извлечение и трансформация, выделяются в качестве самостоятельных областей инвестиций в сообществах открытого исходного кода. Они больше не являются просто прикрученными расширениями существующих платформ данных — для них требуются специализированные стратегии.
• Векторный поиск — это реальное архитектурное решение: Добавление возможностей векторного поиска с открытым исходным кодом в существующие реляционные базы данных (например, добавление PGVector в существующую PostgreSQL) часто проще и полностью достаточно для многих ранних сценариев использования генеративного ИИ. Хотя специализированные векторные базы данных важны при колоссальных нагрузках масштаба миллиардов записей, предположение о том, что вам необходима отдельная векторная база данных с первого дня, является распространенной стратегической переинвестицией.

Когда мы сопоставили более 100 проектов с открытым исходным кодом, связанных с данными, с 5 возможностями, описанными ранее (ингестия, вычисления, каталог, оркестрация/управление, единый интерфейс), вырисовалась четкая картина.

Рисунок 2: Пример маппинга проектов с открытым исходным кодом в области данных на возможности фундаментов данных.

Каждая возможность имеет как минимум 1 зрелый вариант с открытым исходным кодом, а большинство — несколько. Слои ингестии и каталогов характеризуются наиболее активной конкуренцией: в них представлено несколько жизнеспособных проектов разной степени зрелости. Оркестрация и управление имеют наибольшие разрывы между тем, что доступно, и тем, что нужно предприятиям. Базовый уровень (Kubernetes, столбцовые форматы данных, стандарты открытой линейности, контракты данных) является наиболее устоявшимся, что именно и требуется от фундамента.

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

С чего начать

Начните с 5 конкретных шагов:

• Проведите аудит покрытия вашего каталога по всем типам данных: может ли каждая команда в вашей организации найти структурированные и неструктурированные данные, которые ей нужны, никого не спрашивая? Если нет, начните с этого. Автоматизированное обнаружение и каталог с возможностью поиска решают больше проблем, чем любое обновление модели.
• Внедряйте отслеживание линейности данных с первого дня: Не относитесь к линейности как к пункту комплаенса, к которому вы вернетесь позже. Внедрите стандарты открытой линейности прямо сейчас и требуйте, чтобы каждый новый конвейер порождал события линейности.
• Внедряйте открытые стандарты, а не продукты: Поддерживайте контракты API, а не делайте ставку на реализацию одного конкретного вендора. Именно так вы сохраняете гибкость и избегаете привязки к поставщику.
• Начните свою стратегию агентов с комплексного управления: Прежде чем создавать агентский доступ к данным, определите, что агенту разрешено делать. Используйте как традиционные средства контроля доступа, так и семантические средства защиты, такие как фильтрация промптов.
• Думайте о гибридной среде с самого начала, но планируйте гравитацию данных: Если ваши данные распределены между облаками и локальной инфраструктурой, ваша стратегия работы с данными должна работать во всех этих средах. Используйте единую операционную модель, но подходите к размещению данных стратегически, чтобы минимизировать задержки для ресурсоемких задач ИИ.

Данные — это и есть стратегия

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

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

Изучите возможности Red Hat AI

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