Дані про клієнта і захист персональних даних: де проходить конфлікт

За двадцять п'ять років практики я жодного разу не бачила компанію, де відділ комплаєнсу і відповідальний за захист даних сідали за один стіл раніше, ніж це вимагав конфлікт між ними.

Чому комплаєнс і захист даних тягнуть компанію в різні боки?

Бо в них різні відправні точки. Комплаєнс-функція побудована на логіці «що більше я знаю про клієнта, то менший ризик помилки», а захист персональних даних — на логіці «що менше даних я тримаю, то менший ризик шкоди людині».

Обидві логіки раціональні окремо. Проблема виникає, коли одна команда будує процедуру збору даних, не питаючи іншу, чи ці дані взагалі можна так зберігати і передавати. У середній компанії це закінчується політикою, яка виглядає переконливо на папері й розвалюється, щойно клієнт або регулятор ставить конкретне питання «навіщо вам ці дані».

Це та сама проблема, що й у будь-якій системі, яку ніхто не розуміє зсередини: правила існують, але ніхто не може пояснити логіку їх застосування в конкретному кейсі.

Які дані про клієнта компанія має право збирати для AML?

Компанія збирає стільки даних, скільки потрібно для оцінки ризику конкретного клієнта і операції, не більше і не менше. На практиці це означає: ідентифікаційні дані, інформацію про бенефіціарну власність, джерело коштів, мету ділових стосунків і дані, потрібні для скринінгу на санкції та політично значущі особи.

Конфлікт починається, коли «про всяк випадок» компанія почне збирати й зберігати більше — історію листування, геолокацію, дані з відкритих джерел, які не стосуються безпосередньо оцінки ризику. Таке розширення обсягу даних виглядає як обачність комплаєнсу, а за фактом порушує принцип мінімізації і створює додатковий ризик у разі витоку чи запиту суб'єкта даних.

Правило, яке працює: кожне поле в анкеті клієнта повинно мати відповідь на питання «яке рішення я прийму, якщо це поле порожнє». Якщо відповіді немає — поле зайве.

Що таке принцип мінімізації даних і чому він заважає скринінгу?

Принцип мінімізації не забороняє скринінг — він вимагає, щоб обсяг даних, використаних для скринінгу, відповідав саме цій меті, а не був універсальним досьє на всякий випадок. Заважає він не скринінгу як такому, а звичці зберігати «про всяк випадок» усе, що вдалося знайти.

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

Це прямо повторює проблему автоматизації фінансового моніторингу загалом: машині можна віддати обробку обсягу, але не відповідальність за те, які саме дані вона бере в роботу.

Хто відповідає, коли AI-система обробляє персональні дані клієнта?

Відповідає компанія, яка впровадила систему, а не постачальник алгоритму і не сама система. Це правило не змінюється від того, наскільки автоматизоване рішення — відмова у відкритті рахунку, блокування операції чи підвищення ризик-рейтингу клієнта.

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

Та сама логіка лежить в основі пояснюваності моделей узагалі: регулятор питає не «що вирішила система», а «чому саме так», і відповісти на це можна лише маючи документовану логіку обробки даних.

Скільки часу можна зберігати дані клієнта після завершення стосунків?

Рівно стільки, скільки передбачено регуляторною вимогою зберігання для цілей AML, і жодного дня довше без окремої законної підстави. Строк зберігання для комплаєнс-цілей і строк зберігання «про всяк випадок» — це дві різні речі, і друге є прямим порушенням принципу обмеження мети.

На практиці найчастіша помилка — дані, зібрані для KYC, продовжують жити в CRM, маркетинговій базі чи аналітичному сховищі ще довго після того, як стосунки з клієнтом завершились і строк обов'язкового зберігання минув. Формально відповідальність за це несе компанія, навіть якщо фізично дані зберігає підрядник чи хмарний сервіс.

Робоче правило: строк зберігання має бути прописаний у політиці до того, як дані зібрані, а не визначатись заднім числом, коли клієнт чи регулятор ставить питання, чому дані досі є.

Як передавати дані банку-кореспонденту чи регулятору, не порушуючи захист даних?

Передача даних третій стороні для виконання прямого регуляторного обов'язку — законна підстава обробки сама по собі, і це не вимагає окремої згоди клієнта. Але це не означає, що можна передавати більше даних, ніж запитує конкретна сторона з конкретною метою.

На практиці компанії часто передають «весь файл клієнта» у відповідь на запит, замість того щоб виокремити саме ті дані, які стосуються запиту. Це зручно операційно, але створює подвійний ризик: і надлишкову обробку персональних даних, і неможливість пояснити потім, чому саме такий обсяг пішов назовні.

Практичний крок: для кожного типу зовнішнього запиту (банк, регулятор, аудитор, інвестор) заздалегідь визначити мінімальний набір полів, який відповідає на цей запит, і не виходити за нього без окремого обґрунтування.

Що робити, якщо клієнт вимагає видалити свої дані, а триває перевірка?

Право на видалення не скасовує обов'язкового строку зберігання даних для AML-цілей — ці два режими співіснують, і другий тимчасово переважає перший у частині даних, які підпадають під обов'язкове зберігання. Це означає, що запит клієнта не можна ні проігнорувати, ні виконати автоматично.

Правильна відповідь — часткове виконання: видалити ті дані, які не підпадають під обов'язок зберігання (наприклад, маркетингові чи аналітичні), і пояснити клієнту, які дані й чому компанія продовжує тримати в силу регуляторної вимоги. Відсутність такого розмежування — найчастіша причина, чому компанія або порушує строк зберігання, або порушує право клієнта.

Порівняння вимог: де саме виникає тертя

Як побудувати політику, що витримує обидві вимоги: покроково

1. Інвентаризувати всі поля даних про клієнта, які компанія фактично збирає, а не ті, що прописані в старій політиці.
2. Для кожного поля зафіксувати мету обробки і регуляторну підставу — без підстави поле прибрати.
3. Визначити строк зберігання окремо для кожної категорії даних, а не єдиний строк «на все».
4. Прописати мінімальний набір даних для кожного типу зовнішнього запиту: банк, регулятор, аудитор, інвестор.
5. Для автоматизованих систем скринінгу і моніторингу задокументувати, які саме поля система використовує для висновку, а які лише фіксує.
6. Призначити відповідального за узгодження між комплаєнс-функцією і захистом даних перед запуском будь-якої нової процедури збору.
7. Переглядати політику після кожного реального запиту клієнта чи регулятора, а не за графіком раз на рік.

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

FAQ

Чи можна відмовити клієнту в обслуговуванні, посилаючись на захист персональних даних?

Ні, захист персональних даних — це обмеження на те, як компанія обробляє дані, а не підстава для відмови в обслуговуванні. Якщо клієнт відмовляється надати дані, потрібні для обов'язкового KYC, підставою для відмови є саме неможливість виконати комплаєнс-процедуру, а не вимоги захисту даних.

Чи потрібна окрема згода клієнта на обробку даних для AML-скринінгу?

Зазвичай ні, бо обробка для виконання прямого регуляторного обов'язку має законну підставу незалежно від згоди клієнта. Але це не звільняє компанію від обов'язку поінформувати клієнта про факт і мету такої обробки.

Що робити, якщо дані клієнта потрапили в автоматизований скринінг і система помилково позначила збіг із підсанкційною особою?

Компанія має задокументувати, на основі яких саме полів виник збіг, і відрізнити технічну помилку системи від обґрунтованої підозри. Це питання стосується як точності скринінгу, так і обсягу персональних даних, які система фактично обробила для висновку.

Чи можна зберігати персональні дані клієнта довше, якщо є судовий спір чи розслідування?

Так, наявність спору чи розслідування є окремою законною підставою для продовження зберігання понад стандартний строк. Цю підставу варто фіксувати документально в момент, коли вона виникає, а не відновлювати заднім числом.

Хто в компанії має вирішувати конфлікт між комплаєнс-вимогами і захистом даних?

Це рішення не повинна ухвалювати одна функція одноосібно — воно вимагає спільного погодження комплаєнсу, юридичної функції і відповідального за захист даних. Там, де такого погодження немає, конфлікт вирішується ситуативно, і саме це створює вразливість під час перевірки.

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