EU AI Act 2026: вимоги до AI для бізнесу в ЄС

Більшість власників бізнесу в ЄС чули про EU AI Act — але мало хто розуміє що конкретно і коли стає обов'язковим. Медичний центр у Відні що використовує AI-чат для відповідей пацієнтам, юридична фірма у Франкфурті з AI-асистентом для роботи з договорами, дистриб'ютор у Мюнхені з AI-інструментом для менеджерів — всі вони підпадають під дію AI Act. Питання лише в тому до якої категорії ризику потрапляє їхня система і які конкретно зобов'язання це накладає.

У цій статті — чіткий таймлайн, чотири рівні ризику з конкретними прикладами, вимоги для медицини і юристів у DE/AT, і пояснення чому архітектура вашої AI-системи — self-hosted або хмарна — безпосередньо впливає на відповідність закону.

Що таке EU AI Act і чому він стосується вашого бізнесу зараз

EU AI Act — це Регламент ЄС 2024/1689, прийнятий 21 травня 2024 року і опублікований 12 липня 2024 року. Він набув юридичної чинності 1 серпня 2024 року. За своєю логікою він схожий на GDPR — також регулює не конкретні технології, а ризики від їхнього використання, також має екстериторіальне застосування і також передбачає серйозні штрафи за порушення.

Ключова відмінність від GDPR: якщо GDPR регулює як ви обробляєте персональні дані, то AI Act регулює які AI-системи ви використовуєте і для чого. Ці два регламенти не замінюють — а доповнюють один одного. Якщо ваша AI-система обробляє персональні дані клієнтів або пацієнтів — вона підпадає одночасно під GDPR і під AI Act.

Чому це стосується саме вашого бізнесу зараз. AI Act застосовується до будь-якої організації що розміщує AI-системи на ринку ЄС або використовує їх у своїй діяльності в ЄС — незалежно від того де знаходиться розробник системи. Тобто якщо ви медичний центр у Відні що підключив американський AI-чат-бот для відповідей пацієнтам — ви як deployer (впроваджувач) підпадаєте під зобов'язання AI Act. Якщо ви юридична фірма у Берліні що використовує SaaS AI-сервіс для аналізу договорів — аналогічно.

Закон розрізняє два типи операторів: provider (розробник що створює або замовляє AI-систему і виводить її на ринок) і deployer (організація що використовує готову AI-систему у своїй діяльності). Більшість бізнесів — медичні центри, юридичні фірми, дистриб'ютори — є deployers. Зобов'язань у deployers менше ніж у providers, але вони реальні і обов'язкові.

Таймлайн впровадження: що вже діє, що запускається в серпні 2026

AI Act впроваджується поетапно — не все одночасно. Ось точний таймлайн:

Що вже відбулось і що означає для бізнесу. З 2 лютого 2025 року заборонені 8 категорій AI-практик — включаючи соціальний скоринг, системи розпізнавання емоцій на робочих місцях і в навчальних закладах, масовий збір біометричних даних. Штраф за порушення цих заборон: до €35 мільйонів або 7% річного глобального обороту — залежно від того що більше (ст. 99 AI Act).

З 2 серпня 2025 року провайдери GPAI-моделей (OpenAI, Google, Anthropic, Mistral) зобов'язані надавати технічну документацію, дотримуватись авторських прав і публікувати summary про дані для тренування. OpenAI, Google, Mistral і Microsoft вже підписали відповідний Code of Practice. Meta відмовилась — і зараз перебуває в регуляторній невизначеності.

Ключова дата для більшості бізнесів — 2 серпня 2026. З цього дня повністю застосовуються вимоги до high-risk AI систем по Annex III. Це стосується AI в медицині, юриспруденції, фінансах, освіті, зайнятості та критичній інфраструктурі. На сьогодні (квітень 2026) — залишилось менше 100 днів.

Примітка: У листопаді 2025 Єврокомісія запропонувала Digital Omnibus — пакет спрощень що може скоригувати дату застосування high-risk правил. На момент написання статті ця пропозиція ще не прийнята і обговорюється в Європейському парламенті. До прийняття — офіційна дата залишається 2 серпня 2026.

Чотири рівні ризику: до якої категорії потрапляє ваша AI-система

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

Перш ніж читати далі: якщо ви не впевнені до якої категорії відноситься ваша система — скористайтесь безкоштовним Compliance Checker від Future of Life Institute. Інструмент задає 10–15 питань і дає попередню класифікацію.

Рівень 1: Неприйнятний ризик — заборонено з 2 лютого 2025

Це AI-системи що становлять пряму загрозу для фундаментальних прав, безпеки або гідності людини. Вони повністю заборонені на території ЄС — не регулюються, а саме заборонені. Стаття 5 AI Act містить вичерпний перелік з 8 категорій. Заборони набрали чинності 2 лютого 2025 року.

Що конкретно заборонено:

• Соціальний скоринг: AI-системи що оцінюють людей за поведінкою, соціальними характеристиками або особистісними рисами і на основі цього визначають їхній доступ до послуг, можливостей або обмежують права. Аналог китайської системи соціального кредиту — повністю заборонений.
• Маніпуляція через підсвідомі техніки: AI що використовує сублімінальні методи або навмисно експлуатує психологічні слабкості щоб змінити поведінку людини у спосіб що шкодить їй. Сюди потрапляють AI-системи що маніпулюють вразливими групами — дітьми, людьми похилого віку, людьми з психічними розладами.
• Розпізнавання емоцій на робочих місцях і в школах: AI що аналізує емоційний стан співробітників або учнів — за виразом обличчя, голосом, поведінкою. Це пряма заборона для HR-tech рішень що намагаються "читати" емоції персоналу під час роботи.
• Масовий збір біометричних даних: нецільовий скрапінг інтернету або CCTV-записів для побудови або розширення баз даних розпізнавання облич.
• Біометрична категоризація: AI що визначає расу, політичні погляди, релігію, сексуальну орієнтацію або інші захищені характеристики на основі біометричних даних.
• Передбачення злочинів на основі профілювання: AI що оцінює ризик вчинення злочину конкретною людиною на основі особистісних характеристик, а не об'єктивних доказів.
• Дистанційна біометрична ідентифікація в реальному часі у публічних місцях: системи розпізнавання облич у реальному часі для правоохоронних цілей у публічних просторах — з вузькими виключеннями для критичних ситуацій.

Штраф за порушення: до €35,000,000 або 7% глобального річного обороту — залежно від того що більше (ст. 99 AI Act). Для компанії з €10 млн обороту — максимум €700,000. Для компанії з €1 млрд обороту — €70,000,000.

Що це означає для МСБ практично: якщо ваш HR-відділ розглядає AI-інструмент що "аналізує мікровирази обличчя на співбесідах" або "оцінює емоційний стан персоналу" — це пряме порушення ст. 5 AI Act що діє вже зараз. Таких інструментів слід уникати незалежно від того як їх позиціонує продавець.

Рівень 2: Високий ризик (High-risk) — строгі вимоги з 2 серпня 2026

Це найширша і найважливіша категорія з точки зору комплаєнсу для бізнесу. High-risk AI системи не забороняються — але підпадають під детальне регулювання. Повний перелік міститься в Annex III AI Act і охоплює вісім сфер де AI може суттєво впливати на права, здоров'я або добробут людей.

Вісім сфер high-risk AI:

• Біометрія: системи дистанційної ідентифікації особи (не в реальному часі), AI для біометричної категоризації, системи розпізнавання емоцій (окрім заборонених випадків на роботі і в школах). Приклад: система верифікації особи при вході до офісу або онлайн-банкінгу.
• Критична інфраструктура: AI як компонент безпеки в управлінні водопостачанням, газом, електроенергією, дорожнім рухом, цифровою інфраструктурою. Приклад: AI що виявляє аномалії в енергосистемі або керує потоком трафіку.
• Освіта і навчання: AI що визначає доступ або зарахування до освітніх і навчальних закладів, оцінює учнів або студентів, визначає рівень знань. Приклад: AI-система що ранжує вступників до університету або автоматично виставляє оцінки на іспитах.
• Зайнятість і HR: AI для рекрутингу і відбору персоналу, скринінгу і фільтрації резюме, ранжування кандидатів, прийняття або підтримки рішень щодо умов праці. Приклад: AI що автоматично відфільтровує резюме або ранжує кандидатів для HR-менеджера — це high-risk. Важливо для бізнесу в ЄС: якщо ви використовуєте LinkedIn Recruiter з AI-функціями ранжування або будь-який ATS з AI-скринінгом — перевірте відповідність AI Act.
• Основні приватні та публічні послуги: AI для оцінки кредитоспроможності фізичних осіб або визначення кредитного рейтингу (крім виявлення шахрайства), AI для ризикового скорингу і ціноутворення в страхуванні життя і здоров'я, AI для оцінки права на соціальні виплати включно з медичною допомогою. Приклад: алгоритм банку що вирішує схвалити іпотеку або страхова модель що визначає розмір премії для конкретної людини.
• Правоохоронні органи: AI для оцінки ризику злочинності конкретної особи, полігрaфи і аналогічні системи виявлення брехні, AI для аналізу доказів і передбачення злочинів. Стосується поліції і спецслужб — не типових бізнесів.
• Міграція, притулок і прикордонний контроль: AI для оцінки ризику при в'їзді, обробки заявок на візи і притулок, ідентифікації осіб на кордоні. Стосується державних органів.
• Правосуддя і демократичні процеси: AI для допомоги судовим органам в аналізі фактів, тлумаченні закону, застосуванні закону до конкретних справ. Приклад: AI-інструмент що допомагає судді аналізувати справу — high-risk. AI що допомагає юристу знайти відповідний пункт у 300 договорах — не high-risk.

Зобов'язання для high-risk систем (Articles 9–15 AI Act):

• ✔️ Ст. 9: Система управління ризиками — задокументована, безперервна, охоплює весь lifecycle системи
• ✔️ Ст. 10: Управління даними — навчальні і тестові дані мають відповідати вимогам якості і репрезентативності
• ✔️ Ст. 11: Технічна документація — повний опис системи, її можливостей, обмежень і заходів безпеки — підготовлена до розгортання
• ✔️ Ст. 12: Журналювання (logging) — автоматичне ведення журналу подій для забезпечення аудитоспроможності і виявлення ризиків
• ✔️ Ст. 13: Прозорість для deployers — чіткі інструкції для бізнесу що використовує систему про її призначення, обмеження і ризики
• ✔️ Ст. 14: Людський нагляд — людина повинна мати можливість ефективно контролювати систему, розуміти її рішення і мати можливість призупинити або скасувати їх
• ✔️ Ст. 15: Точність, надійність, кібербезпека — задокументовані метрики точності, стійкість до атак і помилок
• ✔️ Реєстрація в EU AI database — до введення в експлуатацію
• ✔️ Conformity assessment — для деяких категорій (біометрія, медичні пристрої) необхідна незалежна оцінка відповідності нотифікованим органом

Штраф за невідповідність: до €15,000,000 або 3% глобального річного обороту — залежно від того що більше.

Що це означає для МСБ практично: якщо ваша компанія у DE/AT використовує AI-інструмент для скринінгу резюме, автоматичної оцінки кандидатів або визначення кредитного рейтингу клієнтів — ці системи є high-risk. До 2 серпня 2026 потрібна технічна документація, задокументована система нагляду і — якщо провайдер не забезпечує відповідність — або міграція на відповідну систему або відмова від функціоналу.

Рівень 3: Обмежений ризик — вимоги прозорості з 2 серпня 2026

Це AI-системи що безпосередньо взаємодіють з людьми або генерують контент — але не приймають рішень що суттєво впливають на права чи добробут. Зобов'язань тут набагато менше ніж для high-risk: головне — прозорість. Людина повинна знати що вона взаємодіє з AI.

Що підпадає під обмежений ризик (ст. 50 AI Act):

• Чат-боти і AI-асистенти що спілкуються з людьми: будь-який публічний або напівпублічний AI-чат — на сайті клініки, інтернет-магазину, юрфірми, банку. З 2 серпня 2026 система повинна явно повідомляти користувача при початку взаємодії що він спілкується з AI. Формулювання "Powered by AI" дрібним шрифтом внизу сторінки — не відповідає вимозі. Потрібне чітке повідомлення на початку сесії.
• Системи генерації зображень, відео, аудіо або тексту: AI що генерує deepfakes або синтетичний контент призначений для публічного поширення — повинен маркувати вихідний контент як AI-згенерований у машиночитаному форматі.
• AI що синтезує голос реальної людини: повинен розкривати що голос синтетичний.

Штраф за порушення ст. 50: до €15,000,000 або 3% глобального річного обороту.

Що це означає для МСБ практично: якщо у вас AI-чат на сайті медичного центру, юрфірми або дистриб'ютора — до 2 серпня 2026 потрібно додати явне повідомлення при початку чату. Це технічно нескладно але юридично обов'язково. Невиконання — це штраф того ж рівня що й для high-risk систем за порушення ст. 13.

Рівень 4: Мінімальний або нульовий ризик — без додаткового регулювання

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

Жодних додаткових зобов'язань за AI Act для цієї категорії немає. Але загальні вимоги GDPR щодо обробки персональних даних — залишаються в силі незалежно від категорії ризику AI Act.

Де в цій класифікації знаходиться AI-асистент на документах

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

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

Конкретні вимоги для бізнесу у DE/AT: медицина, юристи, фінанси

AI Act — загальноєвропейський регламент, але він не працює у вакуумі. У Німеччині та Австрії він взаємодіє з власними GDPR-імплементаціями, галузевим законодавством і професійними кодексами. Для медичних центрів, юридичних фірм і фінансових компаній у DE/AT це означає подвійний або потрійний шар вимог — і ігнорування будь-якого з них створює юридичний ризик. Детальніше про специфіку GDPR у DE/AT — у статті AI та GDPR в Німеччині й Австрії: вимоги до корпоративних систем.

Медичні центри в Австрії та Німеччині

Медицина — найбільш регульована сфера в контексті AI в ЄС. AI-системи в медицині підпадають одночасно під чотири шари законодавства: EU AI Act, GDPR (ст. 9 — спеціальні категорії даних), EU Medical Device Regulation (MDR 2017/745) і національне медичне законодавство. Всі чотири шари діють паралельно і не замінюють один одного.

Що є high-risk в медицині за AI Act (Annex III):

• AI що допомагає в діагностиці захворювань або призначенні лікування — high-risk, і водночас підпадає під MDR як програмне забезпечення медичного пристрою
• AI для тріажу пацієнтів і диспетчеризації швидкої допомоги — high-risk з обов'язковим людським наглядом лікаря або диспетчера
• AI для оцінки права пацієнта на державну медичну допомогу або субсидію — high-risk як система що впливає на доступ до основних послуг

Що не є high-risk але підпадає під рівень 3 (обмежений ризик): AI-асистент що відповідає на інформаційні запитання пацієнтів з протоколів клініки — "як підготуватись до гастроскопії?", "що взяти з собою на прийом?", "скільки часу займає МРТ?" — не є high-risk за AI Act. Але він підпадає під ст. 50 (вимога прозорості) і під GDPR якщо в процесі взаємодії збирає будь-які персональні дані пацієнта.

Практичні вимоги для медичного центру в Австрії або Німеччині:

• Явне повідомлення про AI (ст. 50 AI Act, чинна з 02.08.2026): пацієнт при початку чату повинен отримати чітке повідомлення що він спілкується з AI-системою. Недостатньо написати "AI Chat" у заголовку — вимога стосується активного повідомлення на початку кожної сесії. Формулювання: "Ви спілкуєтесь з AI-асистентом клініки [назва]. Для медичних консультацій зверніться до лікаря."
• Заборона на медичні рішення без лікаря: AI не може самостійно рекомендувати діагноз, призначати або відміняти лікування, визначати дозування. Будь-яке формулювання у відповіді AI що може бути інтерпретоване як медична рекомендація — юридичний ризик. Система повинна мати вбудоване обмеження і чітке направлення до спеціаліста.
• Локація серверів і GDPR (ст. 9 GDPR): медичні дані — спеціальна категорія персональних даних що потребує окремої правової підстави для обробки. Обробка через американські хмарні сервіси (OpenAI API, Google Cloud, AWS) вимагає Standard Contractual Clauses (SCCs), Transfer Impact Assessment (TIA) і — у більшості випадків — додаткових технічних захисних заходів. На практиці для більшості медичних центрів у DE/AT це означає що єдиний безпечний варіант — сервер у ЄС під управлінням не-американської компанії.
• Австрія — § 54 Ärztegesetz (лікарська таємниця): лікарська таємниця в Австрії захищена кримінальним законом і поширюється на будь-яку систему що обробляє медичні дані пацієнтів — включно з AI-асистентами. Передача цих даних до провайдера що підпадає під CLOUD Act США (навіть через зашифрований API) — потенційне порушення § 54. Документи про лікарську таємницю мають бути оновлені щоб охоплювати AI-компоненти.
• Німеччина — Bundesdatenschutzgesetz (BDSG) і Patientendatenschutzgesetz (PDSG): PDSG (Закон про захист даних пацієнтів, 2020) встановлює додаткові вимоги до обробки медичних даних у цифрових системах. AI-система що обробляє дані пацієнтів повинна відповідати PDSG незалежно від того де розташований сервер.
• Журналювання запитів: навіть для інформаційних AI-чатів (рівень 3) ведення журналу рекомендується як елемент accountability під GDPR і AI Act. Для high-risk систем журналювання — обов'язкове (ст. 12). Мінімальний термін зберігання логів для медичних систем — узгоджений з вашим Data Protection Officer (DPO), зазвичай 6–12 місяців.
• Data Protection Impact Assessment (DPIA): якщо AI-система обробляє медичні дані пацієнтів у значному обсязі — DPIA обов'язковий за ст. 35 GDPR. Для high-risk AI систем додатково може вимагатись Fundamental Rights Impact Assessment (FRIA) за AI Act. На практиці рекомендується об'єднати обидва в один процес оцінки.

Детальніше про обробку медичних даних через AI і GDPR — у статті AI в медицині: як обробляти медичні дані без порушення закону.

Юридичні фірми в Австрії та Німеччині

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

Що є high-risk для юридичних фірм за AI Act: AI що допомагає судовому органу аналізувати факти справи або тлумачити закон — high-risk по Annex III п. 8. AI що допомагає юристу знаходити релевантні пункти в договорах або формулювати аргументи — не high-risk, але підпадає під вимоги прозорості якщо взаємодіє з клієнтом напряму.

Специфіка DE/AT для юридичних фірм:

• Німеччина — BRAO § 43e і BORA: Bundesrechtsanwaltsordnung (§ 43e) зобов'язує адвокатів використовувати технічні засоби таким чином щоб гарантувати конфіденційність клієнтських даних. Berufsordnung für Rechtsanwälte (BORA) деталізує ці вимоги. AI-система що передає матеріали справ до американського хмарного провайдера — потенційно порушує § 43e навіть при наявності DPA. Причина: американські провайдери підпадають під CLOUD Act США незалежно від локації серверів і можуть бути зобов'язані надати дані американським правоохоронним органам.
• Австрія — RAO § 9 (Verschwiegenheitspflicht): адвокатська таємниця в Австрії — Verschwiegenheitspflicht — захищена § 9 Rechtsanwaltsordnung і є абсолютним обов'язком. Порушення тягне за собою дисциплінарну відповідальність аж до позбавлення адвокатського статусу. Österreichischer Rechtsanwaltskammertag (ÖRAK — Австрійська палата адвокатів) рекомендує адвокатам використовувати виключно системи де дані обробляються в межах ЄС і не підпадають під юрисдикцію третіх країн.
• Вимога прозорості AI Act (ст. 50) для клієнтів: якщо юридична фірма використовує AI для генерації чернеток документів, меморандумів або листів що підписує партнер — клієнт має право знати про використання AI. Це не означає що потрібно вказувати це в кожному листі — але загальна політика фірми щодо використання AI повинна бути задокументована і доступна клієнту на запит. Ряд юридичних асоціацій у DE/AT рекомендує включати положення про використання AI в retainer agreement з клієнтом.
• Record of Processing Activities (ROPA) з AI-компонентом: за GDPR (ст. 30) юрфірма зобов'язана вести реєстр операцій обробки даних. Кожен AI-інструмент що обробляє клієнтські дані повинен бути відображений в ROPA з зазначенням: назва інструменту, провайдер, локація обробки, категорія даних, правова підстава, технічні заходи захисту. Відсутність запису в ROPA — порушення GDPR незалежно від AI Act.
• Обмеження на які документи можна завантажувати в AI: матеріали активних справ, клієнтські договори з конфіденційними умовами, листування що містить адвокатську таємницю — не можна завантажувати в будь-який хмарний AI-сервіс де дані обробляються поза вашим контролем. Виняток — self-hosted системи де ви є єдиним оператором даних і дані фізично не покидають ваш сервер. Детальніше про це — у статті AI для юридичних компаній: безпека клієнтських даних.
• Що можна завантажувати безпечно: публічні нормативні акти, судову практику з відкритих реєстрів, внутрішні методичні посібники фірми що не містять клієнтських даних, шаблони документів без персональної інформації — все це можна завантажувати в AI-систему для пошуку і відповідей, навіть якщо сервер знаходиться не у ЄС. Але як тільки в документі з'являються ПІБ клієнта, реквізити справи або конфіденційні умови — вимоги до зберігання і обробки стають максимальними.

Фінансові компанії та страхування в Австрії та Німеччині

Фінансовий сектор — зона максимальної уваги AI Act. Annex III прямо відносить до high-risk категорії два ключові use cases що є стандартними для банків і страхових компаній: оцінка кредитоспроможності фізичних осіб і ризиковий скоринг у страхуванні. Поряд з AI Act фінансові компанії у DE/AT підпадають під пруденційне регулювання BaFin і FMA що вже мають власні вимоги до алгоритмічних рішень.

Що є high-risk для фінансових компаній за AI Act (Annex III):

• Оцінка кредитоспроможності фізичних осіб: будь-яка AI-система що визначає кредитний рейтинг, скоринг або рішення про надання кредиту, іпотеки або лізингу конкретній фізичній особі — high-risk. Виняток: AI для виявлення фінансового шахрайства — явно виключений з high-risk категорії Annex III.
• Ризиковий скоринг і ціноутворення в страхуванні: AI що визначає страховий тариф або умови полісу для конкретної людини на основі оцінки ризику — high-risk. Стосується страхування життя, здоров'я і потенційно автострахування де тариф визначається індивідуально.

Зобов'язання для фінансових компаній з 2 серпня 2026:

• Технічна документація (ст. 11): повний опис AI-системи — архітектура, дані для навчання, метрики точності, відомі обмеження і ризики — підготовлений до розгортання і оновлюваний при змінах системи. У разі аудиту BaFin або FMA — надається за запитом.
• Система управління ризиками (ст. 9): задокументований безперервний процес ідентифікації, оцінки і мінімізації ризиків AI-системи протягом всього її lifecycle. Не одноразовий звіт — а операційний процес з призначеними відповідальними і регулярними переглядами.
• Аудиторський журнал (ст. 12): автоматичне логування всіх рішень системи з достатнім рівнем деталізації щоб відновити чому система прийняла конкретне рішення щодо конкретної людини. Для кредитних і страхових рішень — критично важливо для відповіді на скарги клієнтів і запити регуляторів.
• Людський нагляд (ст. 14): для high-risk фінансових рішень AI не може бути єдиним і фінальним арбітром. Повинна бути задокументована процедура людського перегляду — особливо для відмов і граничних випадків. Клієнт має право вимагати пояснення рішення і людського перегляду.
• Реєстрація в EU AI database: до введення high-risk системи в експлуатацію після 2 серпня 2026.
• BaFin (Німеччина): Bundesanstalt für Finanzdienstleistungsaufsicht вже видав рекомендації щодо AI в фінансовому секторі і зазначив що очікує від піднаглядних компаній проактивного підходу до комплаєнсу AI Act. AI-системи для кредитних рішень підпадають додатково під вимоги Basel III щодо model risk management і пояснюваності алгоритмічних рішень.
• FMA (Австрія): Finanzmarktaufsicht Österreich аналогічно очікує від банків і страхових компаній документування AI-систем що впливають на рішення щодо клієнтів. Австрійський DSG (Datenschutzgesetz) додає вимоги до обробки персональних даних при автоматизованих фінансових рішеннях.
• Право клієнта на пояснення (GDPR ст. 22 + AI Act ст. 13): фізична особа щодо якої AI прийняв автоматизоване рішення (відмова в кредиті, підвищення страхової премії) має право вимагати пояснення і людського перегляду. Ця вимога діє вже зараз за GDPR і посилюється AI Act. Фінансові компанії повинні мати задокументовану процедуру відповіді на такі запити.

Що не є high-risk для фінансових компаній: внутрішній AI-асистент що допомагає менеджерам знаходити інформацію у внутрішніх регламентах і продуктових описах — не high-risk, це рівень 4 (мінімальний ризик). AI що відповідає клієнтам на загальні питання про продукти банку через чат на сайті — рівень 3 (обмежений ризик, вимога прозорості). Різниця принципова: один і той самий банк може мати одночасно high-risk систему (кредитний скоринг) і систему мінімального ризику (внутрішній довідник для персоналу).

Чому хмарний AI створює проблеми з AI Act — і де self-hosted виграє

AI Act і GDPR разом створюють compliance-ландшафт де архітектурне рішення — де фізично розгорнута ваша AI-система і хто є оператором даних — має пряме юридичне значення. Це не питання переваг чи зручності. Це питання того чи можете ви виконати конкретні вимоги статей 9–15 AI Act і ст. 5, 24, 28 GDPR при використанні хмарного сервісу американського походження. Для більшості бізнесів у DE/AT що обробляють чутливі дані — відповідь ускладнена трьома системними проблемами.

Детальніше про те де фізично зберігаються ваші дані при різних AI-сервісах — у статті Self-hosted AI vs хмарний: де залишаються ваші дані.

Проблема 1: CLOUD Act США vs GDPR і AI Act

CLOUD Act (Clarifying Lawful Overseas Use of Data Act, США, 2018) дозволяє американським правоохоронним органам вимагати від американських компаній надати дані що зберігаються на їхніх серверах — незалежно від того де фізично знаходяться ці сервери. OpenAI, Google, Microsoft, Amazon, Notion, Salesforce — всі є американськими компаніями і всі підпадають під CLOUD Act. Це означає що навіть якщо ваш OpenAI-based AI-асистент розгорнутий на серверах у Франкфурті — за судовим ордером США OpenAI може бути зобов'язана надати доступ до цих даних американській стороні.

GDPR і AI Act не скасовують і не блокують CLOUD Act — вони регулюють різні юрисдикції. DPA (Data Processing Agreement) з американським провайдером і TIA (Transfer Impact Assessment) — обов'язкові документи, але вони знижують ризик для більшості даних, не усуваючи його для найчутливіших категорій. Для медичних даних пацієнтів (ст. 9 GDPR — спеціальні категорії), матеріалів судових справ що підпадають під адвокатську таємницю, або фінансових даних клієнтів з вимогами банківської таємниці — навіть підписаний DPA не є достатнім захистом. Австрійська палата адвокатів (ÖRAK) і ряд земельних адвокатських палат Німеччини прямо рекомендують не використовувати американські хмарні AI-сервіси для обробки матеріалів справ саме через ризик CLOUD Act.

Що це означає на практиці: якщо ви медичний центр у Відні або юридична фірма у Мюнхені і використовуєте ChatGPT API або Notion AI для роботи з чутливими даними клієнтів — у вас є відкрита юридична вразливість яку не закриває жоден договір з провайдером. Self-hosted система на сервері Hetzner у Нюрнберзі або Гельсінкі — під управлінням німецької або фінської компанії — виключає цей ризик архітектурно: американські правоохоронці не мають юрисдикції над даними що ніколи не потрапляли до американської компанії.

Проблема 2: Прозорість, документація і контроль над системою

AI Act вимагає від deployers — тобто від вас як бізнесу що використовує AI — конкретних можливостей: пояснити як система приймає рішення (ст. 13), продемонструвати контроль над нею (ст. 14), мати технічну документацію системи (ст. 11) і вести журнал її роботи (ст. 12).

Хмарний SaaS-провайдер надає вам документацію своєї системи — але не вашої конкретної інсталяції. OpenAI публікує системну карту GPT-4, Microsoft публікує документацію Copilot — але ця документація описує базову модель, не те як саме ваша компанія її налаштувала, які документи завантажила і який системний промпт використовує. Для цілей AI Act комплаєнсу потрібна документація вашої конкретної системи — яку ви самі конфігурували і розгортали.

Є й інша проблема: хмарні провайдери оновлюють свої моделі — часто без попередження і без можливості залишитись на попередній версії. GPT-4o в лютому 2026 і GPT-4o в серпні 2026 — різні версії з різною поведінкою. Якщо ваша high-risk система пройшла conformity assessment у лютому, а провайдер у квітні оновив модель без вашого відома — технічно ваша документація застаріла і система потребує повторної оцінки. Self-hosted система де ви самі контролюєте яку версію моделі використовуєте — позбавлена цієї проблеми.

Що це означає на практиці: для рівня 3 (обмежений ризик) — хмарний AI цілком прийнятний якщо є DPA і явне повідомлення для користувачів. Для рівня 2 (high-risk) — хмарний AI вимагає значно більших зусиль для документування і доведення відповідності: ви фактично змушені документувати чужу систему, яку не контролюєте і яка може змінитись без вашого відома. Детальніше — у статті Self-hosted AI vs SaaS: що обрати для корпоративних документів.

Проблема 3: Людський нагляд і реальний контроль над системою

Стаття 14 AI Act вимагає щоб для high-risk систем людина могла ефективно контролювати систему, розуміти її рішення, і мати можливість призупинити або скасувати їх. Це не просто вимога до інтерфейсу — це вимога до архітектури: система повинна бути спроектована так щоб людський нагляд був реально можливим, а не формальним.

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

Self-hosted система дає інший рівень контролю: ви самі визначаєте яку модель використовуєте (Llama, Mistral, Qwen або GPT через OpenRouter), самі конфігуруєте системний промпт і обмеження, самі контролюєте коли і яка версія оновлюється. Якщо модель поводиться неочікувано — ви можете відкотити до попередньої версії, змінити конфігурацію або повністю замінити LLM-провайдера без зміни решти системи. Це і є реальний людський нагляд у розумінні ст. 14 AI Act.

Проблема 4: Відповідальність і ланцюжок операторів

AI Act чітко розрізняє provider (розробника системи) і deployer (бізнес що її використовує) і розподіляє між ними зобов'язання. Але коли ви використовуєте хмарний SaaS — ланцюжок відповідальності ускладнюється: є розробник базової моделі (наприклад OpenAI), є SaaS-провайдер що будує продукт на основі цієї моделі, і є ви як кінцевий deployer. Якщо щось піде не так — регулятор прийде до вас як до deployer, і ваша відповідь "це провайдер винен" не звільняє вас від відповідальності за ст. 26 AI Act.

Self-hosted система де ви є і deployer і фактичним оператором — спрощує цей ланцюжок. Ви знаєте що використовуєте, документуєте свою систему, і несете відповідальність за власну інсталяцію — не за чужу платформу яку не контролюєте.

Де self-hosted виграє з точки зору AI Act і GDPR

Чесне застереження: self-hosted не означає автоматичну відповідність AI Act. Ви все одно повинні: явно повідомляти користувачів про взаємодію з AI (ст. 50), вести журнал запитів, документувати свою систему і — якщо ваш use case є high-risk — виконати повний перелік вимог ст. 9–15. Self-hosted дає вам інструменти для виконання цих вимог і усуває структурні бар'єри що виникають при роботі з хмарними провайдерами. Але самої по собі архітектури недостатньо — потрібні задокументовані процеси, призначені відповідальні і регулярний перегляд системи.

Докладніше про ризики витоку даних через AI-сервіси і як їх перевірити — у статті 6 ризиків витоку даних через AI в бізнесі.

Чеклист: що перевірити у вашій системі до серпня 2026

До 2 серпня 2026 залишилось менше 100 днів. Ось що потрібно перевірити зараз — незалежно від того яку AI-систему ви використовуєте.

Про підготовку документів для AI-системи — у статті Як підготувати документи для AI-асистента: що завантажувати і що ні.

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

Чи стосується AI Act малого бізнесу або МСБ?

Так — але з пропорційним підходом до штрафів. Для МСБ і стартапів штраф розраховується як менша з двох сум (фіксована або відсоток від обороту). Тобто для компанії з €500,000 річного обороту максимальний штраф першого рівня — €35,000 (7% від обороту), а не €35 мільйонів. Але зобов'язання щодо прозорості (ст. 50) і заборони (ст. 5) — однакові для всіх незалежно від розміру.

Чи підпадає AI-чат на сайті клініки під AI Act?

Так — як мінімум під вимоги прозорості рівня 3 (ст. 50). З 2 серпня 2026 чат повинен явно повідомляти пацієнтів що вони спілкуються з AI. Якщо чат лише відповідає на інформаційні питання з протоколів клініки — це обмежений ризик. Якщо він допомагає в діагностиці або тріажі — це потенційно high-risk з повним набором вимог.

Чи достатньо підписати DPA з AI-провайдером для відповідності AI Act?

DPA (Data Processing Agreement) — обов'язковий для GDPR, але не достатній для повної відповідності AI Act. AI Act додатково вимагає прозорості системи, журналювання, людського нагляду і — для high-risk систем — технічної документації та реєстрації. DPA вирішує питання "де і як зберігаються дані", але не вирішує питання контролю над AI-системою і аудитоспроможності.

Що таке Transfer Impact Assessment (TIA) і коли він потрібен?

TIA — оцінка впливу передачі даних до третьої країни (наприклад США) яку вимагає GDPR після рішення Schrems II (2020). Якщо ваш AI-провайдер — американська компанія і обробляє дані ваших клієнтів або пацієнтів на серверах поза ЄС — TIA обов'язковий. Навіть якщо сервери фізично в ЄС але провайдер американський — TIA рекомендується через ризик CLOUD Act.

Хочете перевірити чи ваша AI-система відповідає вимогам AI Act?

Ми в AskYourDocs будуємо self-hosted AI-асистентів на документах для МСБ, медичних центрів і юридичних фірм — з розгортанням на сервері в ЄС (Hetzner DE/FI або OVH FR) і архітектурою що відповідає вимогам GDPR і AI Act.

Надішліть нам 2–3 ваших реальних документи. За 30 хвилин покажемо живу демонстрацію і розберемо до якої категорії ризику AI Act потрапляє ваш use case і що конкретно потрібно для відповідності.

Написати в Telegram →

Впровадження під ключ за 5–7 днів. Від $500 разово. Сервер у ЄС. Без IT-команди з вашого боку.

Джерела:

• Регламент ЄС 2024/1689 (EU AI Act) — офіційний текст
• Єврокомісія: AI Act — таймлайн і впровадження
• artificialintelligenceact.eu — High-level summary of the AI Act (Future of Life Institute)
• Annex III AI Act — повний перелік high-risk AI систем
• Article 99 AI Act — штрафи і санкції
• EU AI Act Compliance Checker (безкоштовний інструмент)
• LegalNodes: EU AI Act 2026 Updates — Compliance Requirements and Business Risks
• Legiscope: EU AI Act Practical Compliance Guide for 2026 (березень 2026)
• Matproof: EU AI Act Fines and Penalties — три рівні штрафів (березень 2026)
• Єврокомісія: Navigating the AI Act — FAQ для бізнесу