Кирилл Евдокимов, Data Sapience: ИИ ускорит каталог данных, но отвечать за результат будет человек

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

При разработке любого дата-продукта большая часть времени уходит на три вещи: найти данные, понять их семантику («точно ли это то, что нужно?») и оценить качество («достаточно ли они корректны?»). Если в компании нет процессов управления данными, каталога и глоссария, весь цикл может занимать до 75% трудозатрат на задачу. Около половины этого времени приходится на поиск.

Есть любопытная закономерность: время поиска обратно пропорционально стажу сотрудника. Чем дольше человек работает в компании, тем быстрее находит правильный источник благодаря накопленным знаниям и связям. Каталог с хорошим наполнением дает этот эффект любому сотруднику, а не только «старожилу». По нашим проектам в Data Sapience он сокращает затраты на поиск в несколько раз и экономит до 30% общего времени.

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

ИИ-агенты все чаще отвечают на вопросы по корпоративным данным. Как единый словарь терминов и связи между данными влияют на доверие к таким ответам?

Каталог данных и бизнес-глоссарий хранят метаданные, из которых складывается единый семантический слой. Глоссарий описывает бизнес-смысл данных, каталог показывает, где они лежат и откуда пришли, а связи и аннотации подсказывают ИИ-агенту, как их извлекать. Построить такой слой в крупной организации — отдельная задача: нужно связать бизнес-архитектуру, модели данных и интеграции. Как это делают на практике, 18 ноября на Data Sapience Data Day 2026 покажут участники конференции.

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

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

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

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

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

В Data Sapience вы внедряли каталоги данных и контроль качества на основе Data Ocean Governance EMM и DQ . Кто в компании заказчика должен отвечать за проверки качества данных?

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

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

Если отдать ответственность одной стороне, система получится однобокой. В проектах Data Sapience это всегда совместная работа. Бизнес, то есть владельцы данных, отвечает за логику проверок и требования к качеству. ИТ — за техническую реализацию и закрывает «гигиенический минимум» форматно-логических контролей. Офис данных унифицирует правила и помогает «двигать контроли влево», от точки потребления данных к системам-источникам, через дата-контракты или DQLA.

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

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

При этом важно не допускать избыточности. Каждая проверка занимает время и удлиняет путь данных от точки возникновения до точки использования, то есть бьет по time-2-market и time-2-data. Нужен рациональный подход: оценить вероятность ошибки и ее влияние на результат. Для этого в управлении качеством данных используют «мощность контроля», его полезность для выявления ошибок и предотвращения рисков.

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

Бывает, что каталог заполнен, а пользователей мало. Почему так происходит, и как это увидеть по показателям?

Чтобы каталогом пользовались, он должен помогать решать реальные задачи: быстро давать ответ на вопрос. Картина «каталог наполнен, пользователей мало» обычно вырастает из одной из трех причин. Первая: содержимое неактуально, прежде всего глоссарий. Вторая: пользователи не знают, что каталог есть и какие задачи он решает. Третья: интерфейс неудобен или слишком сложен.

Каждую проблему можно и нужно решать, а способы их решения зависят от зрелости управления данными, культуры компании и иных факторов. С интерфейсом помогает настройка под сценарии, оптимизация поиска и ИИ-помощник, который упрощает работу. Услышать, как это устроено в Data Ocean Governance EMM и DQ, можно будет в моем докладе на Data Sapience Data Day 2026.

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

Эффективность каталога можно измерять по-разному: по числу уникальных и ежедневных пользователей, по количеству запросов. Но главным показателем я считаю сокращение time-2-data, то есть времени от момента, когда данные понадобились, до момента, когда пользователь получил к ним доступ. Это не только заслуга каталога: сюда входят согласование доступа, архитектура платформы и другие факторы. Но каталог работает как навигатор. Он позволяет быстро проверить, есть ли данные, откуда они, подходят ли для задачи (если есть связка с качеством данных). Тогда запрос на доступ не уходит вхолостую, и человек не узнает после всех согласований, что данные ему не подходят.

Как выстроить процесс, чтобы глоссарий и проверки не заглохли через полгода?

Ценность метаданных не всегда очевидна бизнесу, поэтому хранители знаний неохотно тратят время на ведение глоссария. Первое, что нужно, это донести пользу. Единый семантический слой сокращает time-2-market при разработке и изменении дата-продуктов, улучшает качество данных, снижает операционные риски и открывает путь к аналитике с ИИ-агентами.

Второе условие касается организации. Если процесс ведения глоссария существует отдельно от процесса создания дата-продуктов, актуализация становится обузой. Поэтому в проектах Data Sapience мы обычно рекомендуем встраивать ведение глоссария в управление изменениями дата-ландшафта. Тогда глоссарий пополняется и обновляется, пока определяются требования к дата-продукту. Типичный сценарий выглядит иначе: инструменты управления данными строят «сбоку» от основных процессов, описание данных превращается в отдельное задание. Такая схема редко приживается: носители знаний не видят практической ценности и заполняют карточки формально («раз требуют, как-нибудь заполню»). Во внедрении встроенный подход встречает противодействие как «усложнение процесса», но в итоге оказывается органичнее.

Ответственность за ведение глоссария и его актуальность лежит на владельцах данных и бизнес-экспертах.

К 2027 году каталог данных станет рабочим местом для ИИ-агентов или останется справочником для людей? Что для этого должно измениться?

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

Требования у двух групп пользователей отличаются. Человеку важны интерфейс и визуализация, например, карты происхождения данных (data lineage), графические индикаторы, импорт и экспорт данных в удобных форматах. Агенту нужны MCP, управление контекстом, инструменты и скиллы для решения специфических задач и, главное, устойчивость к высокой нагрузке: агенты создают и обрабатывают информацию быстрее человека. Общих требований немного. Это контроль доступа к информации для конкретного пользователя (напрямую или через ИИ-агента), актуальность и непротиворечивость данных.

Современный каталог данных должен закрывать все эти потребности.