AI Act: системи високого риску на практиці (HR, фінанси, скоринг)

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

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

Додаток III до AI Act прямо перелічує сфери високого ризику. Для польських компаній важливі чотири:

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

Коли система кваліфікується як високого ризику, AI Act накладає шість конкретних обов’язків. Це не рекомендації.

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

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

3. Прозорість щодо особи, якої стосується рішення. Особа, якої торкнулася система, має право знати, що рішення було підтримане AI, і вимагати пояснення логіки. Це вимога, яка має бути технічно реалізована, а не просто згадана в правилах.

4. Управління ризиками. Безперервний цикл: ідентифікація ризиків перед впровадженням, моніторинг після впровадження, оновлення документації при зміні моделі або даних. Щонайменше раз на рік; частіше при суттєвих змінах.

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

6. DPIA при обробці персональних даних. Якщо система обробляє персональні дані (а це майже завжди так), паралельно діє RODO. Оцінка впливу на захист даних є обов’язковою, якщо ризик високий. На практиці: скоринг кандидатів, кредитний скоринг та профілювання клієнтів завжди вимагають DPIA.

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

Три технічні вимоги, які мають бути виконані до того, як така система потрапить у продакшн:

• Класифікатор має працювати на анонімізованих характеристиках. Ім’я (вказівка на стать та етнічність), вік та адреса проживання мають бути видалені перед передачею до моделі оцінки. Не через політику, а через PII masking на рівні коду.
• Кожна рекомендація має мати лог пояснення. Які характеристики вирішили ранг цього кандидата? Без цього логу не можна довести відсутність дискримінації та відповісти на запитання кандидата про підставу рішення.
• Human-gate перед комунікацією з кандидатом. Жодна автоматична відповідь про відмову не виходить без затвердження рекрутером. AI пропонує, людина затверджує.

Детальніше про архітектуру рекрутингового пайплайну та навчальні дані розповідає стаття AI в HR та рекрутингу.

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

Специфічні вимоги для фінансових систем:

• Пояснюваність кожного рішення. Клієнт, якому відмовили в кредиті за допомогою системи AI, має право на пояснення основних факторів рішення. SHAP values, LIME або інший механізм пояснюваності має бути реалізований у продакшені, а не лише в аналітичному ноутбуці.
• Тестованість на дискримінацію. Скорингова модель має регулярно тестуватися на контрольних наборах даних, чи не відрізняються показники схвалення систематично між захищеними групами. Різниця, яку не можна пояснити фінансовими змінними, — це регуляторна проблема.
• Людський нагляд над граничними рішеннями. Заявки, чий скоринг потрапляє в інтервал невизначеності, мають надходити на перевірку аналітиком, а не відхилятися автоматично алгоритмом.
• Ізоляція даних та data residency. Фінансові дані клієнтів не повинні залишати інфраструктуру, контрольовану установою, без шифрування та договорів про доручення даних. Self-hosting шару inference для найчутливіших даних є стандартом, а не розкішшю.

В Україні Національний банк України (НБУ) у 2025 році видав рекомендації щодо AI у фінансових послугах, які доповнюють AI Act галузевими вимогами. Кожна скорингова система для установ, що регулюються НБУ, має проходити аудит на відповідність обом наборам вимог.

Не кожен lead scoring є високим ризиком. Класифікація лідів B2B за відповідністю ICP (галузь, розмір компанії, активність на сайті) — це обмежений ризик, якщо результат не вирішує питання доступу до послуги.

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

Практичне правило для проектування системи:

Lead scoring, заснований на анонімній активності (сайт, UTM, тип компанії), є безпечним. Скоринг, що поєднує фінансові дані, дані з соцмереж та історію поведінки конкретної особи, потрапляє в регульовану зону.

Відповідність AI Act для систем високого ризику — це не шар, який додається в кінці проекту. Шість елементів, які проектуємо з першого коміту:

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

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

Guardrails з rejection логом. Кожен запит, який система відхилила через guardrails (вихід за межі, спроба змусити систему прийняти рішення поза її компетенцією), логується. Rejection log є доказом того, що система працює згідно з проектом.

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

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

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

Детальніше про моніторинг якості системи AI після впровадження розповідає окрема стаття.

Оцінка впливу на захист даних (DPIA) вимагається RODO, коли обробка може спричинити високий ризик. На практиці кожна система високого ризику AI Act, що обробляє персональні дані, вимагає DPIA. Тобто майже завжди.

Мінімальний зміст DPIA для системи AI:

• Опис мети обробки та вхідних даних
• Оцінка необхідності: чи можна досягти мети з меншим обсягом даних?
• Ідентифікація ризиків: несанкціонований доступ, алгоритмічна дискримінація, помилкове рішення
• Заходи щодо усунення ризиків: шифрування, masking PII, ізоляція даних, human-gate, логування
• Огляд через 12 місяців або при суттєвій зміні системи

DPIA — це робочий документ, а не формальність. Написаний сумлінно, він стає найкращою технічною документацією проекту та скорочує час відповіді на запити органів нагляду з тижнів до годин. Методику DPIA детальніше описує стаття AI Act та RODO 2026.

Опишіть свою систему (HR, скоринг, фінанси) та обсяг оброблюваних даних, а модель попередньо оцінить, які обов’язки AI Act можуть застосовуватися — як відправна точка для розмови з юристом, а не замість неї (playground: PII маскуються, нульова ретенція):

Не завжди. Скоринг на основі корпоративних даних (галузь, розмір, активність) без впливу на доступ до послуги зазвичай має обмежений ризик. Високий ризик виникає, коли скоринг стосується фізичних осіб у сферах, зазначених в AI Act — працевлаштування, фінанси, страхування, публічні послуги. Якщо скоринг стосується рішень щодо підприємця як фізичної особи (наприклад, одноосібна діяльність, скоринг для мікропозики), обов’язки AI Act можуть застосовуватися. Завжди варто це перевірити з юристом перед впровадженням у продакшн.

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

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

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

Ні. Guardrails блокують неавторизовані запити та обмежують діапазон відповідей системи — це необхідний шар безпеки. Але AI Act вимагає, щоб людина мала реальну можливість перевірити та відхилити кожне рішення, важливе для особи, якої воно стосується. Guardrails не є рішенням людини — це фільтр перед рішенням. Обидва шари мають бути присутніми та логуватися окремо.