Суть. Дисциплина, отвечающая на четыре вопроса про каждый набор данных: откуда он взялся, насколько ему можно верить, кому он доступен и когда его нужно удалить. Без этого слоя ИИ-система работает, но объяснить её поведение невозможно.
Четыре опоры
| Опора | Вопрос | Что бывает без неё |
|---|---|---|
| Происхождение | Откуда данные и на каком основании собраны | Нечего ответить регулятору и невозможно воспроизвести результат |
| Качество | Полнота, дубли, актуальность | Система обучена на мусоре и уверенно его повторяет |
| Доступ | Кто имеет право видеть и использовать | Ответ раскрывает то, что человеку видеть нельзя |
| Жизненный цикл | Сколько храним и когда удаляем | Хранение сверх срока превращается в юридический риск |
Почему это стало отдельной темой
Пока данные использовались для отчётов, ошибка в них стоила неточного графика. Когда на тех же данных принимает решения автоматическая система, ошибка воспроизводится в масштабе и без свидетелей. Отсюда требование объяснимости: нужно уметь показать не только что решила система, но и на чём.
Международные стандарты вокруг управления ИИ прямо предполагают, что жизненный цикл данных существует и у него есть владельцы. Это не пожелание, а условие сертификации.
С чего начать
- Составить список источников, которые кормят ИИ-функции. Обычно их меньше, чем кажется.
- По каждому назначить владельца — человека, а не отдел.
- Описать, как данные попадают внутрь и что происходит при изменении структуры источника.
- Проверить права: наследуются ли они, когда данные попадают в индекс или витрину.
- Задать сроки хранения и убедиться, что удаление действительно происходит.
Что требуется от данных для работы моделей
| Требование | Что означает | Как проверить |
|---|---|---|
| Происхождение | Известно, откуда и на каком основании | Можете назвать источник каждого набора |
| Право использования | Согласие покрывает это применение | Юрист подтверждает, а не предполагает |
| Качество | Полнота, актуальность, отсутствие противоречий | Есть автоматические проверки |
| Разметка | Кто и по каким правилам размечал | Есть инструкция и согласованность между разметчиками |
| Разделение | Чувствительное отделено от обычного | Разные права доступа |
Порядок работы
- Соберите перечень наборов, которые уже используются или планируются. Обычно он длиннее ожидаемого.
- Проверьте правовую сторону до технической. Ошибка здесь не исправляется переобучением.
- Заведите проверки качества на входе, а не разовую очистку. Источники меняются.
- Опишите правила разметки и проверьте согласованность между людьми — расхождения там задают потолок качества модели.
- Определите срок пересмотра: данные устаревают быстрее, чем код.
Где ломается
Управление данными легко превращается в реестр, заполненный один раз. Признак: в описании источника указан сотрудник, который уволился год назад. Второй провал — правила пишет одна команда, а данные использует другая, и обратной связи о том, что реально мешает, между ними нет.
Данные собирали для другого. Согласие получено на оказание услуги, использование для обучения им не покрыто.
Разметку делают без инструкции. Два человека размечают одно и то же по-разному, и модель учится на противоречиях.
Персональные данные попадают в обучающий набор. Обнаруживается при проверке безопасности у крупного заказчика — в самый неудобный момент.
Практическое правило: если вы не можете за час объяснить происхождение обучающего набора, проект несёт риск, которого нет в смете.
Частые вопросы
Связанное
- RAG — где качество данных проявляется быстрее всего
- ISO/IEC 42001 — управленческая рамка, требующая этого слоя
- EU AI Act и GDPR — правовая сторона вопроса
Качество модели ограничено качеством разметки, а законность её применения — происхождением данных. Оба ограничения выясняются слишком поздно, если не проверять заранее.