· LLAIM

Программы для обезличивания документов: какие бывают и как выбрать

Время чтения: около 8 мин

Что вы узнаете:

  • разница между обезличиванием по 152-ФЗ и заменой данных на метки
  • три класса программ и таблица выбора по типу документов
  • как измерить, что обезличивание сработало
  • список типичных ошибок

Коротко: есть ли программы и что выбрать

Да, программы для обезличивания есть: открытые библиотеки и собственные решения под конкретные задачи. Технически они работают одним из трёх способов: ищут данные по правилам и шаблонам, находят их обученной моделью NER - распознаванием именованных сущностей - или дают человеку размечать текст вручную. На практике для договоров и писем обычно сочетают первые два подхода и добавляют проверку человеком.

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

Материал не заменяет консультацию юриста. Ссылки на нормы сверены 22 сентября 2026 года по справочным правовым системам; полный текст приложений приказа автором не изучался. Перед применением сверьте их с актуальным текстом и проконсультируйтесь со своим юристом.

Что такое обезличивание по закону и что делает программа

По 152-ФЗ (ст. 3) обезличивание - это действия, после которых без дополнительной информации нельзя определить, кому принадлежат персональные данные. Подробнее о связи этого вопроса со схемами работы с нейросетью мы рассказали в статье «Работа с нейросетью и 152-ФЗ». Здесь не повторяем эти абзацы.

Для выбора программы важно различать две вещи.

  • Обезличивание в смысле закона. Это процедура оператора со своими требованиями. С 1 сентября 2025 года действует приказ Роскомнадзора от 19.06.2025 N 140, который утверждает требования к обезличиванию и методы обезличивания. По обзорам, он заменил прежний приказ N 996 от 2013 года. Конкретные требования и методы читайте в самом тексте приказа. Применим ли он к вашему сценарию, нужно уточнить у юриста: мы этого не утверждаем.
  • Техническая маскировка текста. Программа находит фамилию, телефон или ИНН и заменяет их меткой вроде «Сторона 1». По позиции автора, если таблица соответствия остаётся у оператора, это скорее псевдонимизация: данные остаются у оператора, а внешний сервис получает текст без них. Это не норма закона.

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

Три подхода и что они находят

Ниже - практический ориентир, а не универсальное описание возможностей каждой программы.

ПодходКак работаетЧто обычно находит хорошоЧто может пропуститьКак меняется цена ошибки
Правила и шаблоны (регулярные выражения, контрольные суммы)Ищет строки заданного видаИНН, ОГРН, телефоны, e-mailИмена, названия организаций, адреса в свободной формеФормат известен, правило можно дополнить
Модель NERМодель размечает имена, места и организации по контекстуФИО, названия компаний, топонимы в связном текстеРедкие имена, склонения и опечатки, косвенные признаки человекаОшибку можно не заметить без проверки
Ручная разметкаЧеловек выделяет и заменяет данные в редактореТо, что человек заметил, включая контекстОшибки внимания на больших объёмахЗависит от объёма и исполнителя

Разберём каждый подход.

Правила и шаблоны

Правило описывает формат: например, ИНН - это цифры заданной длины, а e-mail содержит «@». Плюсы - предсказуемость, скорость и понятное объяснение для аудита. Минусы - правило не понимает контекст, поэтому «Иванов» без дополнительных признаков оно не найдёт. Шаблон может быть и слишком широким: тогда программа замаскирует безобидное число.

У Presidio среди заявленных методов есть регулярные выражения, правила и проверка контрольных сумм - это как раз класс правил. Поддержку русского языка и нужных типов документов проверьте отдельно в текущей документации.

Модель NER

NER ищет имена людей, организации и места по контексту. Для русского языка есть открытая библиотека Natasha с лицензией MIT. Она выполняет токенизацию, морфологический анализ, извлечение фактов и NER-разметку персон, мест и организаций. Библиотека рассчитана прежде всего на новостные тексты и работает на центральном процессоре, поэтому качество на договорах и внутренних письмах нужно измерять на своих данных.

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

Ручная разметка

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

Как выбрать подход

Выбор зависит от четырёх вопросов.

  1. Какие данные в документах? Если это в основном реквизиты и контакты, начните с правил. Если много имён и названий в свободном тексте, добавьте модель.
  2. Сколько документов? Единичные документы можно размечать вручную с проверкой. Регулярный поток лучше обрабатывать автоматически и дополнять выборочным контролем.
  3. Куда уйдёт результат? Если документ передаётся во внешний сервис, заранее определите, какие данные нельзя отправлять, где будет выполняться обработка и где хранится таблица соответствия. Это практический совет, а не вывод о юридическом режиме конкретного сервиса.
  4. Что произойдёт при пропуске? Утечка фамилии в рабочем письме и передача паспортных данных сотрудника - разные по последствиям ситуации. Чем выше цена ошибки, тем тщательнее нужна проверка человеком.

Готовое решение или своя сборка? Открытые библиотеки дают детали конструктора, но подключать их, дописывать правила и измерять качество придётся вам. Готовое решение под ваш процесс может сэкономить эту работу, но его всё равно нужно проверять.

Перед выбором спросите разработчика или поставщика:

  • где выполняется обработка - на вашем сервере или у поставщика;
  • какие типы данных программа находит из коробки;
  • как добавить собственные типы;
  • как хранится таблица соответствия;
  • есть ли журнал замен для аудита;
  • как поставщик предлагает измерять полноту на ваших документах.

Ответ «находит всё» - повод усомниться.

Пример: как это устроено в проекте LLAIM

В проекте по проверке договоров с контрагентами слой анонимизации убирает из текста названия организаций, ФИО, ИНН, ОГРН, КПП, адреса, e-mail, телефоны и банковские реквизиты. Используются регулярные выражения и локальная NER-модель - то есть сочетание первых двух подходов. Во внешний контур уходит текст с условными метками, а результат восстанавливается на стороне заказчика.

По данным проекта, конвейер из 9 ИИ-агентов проверяет договор аренды по чек-листу на 100+ страниц: время сократилось с 4-5 часов до примерно 10 минут, а персональных данных во внешний ИИ передано 0 (метрика проекта, а не общая гарантия). На странице обезличивания документов для ИИ указано, что метки существуют в памяти на время запроса и не сохраняются на диск.

Это результат конкретного проекта на конкретных договорах. Для ваших документов качество нужно измерять заново.

Как проверить результат

Проверка нужна до запуска и периодически после него. Практическая схема:

  1. Соберите небольшую выборку реальных документов вашего типа или их копий, с которыми вы вправе работать внутри компании.
  2. Пусть человек выпишет всё, что должно быть скрыто. Это будет эталонная разметка.
  3. Прогоните документы через программу и сравните результаты. Посчитайте полноту - долю найденных данных из эталона - и точность - долю замен, которые действительно были нужны.
  4. Разберите каждый пропуск: к какому типу он относится и почему программа его не нашла. После этого дополните правила или измените модель.
  5. Отдельно ищите остатки в выходном файле: в колонтитулах, сносках, примечаниях, свойствах файла, подписях на сканах и названиях файлов.
  6. Проверьте косвенные признаки. Должность вместе с датой и городом может указывать на одного человека, даже если имя удалено.
  7. Убедитесь, что таблица соответствия хранится отдельно и доступ к ней ограничен.
  8. Повторяйте проверку на новой выборке при изменении формата документов.

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

Типичные ошибки

  • Остались склонения и падежи. «Иванова», «Иванову» и «Ивановым» правило и модель могут обработать по-разному.
  • Не проверены колонтитулы, таблицы и метаданные. Данные находятся не только в основном тексте.
  • Замена слишком очевидна. Метка «Директор ООО Ромашка-2» остаётся узнаваемой, если название компании уникально и встречается ещё раз в документе.
  • Скан не распознан. Программа, работающая только с текстом, не видит подпись и печать на изображении.
  • Таблица соответствия лежит рядом с обезличенным файлом. Это повышает риск повторно связать метки с исходными данными.
  • Проверка была только один раз. Новый шаблон договора может содержать новые типы данных.
  • Смешаны разные задачи. Текст закрыли метками и решили, что все требования закона выполнены. Это разные вещи.

Когда это может не подойти

  • Специальные категории данных, например сведения о здоровье или биометрические данные. Как практический совет, такой сценарий стоит отдельно обсудить с юристом.
  • Государственные информационные системы и отраслевые требования. Для них могут действовать дополнительные правила; в этой статье мы их не разбираем.
  • Документы, смысл которых держится на личности, например личное дело или переписка с конкретным человеком. Маскировка убирает полезный контекст, а косвенных признаков может остаться много.
  • Единичные документы. В таком случае может быть проще и надёжнее заменить данные вручную, чем настраивать программу.

Если нужно встроить обезличивание в процесс проверки документов, оставьте заявку: обсудим задачу.

Источники

  • Федеральный закон от 27.07.2006 N 152-ФЗ «О персональных данных», ст. 3 и 6: справочные правовые системы
  • Приказ Роскомнадзора от 19.06.2025 N 140 «Об утверждении требований к обезличиванию персональных данных и методов обезличивания персональных данных…»: заголовок и реквизиты по КонсультантПлюс, Гарант, РГ; обзоры Контур.Норматив и ppt.ru (полный текст приложений автором не изучался)
  • Microsoft Presidio: страница проекта presidio.dataprivacystack.org
  • Natasha: репозиторий natasha/natasha на GitHub
  • Проект «Обезличенная проверка договоров с контрагентами» и решение «Обезличивание документов»: сайт llaim.ru

Решение LLAIM: Обезличивание документов для AI →

обсудим ваш проект

Напишите нам в Telegram

Расскажите о задаче в свободной форме — ответим в течение рабочего дня и предложим варианты автоматизации.

Написать в Telegram

hello@llaim.ru · +7 (993) 920-44-68

или оставьте заявку — перезвоним сами