Навіщо бізнесу AI Policy і чому однієї заборони недостатньо

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

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

AI Policy — корпоративна політика використання штучного інтелекту — потрібна саме для встановлення цих меж. Але ефективний документ не може бути декларацією про інновації або загальною забороною передавати «конфіденційну інформацію». Він має перетворити використання ШІ на керований процес: визначити дозволені інструменти й сценарії, правила роботи з даними, рівні перевірки результатів, порядок погодження нових сервісів та дії у разі інциденту.

ШІ вже всередині компанії, навіть якщо його офіційно не впроваджували

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

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

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

Судова практика вже показує головний принцип: відповідальність залишається за людиною

Українські судові рішення, пов’язані з використанням ШІ, поки не формують окремого «права AI Policy». Однак вони вже демонструють принцип, важливий для будь-якої компанії: технологія може бути допоміжним інструментом, але не переносить на себе відповідальність за остаточний результат.

В ухвалі Касаційного адміністративного суду у складі Верховного Суду від 15 січня 2026 року у справі № 240/14153/24 ішлося про касаційну скаргу з посиланнями на постанови Верховного Суду, яких, як установила перевірка Єдиного державного реєстру судових рішень, не існувало. Номери справ і дати постанов були вигаданими, а приписані їм правові висновки — неправдивими. Суд зазначив, що характер таких посилань може свідчити про використання інструментів ШІ та отримання так званих галюцинацій. Важливе уточнення: суд не встановив як безспірний факт, що текст створив конкретний сервіс. Він вказав на ймовірність такого походження помилок. Водночас Верховний Суд прямо наголосив, що використання ШІ саме по собі не заборонене, але відповідальність за достовірність поданої інформації несе учасник справи.

Подібну проблему Верховний Суд зафіксував і в ухвалі від 3 лютого 2026 року у справі № 340/2365/25: у касаційній скарзі були наведені вигадані номери справ, дати постанов і неправдиві посилання на сформовані висновки. Офіційний огляд Верховного Суду використовує цю справу як приклад необхідності перевіряти кожне посилання та не підміняти професійне судження машинною відповіддю.

Ще раніше, в ухвалі від 8 лютого 2024 року у справі № 925/200/22, Касаційний господарський суд оцінив апелювання заявника до «позиції» ChatGPT разом з іншими обставинами подання заяви як зловживання процесуальними правами та вияв неповаги до суду. Суд не сказав, що будь-яке використання ChatGPT у правничій роботі є порушенням. Проблемою була спроба протиставити відповідь системи висновкам у остаточному судовому рішенні та використати її в межах явно необґрунтованої заяви.

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

AI Policy — це не лише про AI Act

Регламент ЄС 2024/1689, відомий як AI Act, став важливою рамкою для регулювання штучного інтелекту. Станом на вересень 2026 року потрібно враховувати його оновлений календар застосування. Регламент набрав чинності 1 серпня 2024 року і загалом застосовується з 2 серпня 2026 року. Водночас заборонені практики та обов’язки щодо AI literacy застосовуються з 2 лютого 2025 року, а правила щодо моделей загального призначення — з 2 серпня 2025 року. Після змін 2026 року правила для high-risk сценаріїв із Додатка III, до яких належать окремі системи у сфері працевлаштування, мають застосовуватися з 2 грудня 2027 року, а для систем, пов’язаних із регульованими продуктами з Додатка I, передбачено перехід до 2 серпня 2028 року.

Це важливо, оскільки формула «з 2 серпня 2026 року набрали чинності всі вимоги AI Act» уже є неточною. Так само неправильно вважати, що кожна українська компанія, працівники якої користуються генеративним сервісом, автоматично підпадає під усі положення Регламенту. Потрібно аналізувати територіальну сферу, роль компанії, тип системи, ринок, на якому вона пропонується або використовується, і конкретний вплив її результатів.

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

AI literacy — не одноразова презентація про промпти

Стаття 4 AI Act вимагає від постачальників AI-систем і суб’єктів, які їх застосовують, вживати заходів для забезпечення достатнього рівня AI literacy персоналу та інших осіб, які працюють із системами від їхнього імені. При цьому мають враховуватися технічні знання, досвід, освіта, навчання, контекст використання та особи, на яких може впливати система.

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

Отже, AI literacy — це здатність працівника розпізнати ризик у власному робочому сценарії, правильно вибрати інструмент, не передати заборонені дані та перевірити результат на рівні, що відповідає можливим наслідкам.

Персональні дані: видалення імені не завжди означає анонімізацію

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

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

Для українського бізнесу базовими залишаються вимоги Закону України «Про захист персональних даних». Дані про стан здоров’я належать до чутливих категорій, а їх обробка потребує підвищеної уваги. Якщо діяльність пов’язана з особами в ЄС або з іншими факторами, що роблять застосовним GDPR, окремо аналізуються його вимоги, зокрема щодо спеціальних категорій даних і відносин між контролером та обробником.

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

NDA і клієнтський договір можуть забороняти те, що дозволяє внутрішня політика

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

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

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

HR: допомога з резюме і автоматизоване рішення — не одне й те саме

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

AI Act відносить окремі системи, призначені для рекрутингу, відбору кандидатів, оцінювання працівників та ухвалення рішень у трудових відносинах, до high-risk категорій Додатка III. Станом на вересень 2026 року важливо враховувати, що відповідні правила після змін мають застосовуватися з 2 грудня 2027 року. Однак відкладена дата не скасовує чинних вимог щодо персональних даних, недискримінації, прозорості внутрішніх процедур та відповідальності роботодавця.

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

Медицина: найчутливіші дані та найвища ціна помилки

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

Ризик залежить від сценарію. Якщо система допомагає виправити стиль уже сформованого лікарем тексту, це одна модель. Якщо вона пропонує діагноз, визначає пріоритет пацієнта, рекомендує лікування або оцінює медичний ризик, наслідки та регуляторна кваліфікація можуть бути принципово іншими. Не кожен AI-інструмент у медицині автоматично є high-risk системою за AI Act; потрібен аналіз його призначення, функцій і, зокрема, можливого зв’язку з регульованим медичним виробом.

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

Принцип human-in-the-loop у медицині має означати реальний професійний контроль. Лікар повинен критично оцінити результат і самостійно прийняти клінічне рішення, а не формально натиснути «погодити». Чим сильніше результат ШІ може вплинути на здоров’я пацієнта, тим вищими мають бути вимоги до валідації, документування та людського нагляду.

AI у МІС: політики для працівників уже недостатньо

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

Ці відповіді мають бути узгоджені не лише з AI Policy. Вони впливають на архітектуру МІС, DPA, перелік субобробників, політику конфіденційності, договір із медичним закладом, опис функціональності, процедури безпеки та повідомлення користувачів. Важливо також правильно визначити ролі медичного закладу, SaaS-постачальника та зовнішнього AI-провайдера щодо різних операцій із даними: одна загальна назва ролі для всього продукту може бути неточною.

IT: код є інформацією, а не нейтральним технічним матеріалом

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

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

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

Інтелектуальна власність: фрази «все належить компанії» недостатньо

Права на AI-assisted або AI-generated результат залежать від конкретної юрисдикції, характеру людського творчого внеску, виду матеріалу, умов обраного сервісу та можливої наявності сторонніх об’єктів. Тому універсальна формула «весь контент, створений ШІ, належить компанії» не вирішує всіх питань.

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

SaaS: коли компанія вже не користувач, а постачальник AI-функції

Якщо SaaS-продукт генерує документи, аналізує договори, класифікує клієнтів, формує рекомендації або відповідає користувачам, ШІ стає частиною послуги. Внутрішньої політики для працівників тут недостатньо. Потрібно перевірити SaaS Agreement, Terms of Use, Privacy Policy, DPA, інформацію про субобробників, опис функціоналу, обмеження використання, процедури безпеки та модель відповідальності.

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

Чому повна заборона часто породжує shadow AI

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

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

Що повинна регулювати AI Policy

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

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

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

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

Нарешті, AI Policy має бути узгоджена з NDA, режимом комерційної таємниці, політикою інформаційної безпеки, правилами обробки персональних даних, договорами з працівниками й підрядниками, клієнтськими угодами, DPA, SaaS Agreement та Privacy Policy. Якщо документи суперечать один одному, працівник фактично залишатиметься без зрозумілого правила.

12 питань, які керівнику варто поставити вже зараз

1. Які AI-сервіси працівники реально використовують, включно з особистими обліковими записами?
2. Для яких завдань використовується кожна система і які результати передаються клієнтам або впливають на рішення?
3. Які документи та дані завантажуються: договори, резюме, код, журнали подій, медичні документи чи інші клієнтські матеріали?
4. Чи потрапляють до систем персональні, медичні або інші чутливі дані?
5. Чи визначені категорії інформації, які не можна передавати за жодних умов?
6. Які сервіси й типи облікових записів офіційно дозволені?
7. Хто і за якою процедурою перевіряє факти, джерела, розрахунки та код?
8. У яких процесах рішення не може бути прийняте без змістовного людського контролю?
9. Чи використовується ШІ у відборі кандидатів або оцінюванні працівників?
10. Чи дозволяють клієнтські договори передавати матеріали зовнішнім AI-сервісам?
11. Чи знає працівник, кому і як повідомити про випадкову передачу забороненої інформації?
12. Коли востаннє компанія перевіряла умови дозволених сервісів і переглядала власні правила?

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

Як впровадити політику без зайвої бюрократії

1. Провести інвентаризацію. З’ясувати, хто, де і для чого використовує ШІ, які дані передає та які результати застосовує в роботі.
2. Класифікувати сценарії. Розподілити їх за рівнем ризику й визначити заборонені випадки, а не намагатися однаково регулювати редагування публічного тексту та клінічне рішення.
3. Перевірити інструменти. Оцінити умови сервісу, режим даних, налаштування корпоративного адміністрування, безпеку, можливість укладення DPA та інші релевантні гарантії.
4. Узгодити документи. Перевірити NDA, клієнтські договори, privacy- і security-документацію, трудові правила та договори з підрядниками.
5. Затвердити політику і робочі додатки. Основний документ має залишатися достатньо стабільним, а перелік сервісів, матриця сценаріїв і контакти для повідомлення про інциденти — оновлюватися простіше.
6. Навчити працівників на реальних прикладах. Формат «можна / лише за умов / після погодження / не можна» зазвичай корисніший за абстрактну лекцію про етику ШІ.
7. Регулярно переглядати систему. Змінюються функції сервісів, умови використання, нормативні вимоги й фактичні сценарії всередині компанії; політика не може прийматися назавжди.

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

Висновок

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

Українська судова практика вже показала: переконливо сформульована машинна відповідь не стає достовірною без перевірки, а відповідальність за результат залишається за людиною. Для медицини до цього додаються дані про здоров’я і безпека пацієнта; для HR — ризик дискримінаційного або непрозорого оцінювання; для IT — код, ключі, вразливості та договірні обмеження клієнтів; для SaaS — відповідальність за AI-функцію як частину продукту.

Тому правильне питання для компанії звучить не так: «Чи можна нашим працівникам користуватися ChatGPT?». Воно має звучати інакше: «За якими правилами ми використовуємо ШІ, які дані дозволено передавати, які рішення система може лише підтримувати, хто перевіряє результат і хто відповідає за остаточне рішення?»

Саме відповіді на ці питання перетворюють використання ШІ з неконтрольованого експерименту на керований бізнес-процес. І саме з цього починаються дієва AI Policy та повноцінна система AI governance.

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

Перевірені джерела

1. Верховний Суд, повідомлення про ухвалу КАС ВС від 15.01.2026 у справі № 240/14153/24
2. ЄДРСР, ухвала КАС ВС від 15.01.2026, справа № 240/14153/24
3. Верховний Суд, огляд практики використання ШІ, зокрема справ № 340/2365/25 і № 520/6119/23
4. Верховний Суд, повідомлення про ухвалу від 08.02.2024 у справі № 925/200/22
5. Європейська комісія, актуальний календар застосування AI Act
6. Консолідований текст Регламенту (ЄС) 2024/1689 станом на 27.07.2026
7. Закон України «Про захист персональних даних»
8. Основи законодавства України про охорону здоров’я
9. GDPR — Регламент (ЄС) 2016/679
10. Європейська рада із захисту даних, Guidelines 01/2025 on Pseudonymisation