Обробка GDPR DSR з AI: pattern на 30-денний SLA

Коли head of ops SaaS-компанії на 70 людей розповів мені, що отримав перший GDPR DSR у пʼятницю після обіду і панікував усі вихідні, намагаючись зрозуміти правильний процес, моя реакція була: це найбільш передбачувана compliance-подія у вашому бізнесі, і у вас немає playbook. GDPR дає 30 днів. Pattern влазить на одну сторінку.

Чому SMB-засновники бояться DSR?

Бо наслідок неправильної відповіді конкретний (GDPR-штрафи до €20M або 4% глобального обороту, EU AI Act до €35M або 7%), дедлайн короткий, і у більшості SMB немає письмового процесу. Перший DSR відчувається як надзвичайна ситуація, бо так воно і є — без процесу ви імпровізуєте проти регуляторного годинника.

Definition: Data subject request (DSR) — формальний запит фізичної особи на реалізацію її GDPR-прав: зазвичай access, deletion (right to be forgotten), portability, correction або заперечення проти обробки.

Компанії, що добре справляються з DSR, отримують той самий обсяг; вони просто отримують у процес. Перший за рік ідентичний за формою двадцятому. Процес — актив.

5-кроковий pattern DSR

Пʼять кроків, цільовий SLA для кожного. Увесь pattern сидить всередині 30 календарних днів GDPR.

Крок 1: Acknowledge (ціль: 48 годин)

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

AI допомагає тут як template-fill: витягує тип запиту з вхідного, заповнює шаблон acknowledgement, надсилає чернетку DSR-owner на затвердження. Медіана: до 5 хвилин. Помилки уникнути: ніколи не давайте AI авто-надіслати DSR-acknowledgement без людського ревʼю — це перший контакт, видимий регулятору.

Крок 2: Верифікація особи (ціль: 5 робочих днів від acknowledgement)

Підтвердьте, що запитувач — це той, хто стверджує. Для облікових записів — logged-in session плюс email у файлі зазвичай достатньо. Для видалених акаунтів чи неідентифікованих запитувачів — потрібні ID-документи або визначений verification flow. Стандарт верифікації документується ДО приходу запиту — не імпровізується.

AI не робить identity verification. Люди роблять — а стандарт затверджує юрист один раз, не per запит.

Крок 3: Pull даних (ціль: 10 робочих днів)

Для access і portability запитів витягніть кожен шматок персональних даних, привʼязаний до верифікованої особи, по всіх системах інвентаря. Це там, де SMB без підготовки втрачають дні: який CRM-запис, які support-тікети, які analytics-події, які AI-tool transcripts, які backups.

Definition: Data pull — операційний процес ідентифікації, витягування і консолідації всіх персональних даних, привʼязаних до верифікованого data subject, по всіх системах data-flow інвентаря.

AI значно прискорює цей шар. З наявним data-flow інвентарем (див. pattern оновлення privacy policy) AI може згенерувати pull-list — які системи опитати, який формат експорту використати, що консолідувати. Ops-лід виконує pulls; AI організовує output у єдиний deliverable.

Крок 4: Ревʼю виключень (ціль: 5 робочих днів)

Не кожен шматок даних, привʼязаний до запитувача, у scope. Виключені категорії: дані, що ідентифікують третіх осіб (інші клієнти у support-transcripts, інші співробітники у HR), дані, покриті legal professional privilege, дані під retention-обовʼязками інших законів (tax, AML), trade-secret-захищені операційні дані.

Тут AI допомагає, а юрист вирішує. AI може видати flagged-версію датасету — «це містить імʼя третьої особи, цей email містить protected legal advice, цей запис під 7-річним tax retention» — і юрист переглядає flags. Людина підписує, що випускається.

Крок 5: Відповідь (ціль: до дня 28-29)

Надішліть відповідь, із data-package для access/portability або підтвердженням видалення для erasure. Задокументуйте все в DSR log: дата отримання, дата acknowledgement, метод verification, опитані системи, застосовані виключення, дата надсилання, sign-off запитувача якщо є. Log — це те, що ви показуєте регулятору.

Дводенний буфер перед 30-денним deadline — навмисний: дає час полагодити фінальне review issue без втрати SLA.

Copy/paste runbook DSR

DSR LOG ENTRY — REQUEST #[N]
Отримано: [DATE / CHANNEL]
Тип: [ACCESS / DELETION / PORTABILITY / CORRECTION / OBJECTION]
Owner: [NAME]
SLA deadline: [DATE = отримано + 30 днів]

КРОК 1 — ACKNOWLEDGE (ціль: +48h)
Acknowledgement надіслано: [DATE]
Метод: [EMAIL / PORTAL]
ID-документи запитано: [LIST]

КРОК 2 — VERIFY IDENTITY (ціль: +5 робочих днів)
Метод: [LOGGED-IN / ID-DOC / OTHER]
Верифіковано: [Y/N — DATE]
Якщо N: відмова надіслана з причиною: [TEXT]

КРОК 3 — DATA PULL (ціль: +10 робочих днів)
Опитані системи (з інвентаря):
- [LIST]
Pull завершено: [DATE]
Формат: [JSON / CSV / PDF]

КРОК 4 — РЕВʼЮ ВИКЛЮЧЕНЬ (ціль: +5 робочих днів)
Дані третіх осіб flagged: [N items]
Legal-privilege flagged: [N items]
Retention-obligation flagged: [N items]
Trade-secret flagged: [N items]
Юрист переглянув: [DATE / NAME]

КРОК 5 — ВІДПОВІДЬ (ціль: ≤ день 28)
Відповідь надіслана: [DATE]
Метод: [SECURE PORTAL / ENCRYPTED EMAIL]
Acknowledgement запитувача: [Y/N / DATE]

POST-RESPONSE
Внутрішній incident report: [Y/N]
Process improvement: [TEXT]

Tool tip (AIAdvisoryBoard.me): Обробка DSR — саме той тип операційної compliance-роботи, де різниця між «оброблено за 8 годин» і «паніка 28 днів» — це чи маєте ви Plan → Fact → Gap огляд data flows ДО приходу запиту. 7-денна діагностика закладає фундамент: які дані де обробляються, якою системою, з яким retention. Коли приходить DSR — pull-list уже намічений. Дивіться https://aiadvisoryboard.me/?lang=en.

Manager scan (2-хвилинний дайджест)

• Plan: кожен DSR acknowledged за 48 годин
• Fact: медіана acknowledgement минулого кварталу — 14 годин
• Gap: тримайте лінію; ризик — коли DSR-owner у відпустці
• Plan: стандарт identity verification задокументований і затверджений юристом
• Fact: стандарт існує, востаннє переглянутий 9 місяців тому
• Gap: запланувати annual review з юристом
• Plan: data-pull список генерується з інвентаря, не збирається з нуля
• Fact: минулий DSR взяв 4 дні pulls, бо інвентар застарілий
• Gap: інвентар не оновлений (див. quarterly privacy процес)
• Plan: виключення переглядає юрист перед відповіддю
• Fact: юрист переглянув 3 з 4 DSR минулого кварталу — один проскочив тільки через ops
• Gap: counsel-review чекбокс відсутній у runbook для low-volume запитів
• Plan: жоден DSR не пропускає 30-денний SLA
• Fact: SLA дотриманий по всіх DSR цього року
• Gap: ще ні — але inventory drift — leading indicator, що це зламає

Micro-case (що змінюється за 7-14 днів)

B2B SaaS-компанія на 110 людей отримала перший GDPR access request від видаленого користувача і витратила 19 днів на відповідь — підключили трьох тімлідів, дані охопили шість систем, юрист переглянув виключення на 26-й день. Після написання 5-крокового runbook проти data-flow інвентаря, тренінгу одного DSR-owner і pre-drafting шаблонів acknowledgement і response, наступні три DSR у наступному кварталі зайняли 8, 6 і 5 днів elapsed time відповідно. Третій включав часткове видалення — юрист переглянув exclusion-список за 25 хвилин, owner надіслав відповідь на 7-й день, audit log регулятору був повний і чистий. Сам runbook — одна сторінка; inventory-робота, що його годувала — це реальна інвестиція.

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

Tool tip (AIAdvisoryBoard.me): DSR pattern — один з багатьох операційних compliance-флоу, де вартість непідготовленості тихо компаундується, доки регулятор не змусить це бачити. Plan → Fact → Gap дисципліна, застосована до compliance, vendor management, customer обовʼязків і data flows — це те, що тримає 30-денний SLA від відчуття «надзвичайна ситуація». Подивіться 7-денну діагностику на https://aiadvisoryboard.me/?lang=en.

FAQ

А якщо запитувач — колишній співробітник, не клієнт? Той самий процес, інша підмножина інвентаря. HR-системи, performance records, payroll, внутрішні комунікації — все у scope, зі своїми retention і exclusion-міркуваннями. Юрист окремо підписує employee-DSR exclusion template, бо трудове право додає шарів.

Що з запитами, які явно надмірні чи vexatious? GDPR дозволяє відмову або плату у випадках «manifestly unfounded or excessive», але поріг високий, регулятор перевірить. Відмови документуються, надсилаються письмово в межах SLA і бажано переглядаються юристом до надсилання. Не відмовляйте без юриста.

Чи може AI авто-відповідати на прості DSR? Не саму відповідь. AI робить чернетку відповіді і data package; люди переглядають і надсилають. Два режими відмови — over-disclose даних третіх осіб і under-disclose даних у scope — це саме те, що люди ловлять, а AI ні.

Що якщо у pull треба залучити sub-processor? Ваш DPA з кожним sub-processor вже має включати DSR-cooperation клаузулу з response SLA. Якщо немає — це прогалина для виправлення ДО наступного DSR, не під час нього. Додайте у vendor-risk фреймворк до renewal.

Як обробляти DSR через кілька режимів — GDPR + CCPA + EU AI Act? Той самий 5-кроковий pattern, різні exclusion-критерії і timing per режим. Юрист маркує, під які режими запитувач підпадає, на acknowledgement; data pull спільний; review і response — per режим. Runbook — дерево, не один шлях.

Висновок

Перший DSR — надзвичайна ситуація; двадцятий — paperwork. Різниця — письмовий 5-кроковий процес, привʼязаний до поточного data-flow інвентаря, AI-assisted data pull і юрист на виключеннях. 30 днів — вдосталь, якщо не втратити перші 10 у паніці.

Це не юридична порада — ваш юрист підписує runbook, exclusion-критерії і шаблони відповідей. Pattern лише дає операційну структуру, щоб їх годувати.

Якщо хочете систему, що автоматично показує Plan → Fact → Gap — включно з data-flow drift, що робить DSR важчими, ніж мають бути — подивіться 7-денну діагностику на https://aiadvisoryboard.me/?lang=en.