Основні ризики AI-агентів в HR-процесах

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Серія статей: Вам не потрібні AI-агенти в HR-процесах.

Попередня стаття: Вам не потрібні AI-агенти в HR-процесах. Частина 1: все про дані

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

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

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

Чим більше AI-агент має можливостей та користувачів, тим більше ризиків виникає. І їх кількість зростає не лінійно, а квадратично, а в окремих випадках — експоненційно. Аналогічно зростає кількість ресурсів, необхідних на забезпечення роботи агента. Окрім ресурсів, необхідно забезпечити прийнятний рівень ризиків шляхом впровадження відповідних систем безпеки: guardrails та human-in-the-loop.

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

Ризики

Я виділяю 5 ключових категорій ризиків, які неодмінно виникнуть після запуску AI-агента.

1. Ризик неправильної відповіді — агент щось порадив, пообіцяв або пояснив неправильно.
2. Ризик зайвого доступу — агент побачив або показав те, що не мав.
3. Ризик неправильної дії — агент створив, змінив, видалив або запустив не той процес.
4. Ризик нерівного ставлення — різним людям дали різні відповіді щодо однакової ситуації.
5. Ускладнення change management в компанії.

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

Ризик неправильної відповіді

Співробітник може обґрунтовано сприймати відповідь корпоративного HR-агента як позицію компанії, якщо агент запущений у корпоративному середовищі, має доступ до внутрішніх політик і відповідає від імені HR або роботодавця. В юридичній площині це також може мати наслідки. Яскравий приклад — нещодавно поданий колективний судовий позов на Amazon від співробітників. Один з позовів подала Ейпріл Вотсон (April Watson). Вона отримала струс мозку на роботі і через те, що AI-агент MyHR/Aza надав неправильну інформацію, Ейпріл тривалий час не могла належним чином оформити лікарняний і отримала за це догану.

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

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

Ризик зайвого доступу

Несанкціонований доступ до інформації

Співробітник може навмисно або випадково отримати доступ до інформації, яка для нього не призначена. В цьому випадку наслідки можуть бути різноманітними, залежно від того, що саме отримав співробітник:

1. Персональна інформація іншого працівника. Це може бути серйозний конфлікт, бо компанія не дотрималась GDPR / ЗУ «Про захист персональних даних».
2. Комерційна таємниця. Список клієнтів, ціни на послуги, довідник постачальників. Тут зʼявляється ризик, що працівник може використати інформацію на свою користь.
3. Безпекові дані. Доступи, ролі, токени тощо. Аналогічно.
4. Корпоративні дані. Юридична інформація, плани скорочень, внутрішні розслідування тощо.
5. Приватні розмови, повідомлення, нотатки. Приватна інформація для того і є приватною, щоб бути доступною обмеженому колу людей. Коли стається подібний витік, може бути серйозний скандал як в середині компанії, так і поза неї. Як правило, подібну інформацію максимально виривають з контексту і подають в невигідному для її власників вигляді.

Відправка даних за межі компанії

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

Найбільш яскравий приклад — це коли великі компанії-розробники LLM масово купляли фізичні книги, самостійно їх сканували та тренували свої моделі. Формально вони дотримались закону, але фактично використали лазівку в підході Fair Use, який на той момент не передбачав цю технологію. Ну і більш очевидне — це обовʼязкові вимоги закону до захисту персональних даних, а також звичайне бажання компанії зберегти свою комерційну таємницю.

Головне правило співпраці з платними AI рішеннями: бути готовим прийняти ситуацію що всі відправлені дані можуть бути скомпрометовані і використані третьою стороною. Звучить дуже просто і очевидно, проте на практиці потребує ретельної підготовки. Або ви можете відмовитись від платних AI рішень на користь self-hosted / open-source. Але якщо обираєте open-source моделі, врахуйте що Контроль ≠ Безпека за замовчуванням.

Хаос в доступах

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

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

Ризик неправильної дії

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

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

1. Агент відібрав 5 найбільш токсичних співробітників і відправив відразу до HRD.

2. HRD переглянув список + логічну аргументацію та звільнив їх.

3. Фактично це була вся команда QA, до обовʼязків якої входить все ламати, писати "критична вразливість"/"знову нічого не працює"/"Ви знову викотили те сміття«.

Поза контекстом це виглядає токсично. І писали вони, до речі, не про продакшен, а про dev середовище. Рішення приймав не агент, а людина — тому правило «агент не приймає важливе рішення» дотримано.

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

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

Класифікація за важливістю:

1. Низька. Наприклад: створити чернетку повідомлення, запропонувати наступний крок.
2. Середня. Наприклад: створити заявку на внутрішню підтримку, запустити онбординг, надіслати нагадування менеджеру, оновити некритичний статус, підготувати запит на доступ.
3. Висока. Наприклад: змінити роль співробітника, оновити компенсаційні дані, погодити виплату, змінити юридичні дані, надати доступ до критичних систем, закрити offboarding, змінити керівника, видалити акаунт.

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

Механізми безпеки

Для дій агента недостатньо прописати заборони та дозволи. Необхідно розробити механізми безпеки:

1. Механізм підтвердження. Хто саме має підтвердити дію і в якій системі (і людина, яка ініціює дію, не завжди має бути тією, хто її погоджує). Будь-яка дія, яка змінює live-систему, має мати чіткий момент підтвердження.
2. Сповіщення стейкхолдерів. Після дії агент має знати, кого потрібно повідомити — співробітника, менеджера, HR, IT, Security або Finance.
3. Захист від дублів. Повторний запуск дії не повинен створити дубль заявки, доступу або повідомлення. Також, агент не повинен масово створювати заявки, повідомлення або оновлення без контролю.
4. Захист від помилкових дій. Потрібно визначити, що робити, якщо агент створив неправильну заявку або оновив не той запис.
5. Для критичних сценаріїв агент спочатку має показувати, що саме він збирається зробити, без фактичного виконання.
6. Захист від несанкціонованих та помилкових інструкцій. Агент не повинен виконувати інструкції, які суперечать системним правилам. І не повинен виконувати жодної випадкової інструкції (наприклад, якщо в контекст випадково попав зайвий промпт).
7. Логування. Хто ініціював дію, що саме зробив агент, які дані використав, які підтвердження отримав і який був результат.
8. Обробка помилок. Агент має вміти пояснити, що саме не вдалося, не приховуючи технічну невизначеність за впевненою відповіддю.

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

Ризик нерівного ставлення

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

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

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

Ситуації нерівного ставлення можуть бути дуже різноманітні:

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

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

Наприклад: «політики відпусток сотий раз за місяць змінили дай мені актуальні» / «Я хочу з дітьми відправитись у відпустку. Дай мені, будь ласка, актуальні правила їх оформлення.» ---> «Співробітник запитав актуальну політику відпусток.»

Прикладів в нерівному ставленні AI-агентів в HR вже багато, переважно вони стосуються рекрутингу (напр. Mobley v. Workday; iTutorGroup). Але також є випадки дискримінації саме працівників. Наприклад, у березні 2025 року ACLU подала скаргу проти Intuit і HireVue від імені D.K. — корінної американки з порушенням слуху, яка працювала в Intuit, мала позитивні оцінки роботи та подалася на підвищення.

У межах процесу відбору її зобов’язали пройти відеоінтерв’ю через HireVue, але компанія, за твердженням ACLU, відмовила їй у розумному пристосуванні — human-generated captions для повного доступу до запитань і інструкцій. Після відмови в підвищенні D.K. отримала фідбек із рекомендацією «practice active listening» (На даний момент Intuit і HireVue заперечують звинувачення та стверджують, що скарга є безпідставною).

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

AI-агент ускладнює change management

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

Можна виділити кілька основних підходів до реагування на зміни:

1. Затримувати зміни в компанії.
   Ініціювали зміни в компанії -> оновили агента та документацію -> анонсували зміни -> вони вступили в дію.
2. Призупиняти агента або окремі його функції.
   Ініціювали зміни в компанії -> призупинили агента -> анонсували зміни -> вони вступили в дію -> оновили агента та документацію -> запустили агента.
3. Гібридний. Щось середнє між попередніми двома, відключення частково агента та окремих його функцій тощо.

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

Відповідальність за агента

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

З погляду управління ризиками AI-агента варто розглядати як корпоративну систему типу Jira, Slack чи CRM. Власником агента завжди залишається компанія. Якщо агент помилився, виконав дію некоректно, використав не ті дані або ухвалив рішення з негативними наслідками, відповідальність не може бути перекладена на модель, постачальника інструменту чи абстрактний «штучний інтелект».

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

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

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

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

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

І окреслити всю відповідальність необхідно до запуску агента. Проте, як це часто буває, це не означає, що вам потрібен цілий відділ, який просто стежить за агентом. Залежно від складності AI-агента та розміру компанії, це може бути як умовні 0.5 FTE керівника відділу, так і цілий департамент, де на кожну роль є кілька співробітників. Після визначення відповідальних компанія має визначитись для себе, які ризики є прийнятними. Юрист має провести ревʼю всіх можливостей AI-агента ще під час його проєктування.

Європейський Союз вже має AI Act, який є діючим законом. Наприклад, HR в цьому законі здебільшого належить до high-risk (Annex 3). Тому відповідність вашої корпоративної AI-системи вимогам ЄС — це обовʼязково. Власне, в інших юрисдикціях аналогічно.

Технічні причини виникнення ризиків

Не можна підходити до розробки AI-систем (в тому числі агентів), як до класичного ПЗ. Основни причини цього закладені в самій концепції LLM моделей. Найголовніше — це те, що AI непередбачуваний. Також LLM-моделі схильні помилятися, можуть бути упередженими й ігнорувати ваші інструкції.

Непередбачуваність. LLM — статистичні моделі, в яких один і той самий промпт може давати різні результати. Максимум, що можуть гарантувати відомі провайдери, — це «mostly deterministic outputs». Модель може давати одну й ту саму відповідь в 99.9% випадках, але ніколи не 100%. В контрольованому середовищі (self-hosted open-source models) теоретично можливо дійти до 100% передбачуваності, проте на даний момент це непросто і в основному економічно недоцільно.

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

Упередження. LLM мають схильність до упереджень. Після первинного тренування (pre-train) розробники зменшують їх, але в цілому вони звертають увагу тільки на соціально гострі питання, а упередження можуть бути дуже різними і непередбачуваними. Мало того, завдання розробників LLM в контексті упереджень — це політкоректність, а не обʼєктивність.

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

Робота з контекстом. LLM працює виключно на основі «своїх знань» і контексту, включно з інструкціями, який ви їй надали. Неповна або надмірна інформація можуть суттєво впливати на дії агента. Якщо співробітник працює 4 дні на тиждень, а всі інші — по 5, то під час аналізу діяльності агент може сформувати логічний висновок: «Низька продуктивність». Але у нього може бути усна домовленість з керівником, що він працює по 11 годин, але 4 дні, що автоматично переносить його в категорію «Висока продуктивність».

Через недостатній контекст цей співробітник може несправедливо пропустити річний перегляд заробітної плати.
В цю категорію можна віднести пріоритетність джерел та source of truth. Особливо небезпечні сценарії, де агент діє на основі неповних або суперечливих даних. Наприклад, якщо в HRM співробітник уже переведений у нову команду, але в IAM ще стара роль, агент може видати неправильну рекомендацію щодо доступів.

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

Ключові принципи безпеки AI-агента

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

1. Мінімум інформації та прав (виключно те що необхідно для роботи агента). Повторюся: Агенту необхідно надати виключно ту інформацію та доступи, які необхідні для виконання ним поставлених задач. Для окремої функції агента це працює так само.
2. Політика нульової довіри до LLM. Якщо ви вважаєте що якась ризикова ситуація для вашої компанії не є важливою для пропрацювання, будьте готові до її виникнення та всіх супутніх наслідків.
3. Агент не може сам відповідати за свою безпеку. Вся логіка безпеки має бути в окремому, ізольованому модулі, який діє незалежно і безперервно.

Guardrails (Системи безпеки)

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

Наприклад, співробітник хоче створити запит на відпустку (який потребує підтвердження від співробітника):

1. Агент отримує повідомлення, формує та перевіряє свою відповідь.
2. В момент перед створенням запиту агентом спеціальний механізм безпеки бачить, що ця дія потребує підтвердження.
3. Механізм безпеки призупиняє поточну сесію агента і відправляє запит користувачу на підтвердження дії.
4. Якщо дозвіл отримано, агент продовжує роботу.

Вся guardrails логіка — це не один модуль, а комплексна система, яка реагує на всі можливі інциденти. Чим більше агент має повноважень та доступів, тим складніше буде система безпеки. В окремих випадках guardrails можуть проєктуватись та розроблятись довше, ніж сам агент.

І зауважте, що просто розробити безпековий мікросервіс (і забути про це) недостатньо. У вашій компанії мають бути відповідні правила, політики, відповідальні тощо. І все це має працювати разом.

Витрати на ризик-менеджмент

Післямова

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

У наступній статті я напишу про третій наріжний камінь будь-якої AI-системи: контроль якості. І поясню, чому, якщо кожна з 5 складових вашого AI-агенту точна на 97%, то точність агента в цілому в районі 86%, а не 97%.

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

Оригінал статті в моєму телеграм-каналі ai last.