Политика методологии анонимизации

Lexaris — lexaris.ru
Версия: 2026-03-19
Оператор: ИП Кудрявцев Степан Александрович, 324784700000012, 780252833730

Настоящий документ генерируется динамически на основании настроек, установленных Оператором в Панели управления Платформы. Значения, выделенные курсивом, являются текущими настройками и могут быть изменены Оператором в пределах, установленных законодательством.

---

Преамбула

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

Настоящая Политика разработана в соответствии с:

• Федеральным законом от 27.07.2006 № 152-ФЗ «О персональных данных»;
• Приказом Роскомнадзора от 05.09.2013 № 996 «Об утверждении требований и методов по обезличиванию персональных данных»;
• Методическими рекомендациями Роскомнадзора по обезличиванию персональных данных (2014);
• Международными стандартами ISO/IEC 29101, ISO/IEC 27701.

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

---

1. Принципы анонимизации

1.1. Основополагающие принципы

Система анонимизации Lexaris построена на следующих принципах:

1.1.1. Принцип обезличивания как конечной цели.
Платформа обрабатывает исходные (неанонимизированные) персональные данные с единственной целью — их замены на токены-заместители. Временная обработка PII является необходимым техническим условием для достижения обезличивания.

1.1.2. Принцип функциональной сохранности.
Анонимизация осуществляется таким образом, чтобы структура и смысл текста были сохранены. Токены-заместители семантически информативны (например, [ФИО_1], [ТЕЛЕФОН_3]).

1.1.3. Принцип полноты охвата.
Система применяет гибридный подход (многоуровневый конвейер) для максимально полного выявления персональных данных, минимизируя вероятность пропуска.

1.1.4. Принцип сессионной изоляции.
Таблица маппинга токенов существует в рамках ограниченной по времени сессии обработки (4ч / 24ч (настраивается Оператором) / бессрочно в рамках подписки) и уничтожается по её завершении.

1.1.5. Принцип обязательной верификации.
В соответствии со ст. 16 ФЗ-152 результаты автоматизированной анонимизации являются черновыми и подлежат обязательной проверке Пользователем перед использованием.

---

2. Типы обнаруживаемых сущностей (13 категорий)

2.1. Сводная таблица

2.2. Детализация по каждому типу

2.2.1. ФИО (тип 1)

Обнаруживаемые форматы:
- Полное ФИО: «Иванов Иван Иванович»;
- Фамилия с инициалами: «Иванов И.И.»;
- Имя + фамилия: «Иван Иванов»;
- Падежные формы: «Иванову Ивану Ивановичу», «Ивановым И.И.»;
- Сокращённые формы: «г-н Иванов», «гр. Иванова».

Методы: spaCy (ru_core_news_lg) распознаёт PER-сущности; Natasha обеспечивает корректную обработку падежных форм через морфологический анализ; Ollama (опционально) обнаруживает неявные упоминания.

Ограничения: Инициалы без фамилии (И.И.) не обнаруживаются без контекста. Односоставные имена (распространённые слова, совпадающие с именами) могут давать ложные срабатывания.

2.2.2. Паспортные данные (тип 2)

Обнаруживаемые форматы: «4510 123456», «45 10 123456», «серия 4510 номер 123456».

Метод: Regex с шаблоном серия (4 цифры) + номер (6 цифр). Контекстные подсказки: «паспорт», «серия», «номер», «выдан».

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

2.2.3. СНИЛС (тип 3)

Обнаруживаемые форматы: «123-456-789 01», «123 456 789 01».

Метод: Regex + валидация контрольного числа (алгоритм проверки двух контрольных цифр). Верификация контрольного числа практически исключает ложные срабатывания.

2.2.4. ИНН (тип 4)

Обнаруживаемые форматы: 10-значный (юридическое лицо), 12-значный (физическое лицо).

Метод: Regex + валидация контрольной цифры (алгоритм проверки последней цифры ИНН). Математическая верификация обеспечивает высочайшую точность.

2.2.5. Телефон (тип 5)

Обнаруживаемые форматы: «+7 (495) 123-45-67», «8-495-1234567», «89991234567», «+7 999 123 45 67».

Метод: Regex с поддержкой множественных форматов записи (с пробелами, дефисами, скобками).

2.2.6. Email (тип 6)

Метод: Regex (стандартный RFC 5322 шаблон). Высокая точность благодаря чёткой структуре формата.

2.2.7. Адрес (тип 7)

Обнаруживаемые форматы: Полные адреса (город, улица, дом, квартира), почтовые индексы, частичные адреса.

Методы: spaCy LOC + Natasha LOC + контекстные маркеры («ул.», «д.», «кв.», «г.», «обл.»).

Ограничения: Частичные адреса без контекстных маркеров (например, «Ленина, 5» без «ул.») могут быть пропущены. Адреса в свободной форме — наиболее сложный тип для обнаружения.

2.2.8. Дата рождения (тип 8)

Обнаруживаемые форматы: «01.01.1990», «1 января 1990 г.», «01/01/1990», «1990 года рождения».

Метод: Regex + контекстные маркеры («г.р.», «рождения», «дата рождения»). Без контекстных маркеров обычные даты не маркируются как даты рождения.

2.2.9. Банковские реквизиты (тип 9)

Обнаруживаемые данные: расчётные счета (20 цифр, начинаются с 3 или 4), БИК (9 цифр, начинается с 04), корреспондентские счета (20 цифр, начинается с 301).

Метод: Regex + структурная валидация.

2.2.10. Автомобильные номера (тип 10)

Обнаруживаемые форматы: «А123БВ 77», «А 123 БВ 777» (российский формат).

Метод: Regex с учётом допустимых букв (А, В, Е, К, М, Н, О, Р, С, Т, У, Х).

2.2.11. Медицинские данные (тип 11)

Обнаруживаемые данные: диагнозы (коды МКБ-10), номера полисов ОМС, результаты анализов с привязкой к персоне.

Методы: NER + контекстный анализ + Ollama (опционально). Наиболее сложный тип для обнаружения из-за разнообразия форматов.

Ограничения: Медицинская терминология без явной привязки к персоне может не быть распознана как PII. F1 ниже, чем для других типов (~75%).

2.2.12. Наименования организаций (тип 12)

Обнаруживаемые форматы: «ООО «Ромашка»», «ПАО Сбербанк», «ИП Иванов И.И.».

Методы: spaCy ORG + Natasha ORG + контекстные маркеры (ООО, ОАО, ПАО, ЗАО, ИП, АО).

Примечание: Государственные органы и суды (Арбитражный суд г. Москвы, ИФНС № 10) не анонимизируются как публичные институциональные субъекты.

2.2.13. Пользовательские сущности (тип 13)

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

---

3. Гибридный конвейер обнаружения

3.1. Архитектура конвейера

Система использует трёхуровневый гибридный конвейер последовательного и параллельного применения нескольких методов:

Документ
    |
    v
[OCR (если изображение/скан)]
    |— EasyOCR (основной)
    |— Tesseract (резервный)
    |
    v
[Уровень 1: Regex]
    |— Структурированные идентификаторы
    |— Валидация контрольных сумм (СНИЛС, ИНН)
    |
    v
[Уровень 2: NER-модели]
    |— spaCy (ru_core_news_lg / en_core_web_trf)
    |— Natasha (морфологический анализ)
    |
    v
[Уровень 3: Ollama LLM (опционально)]
    |— Расширенное обнаружение
    |— Неявные идентификаторы
    |
    v
[Ансамблевое объединение]
    |— Разрешение конфликтов
    |— Приоритезация
    |
    v
[Токенизация]
    |— Генерация токенов [ТИП_N]
    |— Формирование таблицы маппинга
    |
    v
Анонимизированный документ + Таблица маппинга

3.2. OCR-подконвейер (для изображений и сканов)

EasyOCR — основной инструмент оптического распознавания текста:

• Поддержка русского и английского языков;
• GPU-ускорение (при наличии);
• Лучшая производительность на печатном тексте стандартных шрифтов.

Tesseract — резервный инструмент:

• Используется при сбое EasyOCR или для перекрёстной верификации;
• Поддержка широкого спектра языков.

Ограничения OCR:

• Рукописный текст — не поддерживается. OCR не может надёжно распознавать рукописные записи. Документы с рукописными вставками (подписи, резолюции, заметки на полях) требуют ручной проверки;
• Низкое разрешение (менее 150 DPI) существенно снижает качество;
• Сложные макеты (таблицы, многоколоночный текст, фоновые изображения) могут приводить к ошибкам;
• Тексты на фоне градиента или с цветным фоном — повышенный уровень ошибок.

3.3. Ансамблевое объединение результатов

Результаты трёх уровней обнаружения объединяются по следующему алгоритму:

1. Все обнаруженные диапазоны символов (spans) с метками типа PII собираются в единый список;
2. Пересекающиеся диапазоны разрешаются в пользу более узкоспециализированного метода:
3. Для структурированных идентификаторов: Regex > NER > Ollama;
4. Для естественного языка (ФИО, адреса): Natasha > spaCy > Ollama > Regex;
5. Диапазоны с уровнем уверенности ниже порогового значения (0.65) включаются в результат с пометкой «низкая уверенность» для внимания Пользователя.

---

4. Формат токенизации

4.1. Схема токенов

Каждый обнаруженный уникальный идентификатор получает токен по схеме:

[ТИП_СУЩНОСТИ_N]

где:
- ТИП_СУЩНОСТИ — категория обнаруженных данных (из 13 типов);
- N — порядковый номер уникального значения данного типа в документе.

4.2. Примеры токенизации

Исходный текст:

Иванов Иван Иванович, паспорт серия 4510 номер 123456,
ИНН 771234567890, проживающий по адресу: г. Москва,
ул. Ленина, д. 10, кв. 5, телефон +7 (495) 123-45-67,
является сотрудником ООО «Ромашка».

Анонимизированный текст:

[ФИО_1], паспорт серия [ПАСПОРТ_1],
ИНН [ИНН_1], проживающий по адресу: [АДРЕС_1],
телефон [ТЕЛЕФОН_1],
является сотрудником [ОРГАНИЗАЦИЯ_1].

4.3. Консистентность

Одно и то же реальное значение всегда заменяется одним и тем же токеном во всём документе. Это сохраняет логическую связность текста: все упоминания «Иванов Иван Иванович» (включая «Иванову И.И.», «Ивановым») заменяются на [ФИО_1].

4.4. Таблица маппинга токенов

При токенизации формируется таблица маппинга:

{
  "[ФИО_1]": "Иванов Иван Иванович",
  "[ПАСПОРТ_1]": "4510 123456",
  "[ИНН_1]": "771234567890",
  "[АДРЕС_1]": "г. Москва, ул. Ленина, д. 10, кв. 5",
  "[ТЕЛЕФОН_1]": "+7 (495) 123-45-67",
  "[ОРГАНИЗАЦИЯ_1]": "ООО «Ромашка»"
}

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

---

5. Процедура деанонимизации

5.1. Последовательность

1. Запрос Пользователя: Пользователь инициирует деанонимизацию через интерфейс или API;
2. Проверка прав: Система проверяет, что запрашивающий Пользователь является владельцем сессии;
3. Проверка срока: Система проверяет, что сессия не истекла;
4. Обратная замена: Все токены в анонимизированном тексте заменяются соответствующими реальными значениями из таблицы маппинга;
5. Контроль полноты: Проверяется, что все токены заменены; незамещённые токены помечаются в интерфейсе;
6. Представление результата: Деанонимизированный текст отображается Пользователю.

5.2. Ограничения деанонимизации

• Деанонимизация возможна только в пределах срока действия сессии. После истечения TTL таблица маппинга удаляется, и деанонимизация становится невозможной;
• Если Пользователь экспортировал таблицу маппинга, он может выполнить деанонимизацию самостоятельно за пределами Платформы;
• Если токен был изменён Пользователем в анонимизированном тексте (ручное редактирование), автоматическая деанонимизация этого токена не сработает.

---

6. Безопасность таблицы маппинга токенов

6.1. Хранение

• Таблицы маппинга хранятся в Redis с TTL (автоматическое удаление по истечении срока сессии);
• Данные зашифрованы при хранении;
• Доступ к маппингу — только через аутентифицированный API Пользователя-владельца;
• Административного доступа к содержимому маппинга нет.

6.2. Журналирование

Все операции с маппингом журналируются (создание, доступ, экспорт, деанонимизация, удаление) без записи содержимого маппинга в журнал.

6.3. Экспорт

Пользователь может экспортировать таблицу маппинга для локального хранения. После экспорта ответственность за безопасность экспортированных данных несёт Пользователь.

---

7. Метрики точности и известные ограничения

7.1. Сводные метрики

Метрики являются ориентировочными, измерены на тестовых наборах юридических документов на русском языке.

7.2. Риск ложных отрицательных (пропущенные PII)

Пропуск PII — наиболее критичный риск. Основные причины пропуска:

• Нестандартные форматы: PII, записанные в нетипичном формате (транслитерация, аббревиатуры, жаргон);
• Контекстная зависимость: Данные, являющиеся PII только в определённом контексте (например, «5 лет» — не PII, но «5 лет, назначенных Петрову» — содержит PII);
• Многоязычные документы: Документы, сочетающие русский, английский и другие языки — частичная поддержка;
• Рукописный текст: Не поддерживается OCR, PII в рукописных вставках не обнаруживаются;
• Косвенные идентификаторы: Комбинация неуникальных данных (возраст + профессия + район), позволяющая идентифицировать лицо, как правило, не обнаруживается;
• Данные в изображениях внутри документов: Текст на фотографиях, вложенных в PDF, может быть пропущен, если OCR не активирован или изображение низкого качества.

7.3. Пользовательские правила обнаружения

Для компенсации ограничений стандартного конвейера Пользователь может определить:

• Собственные regex-шаблоны для специфических идентификаторов (внутренние номера, коды проектов);
• Списки ключевых слов, требующих анонимизации;
• Правила исключения (false positive whitelist) для данных, ошибочно помечаемых как PII.

7.4. Языковая поддержка

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

---

8. Соответствие стандартам обезличивания

8.1. Приказ Роскомнадзора № 996

Применяемые методы анонимизации соответствуют методам обезличивания, определённым в Приказе Роскомнадзора от 05.09.2013 № 996:

• Введение идентификаторов — замена прямых идентификаторов на токены-заместители [ТИП_N];
• Изменение состава или семантики — удаление или обобщение части данных.

8.2. Классификация обезличенных данных

В соответствии со ст. 3 ФЗ-152, данные, прошедшие конвейер анонимизации Lexaris, квалифицируются как обезличенные данные при условии, что:

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

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

8.3. Аудит

Оператор проводит периодические технические аудиты конвейера анонимизации (не реже 1 раза в квартал):

• тестирование на синтетических документах с заведомо известными PII;
• измерение Recall и Precision;
• целевые показатели: Recall >= 0.90, Precision >= 0.88;
• при отклонении — обновление конвейера.

---

9. Обновление Политики

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

---

Настраиваемые параметры

Следующие параметры настраиваются Оператором в Панели управления Платформы. Указанные ниже значения являются значениями по умолчанию.

Все параметры настраиваются в: Панель управления → Настройки → Сроки хранения

---

10. Контактная информация

По вопросам методологии анонимизации:

• Техническая поддержка: info@lexaris.ru
• Общие вопросы: info@lexaris.ru

ИП Кудрявцев Степан Александрович
Россия, Санкт-Петербург
ОГРН 324784700000012 | ИНН 780252833730

Политика вступает в силу с 2026-03-19