# Готовность данных к ИИ до начала разработки

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

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

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

Я провожу проверку с жесткими критериями еще до того, как кто-либо выберет модель или подпишет контракт с платформой. Мы проверяем решение, качество данных, путь доступа, правовые основания, разметку, происхождение данных, обратную связь в рабочей системе и условия остановки. Слабый результат иногда оправдывает небольшой исследовательский эксперимент. Обещать запуск в рабочей среде он не позволяет.

## Готовность относится к решению, а не к набору данных

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

Команды часто смешивают три разных состояния. Доступные данные где-то существуют. Пригодные данные команда проекта может получить и правильно истолковать. Готовые к рабочей эксплуатации данные поступают по расписанию, с одобренными правами, контролем качества и заранее заданной реакцией на сбой. CSV, который выгрузил аналитик, доказывает только доступность. Он не доказывает ни повторяемый доступ, ни готовность к эксплуатации.

Начните с договора о решении в одном предложении:

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

«Оценивать лиды» звучит слишком расплывчато. Формулировку «Каждый рабочий день в 08:00 ранжировать новые входящие лиды в очереди отдела продаж; менеджер сам выбирает, с кем связаться, а директор по продажам отвечает за жалобы и пропущенные приоритетные компании» уже можно проверить. В ней заданы единица оценки, время, получатель, действие и владелец. Она также показывает, советует ли система или принимает решение автоматически. От этого различия зависят обязательные средства контроля.

Договор о решении мешает дорогой привычке: сначала собрать все подряд, а потом решить, что строить. Такой подход популярен, потому что накопление данных похоже на прогресс и откладывает разногласия. Он ошибочен, потому что у качества нет смысла без поля, группы объектов, временного окна и допустимой ошибки. Храните исходные данные, которые разрешает политика, но оценивайте только тот срез, который нужен реальному решению.

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

## Сначала определите доказательства, потом изучайте столбцы

Проверка готовности должна начинаться с критериев приемки, иначе команда открывает таблицы и подгоняет сценарий под удобные данные. В итоге получается эффектная демонстрация и слабый продукт.

Создайте короткую карточку оценки с такими полями:

1. Решение, объект и момент принятия решения.
2. Владелец со стороны бизнеса и технический владелец.
3. Разрешенное действие, запрещенное действие и возможность вмешательства человека.
4. Показатель успеха и базовый результат действующего процесса.
5. Максимально допустимые вред, задержка и доля отказов от ответа.

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

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

Для рабочего ИИ честным вариантом по умолчанию часто становится разделение по времени. Обучайте на данных, доступных до выбранной даты, а тестируйте на более поздних решениях. Если один объект создает много строк, поместите все его строки только в одну часть выборки. Иначе модель может узнавать клиента вместо того, чтобы учиться закономерности, которая переносится на нового клиента.

В критерии приемки также входит результат теневого запуска. В этот период система выдает ответы, но не управляет действиями. Сравните ответы с действующим процессом, запишите расхождения и попросите владельца классифицировать дорогие ошибки. Общий показатель не объяснит, сосредоточены ли ошибки среди новых клиентов, историй с малым числом событий, одного канала привлечения или после изменения рабочего процесса.

Вместе с планом оценки составьте карту источников. Для каждого поля укажите главную систему учета, таблицу или событие, бизнес-определение, причину обновления, первую надежную дату, способ соединения и владельца, способного разрешить расхождение. Отметьте поля, скопированные из другой системы, потому что удобный столбец в хранилище может отставать от исходного события или преобразовывать его. Если две системы претендуют на главную роль, выберите одну для этого решения и запишите порядок сверки.

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

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

Наконец, сопоставьте запрошенные поля с договором о решении. Удалите поля, которые не нужны согласованному признаку, правилу допуска, аудиту или оценочному срезу. «Возможно, пригодится потом» не считается целью. С меньшим набором полей проще настроить доступ и проверять будущие изменения, а неописанная коллекция позволяет сценарию разрастаться без нового решения.

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

## Качеству данных нужны пороги и действия при сбое

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

Используйте шесть характеристик, но определяйте их применительно к своей задаче. Полнота отвечает на вопрос, присутствуют ли обязательные значения. Допустимость проверяет значения на соответствие правилам предметной области. Уникальность определяет, появляется ли единица решения ровно один раз там, где это требуется. Согласованность показывает, совпадают ли источники. Своевременность проверяет, поступают ли данные до момента решения. Репрезентативность определяет, охватывает ли оценочная выборка рабочую группу, которая получит результаты.

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

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

```sql
/* One row with counts and rates, stored as a quality run artifact */
SELECT
  CURRENT_DATE AS run_date,
  COUNT(*) AS rows_seen,
  SUM(CASE WHEN lead_id IS NULL THEN 1 ELSE 0 END) AS missing_ids,
  COUNT(*) - COUNT(DISTINCT lead_id) AS duplicate_ids,
  AVG(CASE WHEN created_at >= CURRENT_TIMESTAMP - INTERVAL '48 hours'
           THEN 1.0 ELSE 0.0 END) AS fresh_rate,
  AVG(CASE WHEN acquisition_channel IN
      ('organic', 'referral', 'paid', 'partner')
      THEN 1.0 ELSE 0.0 END) AS known_channel_rate
FROM candidate_leads;
```

Результат должен иметь обычную табличную форму, которую можно сохранить в журнале запусков:

```text
run_date  | rows_seen | missing_ids | duplicate_ids | fresh_rate | known_channel_rate
2026-08-09| 1842      | 0           | 3             | 0.992      | 0.978
```

Сам по себе этот результат еще не означает успешную проверку. Политика может запрещать публикацию при `missing_ids > 0`, отправлять дубликаты идентификаторов в карантин, предупреждать о падении свежести ниже согласованного уровня и сравнивать доли каналов с утвержденным контрольным периодом. Храните версию запроса, снимок источника или идентификаторы разделов, результат, версию порогов и принятое действие. Иначе зеленая панель не расскажет расследующему инцидент сотруднику, что именно прошло проверку.

Профилируйте не только схему, но и распределения. Записывайте доли категорий, числовые квантили, долю нулей, длину текста и возраст самого нового события. Сравнивайте их во времени и по группам, значимым для решения. Выбирайте группы по анализу вреда, а не только по столбцам, которые удобно объединять.

У пропусков должны быть причины. «Неизвестно, потому что клиент пропустил поле формы» отличается от «отсутствует из-за сбоя загрузки» и от «не применимо к этому тарифу». Если свести все три случая к null, модель выучит закономерность, способную исчезнуть после изменения формы или конвейера. Сохраняйте код причины, когда процесс ее знает.

## Доступ должен работать от имени рабочей системы

Доступ к данным готов только тогда, когда рабочая задача получает утвержденные поля в нужное время по поддерживаемому пути. Запрос инженера к копии базы с личными учетными данными не проверяет доступ. Это только предварительный просмотр.

Проведите репетицию доступа с настоящей служебной учетной записью в тестовой среде, которая повторяет права. Репетиция должна включать пять действий:

1. Прочитать описанные источники и только утвержденные столбцы.
2. Соединить их по стабильным идентификаторам, а не по именам или меняющимся адресам электронной почты.
3. Получить достаточно истории для построения признаков, не обходя правила хранения.
4. Записать результаты в назначенное место вместе с идентификатором идемпотентности.
5. Создать аудиторские записи, связывающие снимок входных данных, версию кода, версию модели и пакет результатов.

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

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

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

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

## Управление должно назвать цель, полномочия и удаление

Управление готово, когда назначенный владелец может объяснить, зачем используется каждое чувствительное поле, кто вправе его использовать, сколько хранятся производные данные и как человек может оспорить результат, если этого требует политика или закон. Слайд со словом «соответствует требованиям» не отвечает ни на один из этих вопросов.

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

NIST AI Risk Management Framework делит работу на Govern, Map, Measure и Manage. Такая последовательность полезна, потому что измерение не заменяет управление. Команда может получить отличные показатели ошибок для применения, которое бизнес никогда не разрешал. Я добавил бы одно практическое требование: привяжите каждое заявление об управлении к владельцу и проверяемому артефакту. Фраза «Юристы посмотрели» должна указывать на одобренную цель, условия, дату и проверяющего, а не на старое приглашение на встречу.

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

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

Запишите результат проверки в журнал решений с одним из четырех исходов: одобрено, одобрено с условиями, только исследование или отклонено. Для условий нужны сроки и владельцы. «Одобрено после решения вопросов управления» обычно означает, что после успешной демонстрации к управлению никто не вернется.

## Метки описывают реальность, но не равны ей

Метка не становится истиной только потому, что лежит в столбце `outcome`. Это утверждение, созданное процессом, а у процесса есть стимулы, задержки, разногласия и пропущенные случаи.

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

Проверяйте четыре свойства: стабильность определения, задержку наблюдения, охват и разногласия. Стабильность определения показывает, меняли ли политика или программа смысл метки со временем. Задержка наблюдения сообщает, когда результат становится известен. Охват показывает объекты, которые никогда не получают метку. Разногласия определяют, дадут ли два квалифицированных проверяющих одинаковый ответ в неоднозначном случае.

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

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

Утечка метки бывает до смешного незаметной. Поле вроде `case_closed_reason` может безошибочно предсказывать эскалацию, потому что сотрудники заполняют его после эскалации. Зафиксируйте представление признаков на моменте решения из договора и отклоняйте значения, доступные только позднее. Проверки имен столбцов недостаточно, нужны временные метки событий и знание процесса.

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

## Договор о данных должен выдерживать рабочие изменения

Готовность заканчивается, если команда не может заметить изменения источников, смысла и группы объектов до того, как они изменят решения. Реестр схем обнаружит смену типа. Он не заметит, что администратор CRM переопределил понятие «квалифицированный», новый регион использует другие значения по умолчанию или временная метка теперь указывает время обработки вместо времени события.

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

```yaml
dataset: candidate_leads_v3
owner: revenue_operations
decision_time: "08:00 America/Los_Angeles on business days"
entity_key: lead_id
event_time: created_at
freshness:
  newest_event_max_age_minutes: 90
required_fields:
  lead_id: {null_rate_max: 0}
  acquisition_channel: {allowed_set_ref: channel_policy_v4}
population:
  included_regions: [US, CA]
on_breach:
  action: stop_publish
  notify: [revenue_operations, ai_on_call]
```

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

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

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

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

## Оценивайте готовность, не усредняя блокирующие проблемы

Оценка готовности должна упорядочивать доказательства, а не превращать небезопасный проект в зеленый значок с числом 74 процента. Сначала применяйте жесткие критерии, а итоговый балл используйте только для расстановки приоритетов.

Я использую восемь категорий: решение, качество, доступ, управление, метки, оценка, рабочие средства контроля и ответственность. Каждая получает от 0 до 3 баллов:

- 0 баллов: ответ неизвестен или опровергнут фактами.
- 1 балл: допущение записано, но не проверено.
- 2 балла: проведена одна проверка на репрезентативном срезе.
- 3 балла: проверка повторяется, контролируется, имеет владельца и связана с действием при сбое.

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

Не усредняйте критические нули. Проект не может выйти в рабочую среду, если у него нет ответственного бизнес-владельца, законной или одобренной цели, оценки с учетом момента решения, запасного процесса на случай пропажи данных или возможности остановить результаты. Это обязательные условия. Высокое качество не компенсирует отсутствие полномочий, как и подписанное одобрение не компенсирует метки, созданные после решения.

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

Оценка должна закончиться одним из четырех решений:

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

Для основателей, которым нужна независимая проверка, Team & AI Audit на oleg.is за фиксированные $5,000 рассматривает команду и возможности ИИ в течение пяти рабочих дней, а если не удается найти экономию как минимум $50,000 в год, аудит проводят бесплатно. Это предложение не сделает неготовый сценарий готовым, но задаст срок и ответственного для разбора пробелов в готовности, инженерной экономики и вопросов владения.

## Первая проверка должна попытаться закрыть проект

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

Проводите проверку с бизнес-владельцем, владельцем данных, представителем безопасности или конфиденциальности и инженером, которому придется отвечать на ночные вызовы. Последний часто задает лучший вопрос: «Что я увижу в 02:00, когда этот поток данных окажется неправильным?» Ответьте средством контроля, артефактом и действием, а не уверенностью команды модели.

Если доказательства уже существуют, проверку можно закончить за одну рабочую встречу. Чаще она создает короткий список недостающих доказательств. Расположите его по способности неопределенности остановить проект. Правовое основание, пригодность меток, охват группы и рабочий доступ способны закрыть проект, поэтому проверяйте их до настройки признаков или сравнения поставщиков моделей.

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

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

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