Хранилище данных (ДВХ)

Зачем эта функция в ОМВИ

ИИ-инициатива без данных — это презентация, а не продукт. При этом данные обычно живут в хранилище данных (ДВХ), озере данных и десятках систем-источников, за которые отвечает отдельная Data-функция. Если ОМВИ не состыкована с ДВХ, происходит типичное: инициативу одобрили, бюджет выделили, а нужных данных нет, они плохого качества или их нельзя использовать по правовым причинам.

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

Где подключается

Этап ОМВИ	Роль ДВХ / Data-команды
Оценка	Подтверждает наличие, доступность и пригодность данных
Деливери	Предоставляет доступ к витринам, готовит датасеты, настраивает пайплайны
Перед продом	Фиксирует контракт данных и SLA по свежести/качеству
Подтверждение эффекта	Поставляет данные для расчёта метрик и эффекта

Что функция получает на вход

• Сценарий использования: какие данные, в каком объёме и с какой свежестью нужны.
• Требования к качеству и к режиму обработки (вместе с ИБ — классификация).
• Назначение данных: обучение, RAG-контекст, аналитика, расчёт эффекта.

Что функция отдаёт на выход

• Доступ к источникам и витринам (или обоснованный отказ с альтернативой).
• Оценку готовности данных: полнота, качество, история, документированность.
• Контракт данных — согласованную структуру, свежесть, владельца и SLA.

Ключевые артефакты стыка

• Контракт данных (data contract) — что за данные, кто владелец, какое качество и SLA гарантируется.
• Витрина под инициативу/продукт — подготовленный слой данных для RAG, обучения или аналитики.
• Метрики эффекта — данные, на которых считается подтверждённый эффект инициативы.

Антипаттерны

• «Данные найдём по ходу». Инициатива стартует без проверки данных и встаёт в деливери. Лечится обязательной оценкой данных на этапе оценки.
• Ручные выгрузки вместо витрин. Пилот живёт на разовом экспорте, который невозможно повторить в проде.
• Нет контракта данных. Источник меняется, пайплайн ломается, и никто не отвечает за свежесть и качество.
• Эффект некому посчитать. Данные для метрик не предусмотрели заранее, и подтвердить эффект нечем.

Управление данными

Назначение

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

Данные — один из главных источников провала инициатив. Если вопрос данных откладывается до деливери, команда часто поздно узнаёт, что нужного источника нет, доступ невозможен, качество низкое или данные нельзя использовать в выбранном контуре.

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

• Владелец данных должен быть известен. Нельзя строить инициативу на источнике, за который никто не отвечает.
• Качество данных проверяется до деливери. На этапе оценки достаточно предварительной проверки, но перед внедрением нужны факты.
• Доступ должен соответствовать цели. Доступ для анализа, обучения, проверки и рабочей эксплуатации — это разные режимы.
• Чувствительные данные требуют отдельного контроля. Персональные данные, банковская тайна, коммерческая тайна и клиентская информация не должны попадать в неподходящие контуры.
• Минимизация важнее удобства. Инициатива должна использовать только те данные, которые действительно нужны для результата.

Как это работает

Управление данными встроено в контрольные точки (gate):

Этап	Что проверяется	Типовое решение
Новая	понятно ли, какие данные могут потребоваться	отправить в оценку или уточнить бриф
Оценка	существуют ли источники, кто владелец, есть ли ограничения	выбрать ИИ-продукт, запросить доступ, отложить или отклонить
Деливери	качество, доступ, контур обработки, маскирование, журналирование	разрешить разработку, ограничить контур, запросить доработку
Ожидает эффекта	доступны ли фактические данные для измерения результата	подтвердить эффект или пересмотреть методику
Поддержка	стабильность источников, контроль качества, изменение доступа	продолжать, пересмотреть или остановить решение

Связанные разделы: модель управления ИИ, риски ИИ, архитектурное управление.

Минимальная карточка данных

Для инициативы нужно фиксировать:

• какие источники данных используются;
• кто владелец каждого источника;
• для чего используются данные;
• какие поля или наборы данных нужны;
• есть ли персональные данные;
• есть ли банковская или коммерческая тайна;
• где данные будут обрабатываться;
• кто получает доступ;
• как долго данные хранятся;
• как данные удаляются или обезличиваются;
• какой показатель качества данных критичен для результата.

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

Классификация данных

Минимальная классификация:

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

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

Проверка качества данных

Качество данных оценивается не вообще, а относительно задачи.

Минимальные критерии:

• полнота — хватает ли данных для решения;
• актуальность — не устарели ли данные;
• точность — насколько данные отражают реальный процесс;
• стабильность — не меняется ли структура источника без предупреждения;
• связность — можно ли сопоставить данные между системами;
• воспроизводимость — можно ли повторить расчёт или обучение;
• доступность — можно ли получать данные в нужной частоте.

Если качество данных неизвестно, инициатива может идти в оценку, но не должна идти в полноценную деливери без задачи на проверку данных.

Доступы и контуры

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

• просмотр данных для оценки;
• выгрузка ограниченного набора для проверки;
• обработка в изолированном контуре;
• обучение или настройка решения;
• рабочий доступ в эксплуатации;
• доступ ИИ-помощника или агентного сценария.

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

Для внешних или облачных сервисов должны быть отдельно проверены:

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

Что блокирует переход

Инициатива не должна переходить в деливери, если:

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

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

Роль ИИ-помощника

ИИ-помощник может помогать:

• собрать описание источников данных;
• задать вопросы о владельце и доступе;
• подготовить черновик классификации;
• подсказать риски обработки;
• сформировать задачи на проверку данных;
• подготовить описание для безопасности или архитектуры.

Но ИИ-помощник не должен самостоятельно разрешать использование чувствительных данных. Решение остаётся за владельцем данных, безопасностью и ответственными ролями.

Анти-паттерны управления данными

• «данные потом найдём»;
• выгрузки на личные компьютеры;
• обучение на данных без цели и срока хранения;
• отсутствие владельца источника;
• использование клиентских данных в неподходящем контуре;
• эффект считается по показателю, к которому нет доступа;
• качество данных проверяется после разработки прототипа.

Хорошее управление данными делает данные частью ранней оценки, а не поздним препятствием.