Проблема множества форматов при соблюдении требований о защите данных
Обновлено для 2026 года
Спросите сотрудника по соответствию требованиям, какие форматы они обезличивают для ответов на DSAR. Список всегда один и тот же: договоры Word, счета-фактуры PDF, клиентские данные Excel, экспорты CSV и журналы JSON.
Затем спросите, какие инструменты они используют. Как правило, ответ — от трёх до пяти. У каждого инструмента разный охват сущностей. Разные настройки. Разный журнал аудита.
Это и есть фрагментация форматов. Она создаёт реальные пробелы в соответствии требованиям.
Почему возникает фрагментация
Ни один инструмент не обеспечивал одинаково высокое качество обработки всех производственных форматов. Для каждого формата появились специализированные инструменты. Один для PDF, один для таблиц, макрос для CSV. У каждого свой список сущностей. Ни у одного нет общего журнала аудита.
Результат предсказуем. Ответ на DSAR охватывает несколько типов файлов. Их обрабатывают разные инструменты с разными стандартами. Сущность X обнаруживается в PDF, но не замечается в Excel. Проверки регуляторов выявляют эту непоследовательность.
Технические сложности, специфичные для каждого формата
Каждый формат создаёт собственные проблемы обнаружения.
PDF бывают двух типов: с нативным текстом и на основе отсканированных изображений. Отсканированные PDF требуют предварительного OCR, который вносит ошибки. В нативных PDF каждое слово нередко хранится как отдельный текстовый объект — это нарушает обнаружение сущностей на границах слов. Многоколоночные макеты требуют восстановления порядка чтения перед анализом.
Word (DOCX)
Файлы DOCX хранят текст в XML, но также в верхних и нижних колонтитулах, комментариях, отслеживаемых изменениях и текстовых полях. Адрес на бланке в заголовке страницы — это персональные данные. Большинство инструментов его пропускает. В отслеживаемых изменениях могут содержаться удалённые ПДн — такой текст невидим в отображаемом виде, но присутствует в файле.
Excel (XLSX)
Excel хранит ПДн в любой ячейке среди сотен столбцов и тысяч строк. Заголовки столбцов вроде «ИНН» или «Email» дают контекст, который модели NER пропускают при анализе сырого текста. Даты и номера социального страхования часто хранятся как числа. Поля свободного текста, например «Заметки менеджера», содержат неструктурированные ПДн, которые пропускают инструменты, ориентированные на столбцы.
CSV
CSV лишён структуры Excel. Поля свободного текста в столбцах «Примечания» смешивают ПДн с другим содержимым. Проблемы кодировки — UTF-8 против Latin-1 — вызывают сбои для символов не ASCII в европейских именах и адресах.
JSON
Вложенный JSON прячет ПДн глубоко: user.address.street.line1. Массивы требуют итерации. Одно и то же имя поля может содержать разные типы данных в разных объектах. Качественное обнаружение требует одновременного анализа схемы и содержимого.
Непоследовательность — это правовой риск
Рассмотрим конкретный сценарий с DSAR по GDPR.
Субъект данных запрашивает все хранящиеся о нём персональные данные. Отдел по соответствию требованиям находит следующие файлы:
- 3 документа Word (договоры, переписка)
- 2 документа PDF (счета-фактуры, записи поддержки)
- 1 таблица Excel (данные клиентского аккаунта)
- 1 экспорт CSV (журналы доступа к системе)
Для PDF используется Инструмент А, для Word — Инструмент Б, для XLSX — макрос, для CSV — ручная проверка. У каждого инструмента разный охват сущностей.
Субъект данных получает обезличенный пакет. Столбец «Заметки менеджера» в Excel не был обработан. Адрес на бланке в Word пропущен. Оба содержат ПДн, которые субъект просил обезличить.
По статье 15 GDPR (право доступа) или статье 17 (право на удаление) — это неполный ответ на DSAR. Если субъект данных или регулятор обнаружит этот пробел, непоследовательность в инструментарии станет задокументированным отягчающим фактором.
Аргументы в пользу единого стандарта
Надёжное соответствие DSAR не просто перечисляет типы ПДн для обезличивания. Оно требует одинакового стандарта для каждого формата в наборе ответа.
Это означает:
- Одинаковые типы сущностей проверяются в Word, PDF, Excel, CSV и JSON.
- Одинаковые пороговые значения достоверности применяются ко всем файлам.
- Используются одинаковые токены замены. Если «Иван Иванов» встречается в трёх документах, одним токеном заменяется имя во всех трёх.
- Единый журнал аудита охватывает все форматы.
Решение на единой платформе делает это возможным через пресеты. Один пресет «DSAR EU Individuals» проверяет одни и те же 32 типа сущностей в PDF-договоре, записи Excel и журнале CSV, используя один и тот же механизм для всех трёх.
Подробнее о работе пресетов в пакетных заданиях см. в нашем руководстве по пакетной обработке GDPR DSAR в масштабе.
Пакетная обработка наборов со смешанными форматами
Соответствие требованиям DSAR в масштабе означает обработку папок со смешанными форматами как единого целого.
Входные данные: папка с 15 файлами — PDF, DOCX, XLSX, CSV — представляющими все данные одного субъекта.
Этапы обработки:
- Определение формата каждого файла.
- Применение нужного парсера: извлечение текста PDF, разбор XML DOCX, итерация ячеек XLSX, разбор полей CSV.
- Запуск одного NLP-конвейера для извлечённого текста из всех файлов.
- Применение одного пресета к каждому файлу в пакете.
- Использование общего пула токенов: одно и то же имя получает одинаковый токен замены во всех 15 файлах.
Результат:
- Обезличенные версии всех 15 файлов в исходных форматах.
- Единый кросс-форматный отчёт аудита, показывающий каждую обнаруженную сущность, исходный документ, показатель достоверности и предпринятое действие.
Этот отчёт аудита и является документом о соответствии требованиям. Он доказывает, что все 15 файлов обработаны с одинаковым стандартом. При проверке регулятором это значительно весомее, чем разрозненные инструменты.
См. также: Предотвращение утечек ПДн в реальном времени при использовании ИИ.
Известные ограничения унифицированных конвейеров
Унификация форматов решает проблему фрагментации, но вводит собственные ограничения.
Точность конвертации: преобразование DOCX в формат обработки и обратно может привести к потере истории отслеживаемых изменений или повреждению встроенных объектов. Юридические документы требуют дополнительной проверки после обработки.
Обслуживание для каждого формата: распознаватели сущностей для CSV отличаются от тех, что используются для отсканированных форм. «Унифицированный» конвейер всё равно требует предварительной обработки для каждого формата, которую необходимо обновлять по мере эволюции форматов.
Точность для редких форматов: большинство NLP-моделей обучаются на веб-текстах и распространённых офисных документах. Устаревшие форматы — старые EDI-файлы, нестандартные XML-схемы, метаданные САПР — нередко дают точность хуже, чем обещают тесты.
Невосстанавливаемые форматы: некоторые типы PDF и файлы только с изображениями не могут быть обезличены на месте — они требуют визуального редактирования, которое уничтожает машиночитаемую структуру. Если после обезличивания нужен поиск или индексирование, этот вариант может оказаться недостаточным.
Практический рабочий процесс DSAR
Для команд с регулярным объёмом DSAR:
- Собрать все документы о субъекте данных
- Создать пакет DSAR — перетащить все файлы независимо от формата
- Выбрать пресет «DSAR EU Individuals»
- Запустить пакет
- Скачать обезличенные результаты и сводный отчёт аудита
- Проверить два-три документа из результатов
- Упаковать обезличенные документы для ответа субъекту данных
- Приложить отчёт аудита к записи о DSAR
Шаг 1 (ручной сбор) по-прежнему требует наибольших временны́х затрат. Шаги 2–8 занимают менее 10 минут для типичного пакета. Отчёт аудита из шага 5 удовлетворяет принципу подотчётности по GDPR.
anonym.legal обрабатывает DOCX, PDF, XLSX, CSV и JSON. Каждый файл использует один пресет. Один отчёт аудита охватывает весь пакет.