Как обезличить данные перед загрузкой в ИИ и не потерять смысл задачи

Решите, какие данные нужны для проверки

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

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

Как сохранить полезность набора

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

Проверка перед передачей модели

Просканируйте набор на оставшиеся контакты, имена в вложениях, метаданные документов и скрытые листы таблиц. Затем выборочно посмотрите примеры вручную. NIST Generative AI Profile помогает рассматривать риски применения в контексте; для пилота это означает использовать минимально необходимые данные, а не отправлять весь архив ради удобства.

Сохраняйте связь между объектами

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

Проверьте остаточный риск

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

Проверка полезности после замены

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

Не переносите в тест реальные тайны под новым именем

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

Кто утверждает готовность набора

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