Впровадження ШІ в публічному управлінні: прозорість та відповідність

Комунальний заклад Кракова-Кроводжа запускає чат-бота для обслуговування мешканців. Через шість тижнів він обробляє 300-400 запитів на день, скорочує час першого контакту з 48 до 4 годин і звільняє працівників від рутинних запитань щодо процедур реєстрації, графіків вивезення відходів та термінів подання заяв. Жодне адміністративне рішення не було прийнято моделлю. Це реалістичний сценарій, а не обіцянка, оскільки межа між інформаційною допомогою та адміністративним рішенням є чіткою і не може бути порушена без порушення закону.

Нижче описано, де проходить ця межа, які вимоги накладають на ОМС AI Act та RODO, а також як побудувати архітектуру, яка є відповідною, прозорою та можливою для підтримки типовим органом влади без десятків ІТ-фахівців.

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

Інформація з бази знань. Агент RAG, індексований на офіційних документах (регламенти, BIP, зразки документів, FAQ, графіки), відповідає на запитання мешканців природною мовою з цитуванням джерел. Модель не створює контент з уяви, а лише шукає та перефразовує публічно доступні документи. За належних guardrails система відмовляється відповідати поза межами документації та ескалує до працівника. Приклади запитань: «Які документи потрібні для реєстрації місця проживання?», «Коли можна подавати заяви на 500+?», «Куди скаржитися на невивезене сміття?»

Маршрутизація справ. Класифікатор на основі змісту звернення визначає відповідний відділ та терміновість. Мешканець описує справу в одному формулярі, система призначає її до технічного, фінансового, соціального або юридичного відділу без залучення працівника на першому етапі. Це structured output з жорсткою схемою: {відділ: enum, терміновість: 1-3, категорія: string, потребує_перевірки: bool}. Рішення про передачу приймає людина, ШІ лише пропонує.

Попереднє заповнення заяв. На основі даних сесії (наприклад, адреса з попередньої взаємодії) або інформації, наданої мешканцем, система попередньо заповнює поля форми. Мешканець перевіряє кожне поле та підтверджує перед поданням. Модель не подає заяву замість мешканця: вона допомагає її підготувати. Це типовий agent tool-use з дією fill_field, без дії submit_form без підтвердження людиною.

Адміністративне рішення в розумінні ст. 104 КУпАП — це одностороннє рішення органу, що формує права або обов’язки сторони. Дозвіл, відмова, припис, заборона, нарахування плати. Жодна з цих дій не може бути результатом автономного рішення системи ШІ, навіть якщо технічно це було б можливо.

Причини дві. Правова: КУпАП вимагає, щоб рішення підписав уповноважений працівник або орган, який несе за нього юридичну відповідальність. ШІ не є юридичною особою. Етична та регуляторна: AI Act у Додатку III п. 1 та 5 класифікує як високоризикові системи ШІ, що використовуються для прийняття рішень щодо доступу до публічних послуг, соціальних виплат та оцінки юридичних ризиків. Для таких систем вимоги суворі: технічна документація, аудитні логи, human-oversight як операційна умова, explainability на вимогу.

Практичні приклади межі:

• Чат-бот може сказати: «Для отримання допомоги потрібні документи X, Y, Z». Не може сказати: «Вашу заяву відхилено».
• Агент маршрутизації може запропонувати відділ. Працівник вирішує, чи потрапляє звернення до цього відділу.
• Система попереднього заповнення може вписати PESEL з даних сесії. Мешканець перевіряє та підтверджує перед поданням.

AI Act ставиться до публічного сектору з підвищеною пильністю. Органи публічної влади, що використовують системи ШІ в сферах, зазначених у Додатку III, мають статус deployer систем високого ризику з повним набором обов’язків.

Ключові обов’язки deployer для ОМС:

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

Технічна документація. Deployer повинен мати технічну документацію системи, надану постачальником. У публічних закупівлях варто вже на етапі ТЗ вимагати від постачальника документації, відповідної до AI Act (ст. 11 та Додаток IV).

Людський нагляд. Ст. 26 п. 1 AI Act: deployer впроваджує «належні технічні та організаційні заходи», щоб забезпечити, що особи, призначені для нагляду, мають здатність втручатися, розуміють обмеження системи та можуть її зупинити.

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

Деталі класифікації та обов’язків описано в статті про AI Act та RODO 2026 для компаній та про системи високого ризику.

Обробка персональних даних системою ШІ в органі влади вимагає кількох кроків, які мають передувати запуску в продакшені.

Правова підстава обробки. Для ОМС підставою найчастіше є ст. 6 п. 1 літ. e RODO (завдання в суспільному інтересі або здійснення публічної влади). Важливо: підстава має відповідати конкретній меті. Збір чат-ботом інформації про справу мешканця для її класифікації підпадає під цей обсяг. Профілювання мешканця для інших цілей — вже не обов’язково.

Договір доручення обробки. Якщо систему ШІ надає зовнішній постачальник (SaaS або on-premise з зовнішньою моделлю), орган влади як адміністратор даних повинен укласти з постачальником договір доручення обробки відповідно до ст. 28 RODO. Запуск системи без цього договору є порушенням RODO.

DPIA. Оцінка впливу на захист даних є обов’язковою, якщо обробка може спричинити високий ризик. На практиці для ОМС: системи оцінки заяв на виплати, чат-боти, що збирають персональні дані мешканців (навіть у описовій формі), системи моніторингу з аналізом зображення, системи, що обробляють чутливі дані (здоров’я, інвалідність, соціальний статус). УОДО рекомендує профілактичний підхід: якщо є сумніви, проведіть DPIA. Вартість підготовки DPIA для простої системи — кілька днів роботи; вартість порушення RODO — багаторазово вища.

PII masking. Персональні дані мешканців не повинні потрапляти до зовнішньої моделі у відкритому вигляді. Архітектура: модуль PII masking перед відправкою запиту до моделі, зворотне розкриття маскування при відображенні відповіді користувачеві. При self-hosting локальної моделі (data-residency в інфраструктурі органу влади) проблема менша, але все одно вимагає управління логами.

Інформація про обробку (ст. 13/14 RODO). Мешканець, який взаємодіє з чат-ботом ШІ, має бути поінформований про обробку персональних даних: адміністратор, мета, правова підстава, права. Ця вимога поєднується з вимогою прозорості з AI Act (розкриття, що це система ШІ).

ОМС рідко мають власні команди ШІ. Впровадження через зовнішнього інтегратора зі збереженням суверенітету даних органу влади можливе, але вимагає відповідних положень у договорі.

Пілот у режимі shadow mode. Протягом перших 4-8 тижнів система ШІ працює паралельно з поточним процесом: відповідає на запити, але працівник перевіряє кожну відповідь перед тим, як вона потрапить до мешканця. Збираєте дані про якість (що модель плутає, які запитання виходять за її межі) без операційного ризику.

Обсяг бази знань. RAG на публічних документах BIP, регламентів та зразків документів є безпечним. Індексація персональних даних мешканців (історія справ, дані з реєстрів) вимагає юридичного аналізу та є опцією виключно для власної інфраструктури органу влади з відповідною правовою підставою.

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

Моніторинг та звітність. Реєструйте: кількість запитів, частоту ескалації до працівника, теми запитань (без PII), оцінку якості мешканцями. Для систем високого ризику AI Act вимагає аудитних логів, що зберігаються протягом достатнього терміну для підтвердження відповідності. Практично: 24 місяці для адміністративних систем. Інструменти для планування впровадження: blueprint агента та калькулятор ROI.

Опишіть своє впровадження або запланований проєкт ШІ в ОМС, а модель вкаже конкретні правові вимоги, межі автономії та рекомендовану архітектуру:

Так, це безумовний обов’язок. Ст. 50 AI Act накладає на deployer систем ШІ, що взаємодіють з фізичними особами, обов’язок розкривати, що співрозмовник є системою ШІ, якщо це не очевидно з контексту. У випадку чат-бота обслуговування мешканців очевидність з контексту недостатня: орган влади повинен чітко позначати систему як «асистент ШІ» або «чат-бот» в інтерфейсі та при кожному відкритті сесії. Відсутність розкриття є порушенням AI Act незалежно від того, чи приймає система рішення.

Підтримуватися — так, прийматися ШІ — ні. Система ШІ може підготувати проєкт рішення на основі матеріалів справи, вказати на відсутні документи, виявити подібні прецеденти в базі судової практики та запропонувати текст обґрунтування. Однак рішення в розумінні ст. 104 КУпАП має бути підписане уповноваженим працівником або органом, який несе за нього юридичну та адміністративну відповідальність. Human-oversight тут не є опцією: це умова легальності.

DPIA є обов’язковою при обробці персональних даних, що може спричинити високий ризик. На практиці для ОМС: системи оцінки заяв на виплати, чат-боти, що збирають персональні дані мешканців (навіть у описовій формі), системи моніторингу з аналізом зображення, системи, що обробляють чутливі дані (здоров’я, інвалідність, соціальний статус). УОДО рекомендує профілактичний підхід: якщо є сумніви, проведіть DPIA. Вартість підготовки DPIA для простої системи — кілька днів роботи; вартість порушення RODO — багаторазово вища.

Мінімум правовий: договір доручення обробки персональних даних відповідно до ст. 28 RODO (мета, обсяг, термін, обов’язки постачальника), положення про локалізацію даних (де дані зберігаються та обробляються, обов’язок дотримання data-residency в ЄЕЗ або в інфраструктурі органу влади), зобов’язання постачальника надати технічну документацію, необхідну за AI Act, якщо система класифікується як високоризикова, та положення, що дозволяє аудит з боку органу влади або наглядового органу. У публічних закупівлях варто врахувати ці вимоги вже в ТЗ, щоб уникнути необхідності переговорів після підписання договору.

Через два канали одночасно. Перший: інформаційне положення RODO (ст. 13) при першій взаємодії з системою ШІ, що містить адміністратора даних, мету та правову підставу обробки, права мешканця (доступ, заперечення, видалення). Другий: позначення інтерфейсу як системи ШІ відповідно до AI Act ст. 50. Обидві вимоги можна об’єднати в одному привітальному повідомленні чат-бота. Також варто розмістити скорочену інформацію у видимому місці інтерфейсу протягом усієї сесії, а не лише на початку. Як положення RODO, так і позначення ШІ мають бути доступні українською без юридичного жаргону.