Как подготовить данные компании к внедрению AI

Чтобы подготовить данные компании к внедрению AI, не нужно сначала собирать всё в одно хранилище. Нужно определить конкретное решение, которое должна поддержать система, найти источники нужных фактов, назначить владельца каждого набора, зафиксировать обязательные поля и допустимое качество, устранить критичные дубли, классифицировать чувствительные данные и выдать AI только минимально необходимый доступ. Результат подготовки — не «чистая база вообще», а проверяемый контур данных для одного бизнес-процесса.

Эта статья отвечает именно за готовность данных до пилота. Здесь не разбирается построение корпоративной базы знаний, настройка прав в документообороте или техническая выдача доступа AI к CRM — для этих задач предусмотрены отдельные материалы. Цель — получить data readiness package, по которому можно обоснованно решить: запускать пилот, сузить сценарий или сначала исправить источники.

Что должно быть готово до подключения модели

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

• описание бизнес-задачи и действия, которое AI должен предложить или выполнить;
• реестр источников с владельцами, назначением, периодом обновления и классом чувствительности;
• словарь ключевых сущностей: клиент, заявка, договор, товар, обращение, платёж;
• data contract с обязательными полями, форматами, допустимыми значениями и правилами свежести;
• правила идентификации и объединения дублей;
• матрица доступа: кто и какой компонент может читать, изменять и экспортировать;
• набор контрольных примеров, включая ошибки, исключения и пограничные случаи;
• метрики допуска к пилоту и безопасный сценарий при нехватке или конфликте данных.

Это не бюрократия. Такой пакет отделяет подтверждённые факты от предположений и не позволяет скрыть проблему качества за красивым демо. Если вы ещё не определили сам процесс, начните с материала о том, как найти узкие места до автоматизации.

Начните с решения, а не с выгрузки всех данных

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

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

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

Где лежат данные: соберите реестр источников

Реестр источников — это не перечень названий систем. Для каждого набора нужен операционный паспорт: система и объект, бизнес-владелец, технический ответственный, способ получения, частота обновления, историческая глубина, критичные поля, известные дефекты, класс чувствительности и разрешённая цель использования.

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

Кто отвечает за качество данных

Фраза «за данные отвечает IT» почти всегда создаёт разрыв ответственности. IT поддерживает хранение, интеграции и доступность, но не может самостоятельно определить, верно ли указан этап сделки, причина отказа или категория документа. За смысл отвечает владелец бизнес-домена; за правила качества — назначенный data steward; за техническое исполнение — инженер или владелец системы; за допустимость обработки чувствительных данных — безопасность и профильные специалисты.

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

Какие поля обязательны: сформируйте data contract

Data contract фиксирует ожидания между источником и потребителем данных. Для AI-процесса он должен описывать не только тип столбца, но и его бизнес-смысл. Поле «дата» без уточнения может означать создание, оплату, отгрузку или последнее изменение. Поле «клиент» может хранить юридическое лицо, контакт или группу связанных организаций.

Для каждого входа зафиксируйте:

• машинное имя и понятное бизнес-определение;
• тип, формат, единицу измерения и допустимые значения;
• обязательность для конкретного решения, а не для всей системы;
• источник истины и правило при конфликте источников;
• максимальный возраст значения;
• допустимость пустого значения и поведение при его отсутствии;
• класс чувствительности и разрешённые цели использования;
• версию схемы и порядок обратной совместимости.

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

Как убрать дубли и не склеить разных клиентов

Дедупликация начинается с определения сущности. Две строки могут быть дублями контакта, но не дублями обращения: один человек вправе создать несколько заявок. Поэтому сначала выбирают уровень объединения — клиент, организация, документ, товар или событие — и только затем сравнивают признаки.

Безопасная схема состоит из четырёх уровней:

1. Нормализация. Единый регистр, формат телефона, адреса, даты и идентификатора.
2. Точное совпадение. Подтверждённый ID, номер договора или другая устойчивая связка.
3. Вероятностное совпадение. Сочетание имени, домена, телефона, адреса и контекста.
4. Ручная очередь. Пары в серой зоне не объединяются автоматически.

Перед объединением определите survivorship rules: какое значение сохраняется, откуда берётся актуальный адрес, как хранится происхождение каждого атрибута и можно ли отменить склейку. Потеря provenance превращает «очищенную» карточку в необъяснимую смесь источников.

Права доступа: AI не должен видеть всё, что видит интеграция

У сервисного аккаунта, коннектора, поискового индекса и модели разные роли. Доступ надо задавать по принципу минимальной необходимости: только нужные объекты, поля, операции и период. Если сценарий классифицирует обращения, ему не нужны реквизиты оплаты, медицинские сведения или полный архив кадровых документов.

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

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

Что нельзя передавать модели без отдельного решения

Запрет определяется не форматом, а содержанием, целью и договорными условиями. До подключения внешнего AI-сервиса выделите категории, требующие отдельного согласования или исключения:

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

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

Архитектура контура данных для AI

Надёжная архитектура не копирует все данные в модель. Она отделяет источники, подготовку, контекст и действие:

1. Источники. CRM, ERP, документы, переписка и справочники остаются системами истины.
2. Слой получения. Коннекторы читают изменения с техническими идентификаторами и временем.
3. Проверка и нормализация. Схема, обязательность, форматы, справочники и дубли контролируются до AI.
4. Классификация и политики. Чувствительность, цель, срок и права определяют допустимый маршрут.
5. Контекстный слой. В модель передаётся минимальный, актуальный и разрешённый фрагмент.
6. Решение и подтверждение. Результат проходит правила, пороги уверенности и, при необходимости, человека.
7. Журнал. Сохраняются версии входа, политики, модели, результата и действия.

Разделяйте сырой, нормализованный и опубликованный слой. Исправление преобразования не должно уничтожать исходник; изменение записи в источнике должно быть отслеживаемым; каждое решение должно воспроизводиться по версии данных. Такая схема помогает понять, где возникла ошибка: в источнике, преобразовании, извлечении контекста, модели или бизнес-правиле.

Как измерить готовность данных к пилоту

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

• полнота — доля записей с обязательными значениями;
• валидность — соответствие формату, диапазону и справочнику;
• уникальность — доля сущностей без необъяснённых дублей;
• согласованность — отсутствие конфликтов между системами;
• свежесть — доля данных, обновлённых в допустимый срок;
• точность — совпадение с проверенным фактом на контрольной выборке;
• покрытие доступа — доля записей с корректной классификацией и политикой;
• происхождение — доля значений, для которых известны источник и преобразования.

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

Расчётный пример: данные для AI-маршрутизации заявок

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

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

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

Типичные ошибки подготовки

• Собирать всё заранее. Растёт стоимость, поверхность риска и количество неоднозначных полей.
• Считать очистку разовым проектом. Источники меняются, поэтому правила должны работать постоянно.
• Удалять дубли без обратимости. Ошибочная склейка портит историю и отношения между сущностями.
• Оценивать качество без контекста решения. Формально заполненное поле может быть неверным или устаревшим.
• Давать модели прямой широкий доступ. Контроль должен срабатывать до формирования запроса.
• Не хранить lineage. Без происхождения невозможно объяснить и исправить результат.
• Тестировать только хорошие записи. Пилот должен включать пропуски, конфликты, неверные форматы и запрещённые данные.

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

Пошаговый план подготовки данных

1. Опишите одно решение AI, границы автономности и последствия ошибки.
2. Составьте карту необходимых фактов и реестр источников.
3. Назначьте владельцев сущностей, наборов и критичных полей.
4. Соберите словарь терминов и data contract первой версии.
5. Проведите профилирование: пропуски, форматы, распределения, свежесть и дубли.
6. Определите правила нормализации, объединения и обратимости.
7. Классифицируйте чувствительность и сократите контекст до минимально нужного.
8. Настройте версии, lineage, журнал доступа и карантин дефектов.
9. Соберите контрольную выборку с нормальными и пограничными примерами.
10. Зафиксируйте пороги допуска и только после этого подключайте модель.

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

Частые вопросы

Нужно ли создавать единое хранилище до пилота AI?

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

Можно ли начать с Excel и ручных выгрузок?

Для исследования — да, если известны владелец, версия, период и происхождение. Для production ручная выгрузка обычно не обеспечивает свежесть, повторяемость, контроль доступа и журналирование.

Как понять, что качество уже достаточно?

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

Нужно ли удалять все дубли?

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

Кто должен утверждать обязательные поля?

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

Можно ли отправлять персональные данные во внешнюю модель?

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

Чем маскирование отличается от удаления?

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

Что делать, если источники противоречат друг другу?

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