AI literacy у закладі освіти: як виконати статтю 4 AI Act

Оновлено: 5 серпня 2026 року

Стаття 4 AI Act коротка, але практичних питань після її прочитання стає більше. Кого навчати: усіх працівників чи лише тих, хто регулярно користується ChatGPT? Скільки годин має тривати курс? Чи потрібен сертифікат? Які документи покаже заклад під час перевірки?

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

Зміст

• Що саме вимагає стаття 4
• Хто такий deployer у контексті ЗВО
• Кого треба навчати
• Що має знати персонал
• Політика використання ШІ: структура
• Як задокументувати навчання
• Чекліст на 30 днів
• Ризики невиконання
• FAQ

Що саме вимагає стаття 4

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

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

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

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

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

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

Хто такий deployer у контексті ЗВО

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

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

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

Практично варто розрізняти три сценарії:

1. Використання готового інструмента. Заклад налаштовує доступ і правила, але не випускає систему під своєю назвою. Типова роль — deployer.
2. Інтеграція через API. Заклад будує власний сервіс на моделі стороннього постачальника. Роль залежить від архітектури, брендування, призначення та розподілу контролю; автоматичної відповіді немає.
3. Власна або суттєво змінена система. Заклад може стати provider і отримати ширший набір обов’язків, особливо якщо система використовується для вступу, оцінювання чи іншого high-risk сценарію.

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

Кого треба навчати

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

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

Що має знати персонал

Мінімум AI literacy — це не курс із програмування. Людина має розуміти систему настільки, щоб безпечно виконувати свою роль, перевіряти результат і знати, коли потрібно зупинитися та звернутися до відповідального фахівця.

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

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

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

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

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

6. Межі делегування рішень. ШІ може підготувати чернетку, структурувати інформацію або запропонувати варіанти. Але остаточне рішення з істотними наслідками має приймати компетентна людина за визначеною процедурою. Формальна кнопка «погодити» не є змістовним людським контролем, якщо працівник не розуміє даних, обмежень і логіки результату.

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

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

Політика використання ШІ: структура

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

Робочий каркас документа може містити такі розділи:

1. Мета і сфера дії. На кого поширюється політика: працівники, сумісники, стажери, підрядники, проєктні команди. Які види систем вона охоплює.
2. Терміни та ролі. Визначення ШІ-системи, provider, deployer, власника процесу, адміністратора системи, відповідального за дані та особи, яка затверджує результат.
3. Реєстр дозволених інструментів. Власник, версія або тариф, призначення, категорії даних, доступні функції, строк перегляду дозволу.
4. Дозволені сценарії. Наприклад, ідеї, мовне редагування, переклад неперсоналізованого тексту, чернетки презентацій, технічна допомога — з обов’язковою людською перевіркою.
5. Заборонені або обмежені сценарії. Введення захищених даних у непогоджений сервіс; автоматичне прийняття істотних рішень; генерування неправдивих доказів; прихований deepfake; використання системи поза погодженим призначенням.
6. Персональні дані й інформаційна безпека. Категорії даних, які не можна вводити; порядок погодження нового сервісу; контроль доступу; зберігання; повідомлення про інциденти.
7. Перевірка та людський контроль. Мінімальні дії для фактів, посилань, розрахунків, оцінок і рекомендацій. Хто має право затвердити результат у кожному процесі.
8. Авторське право й академічна доброчесність. Правила щодо завантаження матеріалів, використання результатів, цитування, декларування допомоги ШІ та перевірки запозичень.
9. Прозорість і маркування. Окремі правила для чат-ботів, deepfake-контенту, публікацій суспільного інтересу та редакційного контролю. Не варто вводити формулу «маркувати все» без урахування статті 50 й інших застосовних правил.
10. Навчання та доступ. Який модуль потрібно пройти перед отриманням доступу, як часто оновлюються знання, хто навчає підрядників.
11. Відповідальність і ескалація. Куди повідомляти про помилку, витік, дискримінаційний результат або сумнівний сценарій; хто може тимчасово зупинити використання системи.
12. Перегляд політики. Власник документа, дата наступного перегляду та події, після яких потрібне позачергове оновлення: нова система, зміна постачальника, інцидент, нові офіційні рекомендації.

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

Як задокументувати навчання

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

Для закладу освіти практичний пакет доказів може складатися з п’яти частин:

1. Реєстр ШІ-систем. Назва, постачальник, призначення, підрозділ, власник процесу, користувачі, категорії даних, рівень ризику, дата погодження й наступного перегляду.
2. Матриця ролей і навчання. Які групи працюють із кожною системою, який модуль вони проходять, хто відповідає за організацію та актуальність матеріалів.
3. Журнал навчань. Дата, тема, формат, викладач або автор матеріалу, список учасників, тривалість, версія програми, підтвердження участі.
4. Результати перевірки засвоєння. Короткий тест, практичний кейс або підтвердження ознайомлення можуть бути корисними, хоча закон не встановлює обов’язкового іспиту. Їхня мета — виявити прогалини, а не створити формальну «галочку».
5. Подальші дії. Оновлені інструкції, відповіді на запитання, додаткове навчання після інциденту, зміни доступів, рішення про заборону або обмеження сценарію.

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

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

Чекліст на 30 днів

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

1. Дні 1–3 — призначити координатора. Керівник визначає особу, яка збере дані та організує процес. Це може бути представник юридичного, ІТ, комплаєнс- або навчального підрозділу; окрема посада не обов’язкова.
2. Дні 1–7 — провести інвентаризацію. Керівники підрозділів подають перелік ШІ-інструментів, сценаріїв, користувачів і даних. Окремо фіксують неофіційні та особисті акаунти, які реально використовуються в роботі.
3. Дні 5–10 — розподілити сценарії за ризиком. Юрист, ІТ і власники процесів відокремлюють низькоризикові чернетки від процесів із персональними даними, публічними комунікаціями або істотним впливом на студентів.
4. Дні 8–14 — затвердити тимчасові правила. До повної політики достатньо короткої інструкції: дозволені інструменти, заборонені дані, обов’язкова перевірка, порядок повідомлення про інцидент.
5. Дні 10–18 — підготувати базовий модуль. Він охоплює принцип роботи генеративних моделей, галюцинації, дані, авторське право, упередженість, людський контроль і правила закладу.
6. Дні 15–24 — провести рольове навчання. Першими навчають групи з найбільшим впливом: приймальну комісію, ІТ, адміністрацію, пресслужбу та викладачів, які застосовують ШІ в оцінюванні.
7. Дні 20–27 — оформити докази. Створюють журнал, зберігають програму й матеріали, фіксують учасників, результати практичних завдань і питання, які потребують додаткового роз’яснення.
8. Дні 25–30 — затвердити план наступного циклу. Визначають прогалини, дату перегляду політики, періодичність оновлення та відповідальних за нові системи й підрядників.

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

Ризики невиконання

Універсальної формули «за статтю 4 одразу штрафують на 7,5 млн євро або 1% обороту» немає. Рівень 7,5 млн євро або 1% у системі санкцій AI Act пов’язаний із наданням органам неправильних, неповних або оманливих відомостей, а не є окремою автоматичною санкцією за відсутність навчального курсу.

Єврокомісія пояснює, що порушення статті 4 контролюють національні органи ринкового нагляду, а санкції та інші заходи ґрунтуються на національних правилах. Застосування має бути пропорційним і враховувати характер, тяжкість, умисність або недбалість. Імовірність жорсткішої реакції може зростати, якщо інцидент пов’язаний із відсутністю належного навчання чи інструкцій.

Для закладу реалістичні ризики ширші за штраф:

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

Тому головна мета AI literacy — не «закрити штраф». Вона має зменшити ймовірність помилки та зробити відповідальність у процесі видимою.

FAQ

Скільки годин навчання достатньо?

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

Чи потрібен сертифікат?

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

Чи треба навчати студентів?

Стаття 4 безпосередньо орієнтована на персонал та інших осіб, які працюють із ШІ від імені provider або deployer. Вона не створює загального обов’язку навчити кожного студента. Водночас ШІ-грамотність студентів є доцільною частиною освітньої програми, а студенти-працівники, стажери чи учасники проєктів можуть потрапляти до рольової програми за своєю функцією.

Хто відповідальний у структурі закладу?

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

---

Практичний наступний крок: підготуйте для команди PDF «Чекліст AI literacy для закладу освіти» та шаблон політики використання ШІ. Для процесів із європейськими користувачами, партнерами або системами високого ризику доцільно окремо провести аудит ролей, даних, договорів і програми навчання.

Докладний контекст щодо строків і сфери застосування регламенту дивіться у статті «EU AI Act для закладів освіти: що вже діє, а що відклали».

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

© BI-Systems. Передрук і поширення матеріалу дозволено за умови збереження авторства та активного посилання на оригінальну публікацію.