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

Где живут данные и кто к ним прикасается

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

Второй вопрос – кто имеет доступ к сырым данным на каждом этапе. В закрытом контуре подготовка датасета сама по себе становится объектом защиты. Все операции выполняются на инфраструктуре заказчика или в аттестованном сегменте, разметчики работают через тонкий клиент без права выгрузки, а каждое обращение к исходным таблицам логируется. После того как требования ФСТЭК по приказу №117 вступили в силу, такой контроль доступа к данным для ИИ перестал быть опцией – это базовое требование к значимым объектам и ГИС.

Обезличивание без потери смысла

Обучать модель на персональных данных в открытом виде нельзя, но грубое удаление колонок убивает полезный сигнал. Нужна аккуратная деперсонализация: ФИО, телефоны, паспорта, адреса заменяем на стабильные псевдонимы, чтобы связи между записями сохранились, а реальное лицо не восстанавливалось. Для свободного текста – обращений, переписки, актов – применяем NER-модели, которые находят и маскируют чувствительные сущности прямо в потоке, и обязательно прогоняем ручную проверку на выборке: автоматика пропускает редкие форматы.

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

Версионирование и воспроизводимость

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

Когда датасеты питают не статичную модель, а агентов, которые сами обращаются к данным в продакшене, контроль усложняется. Подходы к наблюдаемости и управлению такими системами мы описывали в материале про практики AgentOps – версионирование данных там становится частью общего контура эксплуатации.

Вывод

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