Data Governance: почему ИИ-проекты ломаются на качестве данных

ИИ-проекты ломаются не на модели, а на данных: корпоративные системы заполнялись ради закрытия периода и аудита, поэтому выборка описывает процесс учёта, а не реальность. Gartner прогнозирует (пресс-релиз от 26.02.2025), что до конца 2026 года организации откажутся от 60% ИИ-проектов, не обеспеченных AI-ready данными; по данным MIT NANDA (август 2025), 95% пилотов не дают эффекта на P&L. Data Governance отвечает на два вопроса — кто отвечает за смысл поля и кто узнает первым, если оно сломалось. Пригодность данных под сценарий проверяет дата-аудит за 3–4 недели, до бюджета на пилот.

Компания собрала дата-команду, арендовала мощности, выбрала модель. Через три месяца пилот готов, на валидации метрики приличные — а в проде он выдаёт предсказания мимо здравого смысла или тихо деградирует за квартал. Первым делом чинят модель.

Хотя чинить нечего. Модель не сломалась, она честно выучила то, что ей дали: выборка описывает не поведение клиента, а артефакты учётного процесса. Поэтому вопрос, почему ИИ-проекты проваливаются, решается не в модельном слое, а в контуре Data Governance.

Data Governance простыми словами: кто отвечает за смысл поля

Data Governance (управление данными в компании) — это система полномочий и правил, которая определяет, кто отвечает за смысл каждого поля данных, кто задаёт критерии его корректности и кто отвечает, если поле сломалось. Data Governance не измеряет качество данных, а назначает тех, кто его определяет и поддерживает. В своде знаний DAMA-DMBOK это центральный домен управления данными.

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

Работающий Data Governance сводится к двум ответам: кто отвечает за смысл поля и кто узнает первым, если оно сломалось. Остальное — оснастка вокруг них, data governance framework. Разница простая: Data Quality отвечает на вопрос «данные правильные?», Data Governance — «кто решает, что правильно».

Сколько ИИ-проектов не доходит до продакшена: цифры

Доля неуспешных корпоративных ИИ-проектов гуляет в диапазоне 55–95%. Разброс — от определения: считать провалом брошенный пилот или внедрённое решение без эффекта на P&L.

Gartner и Bercut считают брошенные проекты — пилот ИИ не масштабируется. MIT NANDA (150 интервью, 350 опрошенных, 300 внедрений) описывает случай неприятнее: решения дошли до эксплуатации, но эффекта на P&L не дали.

Провал ИИ-проекта почти всегда упирается в данные. Около половины сложностей даёт подключение источников и их обработка (Bercut, ПАО «Ростелеком», апрель 2026), а на подготовку данных, по отраслевым оценкам, уходит до 80% времени аналитика. Ошибки внедрения ИИ в компании концентрируются до модели, а не в ней.

Данные собирались не под ИИ — и это главная причина

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

Модель на таких данных выучивает поведение сотрудника, заполнявшего форму, а не поведение клиента.

Пример — прогноз оттока. Целевую переменную берут из CRM: оттоком считается статус «неактивен». Ставит его менеджер при чистке базы — через полтора-два месяца после ухода клиента. Сильнейшие предикторы — дата последнего изменения карточки и смена ответственного. На валидации метрики отличные. В проде модель бесполезна: оба признака появляются одновременно со статусом или позже. Подготовка данных для machine learning свелась бы к одному — брать дату ухода из биллинга.

Отраслевая оценка затрат в провальных проектах — 10% технология, 20% данные, 70% люди и процессы. Она объясняет, почему усиление модели не спасает: чинят десятую часть проблемы.

Шесть дефектов данных, которые убивают модель

Шесть дефектов, из-за которых модель учится на артефактах учёта, встречаются почти в каждом проекте: дубли в справочниках, поля-«помойки», статусы задним числом, переписанная история, разрывы между системами и отсутствие data lineage. К каждому — быстрая проверка.

Справочники и дубли: три записи об одном контрагенте

НСИ ведут руками, мастер-источника нет — и один контрагент живёт как «ООО Ромашка», «Ромашка ООО» и просто «ромашка». Бухгалтерии это не мешает: строки сводят вручную. Модель видит три сущности, и «семь лет с нами» распадается на три признака «новый клиент». Проверка — доля записей с одним ИНН при разных наименованиях. Лечится мастер-данными и MDM.

Поля-«помойки»: комментарий вместо структуры

Свободное текстовое поле, куда годами складывали всё, что не влезло в форму: причину отказа, номер согласования, признак льготы. Форму не расширяли — в комментарий было быстрее. Человек такую строку читает без труда. Модель видит шум, хотя поле самое информативное: причина отказа есть только там. Проверка — сколько уникальных шаблонов записи на двухстах строках.

Статусы задним числом: процесса не было

Заявка помечена закрытой 30-го числа — потому что 30-го закрывали период. Фактически её закрыли 12-го. Отчётность не страдает: период сошёлся. Модель, которую учат предсказывать сроки, выучивает календарь отчётности вместо длительности процесса. Постройте гистограмму дат по дням месяца: пик на последних двух днях означает, что даты не по факту.

Переписанная история: update без версионирования

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

Разрывы между системами: ключи и определения

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

Нет data lineage: откуда приехало число

Data lineage — это прослеживаемость происхождения данных: из какого источника и какими преобразованиями получено значение в витрине. Обычно её нет: витрина считается из витрины, та — из ручной выгрузки 2021 года. Пока всё сходится, это никого не беспокоит. Когда число в проде расходится с ожиданием, разбор занимает недели. Возьмите один показатель и восстановите цепочку до источника. Дольше суток — lineage отсутствует.

«AI-ready» — не то же самое, что «чистые данные»

AI-ready данные — это данные, репрезентативные для конкретного сценария использования: включающие все паттерны, ошибки, выбросы и аномалии, необходимые для обучения или работы модели (определение Gartner, Roxane Edjlali). Чистота и пригодность для модели — свойства разные, и потому логика «сначала почистим данные, потом займёмся ИИ» не работает: очистка убирает ошибки ввода и дубли, а пригодность задаёт сценарий.

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

Data owner и data steward: почему без ролей процесс не живёт

Схема ролей проста. Data owner отвечает за смысл поля и правила заполнения, data steward — за соблюдение этих правил в своей области. Каталог данных, DQ-правила и бизнес-глоссарий данных — места, куда что-то записывают. Без человека, отвечающего за записанное, всё это устаревает за квартал. Обязанность создаёт политика управления данными, а не инструмент.

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

Второй вопрос — «кто узнает первым, если поле сломалось» — решается конфигурацией: проверка, порог, SLA на данные, получатель алерта. Приказом не решается ничего: по опросу Writer и Workplace Intelligence (2 400 сотрудников), 29% сотрудников активно мешают внедрению ИИ.

Российская специфика: импортозамещение как источник деградации данных

У российских компаний качество данных дополнительно проседает из-за импортозамещения. Перенос BI, смена СУБД, перенастройка интеграций, параллельная работа легаси и новой системы — каждый шаг оставляет разрыв в исторических данных.

Таблицы при миграции переносят аккуратно. Договорённости о смысле полей не переносит никто: что попадало в значение «прочее», с какого месяца поле заполняют по новым правилам. Это знание жило в голове аналитика — после миграции его нет. Без формализованного управления корпоративными данными качество деградирует в момент перехода, а всплывает через полгода, когда на этих данных пробуют учить модель.

Разрыв между намерением и готовностью виден по цифрам. По данным Strategy Partners, 97% крупных российских компаний внедряют ИИ или планируют внедрение; по опросу МТС Web Services (700 компаний), формализованная ИИ-стратегия есть у 26%. Дата-платформа для ИИ строится параллельно с миграцией и наследует её незакрытые вопросы; 152-ФЗ и обезличивание дополнительно ограничивают состав выборки.

Дата-аудит до старта пилота: что смотреть и сколько это занимает

Дата-аудит компании — диагностика пригодности данных под конкретный ИИ-сценарий: ответ приходит раньше, чем потрачены деньги на модель.

Что смотрят в первую очередь

Начинают с профилирования ключевых таблиц (data profiling): заполненность полей смотрят по годам, а не в среднем. Средняя цифра обычно скрывает полную заполненность за последние два года и половинную за более ранние. Дальше — доля дефолтных значений, кардинальность справочников, доля дублей, история изменений, согласованность ключей.

Технический слой на этом заканчивается. Дальше организационный: кто заполняет поле и есть ли описание вне головы аналитика. Из этих замеров и складываются метрики качества данных и оценка зрелости управления данными.

Сроки, результат и красные флаги

Аудит под один сценарий занимает 3–4 недели. Аудит всех данных компании не назначают — он не заканчивается. На выходе: заключение о выполнимости, перечень блокирующих дефектов, оценка работ. А вот признаки, при которых пилот запускать рано:

• никто не объясняет смысл ключевого поля выборки;

• целевая переменная восстанавливается только вручную;

• история переписывается, состояние на дату невосстановимо;

• данных меньше, чем на один бизнес-цикл.

Аудит дешевле пилота на порядок, а чем позже найден дефект, тем он дороже: ошибка на вводе дешевле её же в отчёте и в проде.

Чек-лист готовности данных к ИИ-проекту

Чек-лист проходят по одному сценарию, не по компании целиком.

• Целевую переменную можно получить автоматически из источника.

• Известно, кто отвечает за смысл каждого поля выборки.

• Состояние данных восстанавливается на любую дату обучения.

• Справочники контрагентов и номенклатуры имеют мастер-источник.

• Расхождение метрики между системами задокументировано.

• Заполненность ключевых полей проверена по годам.

• Глубина истории покрывает минимум один бизнес-цикл.

• Известно, какие признаки доступны позже момента прогноза.

• Настроен мониторинг качества и назначен получатель алерта.

• Для каждого поля витрины прослеживается путь до источника.

Три и более «нет» — запускать пилот рано. Сначала подготовка данных для ML, потом бюджет. Внедрение Data Governance обычно и начинается с первых двух пунктов списка.

Частые вопросы

1. Что такое Data Governance простыми словами?

   Data Governance — это система полномочий и правил, которая определяет, кто отвечает за смысл каждого поля данных, кто задаёт критерии его корректности и кто отвечает, если поле сломалось. Это не регламент, не платформа и не отдел: без назначенных ролей ни каталог, ни DQ-правила не меняют процесс ввода.

2. Чем Data Governance отличается от Data Quality?

   Data Quality — измерение: полнота, точность, непротиворечивость. Data Governance — полномочия: кто задаёт эти критерии и кто отвечает за соблюдение. DQ без DG — дашборд, который никто не обязан гасить.

3. Сколько ИИ-проектов проваливается из-за качества данных?

   По прогнозу Gartner и Forrester на 2026 год, из-за проблем с качеством данных, контекстом и интерпретацией могут провалиться 50–60% ИИ-инициатив.

4. Можно ли запустить ИИ-пилот без внедрения Data Governance?

   Да, если сценарий один и данные лежат в одной системе. Минимум: владелец у ключевых полей, однозначная целевая переменная, восстановимая история.

5. Сколько времени занимает подготовка данных к ИИ-проекту?

   Диагностика — 3–4 недели на сценарий. Сведение справочников — недели, восстановление истории — кварталы, иногда невозможно.

6. Нужен ли дата-офис или хватит ролей в существующих командах?

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

7. С чего начать, если данных много, а описания нет ни у кого?

   С одного сценария и пяти-семи полей: описать смысл, назначить владельца, замерить заполненность по годам. На узком участке качество данных видно за две недели.