Готовы ли ваши данные к AI-автоматизации: экспресс-аудит
Process-specific проверка data readiness до выбора модели
Доступ, права, качество, meaning, freshness и ownership
Авторская матрица DATA-5 с defect priorities и decision gates
Аудит данных для AI-автоматизации, критерии зрелости, исправления и bounded pilot
$ audit data --matrix DATA-5
> inspect: access / rights / quality / meaning / freshness
> classify: P0 stop / P1 repair / P2 control / P3 improve
> route: blocked / discovery / bounded-pilot / readyАудит данных для AI-автоматизации — это не поиск идеально чистой базы. Это проверка, хватает ли конкретному процессу доступных, правомерно используемых, понятных и наблюдаемых данных для ограниченного решения. Полезный вопрос звучит не «есть ли у нас данные», а может ли команда проследить input, воспроизвести ожидаемый output и исправить ошибку до неприемлемого side effect.
Этот экспресс-аудит поддерживает broad intent страниц AI-автоматизация и AI-специалист в Армении узкой методикой data readiness. Он не заменяет их коммерческий интент и не обещает, что прохождение checklist гарантирует качество модели или ROI.
Область аудита: один процесс, а не вся компания
Начните с одного process slice и одного предполагаемого AI-assisted действия. «Проверить CRM» — слишком широко. «Использовать текст входящего запроса и карточку клиента, чтобы предложить категорию маршрутизации, а оператор подтверждает очередь» — проверяемая область.
До scoring зафиксируйте шесть границ:
- trigger, который запускает процесс;
- записи и файлы, которые системе разрешено читать;
- поле, документ или event с ожидаемым результатом;
- системы и люди, изменяющие эти данные;
- предполагаемый AI output и его consumer;
- side effect, approval и recovery path.
Проверяйте representative examples, а не удобный demo set. Включите обычные случаи, редкие категории, пропуски, дубликаты, смешанные языки, задержанные обновления и известные exceptions. Если процесс меняется по сезонам или режимам работы, берите примеры из разных периодов.
Не переносите в audit workspace персональные, конфиденциальные или регулируемые поля «на всякий случай». До передачи данных модели, evaluation-среде или внешнему provider подтвердите purpose, права доступа, retention и deletion rules. Юридические требования зависят от организации и юрисдикции: этот checklist помогает сформулировать вопросы, но не заменяет правовую проверку.
DATA-5: матрица готовности
Оцените пять областей от 0 до 3. Ноль означает отсутствие, запрет или неизвестность. Один — работу только через хрупкие ручные действия. Два — возможность bounded pilot с явными repairs или controls. Три — документированное, проверяемое состояние с owner.
| Область | 0 — blocked | 1 — fragile | 2 — pilot-ready с controls | 3 — operationally ready |
|---|---|---|---|---|
| Inventory и доступ | источники или owner неизвестны | ручные exports и персональный доступ | названы sources, owner и bounded export/API | governed access, versioned schema и least privilege |
| Права и purpose | права или допустимое использование неизвестны | assumptions или разное понимание consent | согласованы purpose, exclusions и retention | auditable policy, deletion route и vendor boundaries |
| Качество и покрытие | нет representative sample | скрытые пропуски, дубли или label drift | defects измерены по сегментам; есть repair plan | automated checks, thresholds и exception queue |
| Значение и lineage | у полей нет общего смысла | правила живут в памяти сотрудников | glossary, source of truth и joins документированы | lineage, versions и owner изменений наблюдаемы |
| Freshness и operations | время обновления неизвестно | stale snapshots и manual reconciliation | freshness target, fallback и incident owner | monitored lag, replay/idempotency и recovery runbook |
Рядом с каждым score храните evidence: query result, schema, policy, sample review, API contract, data-quality check или подтверждение owner. Балл без доказательства — предположение. Нельзя растворять ноль по правам или доступу в удобной средней сумме.
Матрица всегда привязана к процессу. Одна CRM может быть готова к read-only search, но не к автономному изменению цен. Один архив документов может поддерживать retrieval после access filtering, но провалить extraction use case, если нужные поля исторически записывались непоследовательно.
Уровни зрелости и decision gates
Маршрут задаёт самая слабая критическая область:
- Level 0 — blocked: источник, права, outcome или owner неизвестны. Остановить реализацию и снять blocker.
- Level 1 — discovery only: samples доступны, но стабильного evaluation или integration contract ещё нет.
- Level 2 — bounded pilot: есть representative cases, явные exclusions и безопасный read-only, shadow, draft или approval mode.
- Level 3 — operationally ready: checks, ownership, monitoring, correction и change control поддерживают production rollout.
Сумма баллов помогает сравнивать snapshots, но не отменяет critical gates. Не начинайте pilot, если права и purpose равны нулю, у source нет owner, ожидаемый output нельзя восстановить или consequential write не имеет approval и rollback.
Для первого пилота практический gate DATA-5 — минимум level 2 по inventory, quality, meaning и operations плюс явно подтверждённые rights и purpose. Это рабочее правило метода, а не универсальный отраслевой benchmark.
Типовые дефекты и способы их найти
Неизвестный source of truth. Два export показывают разный статус клиента, наличие товара или owner тикета. Проследите 3–5 реальных записей от trigger до финального outcome и назовите authoritative field на каждом шаге.
Скрытые пропуски. Поле заполнено для простых случаев и отсутствует именно там, где процесс сложен. Измеряйте missingness по category, language, channel, team и period, а не только общим процентом.
Исторические labels описывают старое поведение. Категория маршрутизации или результата может отражать прежнюю policy, старую структуру команды или shortcuts закрытия тикетов. Проверьте definitions и разберите disagreements с текущими операторами.
Дубликаты и identity collisions. Один клиент, компания или product существует под несколькими ID; либо две сущности объединяются слабым ключом. До evaluation проверьте joins, deduplication rules и merge history.
Незаписанные exceptions. Операторы решают edge cases в мессенджере, таблице или по памяти, а основная система хранит только final state. Нанесите exception paths на карту и включите их в representative set.
Data leakage. Ожидаемый ответ или поздняя human correction попадает во input, evaluation split или retrieved context. Разделяйте timestamps, identities и периоды, чтобы система не «предсказывала» информацию, которой не было в момент решения.
Freshness mismatch. Модель читает ночной export, хотя решение зависит от изменений последних минут. Зафиксируйте event time, processing time и допустимый lag; определите route при нарушении freshness target.
Нестабильная семантика. Имя поля не меняется, но его смысл меняется. Версионируйте taxonomies и business rules, связывайте изменения с evaluation results и downstream contracts.
Приоритет исправлений: риск важнее удобства
Классифицируйте findings по решению, которое они блокируют:
| Приоритет | Значение | Примеры | Обязательный маршрут |
|---|---|---|---|
| P0 — stop | небезопасно, запрещено или непроверяемо | неизвестные права, открытые secrets, нет source owner, необратимая запись без recovery | stop; убрать доступ или решить governance до model test |
| P1 — repair before pilot | вероятно ломает evaluation или workflow | отсутствует target outcome, broken joins, большие segment gaps, stale source, inconsistent labels | исправить, пересобрать sample и повторить checks |
| P2 — control in pilot | bounded defect с безопасным ответом | редкий неподдерживаемый формат, low-volume exception, известный manual fallback | исключить или отправить на review; явно monitor |
| P3 — improvement | не блокирует текущие acceptance criteria | optional enrichment, удобное поле, расширение coverage | backlog; не задерживать evidence |
Исправляйте минимальную причину, которая меняет readiness. Новая data platform — не ответ по умолчанию. Иногда достаточно documented field definition, API permission, exception queue, timestamp, representative evaluation set или сужения pilot scope.
После repair повторите только зависящие от него checks и сохраните новое evidence. Недостаточно просто поменять score. Readiness — traceable state, а не презентация.
Формат итогового отчёта
Отчёт должен быть достаточно коротким для решения:
- Scope и proposed action: trigger, input, output, systems, owner и возможный side effect.
- Source register: source of truth, access method, schema/version, owner, rights, retention и freshness.
- Representative sample: способ отбора, segments, periods, exclusions и blind spots.
- DATA-5 matrix: score, evidence и uncertainty по каждой области.
- Defect register: finding, affected segment, impact, priority, repair owner и verification step.
- Pilot gate: blocked, discovery only, bounded pilot или operationally ready.
- Control contract: разрешённые reads/writes, review route, monitoring, stop condition, fallback и rollback.
- Next decision: дата, требуемое evidence и человек с правом continue, redesign или stop.
Отделяйте наблюдаемые факты от гипотез. «В 18 из 50 проверенных обращений нет подтверждённого resolution field» — evidence ограниченного sample. «Очистка CRM сократит handling time на 30%» — неподтверждённый forecast, если нет измеренного causal test.
Что делать после экспресс-аудита
При статусе blocked сначала решите rights, ownership или traceability. Для discovery-only соберите source register и representative case set. При готовности к bounded pilot оставьте первый запуск в read-only, shadow, draft или approval mode и сравнивайте результат по той же sample definition.
Свяжите проверку с матрицей ценности и риска первого AI-пилота: data readiness — только один gate, а value, evaluation, reversibility, integration и ownership определяют, подходит ли процесс для первого пилота. Проверяемые delivery patterns собраны в кейсах.
Хорошая готовность данных не означает «всё очищено». Она означает, что команда знает, что читает процесс, что означают поля, какие defects существенны, кто отвечает за correction и как система безопасно останавливается при недостаточном evidence.
require(sourceOwner && permittedPurpose && representativeCases);
require(targetOutcome && freshnessTarget && correctionPath);
route = criticalZero ? "blocked" : minReadiness >= 2 ? "bounded_pilot" : "repair_first";