Готовность данных — оценка того, насколько данные компании пригодны для ИИ-сценария без предварительной очистки: в каком они формате, где живут, кто их владелец и насколько они актуальны. Это диагностика до внедрения: её результат — список работ, без которого смета внедрения будет выдумкой.
Большинство провалов ИИ-проектов выглядит как «модель не работает», а по механизму — «данные не годились»: сканы вместо текста, три версии одного документа без признака актуальной, знания в головах сотрудников, а не в системах. Диагностика перед стартом дешевле, чем тот же вывод через два месяца разработки.
Что проверять
Машиночитаемость. Возьмите 20–30 случайных документов сценария и попробуйте извлечь из них текст программно. Отсканированные PDF без текстового слоя, таблицы-картинки, вложения в письмах — всё это требует OCR и ручной проверки; детали — в статье про распознавание документов. Оценка по случайной выборке, а не по «образцовым» файлам: образцы отбирали люди, которым свойственно выбирать лучшие.
Где данные живут. Одна система с API, пять систем с экспортом руками или личные папки сотрудников. Каждая ручная выгрузка — это точка отказа и месяц задержки. Для пилота достаточно одного-двух источников; полный перечень нужен для внедрения.
Дубли и версии. Два противоречащих регламента на один процесс, три версии прайса, черновик рядом с финалом. ИИ-система без признака актуальности выберет документ случайно — и это не ошибка модели, а ошибка данных. Нужен явный признак актуальной версии или правило разрешения конфликтов.
Владельцы и актуальность. У каждого источника есть человек, отвечающий за его обновление. Источник без владельца — архив: система будет цитировать устаревшее с полной уверенностью. Заодно проверьте, обновляется ли он реально: дата последнего изменения по файловому журналу честнее слов.
Права доступа. Кто имеет право видеть эти данные внутри компании и что из них можно передавать подрядчику или внешнему API. Персональные данные подчиняются 152-ФЗ; политика передачи и обезличивания — тема отдельных статей про персональные данные и обезличивание. Доступ подрядчика ограничивается ролью и журналируется.
Чек-лист по шагам
Шаг 1. Перечислите источники по сценарию. Не «все данные компании», а данные одного сценария: для бота поддержки — база знаний и журнал обращений, для обработки документов — сами документы и целевая система. Обычно выходит 3–7 источников.
Шаг 2. Оцените объём и качество на выборке. По каждому источнику: сколько записей или документов, какая доля машиночитаема, какая доля дубликатов. Выборка 30–50 случайных элементов на источник даёт оценку с точностью, достаточной для решения.
Шаг 3. Проверьте доступность технически. Есть ли API или экспорт, как часто обновляется, можно ли получить доступ за неделю. Источник с доступом «по заявке через ИБ за месяц» — риск срока, а не только техники.
Шаг 4. Назначьте владельцев. По каждому источнику — имя, а не подразделение. Согласие владельца на использование данных фиксируется письменно; без этого пилот в любой момент останавливается возражением «мы не давали».
Шаг 5. Сформулируйте работы по расхождениям. Список вида «документы X требуют OCR — 3 недели», «в регламенте Y три версии — владелец решает неделю». Этот список и есть результат диагностики: он превращается в этап работ или в осознанное ограничение сценария.
Шаг 6. Решите, что не чините. Часть источников отсеивается: затраты на очистку выше эффекта. Честная граница сценария на плохих данных лучше честного «почистим потом всё».
Где уместна диагностика и когда можно без неё
Перед пилотом — минимальный вариант. Пилоту достаточно одного источника и проверки машиночитаемости на выборке; полная диагностика перед пилотом избыточна. Но вывод пилота «система не работает» без проверки данных не принимается — сначала убедитесь, что вход был годным.
Перед полным внедрением — полный вариант. Все источники, доступы, владельцы, план работ по расхождениям. Это та диагностика, из которой получается реалистичная смета и сроки; без неё смета — оценка на глаз.
При выборе сценария из нескольких. Готовность данных — один из критериев выбора: сценарий с 70% потенциального эффекта, но готовыми данными часто выгоднее сценария со 100% эффекта на нечитаемых архивах. Считайте эффект вместе со стоимостью подготовки.
Когда можно без диагностики. Данные уже чистые и в одной системе — редкий, но реальный случай: свежая база знаний, структурированная CRM. Тогда проверка занимает день и сразу переходит к пилоту.
Типичные ошибки
Чистить всё сразу. «Наведём порядок в данных компании» — проект без конца и без заказчика результата. Данные чистятся под конкретный сценарий; остальное — по мере появления сценариев.
Ждать идеальной чистоты. Обратная крайность: подготовка длится год, сценарий устаревает. Для большинства сценариев достаточно 80–90% чистоты на целевом источнике — оставшиеся проблемы видны по ошибкам системы и чинятся адресно.
Наводить порядок без владельца процесса. ИТ вычищает данные, но актуальность определяет бизнес; без него через полгода данные снова разойдутся с реальностью. Владелец назначается до начала работ, а не после первого конфликта.
Оценивать по образцам, а не по выборке. Десять красивых файлов из презентации не представляют массив; решение по ним принимается о другом массиве. Только случайная выборка, лучше — сгенерированная системой, а не человеком.
Связь с соседними темами
Готовность — про «можно ли начинать», качество данных — про свойства самих данных. Что именно считается качеством и как его мерить — в статье качество данных. Готовность отвечает на вопрос прагматичный: сколько работы до старта пилота.
Подготовка базы знаний — отдельный этап после диагностики. Когда источники известны и доступны, наступает черёд нарезки, дедупликации и структуры — это тема статьи подготовка базы знаний. Диагностика не заменяет эту работу, а выявляет её объём.
Готовность данных — вход в пилот. Как встроить проверку данных в короткий пилот с критериями успеха — в статье про пилотный проект.
Частые вопросы
Можно ли начать с «грязных» данных?
Да, если грязь не в главном: для бота по базе знаний критичны актуальность и отсутствие противоречащих версий, а опечатки в тексте система переживёт. Нельзя — когда данные принципиально не машиночитаемы или их физически мало: тут не поможет никакая модель. Минимальная проверка выборки отвечает на этот вопрос за день.
Кто должен наводить порядок — ИТ или бизнес?
Разделение такое: ИТ отвечает за машиночитаемость, доступы и пайплайны; бизнес — за актуальность, дедупликацию по смыслу и решения «какая версия правильная». Полностью делегировать бизнесу или ИТ нельзя: первый чистит не то, второй не может решить, что устарело.
Сколько занимает диагностика готовности?
По одному сценарию — от 3–5 дней до 2–3 недель: быстрее, когда источники в известных системах и владельцы доступны; дольше, когда доступ согласовывается через службу безопасности. Затягивание обычно организационное, а не техническое.
Что делать, если данные в головах сотрудников?
Это не блокер, а другой сценарий: знания сначала фиксируются в документах — регламенты, FAQ, записи решений. На фиксацию уходит недели; иногда честнее признать, что сценарий пока не готов, и начать с другого, где данные уже есть.
Нужна ли диагностика, если подрядчик обещает «ИИ сам разберётся»?
Обещание означает «разберёмся на ваших данных во время работ, за ваш бюджет». Диагностика переносит это выяснение на этап до обязательств: за неделю вы узнаёте то, что иначе узнали бы в середине сметы. Отказ подрядчика от диагностики данных — сам по себе сигнал при выборе подрядчика.
Как проверить готовность без раскрытия данных наружу?
Выборку обезличивают и оценивают внутри контура, подрядчику передают статистику: форматы, объёмы, долю сканов, число версий. Для глубоких проверок используют NDA и обезличенные фрагменты — механика в статье про обезличивание данных.