GDPR DSAR: наскрізна автоматизація

Автоматизація закриває цикл DSAR — від прийому запиту до відправлення заявнику готового звіту з його персональними даними. В обробці беруть участь структуровані системи (CRM, сховище даних) та неструктуровані джерела (договори, переписка, тикети, скани документів), де ховається основна частина PII.

Юрист залишається в контурі прийняття рішень щодо спірних кейсів, але ручний пошук, копіювання та зшивання даних виходять з його зони відповідальності.

Приклад застосування: клієнт e-commerce-майданчика запитує всі свої дані — автоматизація збирає профіль із CRM, історію замовлень зі сховища даних, переписку з підтримкою з тикет-системи і повертає єдиний звіт за кілька годин замість тижнів ручної роботи.

Кроки процесу

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

Що автоматизація НЕ робить

• Не приймає юридичне рішення про відмову у наданні даних — спірні кейси (комерційна таємниця, права третіх осіб, судові винятки) ескалюються до DPO з готовим досьє.
• Не обробляє інші права суб'єкта: видалення (RTBF), виправлення, переносність у сторонні системи, заперечення проти обробки — це окремі процеси з власною логікою.
• Не замінює DPO та юриста. Відповідальність за коректність відповіді, трактування винятків GDPR і фінальний підпис залишається за людиною. Автоматизація — інструмент підготовки, а не прийняття рішень.

Технічно DSAR-автоматизація будується як оркестратор поверх наявних систем компанії. Ядро — рушій робочих процесів (рушій робочих процесів або еквівалент), який управляє етапами та станом кожного запиту, зберігає контрольні точки між кроками та відновлює виконання після збоїв. Навколо ядра підключаються конектори до джерел PII та спеціалізовані компоненти для роботи з неструктурованими даними. Архітектурний принцип — мінімальні привілеї для всіх інтеграцій та повний журнал аудиту для подальшої перевірки регулятором.

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

1. Вхідний канал приймає запит (веб-форма на сайті, виділена поштова скринька, клієнтський портал) та нормалізує його у структурований об'єкт: ідентифікатор заявника, тип запиту, прикладені документи, канал звернення.
2. Перевірка особи звіряє надані дані з CRM та запускає додаткову перевірку при невідповідності — одноразовий код на телефон або email.
3. Оркестратор надсилає паралельні запити до структурованих систем — SQL до сховища даних, REST до CRM, запит до білінгу — та збирає відповіді у проміжний буфер.
4. RAG-шар обробляє файлове сховище: векторний індекс по документах дозволяє знаходити релевантні файли, навіть якщо в них немає явного ідентифікатора заявника (ім'я згадується в тексті договору, email — у вкладенні тікета).
5. LLM-екстрактор аналізує кожен знайдений документ та витягує структуровані поля: імена, дати, адреси, реквізити, предмет договору. Використовується AI-модель або порівнянна модель з викликами інструментів для суворої JSON-схеми виводу.
6. Шар редакції застосовує правила маскування: згадки інших клієнтів, співробітників, контрагентів замінюються на [THIRD PARTY]. Правила описуються декларативно та проходять ревью юриста перед деплоєм.
7. Конструктор звітів збирає єдиний документ у двох форматах: PDF для людиночитаності та машиночитаний JSON/CSV для переносимості за GDPR стаття 20.
8. Журнал аудиту фіксує кожен крок з таймштампом, джерелом даних, застосованими правилами редакції — матеріал для регулятора при перевірці.

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

Етапи впровадження

1. Виявлення — інвентаризація всіх систем, що містять PII, класифікація за чутливістю, карта потоків даних між системами.
2. Картування даних — для кожного джерела описується, які поля яких сутностей потрапляють у DSAR-звіт, як знаходяться за ідентифікатором заявника, які поля належать до третіх осіб.
3. Налаштування конекторів та службових облікових записів з доступом лише для читання за принципом мінімальних привілеїв. Застосовуються стандартні інтеграції (SQL, REST, GraphQL) та, за потреби, нестандартні конектори для застарілих систем.
4. Побудова RAG-індексу по файловому сховищу: витягування тексту (OCR для сканів), чанкінг, векторні вкладення, інкрементальне оновлення при додаванні нових файлів.
5. Розробка промптів для вилучення даних зі суворою JSON-схемою виводу та валідація на вибірці реальних документів — метрики точності та повноти витягнутих полів відносно еталонної розмітки людиною.
6. Визначення правил редакції спільно з DPO та юристами: список категорій третіх осіб, перелік дозволених ідентифікаторів заявника, політика для граничних випадків (родина клієнта, співробітник компанії).
7. Шаблон звіту у двох форматах та політика сповіщень заявника на кожному етапі.
8. Пілотний прогін на 3-5 історичних DSAR та звірка з ручним результатом: перевірка повноти зібраних даних, коректності редакції, дотримання формату.
9. Запуск у продакшн з моніторингом SLA 30 днів, алертами на збої конекторів та регулярними перевірками журналу аудиту.

Перед стартом впровадження компанія збирає набір вхідних даних і узгоджує ролі. Без цих передумов проєкт розтягується або дає низькоякісний результат.

Дані та доступи

• Інвентаризація всіх систем з персональними даними: CRM, сховище даних, білінг, тікет-система, файлове сховище, поштовий архів, застарілі бази.
• Службові облікові записи з доступом лише для читання до кожної системи та перелік дозволених IP-адрес оркестратора.
• Політика ідентифікації заявника — які поля вважаються достатніми для верифікації і коли потрібна додаткова перевірка.
• Політики зберігання за кожним джерелом даних, щоб коректно враховувати вже видалені записи.
• Шаблон DSAR-звіту та вимоги до формату: PDF-брендинг, структура розділів, мова відповіді.

Команда та ролі

• DPO або старший юрист як власник процесу і приймач спірних кейсів.
• IT-архітектор для узгодження доступів і архітектури інтеграцій.
• Інженер з даних для налаштування конекторів і RAG-індексу.
• Спонсор рівня COO або CTO для розблокування доступів між департаментами.

Таймлайн

Впровадження займає 6-10 тижнів при середній складності:

1. Виявлення та картування даних — 2 тижні.
2. Збірка конекторів, RAG-індексу та логіки вилучення даних — 3-4 тижні.
3. Правила редакції та шаблон звіту — 1-2 тижні.
4. Пілотний прогін і коригування — 1-2 тижні.

При великій кількості застарілих джерел або складних багатомовних вимогах термін зсувається до верхньої межі.