GDPR DSAR: end-to-end автоматизация

Автоматизация закрывает цикл DSAR — от приёма запроса до отправки заявителю готового отчёта с его персональными данными. В обработке участвуют структурированные системы (CRM, data warehouse) и неструктурированные источники (договоры, переписка, тикеты, сканы документов), где прячется основная часть PII. Юрист остаётся в контуре принятия решений по спорным кейсам, но ручной поиск, копирование и сшивание данных уходят из его зоны ответственности. Пример применения: клиент e-commerce-площадки запрашивает все свои данные — автоматизация собирает профиль из CRM, историю заказов из data warehouse, переписку с поддержкой из тикет-системы и возвращает единый отчёт за несколько часов вместо недель ручной работы.

Шаги процесса

1. Приём запроса через веб-форму, email или клиентский portal с автоматической регистрацией в журнале DSAR и постановкой 30-дневного таймера.
2. Верификация личности заявителя по данным из CRM — email, телефон, идентификатор клиента, номер договора.
3. Параллельные запросы во все системы с PII: CRM, data warehouse, биллинг, тикет-система, файловое хранилище, почтовый архив.
4. RAG-поиск по файловому хранилищу — контракты, подписанные документы, PDF-формы, вложения в тикетах, сканы документов.
5. LLM-извлечение структурированных полей из неструктурированных документов: имена, адреса, даты рождения, реквизиты, договорные условия.
6. Автоматическая редакция упоминаний третьих лиц — других клиентов, сотрудников компании, контрагентов, сторонних сервисов.
7. Сборка унифицированного отчёта в требуемом формате: PDF для человекочитаемости и машиночитаемый JSON/CSV для переносимости.
8. Аудит-лог всех шагов сбора и редакции для последующих проверок регулятором и внутреннего контроля.
9. Отправка отчёта заявителю через безопасный канал (защищённый portal, зашифрованный email) с подтверждением получения.

Что автоматизация НЕ делает

• Не принимает юридическое решение об отказе в предоставлении данных — спорные кейсы (коммерческая тайна, права третьих лиц, судебные исключения) эскалируются DPO с готовым досье.
• Не обрабатывает другие права субъекта: удаление (RTBF), исправление, переносимость в сторонние системы, возражение против обработки — это отдельные процессы с собственной логикой.
• Не заменяет DPO и юриста. Ответственность за корректность ответа, трактовку исключений GDPR и финальную подпись остаётся за человеком. Автоматизация — инструмент подготовки, а не принятия решений.

Технически DSAR-автоматизация строится как оркестратор поверх существующих систем компании. Ядро — workflow engine (workflow-движок или эквивалент), который управляет этапами и состоянием каждого запроса, хранит checkpoint между шагами и восстанавливает выполнение после сбоев. Вокруг ядра подключаются коннекторы к источникам PII и специализированные компоненты для работы с неструктурированными данными. Архитектурный принцип — минимальные привилегии для всех интеграций и полный audit-trail для последующей проверки регулятором.

Архитектура потока

1. Входной канал принимает запрос (веб-форма на сайте, dedicated email-ящик, клиентский portal) и нормализует его в структурированный объект: идентификатор заявителя, тип запроса, приложенные документы, канал обращения.
2. Identity verification сверяет предоставленные данные с CRM и запускает дополнительную проверку при несовпадении — одноразовый код на телефон или email.
3. Оркестратор рассылает параллельные запросы в структурированные системы — SQL к data warehouse, REST к CRM, запрос к биллингу — и собирает ответы в промежуточный буфер.
4. RAG-слой обрабатывает файловое хранилище: векторный индекс по документам позволяет находить релевантные файлы, даже если в них нет явного идентификатора заявителя (имя упоминается в тексте договора, email — во вложении тикета).
5. LLM-экстрактор анализирует каждый найденный документ и извлекает структурированные поля: имена, даты, адреса, реквизиты, предмет договора. Используется AI-модель или сопоставимая модель с function calling для строгой JSON-схемы вывода.
6. Redaction layer применяет правила маскирования: упоминания других клиентов, сотрудников, контрагентов заменяются на [THIRD PARTY]. Правила описываются декларативно и проходят ревью юриста перед деплоем.
7. Report builder собирает единый документ в двух форматах: PDF для человекочитаемости и машиночитаемый JSON/CSV для переносимости по GDPR Article 20.
8. Audit log фиксирует каждый шаг с таймштампом, источником данных, применёнными правилами редакции — материал для регулятора при проверке.

Компоненты решения

Этапы внедрения

1. Discovery — инвентаризация всех систем, содержащих PII, классификация по чувствительности, карта потоков данных между системами.
2. Data mapping — для каждого источника описывается, какие поля каких сущностей попадают в DSAR-отчёт, как находятся по идентификатору заявителя, какие поля относятся к третьим лицам.
3. Настройка коннекторов и service accounts с read-only-доступом по принципу минимальных привилегий. Применяются стандартные интеграции (SQL, REST, GraphQL) и, при необходимости, custom-коннекторы для legacy-систем.
4. Построение RAG-индекса по файловому хранилищу: извлечение текста (OCR для сканов), чанкинг, embeddings, инкрементальное обновление при добавлении новых файлов.
5. Разработка extraction-промптов со строгой JSON-схемой вывода и валидация на выборке реальных документов — метрики precision и recall извлечённых полей относительно human-ground-truth.
6. Определение redaction-правил совместно с DPO и юристами: список категорий третьих лиц, whitelist идентификаторов заявителя, политика для edge-cases (семья клиента, сотрудник компании).
7. Шаблон отчёта в двух форматах и политика уведомлений заявителя на каждом этапе.
8. Пилотный прогон на 3-5 исторических DSAR и сверка с ручным результатом: проверка полноты собранных данных, корректности редакции, соблюдения формата.
9. Production-запуск с мониторингом SLA 30 дней, алертами на сбои коннекторов и регулярными audit-trail-проверками.

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

Данные и доступы

• Инвентаризация всех систем с персональными данными: CRM, data warehouse, биллинг, тикет-система, файловое хранилище, почтовый архив, legacy-базы.
• Service accounts с read-only-доступом к каждой системе и whitelist IP-адресов оркестратора.
• Политика идентификации заявителя — какие поля считаются достаточными для верификации и когда нужна дополнительная проверка.
• Retention-политики по каждому источнику данных, чтобы корректно учитывать уже удалённые записи.
• Шаблон DSAR-отчёта и требования к формату: PDF-брендинг, структура разделов, язык ответа.

Команда и роли

• DPO или старший юрист как owner процесса и приёмщик спорных кейсов.
• IT-архитектор для согласования доступов и архитектуры интеграций.
• Data engineer для настройки коннекторов и RAG-индекса.
• Sponsor уровня COO или CTO для разблокировки доступов между департаментами.

Таймлайн

Внедрение занимает 6-10 недель при средней сложности:

1. Discovery и data mapping — 2 недели.
2. Сборка коннекторов, RAG-индекса и extraction-логики — 3-4 недели.
3. Redaction-правила и шаблон отчёта — 1-2 недели.
4. Пилотный прогон и корректировки — 1-2 недели.

При большом количестве legacy-источников или сложных мультиязычных требованиях срок сдвигается к верхней границе.