Деякий контент на цьому сайті був створений з допомогою штучного інтелекту
Повернення до блогу Безпека

Реєстр дій обробки, коли в процесі з'являється AI

Zespół ESKOM.AI 2026-09-04 Час читання: 6 min

Впровадження AI рідко створює нову діяльність з обробки. Частіше змінює існуючу: та сама рекрутація, та сама обробка рекламацій, тільки дані тепер проходять через модель, якої рік тому не було в архітектурі. Реєстр з статті 30 GDPR цього не відзначив, бо ніхто його відтоді не відкривав.

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

П'ять полів, які зазвичай потребують доповнення

  • Категорії одержувачів. Якщо запит, що містить особисті дані, виходить до зовнішньої служби, її постачальник є суб'єктом обробки і потрібен є договір про передачу. Фраза «наші люди вставляють туди лише фрагменти» нічого в цій кваліфікації не змінює.
  • Категорії даних фактичні, а не заплановані. У полі запиту опиняється те, що вставляє працівник: життєпис кандидата, фрагмент договору, повідомлення від клієнта разом з номером PESEL у підніжці.
  • Передача поза ЄС, якщо модель працює поза Європою. Потрібно вказати підставу, зазвичай рішення про адекватність або стандартні умовні клаузули, і вписати її до реєстру, а не тримати в кореспонденції з постачальником.
  • Термін зберігання змісту запитів і відповідей. Відокремий пункт, майже завжди пропущений, бо дані виникають у двох місцях одночасно: по стороні постачальника і у журналах власної програми.
  • Автоматизоване прийняття рішень, якщо результат моделі щодо чогось щодо особи вирішує, а не тільки підказує людині. Це поле має подальші наслідки, бо запускає статтю 22 GDPR і зобов'язання інформувати про логіку обробки.

Журнали запитів - це зібрання даних, а не технічний файл

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

Два запитання до постачальника, обидва письмові: як довго він зберігає вміст запитів і чи використовує його для навчання моделей. Відповідь записується до реєстру та до договору про передачу даних. Третє запитання ставиться власній команді: скільки ми тримаємо в своїх журналах і чи хтось колись встановив їм термін зберігання.

Коли потрібна оцінка впливу

Стаття 35 GDPR вимагає оцінки впливу на захист даних, коли обробка може призвести до високого ризику порушення прав і свобод. Регламент прямо вказує три випадки: систематична та комплексна оцінка особистісних чинників на основі автоматизованої обробки, обробка великої кількості спеціальних категорій даних та систематичне моніторинг публічно доступних місць. Голова УОДП також опублікував перелік типів операцій, для яких така оцінка є обов'язковою.

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

Інформаційний обов'язок, коли дані не походять від особи

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

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

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

Інший шлях - анонімізація або псевдоанімізація перед відправленням запиту на зовні. Тоді зовнішній постачальник взагалі не отримує особистих даних, а в реєстрі залишається лише внутрішня дія.

Як перевірити власний реєстр за годину

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

FAQ

Чи потрібно створювати нову дію обробки для самого інструменту AI?

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

Що, якщо працівники використовують інструменти AI без згоди відділу IT?

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

Чи цей обов'язок стосується малих компаній?

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

Перевіримо Ваш реєстр

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

#RODO #rejestr czynności #compliance #dane osobowe #AI

Маєте подібну проблему з додатком?

Замовте безкоштовну 30-хвильну консультацію — без зобов'язань. Покажемо, як це можна зробити швидше та дешевше з AI.

Записатися на безкоштовну консультацію

Кожного місяця: як компанії модернізують програмне забезпечення з AI

Конкретики, без жаргону. Нуль спаму — виписуєтеся одним кліком.

Free checklist: Is your legacy application a good candidate for AI modernization?