Як HR-командам впроваджувати застосунки, створені за допомогою ШІ, не розкриваючи дані працівників

Компанія RedAccess, що працює у сфері безпеки, шукала застосунки, створені інструментами програмування з ШІ й опубліковані на власному хостингу цих інструментів, та знайшла понад 5 000 застосунків практично без будь-якого захисту чи автентифікації. Серед знімків екрана, переданих Wired, було щось схоже на розподіл робочих завдань у лікарні, разом з особистою інформацією лікарів.

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

TL;DR

• Інструмент, який допомагає вирішувати, кого найняти або підвищити чи як оцінювати людей, може належати до категорії високого ризику за Законом ЄС про ШІ. Перш ніж він оцінить будь-кого, його потрібно передати ІТ та юристам або DPO.
• Записи працівників ніколи не повинні зберігатися на власному хостингу інструмента програмування з ШІ. За замовчуванням це сервер під контролем команди, доступний лише через приватну мережу; коли доступ потрібен керівникам або всім працівникам, перед застосунком додається вхід через корпоративний обліковий запис.
• Виправлення виконуються через той самий ШІ-інструмент, який створив застосунок: скоротіть поля, які він читає, надайте HR-адміністраторам, керівникам і працівникам різні представлення, приберіть облікові дані з коду, зменште обсяг даних, що надсилаються назовні, реєструйте, хто відкриває які записи, й опрацьовуйте запити на видалення з урахуванням вимог до зберігання. Кожне виправлення підтверджує перевірка, яку ви виконуєте самі, а не звіт ШІ.
• Доступ до інструмента має припинятися в день завершення трудових відносин, за нього має відповідати конкретна людина, а вибір розташування сервера сам собою не забезпечує дотримання вимог.

Помилки розгортання, що розкривають дані працівників

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

Саме першу помилку RedAccess виявила в масовому масштабі. У матеріалі Wired про результати RedAccess три з чотирьох компаній, що пропонують програмування з ШІ, заперечили твердження дослідників (четверта не відповіла), проте не заперечували, що знайдені RedAccess застосунки, створені за допомогою вайб-кодингу, залишилися відкритими. Я бачу в цьому проблему конфігурації та пропущений етап перевірки.

Перевірте, чи допомагає інструмент вирішувати, кого найняти, підвищити або оцінити

Сам факт створення за допомогою інструмента програмування з ШІ не робить HR-інструмент високоризиковим за Законом ЄС про ШІ. Це визначається його функціями. Додаток III до Закону ЄС про ШІ перелічує системи ШІ для набору та відбору людей, ухвалення рішень про підвищення, звільнення й розподіл завдань, а також моніторингу та оцінювання роботи.

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

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

Закон не обмежується компаніями ЄС: стаття 2 охоплює постачальників та організації, які використовують системи ШІ за межами ЄС, коли результати цих систем використовуються в ЄС. За статтею 113 зі змінами, зобов'язання для високоризикових систем із Додатка III застосовуються з 2 грудня 2027 року. Вони включають систему управління ризиками, управління даними, технічну документацію, ведення записів, прозорість для організацій, які використовують системи, та людський контроль (статті 9–14); оцінювати ці зобов'язання мають ІТ та юристи.

Якщо відповідь позитивна, зупиніться до того, як інструмент оцінить хоча б одного реального кандидата або працівника. Передайте його ІТ та відповідальному за юридичні питання або захист даних (DPO, якщо така посада є). Ця перевірка не визначає, чи підпадає конкретний інструмент під закон; вона показує, хто має це вирішити. Деякі штати США також регулюють автоматизовані рішення про найм; ці правила наведені в таблиці нижче.

Можна заздалегідь підготувати цю перевірку. Я попросив би ШІ-інструмент шукати аргументи проти власної системи оцінювання, а не захищати її:

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

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

Де має працювати HR-інструмент

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

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

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

Чому приватна мережа, а не вже наявна в застосунку сторінка входу? Приватна мережа означає, що інструмент узагалі не відповідає ззовні, тому сторонні не можуть завантажити його, досліджувати чи підбирати паролі. Сторінки входу, написаної ШІ-інструментом, самої по собі недостатньо. Вона доступна всім, а її надійність обмежена згенерованим кодом за нею. Звіт Veracode про безпеку коду GenAI за 2025 рік показав, що 45% перевірених зразків коду, отриманих від понад 100 моделей, не пройшли тести безпеки через уразливість OWASP Top 10 (із широко використовуваного списку найкритичніших ризиків безпеки вебзастосунків). Тому я волів би поставити захист перед застосунком, а не покладатися на той, що написав ШІ.

Під час передачі в експлуатацію інструмент працює на VPS (орендованому сервері, повністю контрольованому командою) під управлінням засобу розгортання на кшталт Coolify або Dokku, який запускає застосунок із його коду; Coolify також дозволяє через панель керування відкотити невдале оновлення до попередньої версії. Вибір між Coolify і Dokku значною мірою залежить від кількості застосунків на сервері та від того, чи надає ІТ-фахівець перевагу панелі керування. Приватну мережу забезпечує Tailscale або WireGuard. Tailscale налаштовується швидше, але його координаційним сервісом керує Tailscale, тоді як WireGuard повністю розміщується самостійно. Корпоративний вхід забезпечує постачальник ідентифікації на кшталт Authentik або Keycloak. Зворотний проксі, наприклад Caddy або Nginx Proxy Manager, додає HTTPS там, де вхід доступний з інтернету. Цю частину потрібно передати ІТ-фахівцю разом із контрольним списком наприкінці.

Виправлення у вигляді запитів до вашого ШІ-інструмента

Більша частина роботи з безпечного розгортання HR-застосунку, створеного за допомогою ШІ, виконується через інструмент, який його створив, але лише за запитом. Як сказав Wired дослідник безпеки Joel Margolis, інструменти програмування з ШІ «роблять те, що ви просите. І якщо ви не просите зробити це безпечно, вони не докладатимуть додаткових зусиль заради цього».

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

Знайдіть поля працівників, які використовує інструмент, і закрийте доступ до решти

Неможливо закрити доступ до поля, якщо ви не знаєте, що воно є в інструменті, тому перший запит — аудит:

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

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

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

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

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

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

Надайте HR-адміністраторам, керівникам і працівникам різні представлення

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

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

- HR-адміністратор: може читати й редагувати всі записи працівників.

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

- Працівник: може читати лише власний запис.

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

Деякі компанії дозволяють керівникам бачити зарплату під час перегляду винагороди; якщо у вас так, змініть рядок ролі керівника.

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

Приберіть облікові дані з коду й чату

Пароль бази даних або API-токен HRIS чи системи розрахунку зарплати (довгий ключ, який одна система використовує для входу в іншу) можна видалити з поточного коду, але він може залишитися в раніше збережених версіях проєкту, тому запит стосується й історії. Змінна середовища вирішує проблему в коді. Це значення, яке сервер передає застосунку під час запуску, тому код звертається до нього за назвою, не містячи самого значення.

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

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

Власні копії цих паролів команди мають зберігатися в менеджері паролів, наприклад на самостійно розміщеному сервері Vaultwarden (який варіант підійде команді — окремий вибір). Він зберігає облікові дані для людей і не передає їх застосунку, що працює: застосунок отримує значення з інструмента розгортання. Для секретів, які читає сам застосунок під час роботи, HashiCorp Vault — складніший варіант із централізованими політиками й ротацією для команд, яким це потрібно.

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

Перевірте, які дані працівників залишають інструмент

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

Перевір усі зовнішні виклики цього застосунку: до OpenAI, Anthropic або будь-якого іншого API ШІ, до HR-систем на кшталт HRIS чи ATS, до інструментів аналітики або відстеження помилок та до будь-яких вебхуків. Для кожного виклику точно перелічи поля працівників або кандидатів у даних, що надсилаються. Познач сервіси, які можуть зберігати або записувати в журнал отримані дані, і вкажи, які виклики могли б працювати з меншим обсягом даних. Познач усе, у чому не впевнений.

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

Реєструйте, хто відкриває які записи працівників

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

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

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

Перевірка: від імені HR-адміністратора відкрийте запис, потім перегляньте журнал і переконайтеся, що запис про дію з'явився. Попросіть ІТ або ШІ-інструмент (із показом результату) спробувати видалити рядок журналу через обліковий запис бази даних застосунку; ви маєте побачити саму помилку дозволів.

Опрацьовуйте запити на видалення без порушення правил зберігання

Що відбувається, коли працівник просить видалити дані, а частина його записів — документи із зарплати, які компанія зобов'язана зберігати? Очевидний запит («видали всі персональні дані цього працівника в усіх таблицях») усе одно їх видалить, порушивши одразу дві речі. Роботодавці часто зобов'язані зберігати деякі записи, наприклад документи із зарплати, податків і дозволу на роботу, а право на видалення за GDPR не діє тією мірою, якою обробка необхідна для виконання юридичного зобов'язання чи для правових вимог (стаття 17(3)(b) та (e)). Кнопку видалення всього також небезпечно залишати доступною. Безпечніший варіант відокремлює «видалити за запитом» від записів, що підлягають обов'язковому зберіганню, тобто тих, які компанія має зберігати незалежно від запиту, і показує план до видалення будь-чого:

Створи інструмент опрацювання запитів на видалення, доступний лише HR-адміністраторам. Отримавши ідентифікатор працівника, він спочатку показує всі таблиці й поля з даними цієї людини, згруповані за категоріями з аудиту полів. Для кожної категорії HR-адміністратор задає налаштування зберігання: «видалити за запитом» або «зберегти: обов'язкове зберігання». Після підтвердження HR-адміністратором інструмент видаляє лише категорії з налаштуванням «видалити за запитом». Він записує в журнал лише ідентифікатор працівника, час, користувача, який підтвердив дію, та категорії, що були видалені чи збережені, без інших відомостей про людину. Будь-який користувач, який не є HR-адміністратором, отримує «доступ заборонено».

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

Перевірка: створіть тестового працівника із записами у двох категоріях: одній із налаштуванням «видалити за запитом» та іншій з обов'язковим зберіганням. Запустіть інструмент від імені HR-адміністратора й переконайтеся, що зникла лише перша категорія. Потім відкрийте інструмент через обліковий запис керівника та очікуйте «доступ заборонено».

Норми трудового права для обговорення з DPO або відповідальним за дотримання вимог

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

Система обліку відпусток із примітками про пристосування умов праці працівників у Німеччині та Каліфорнії підпадає під інші правила, ніж планувальник чисельності, що зберігає лише назви посад. Питання Закону ЄС про ШІ належить до перевірки впливу на рішення про найм.

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

Доступ припиняється разом із трудовими відносинами

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

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

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

Призначений наступник отримує сервер, який комусь довелося налаштувати, разом з інструментом розгортання, приватною мережею та, для ширшого доступу, корпоративним входом. Наш Linux VPS надає root-доступ, а Coolify, Tailscale і Authentik розгортаються як застосунки в один клік, дозволяючи ІТ-фахівцю витрачати час на перевірки. Серед розташувань — Франкфурт та Амстердам у ЄС, Лондон у Великій Британії й кілька міст США. Це визначає країну розташування сервера — вихідну інформацію для обговорення з DPO, а не заміну такого обговорення.

Контрольний список перед запуском

До додавання записів працівників кожен пункт нижче або виконано, або ні; передайте цей список тому, хто налаштовує сервер.

1. Питання впливу на рішення про найм вирішено, і будь-яку відповідь «так» передано ІТ та юристам.
2. Інструмент працює на сервері під контролем команди, а не на хостингу ШІ-інструмента.
3. Він доступний лише через приватну мережу або корпоративний вхід.
4. Обліковий запис бази даних застосунку читає лише перелічені поля.
5. Тестовий керівник і тестовий працівник обоє отримують «доступ заборонено» під час перевірки адресного рядка.
6. Усі облікові дані, що потрапляли в чат або код, замінено, а старі відкликано.
7. Аудит вихідних даних виконано, непотрібні поля виключено.
8. Журнал аудиту фіксує перегляди, а обліковий запис застосунку не може його редагувати чи видаляти.
9. Налаштування зберігання й норми трудового права перевірені DPO або відповідальним за дотримання вимог.
10. Призначено одного конкретного відповідального та конкретного заступника.

Часті запитання

Що таке тіньовий ШІ в HR?

Тіньовий ШІ в HR — використання ШІ-інструментів або створених за їхньою допомогою застосунків із HR-даними без відома чи схвалення ІТ. Щорічне дослідження HR-систем Sapient Insights за 2026 рік, за даними Cornerstone OnDemand, показало, що понад 80% HR-фахівців щодня використовують особисті ШІ-інструменти, тоді як 3% використовують ШІ, вбудований у їхні HR-системи.

Чи можна використовувати реальні записи працівників під час створення інструмента?

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

Чи мають працівники давати згоду на використання своїх даних HR-інструментом?

Зазвичай згода — невідповідна підстава. У рекомендаціях EDPB щодо згоди зазначено, що рада «вважає проблематичною обробку роботодавцями персональних даних нинішніх або майбутніх працівників на підставі згоди, оскільки вона навряд чи надається вільно». Яка законна підстава застосовується за статтею 6 GDPR, має визначити ваш DPO.

Чи поширюється HIPAA на медичні нотатки в HR-інструменті?

Зазвичай ні. Визначення захищеної медичної інформації HIPAA виключає відомості у трудових записах, що зберігаються в організації, охопленій законом, у її ролі роботодавця (45 CFR 160.103). Це не означає, що такі нотатки не регулюються, тому запитайте відповідального за дотримання вимог, які правила до них застосовуються.