Качество данных перед внедрением ИИ: минимальный аудит за неделю

Почему BI не гарантирует готовность к ИИ

Это самое частое возражение на старте любого ИИ-проекта: «У нас Power BI работает, дашборды сходятся, значит с данными всё в порядке».

Логика понятна, но она ошибочна — и вот почему.

BI-инструмент агрегирует данные. Один дубль контрагента в справочнике растворяется в строке «Итого по группе». Пустое поле «Регион» в 8% записей не мешает построить диаграмму продаж по месяцам — оно просто попадает в категорию «Не указано» или отбрасывается фильтром. Ручная корректировка задним числом не видна на графике выручки.

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

Разница не в качестве инструмента. Разница в том, что BI прощает грязные данные, а ИИ масштабирует их последствия.

Путь данных из 1С в ИИ: где возникают потери

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

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

Хранение в 1С → незакрытые документы без проводок, ручные корректировки регистров, накопленные дубли НСИ после слияний и реорганизаций.

Выгрузка / интеграция → потеря типов данных при экспорте в CSV/Excel, нарушение связей между объектами, отсутствие метаданных о времени последнего изменения.

Подача в модель → передача персональных данных без обезличивания (нарушение 152-ФЗ), несоответствие форматов дат и кодировок, отсутствие исторической глубины для обучения.

На каждом из этих этапов качество снижается — и аудит должен охватывать все четыре.

Четыре измерения: что именно проверять и какие пороги

Западные методологии часто смешивают completeness и quality в одну метрику. Это ошибка планирования: восстановить пустые поля можно за дни, исправить системную некорректность — за недели. Разделяйте эти два типа проблем с самого начала.

Типичные 1С-антипаттерны и их влияние на ИИ

Это не абстрактные «проблемы качества» — это конкретные объекты и ситуации, которые встречаются в большинстве российских ERP-баз.

Пятидневный спринт аудита

Этот план рассчитан на команду из двух-трёх человек: аналитик данных или 1С-специалист, IT-директор или руководитель проекта, и опционально — владелец бизнес-процесса (например, руководитель отдела продаж или логистики).

День 1 — Инвентаризация источников

Кто: IT-директор + 1С-специалист. Что делать: Определить объекты, которые войдут в пилот (не всю базу — только целевые). Зафиксировать: какие справочники и регистры используются, за какой период, есть ли внешние источники (CRM, WMS, Excel-файлы). Проверить наличие прав на выгрузку данных. Инструмент: Интервью с владельцами процессов + схема потоков данных на бумаге или в Miro. Артефакт: Карта источников данных — список объектов 1С с указанием периода, объёма и ответственного.

День 2–3 — Профилирование по четырём измерениям

Кто: 1С-специалист / аналитик данных. Что делать: Запустить проверки по таблице измерений выше. Для каждого целевого объекта зафиксировать фактические значения метрик. Не пытаться сразу чистить — только измерять. Инструмент: Встроенные отчёты 1С (Анализ субконто, Поиск дублей через БСП), выгрузка в Excel для СЧЁТЕСЛИ, при наличии — SQL-запросы к базе через COM-соединение или прямое подключение к СУБД. Артефакт: Таблица фактических значений метрик по каждому объекту.

День 4 — Скоринг и классификация проблем

Кто: IT-директор + аналитик. Что делать: Сравнить фактические значения с пороговыми. Разделить проблемы на два типа: completeness (пустые поля — быстро исправляется) и quality (системная некорректность — требует регламентных изменений). Рассчитать итоговый Data Health Score. Инструмент: Таблица скоринга (см. ниже). Артефакт: Скоринговая карта с RAG-статусом по каждому измерению.

День 5 — Итоговый отчёт для руководства

Кто: IT-директор / руководитель проекта. Что делать: Оформить одностраничный executive summary. Зафиксировать вердикт, топ-3 блокера и рекомендуемые следующие шаги. Согласовать с бизнес-владельцем пилота. Инструмент: Шаблон отчёта (см. следующий раздел). Артефакт: Одностраничный отчёт «Готовность данных к ИИ-пилоту».

Итоговый скоринг: как считать Data Health Score

Каждое измерение оценивается по шкале 0–20 баллов (итого максимум 100 при шести измерениях, где ручные корректировки и глубина истории объединены в один блок).

• ≥ 80 баллов — данные готовы к пилоту. Можно стартовать с минимальными оговорками.
• 60–79 баллов — условная готовность. Пилот возможен на ограниченном наборе данных; параллельно ведётся чистка по выявленным блокерам.
• < 60 баллов — данные не готовы. Запуск пилота без предварительной чистки создаёт высокий риск получить уверенно неверный результат и дискредитировать ИИ-инициативу внутри компании.

Шаблон одностраничного отчёта для руководства

Этот шаблон заполняется по итогам Дня 5 и предназначен для презентации CIO, CDO или генеральному директору.

Отчёт: Готовность данных к ИИ-пилоту Дата: [дата] | Объект пилота: [описание] | Подготовил: [имя]

Итоговый Data Health Score: XX / 100

Вердикт: Готовы / Условно готовы / Не готовы к пилоту

Топ-3 блокера:

1. [Блокер и тип: completeness или quality]
2. [Блокер и тип]
3. [Блокер и тип]

Рекомендуемые следующие шаги:

• [Действие, ответственный, срок]
• [Действие, ответственный, срок]

Блок 152-ФЗ: что нельзя передавать в ИИ без обезличивания

Этот пункт часто игнорируют при планировании пилота — и он становится блокером уже после начала работ.

Требуют обезличивания до передачи в ИИ-контур:

• ФИО физических лиц (сотрудники, частные клиенты, контактные лица)
• ИНН физических лиц
• Паспортные данные
• Адреса проживания
• Номера телефонов и email сотрудников и физлиц

Не подпадают под 152-ФЗ, но требуют проверки договорной базы:

• ИНН и наименования юридических лиц
• Реквизиты организаций

Практическое правило: перед выгрузкой данных для пилота составьте список всех полей, которые передаются в ИИ-контур, и проверьте каждое поле на наличие персональных данных. Если ИИ-платформа — внешний сервис (облачный LLM), проверьте условия обработки данных в договоре с вендором.

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

Два сценария пилота: разные пороги для разных задач

Пороговые значения не универсальны — они зависят от задачи пилота. Вот три типичных сценария для российского B2B:

Прогнозирование спроса / управление запасами. Критичны: полнота кода номенклатуры и единицы измерения (≥ 98%), глубина истории ≥ 24 месяца, дубли номенклатуры < 1%. Свежесть менее критична — достаточно ≤ 7 дней.

Операционный ИИ-ассистент (чат-бот по заказам, статусам, остаткам). Критичны: свежесть данных ≤ 1 рабочего дня, консистентность регистров < 0,5%, незакрытые документы < 1%. Глубина истории менее важна.

RAG-система по базе знаний и документам. Критичны: полнота метаданных документов (дата, автор, тип), консистентность версий. Транзакционные данные могут не участвовать вовсе — но тогда аудит смещается на документарный корпус, а не на ERP.

Что делать, если данные не готовы

Вердикт «не готовы» — это не приговор проекту. Это план работ.

Разделите выявленные проблемы на два типа и оцените сроки:

Completeness (пустые поля, отсутствующие записи): 3 дня — 2 недели. Восстанавливается из первичных документов, справочников или путём проставления дефолтных значений с фиксацией в регламенте. Не требует изменения бизнес-процессов.

Quality (системная некорректность: неверные ИНН, перепутанные единицы, ручные корректировки как норма): 3–8 недель. Требует участия владельцев данных, изменения регламентов ввода, возможно — доработки конфигурации 1С для принудительной валидации. Без изменения процесса проблема вернётся.

Важно: не пытайтесь починить всё перед пилотом. Сузьте область пилота до тех объектов, где данные уже достаточно чисты — и запустите. Успешный пилот на чистом срезе данных убедительнее любого отчёта об аудите.

brezatech помогает командам пройти путь от аудита данных до работающего ИИ в производственном контуре — от профилирования 1С/ERP до интеграции LLM и BI.

Связанные материалы в блоге brezatech:

• BI как фундамент для ИИ: почему дашборд — это не конечная точка
• LLM в производственном контуре: что нужно проверить до запуска
• НСИ в 1С: как навести порядок в справочниках без остановки работы