Data lineage в эпоху ИИ

Старый вопрос — «чисты ли мои данные». Новый — «что ИИ в них видит и что он раскроет».

Несколько лет назад вопрос про корпоративные данные звучал так: чисты ли они, есть ли каталог, кто владелец, можно ли доверять отчёту. Это была эпоха data governance — навести порядок в собственном доме.

Потом к данным пришёл ИИ — и спрашивать их стали не только инженеры и дата-аналитики, но и те, кто раньше ждал отчёт от ИТ: маркетинг, финансы, продукт. Спросить данные на обычном языке теперь может любой, кто работает с цифрами, — а не только тот, кто умеет писать SQL: аналитику строят быстрее, и строят её больше людей. Языковая модель индексирует схему и отвечает им; RAG-система достаёт фрагменты описаний таблиц; агент сам решает, какие данные свести. И вопрос поменялся — тихо, но необратимо: уже не «чисты ли мои данные», а «что ИИ в них видит, откуда это пришло и что он раскроет наружу».

Это другой вопрос. И ответ на него начинается не с каталога, а с происхождения данных.

Старый вопрос и новый

Data governance отвечал на вопрос о состоянии: вот наши таблицы, вот владельцы, вот правила качества. Снимок порядка.

AI governance отвечает на вопрос о поведении: что обучало модель, что видит ретривер, по каким данным агент принял решение, что из чувствительного утекло в ответ. Не снимок, а движение.

Это не наша формулировка — это направление, в которое двинулась вся отрасль. Рынок инструментов AI governance, по оценке MarketsandMarkets, вырастет примерно с $0,9 млрд в 2024-м до $5,8 млрд к 2029-му — почти 45% в год; Forrester прогнозирует, что расходы на такой софт к 2030-му учетверятся. И когда крупные игроки — Databricks, IBM, Informatica — описывают, как этого добиться, они говорят одно и то же:

Data lineage — фундамент AI governance. Не опция, не отчётность задним числом, а основа: чтобы доверять тому, что делает ИИ с данными, нужно знать, откуда эти данные и как они связаны.

AI governance, по сути, — следующее поколение data governance. И у этого поколения другой фундамент.

Почему происхождение данных — фундамент

Чтобы управлять тем, что ИИ делает с данными, нужно сначала знать о данных три вещи: откуда они пришли, как связаны между собой и куда текут дальше. Это и есть анализ зависимостей данных — data lineage.

Без него любое утверждение об ИИ-системе повисает в воздухе. «Модель не видит персональных данных» — откуда вы знаете, если не прослежена цепочка от источника до индекса? «Этот отчёт можно доверять» — а на каких таблицах он стоит и не протухли ли они? «Чувствительное не утекает» — но вы проверяли только таблицы, а данные расходятся на уровне колонок.

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

Что ломается, когда приходит ИИ

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

Схема сама становится уязвимостью. Чтобы отвечать на вопросы, RAG-система индексирует описания таблиц и полей. Тем самым интерфейс для аналитика превращается в интерфейс для изучения схемы: серией вопросов можно восстановить структуру данных, не имея доступа к базе. Подробнее — «Схема тоже чувствительна».

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

Похожее принимают за то же. Поиск по смыслу (embeddings) находит таблицу, которая похожа на вопрос, — но похожее не значит нужное, а одно и то же часто выглядит по-разному. ИИ уверенно подставляет не ту таблицу. Подробнее — «Похоже ≠ то же».

Знание устаревает молча. Схема меняется, а система продолжает строить запросы по старой — уверенно и каждый раз. В долгоживущих хранилищах за два-три года протухает 20–30% накопленного знания. Подробнее — «Забывающие базы данных».

Изоляцию нужно проверять. Даже если чувствительное помечено и закрыто, в недетерминированной системе оно может просочиться обходным путём. Помеченный элемент сам становится точкой контроля. Подробнее — «Канарейки в схеме».

У всех пяти — общий корень: система не знает, что от чего зависит и откуда что пришло. То есть нет слоя происхождения.

Почему каталога и коннекторов недостаточно

Возразят: для этого есть инструменты data lineage — они подключаются к источникам и рисуют граф. Это правда, и зрелые продукты (Collibra, Informatica, Alation) умеют строить граф, включая колоночный уровень.

Но есть разница между «нарисовать граф из коннекторов» и «знать, как данные используются на самом деле». Коннектор видит объявленные связи — внешние ключи, описания, конфигурацию ETL. Он не видит, как аналитики реально соединяют таблицы в тысячах запросов, какие поля используются как один и тот же объект под разными именами, какие зависимости живут только в истории SQL, а не в схеме.

А именно это и нужно для AI governance: не «что объявлено», а «что происходит». Методология хранилища определяет, насколько легко это восстановить, но сам ответ — в коде запросов, а не в вики, которую перестали обновлять в день её создания.

Каким должен быть слой происхождения

Из всего сказанного складывается, чего требует AI governance от слоя данных под ним.

Из реального кода, а не из документации. Граф зависимостей выводится разбором SQL — историю запросов превращают в синтаксические деревья (AST) и извлекают, что от чего зависит. Это правда из того, как данные использовались, а не из того, как их описали. Сегодня источник — SQL; тот же принцип ложится на любые контракты данных: API-спецификации (OpenAPI/Swagger), protobuf-схемы — всюду, где данные описаны и движутся в коде. В ИИ-эпоху это и важно: данные текут не только через хранилище, но через сервисы и API.

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

В обе стороны. «Откуда пришли эти данные» и «что сломается, если их изменить» — две стороны одного графа. AI governance нужны обе: и происхождение, и импакт.

И не только структура — но и смысл. Lineage отвечает «откуда и куда». Но человек спрашивает про MAU, churn, выручку — а таблицы «MAU» в данных нет. Нужен ещё слой: что эти данные значат — бизнес-метрики, термины, локальные знания вроде «Курс 18 — это математика». Бенчмарк BEAVER показал, как это тяжело: 57 из 100 вопросов требуют именно такого доменного знания. Этот слой семантики идёт раньше ИТ: сначала смысл, потом таблицы.

On-premise. Если слой строится ради контроля над данными, он не должен сам становиться каналом утечки. Разбор кода идёт там же, где данные, и не покидает периметр.

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

Чего происхождение не решает

Честно — слой происхождения не закрывает всё. Есть пределы, которые важно назвать.

Агрегация рвёт цепочку. Когда строки свёрнуты в SUM или COUNT, проследить результат к исходным записям стандартными методами нельзя — это математическое свойство, установленное ещё в 2000 году (Cui, Widom & Wiener) и не опровергнутое за четверть века.

Динамический SQL. Запросы, которые приложение собирает строками на лету, не существуют как текст до выполнения — граф можно построить только по тому, что попало в историю.

Что считать чувствительным — решает человек. Машина проследит поток и построит граф, но «является ли этот производный показатель персональными данными» — вопрос юриста и владельца данных, а не алгоритма. Инструмент фиксирует решение, но не принимает его.

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

Data governance спрашивал: знаешь ли ты свои данные. AI governance спрашивает: знаешь ли ты, что с ними делает ИИ. Ответить можно только с одного места — снизу, от происхождения. Кто построит этот слой первым, тот и задаёт правила сверху.