Обезличивание — обработка, после которой определить, к какому человеку относятся сведения, невозможно без дополнительной информации. В ИИ-проектах это основной способ пользоваться внешней моделью, не вынося за периметр то, что выносить нельзя.
Термин покрывает приёмы разной обратимости, и их стоит различать. Маскирование — замена чувствительных значений метками или символами. Псевдонимизация — замена, сохраняющая возможность обратной подстановки при наличии ключа. Агрегация — переход к диапазонам и сводным значениям, после которого точное значение не восстанавливается вовсе. По общему правилу псевдонимизированные данные не перестают быть персональными, а вот где проходит граница для вашей задачи — требует оценки юриста; техника выбора приёма от этого решения зависит напрямую.
Способы
Удаление. Поля просто вырезаются. Надёжно, но иногда ломает смысл: без имени обращение «перезвоните Ивану Петровичу» становится непонятным.
Замена на метки. Имя заменяется на [ИМЯ_1], телефон на [ТЕЛЕФОН_1]. Структура сохраняется, модель понимает, что речь об одном и том же человеке, а обратная подстановка выполняется после ответа.
Замена на правдоподобные значения. Настоящее имя меняется на вымышленное. Полезно, когда важна естественность текста, но требует внимания: подстановка не должна случайно совпасть с реальным человеком.
Обобщение. Точный возраст заменяется диапазоном, адрес — городом. Применяется там, где точность не нужна для задачи.
Способы комбинируются: в одном тексте ФИО маскируется меткой, дата рождения обобщается до года, а телефон удаляется — выбор зависит от того, что реально нужно модели для задачи.
Слои применяются в фиксированном порядке: сначала словари и регулярные выражения, затем модель распознавания на остаток, затем контрольная выборочная проверка. Так каждый слой видит только то, что не взяли предыдущие, и качество конвейера измеримо по остатку на выходе.
Как это устроено технически
Распознавание персональных данных собирают из трёх слоёв. Словари и справочники — списки сотрудников, клиентов, известных адресов: точны, но покрывают только известное заранее. Регулярные выражения — телефоны, номера карт, email: хорошо работают на форматах, плохо — на вольном тексте. Модель распознавания сущностей — ловит имена и адреса в свободном тексте, но ошибается на редких фамилиях и границах. Для русского языка слои особенно важны вместе: фамилии склоняются, адреса пишут без стандарта, а названия компаний путаются с фамилиями.
Стабильность меток — отдельное требование: один человек внутри одного обращения должен иметь одну метку, иначе модель теряет связность, а обратная подстановка ломается.
Где обычно ошибаются
Чистят структурированные поля и забывают свободный текст. Самая частая ошибка. Поля «имя» и «телефон» вычищены, а в комментарии менеджера, теле письма и расшифровке звонка всё осталось.
Не учитывают косвенные признаки. Должность в маленькой компании, редкая модель автомобиля, точная дата и место — вместе они идентифицируют человека не хуже фамилии.
Забывают про журналы. Данные обезличены на входе в модель, но исходный текст записан в лог приложения.
Хранят таблицу соответствия рядом. Если ключ обратной подстановки лежит в той же системе с тем же доступом, обезличивание условно.
Что подходит для промптов, а что для обучения
Потоковые промпты. Маскирование метками с обратной подстановкой в рамках одного обращения: добавляет единицы–десятки миллисекунд на распознавание, сохраняет структуру диалога. Ключ соответствия в этом режиме живёт в памяти запроса и после ответа уничтожается.
Обучение и дообучение. Здесь выбор другой: датасет живёт долго и копируется, поэтому псевдонимизация с хранимым ключом опасна — утечка датасета вместе с ключом возвращает все данные. Практика — правдоподобные подстановки и агрегация без ключа. Метки вида [ИМЯ_1] при дообучении вредны ещё и тем, что модель учится воспроизводить их в ответах.
Индексация для поиска. Компромисс описан ниже в разделе о нарезке: либо поиск без имён, либо индекс с персональными данными.
Как проверять качество
Автоматическое распознавание персональных данных ошибается, особенно на русском: пропускает редкие имена, не видит адреса в вольной форме, путает названия компаний с фамилиями.
Рабочая проверка — выборочный ручной просмотр обезличенных текстов, не менее сотни, с подсчётом пропусков. Считать надо не «сколько нашли», а «сколько пропустили»: именно пропуски создают риск. Для чувствительных сценариев долю пропусков целевого уровня не назначают — её стремятся привести к нулю ручным контролем, потому что один пропуск в таком контексте уже инцидент.
Проверку стоит повторять при изменении источника данных: новый канал приносит новые форматы, и настроенное распознавание перестаёт справляться.
Связь с режимом персональных данных
Рамочно: общие требования к обработке персональных данных задаёт 152-ФЗ, и обезличивание — один из предусмотренных законом способов снижения рисков. По общему правилу обезличенные данные выводятся из-под части требований к обработке, а псевдонимизированные — нет, потому что связка с человеком восстанавливается по ключу. Где именно проходит граница для вашей схемы — зависит от состава данных и способа обратной подстановки, и это решение фиксируют с юристом.
Инженерный практицизм тот же: чем меньше обратимость, тем проще режим. Агрегация и правдоподобные подстановки без ключа спрашивают меньше, чем метки с таблицей соответствия, — и это стоит учитывать при выборе техники, а не только при разборе юридических последствий. Подробно про режим персональных данных в ИИ — в отдельной карточке.
Ограничение подхода
Полного обезличивания в свободном тексте достичь трудно. Чем богаче контекст, тем выше шанс, что человек определяется по совокупности деталей. Критерий осмысленности: каждая запись после чистки должна совпадать по оставшимся признакам с несколькими другими людьми — если по сочетанию должности, даты и города находится единственный кандидат, формальная чистка полей не спасла.
Поэтому для чувствительных данных обезличивание разумно сочетать с локальной моделью, а не рассматривать как замену ей.
Обратная подстановка
Схема с метками требует решения о том, где хранится соответствие «метка — настоящее значение». Практика такая: соответствие живёт в памяти в рамках одного обращения и не записывается в постоянное хранилище.
Если сохранять его надолго, обезличивание превращается в псевдонимизацию: данные формально разделены, но связываются обратно любым, кто имеет доступ к обеим частям. Это другой уровень защиты, и относиться к нему надо соответственно.
Что учесть при нарезке и индексации
Если обезличивание выполняется до индексации, вектор строится по обезличенному тексту — и поиск по имени клиента работать не будет. Это может быть и требованием, и неожиданностью, поэтому решение принимается осознанно.
Обратный порядок — индексировать исходный текст, а обезличивать перед передачей модели — сохраняет поиск, но оставляет персональные данные в индексе со всеми вытекающими требованиями к его размещению.
Частые вопросы
Достаточно ли убрать имя и телефон?
Нет. Человек определяется и по совокупности косвенных признаков: должность в небольшой компании, дата и место события, детали заказа. Обезличивание оценивается не по списку удалённых полей, а по тому, можно ли восстановить личность по оставшемуся тексту.
Что чаще всего пропускают?
Свободный текст: комментарии менеджеров, тело писем, расшифровки звонков. Структурированные поля обычно чистят, а данные остаются именно там. Второе по частоте — журналы приложения, куда исходный текст пишется до обезличивания.
Можно ли доверять автоматическому распознаванию?
Как основному инструменту — да, как единственному — нет. На русском тексте оно пропускает редкие имена и адреса в вольной форме. Нужна выборочная ручная проверка с подсчётом именно пропусков, а не найденного.
Влияет ли обезличивание на качество ответов?
На классификацию и суммаризацию — как правило, незначительно: метки сохраняют структуру связей в тексте. Заметнее эффект там, где само значение несёт смысл: генерация обращений по имени, задачи с датами и возрастом. Проверяется замером на своих данных до и после, на одном и том же наборе.
Какие значения считать персональными, а какие нет?
Ориентир: всё, что само по себе или в связке идентифицирует человека, — ФИО, телефон, email, номер документа, а в ряде сценариев и комбинация должности с городом и датой. Итоговый перечень для вашей системы фиксируют совместно с юристом, и он становится частью регламента, а не решением инженера в моменте.