ШІ-автоматизація відповідно до KVKK: що потрібно знати бізнесу

ШІ-автоматизація та KVKK: три точки конфлікту

Примітка: ця стаття не є юридичною консультацією; вона носить інформаційний характер.

KVKK вимагає правової підстави та обмеження мети при обробці персональних даних. ШІ-автоматизація створює конфлікти у трьох точках.

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

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

По-третє, сторонні обробники: хмарні ШІ-провайдери та LLM-API є обробниками даних. Письмовий договір на обробку даних (DPA) обов'язковий за ст. 8 KVKK.

Мінімізація даних: принцип "менше — краще"

Мінімізація даних — ключовий принцип KVKK та GDPR: збирайте та зберігайте лише ті дані, які суворо необхідні для заявленої мети. У ШІ-проектах цей принцип легко порушити.

Типовий сценарій: компанія електронної торгівлі будує ШІ-систему, що обробляє геолокацію клієнта в реальному часі для відстеження замовлень. Згодом система починає поглинати також історію браузера та пошукові запити — адже модель "передбачає краще." Це порушення принципу мінімізації.

Практичне правило: для кожного поля даних запитайте: "чи зламається задача без цього поля?" Якщо ні — приберіть його. Також: строки зберігання. Необроблені персональні дані у логах ШІ мають бути анонімізовані протягом 30–90 днів. Вбудуйте це як автоматичний тригер; не покладайтеся на ручні процеси.

Практичний чек-лист

Наступний чек-лист підсумовує ключові пункти для перевірки перед запуском ШІ-проекту в рамках KVKK. Не є юридичною консультацією.

1. Правова підстава: визначте підставу для кожної категорії даних (згода, договір, законний інтерес) і задокументуйте.

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

3. Договори на обробку даних (DPA): переконайтеся, що підписаний DPA є з кожним ШІ-провайдером. Уточніть, чи передаються дані за межі Туреччини — це вимагає додаткового затвердження за ст. 9 KVKK.

4. Автоматизація строків зберігання: розробіть політику зберігання для кожної категорії і вбудуйте автоматичні тригери видалення або анонімізації.

5. Аудит доступу: хто, коли і до яких даних мав доступ? Перевіряйте журнали доступу кожні 90 днів.

Тіньовий ШІ: ризик, що ховається всередині вашої команди

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

Згідно з KVKK це не знижує вашу відповідальність, а навпаки, збільшує її. Як контролер даних, ви залишаєтеся відповідальними за те, як обробляються персональні дані, навіть якщо працівник, діючи сумлінно, сам обрав інструмент, а не керівництво. Безкоштовний ШІ-асистент фактично є неперевіреним обробником даних: без підписаної угоди про обробку даних (DPA), без розуміння, де і як довго зберігаються дані, і часто з умовами використання, які дозволяють постачальнику використовувати надіслані дані для навчання власних моделей. Один вставлений список клієнтів способен звести нанівець місяці ретельної роботи з мінімізації та зберігання даних у вашій основній системі, і оскільки ця копія перебуває поза вашою інфраструктурою, ви можете взагалі ніколи не дізнатися, що це сталося.

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