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

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

Закон України «Про академічну доброчесність» № 4742-IX прямо відносить недоброчесне використання результатів, згенерованих штучним інтелектом, до видів порушень. Якщо в академічному творі використано об’єкт, згенерований ШІ, закон передбачає повідомлення про це із зазначенням методики генерування та/або посиланням на відповідну комп’ютерну програму.

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

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

Зміст

1. Чому «заборонити» не працює
2. Три моделі регулювання
3. Структура політики: каркас документа
4. Як це виглядає в Moodle
5. ШІ-детектори: чому їм не можна довіряти як єдиному доказу
6. Що працює замість детекторів
7. Зв’язок із регулюванням ЄС
8. FAQ

Чому «заборонити» не працює

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

На практиці проблема переноситься в інше місце.

По-перше, заборона не створює надійного способу перевірки. Автоматичні AI-detectors дають нерівномірні результати залежно від інструмента, моделі, типу тексту та способу його редагування. Дослідження 2026 року, яке порівнювало GPTZero, Pangram, Copyleaks і Turnitin, показало суттєву різницю між інструментами й зниження якості виявлення для hybrid та humanised text. Автори рекомендують використовувати detector як первинний сигнал, а не як єдину підставу для рішення.

По-друге, «використання ШІ» — занадто широка категорія. Перекласти власний абзац, попросити пояснити складний термін, згенерувати план, перевірити синтаксис коду й доручити моделі написати повну відповідь замість студента — це різні дії з різним впливом на навчальний результат.

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

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

Три моделі регулювання

Для закладу зручно розрізняти три базові моделі.

1. Заборона

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

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

2. Дозвіл із декларуванням

Ця модель працює, коли ШІ може бути допоміжним інструментом, але авторство й відповідальність залишаються за студентом.

Декларація має відповідати на практичні питання:

• який інструмент використовувався;
• для якого етапу;
• який тип результату отримано;
• як результат перевіряли або доопрацьовували;
• де AI-generated матеріал увійшов до фінальної роботи.

Не потрібно вимагати сотні скриншотів кожного діалогу, якщо це не має методичної цінності. Мета декларації — відтворити роль ШІ у виконанні роботи.

3. Диференціація за типом завдання

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

Наприклад:

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

Таке правило складніше написати один раз, зате воно значно менше залежить від конкретної назви моделі чи сервісу.

Структура політики: каркас документа

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

Практичний каркас може складатися з восьми блоків.

1. Сфера дії

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

Для D1 доцільно зосередити основний документ саме на навчальному процесі та академічній доброчесності, а корпоративне використання ШІ працівниками регулювати окремими ІТ- та інформаційними правилами.

2. Терміни

Не прив’язуйте визначення до одного продукту. Краще визначити:

• генеративний ШІ;
• AI-generated content;
• AI-assisted work;
• деклароване використання;
• недеклароване використання;
• самостійна робота.

3. Базовий принцип

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

Це редакційна рекомендація, а не цитата із закону.

Як зробити правила однаковими для всіх курсів

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

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

Водночас категорія не повинна замінювати коротку інструкцію. Для «ШІ дозволений як допомога» треба назвати дозволені етапи; для «із декларацією» — формат декларації; для «не дозволений» — за потреби перелік дозволених негенеративних інструментів. Студент має знати ці умови до здачі, а не після того, як detector або викладач поставив роботу під сумнів.

4. Дозволені сценарії

Замість загального «можна користуватися ШІ» наведіть типові приклади:

• генерація ідей;
• пояснення термінів;
• мовне редагування;
• переклад;
• створення тестових даних;
• пошук помилок у коді;
• підготовка запитань для самоперевірки.

Для кожного факультету перелік може бути іншим.

5. Заборонені сценарії

Заборона має бути прив’язана до підміни роботи, наприклад:

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

6. Декларація

До політики варто додати єдину форму. Наприклад:

Декларація використання ШІ: «Під час виконання роботи я використовував(ла) [інструмент] для [мета/етап]. Отриманий результат використано для [опис]. Факти, джерела та фінальний текст перевірено/доопрацьовано мною».

Для окремих типів робіт може знадобитися детальніший формат із методикою генерування — з урахуванням вимог Закону № 4742-IX до академічного твору.

7. Порядок розгляду сумнівів

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

8. Перегляд політики

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

Як це виглядає в Moodle

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

У стандартному Moodle 5.2 немає універсального довільного поля «Декларація ШІ» для кожного Assignment. Тому технічну реалізацію потрібно вибирати за потрібним рівнем деталізації.

Варіант 1. Правило в описі Assignment

Найпростіший варіант — додати в Description кожного завдання короткий блок:

ШІ для цього завдання:

Дозволено: пошук ідей і мовне редагування.

Потрібно декларувати: використаний сервіс і етап роботи.

Заборонено: генерація фінальної відповіді.

Перевага — правило видно безпосередньо біля дедлайну й файлів завдання.

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

Варіант 2. Submission statement

Moodle має штатне налаштування Require that students accept the Submission statement. За MoodleDocs адміністратор задає текст submission statement на рівні сайту, а студент підтверджує його перед поданням.

Цей механізм підходить для загальної декларації, наприклад про авторство та дотримання правил. Але він не вирішує все: site-wide statement не є зручним місцем для різних умов кожного окремого завдання.

Тому краще поєднати:

загальний submission statement + конкретні правила в Description Assignment.

Важливо називати це декларацією або підтвердженням, а не «згодою» в сенсі згоди на обробку персональних даних.

Варіант 3. Структурована декларація

Якщо закладу потрібно збирати для кожної роботи конкретні поля — назву інструмента, сценарій використання, опис перевірки — стандартного Assignment може бути замало.

Тоді можливі:

• окрема Moodle-активність/форма перед поданням;
• спеціальний плагін;
• власне поле через розроблення інтеграції;
• інший контрольований workflow, який зберігає декларацію разом із роботою.

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

ШІ-детектори: чому їм не можна довіряти як єдиному доказу

AI-detector може бути корисним як інструмент скринінгу, але політика не повинна перетворювати його відсоток на автоматичний вирок.

Причина не в тому, що «всі детектори завжди погані». Актуальні дослідження показують складнішу картину.

У дослідженні Weber-Wulff та співавторів 2023 року 14 інструментів не продемонстрували достатньої стабільності для надійного розрізнення AI-generated і human-written text; обфускація додатково погіршувала результати. Інше дослідження 2023 року виявило систематичні false positives щодо англомовних текстів неносіїв мови.

Але технологія змінюється. Дослідження Van Vlasselaer, Van Droogenbroeck і Spruyt, опубліковане у 2026 році, показало, що частина сучасних інструментів зменшила false positives на їхньому тестовому наборі. Водночас точність сильно відрізнялася між detectors, а hybrid та humanised AI-text залишалися складними для виявлення. Автори прямо рекомендують використовувати результат як початковий сигнал для подальшої перевірки, а не як єдину підставу для high-stakes рішення.

Отже, коректне формулювання політики:

«Результат автоматичного AI-detector може ініціювати додаткову перевірку, але сам по собі не встановлює факт порушення».

Не варто також закріплювати універсальний поріг на кшталт «понад 30% = порушення». Навіть якщо конкретний постачальник дає числову оцінку, її значення залежить від версії інструмента, мови, типу тексту та методики перевірки.

Що працює замість детекторів

Найнадійніша стратегія — не намагатися вгадати походження кожного речення, а зробити процес виконання роботи видимішим.

1. Перепроєктування завдань

Ставте питання, де потрібно застосувати матеріал курсу до конкретного локального кейсу, пояснити вибір, порівняти альтернативи або захистити рішення.

Це не робить ШІ «безсилим», але підвищує цінність власного розуміння. Детальніше про дизайн контрольних завдань — у матеріалі «Як налаштувати тести в Moodle, щоб зменшити списування».

2. Захист роботи

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

3. Чернетки й проміжні етапи

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

4. Перевірка джерел

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

5. Декларування

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

Зв’язок із регулюванням ЄС

Ця стаття — про академічну доброчесність, а не про повний комплаєнс із EU AI Act. Якщо конкретний заклад і сценарій використання підпадають під сферу застосування регламенту та заклад виступає provider або deployer AI-системи, можуть виникати окремі обов’язки. Зокрема, стаття 4 AI Act регулює заходи щодо AI literacy персоналу та інших осіб, які працюють із системами від імені організації.

Практичний розбір цієї теми є в окремому матеріалі: «AI literacy у закладі освіти: як виконати статтю 4 AI Act».

FAQ

Чи можна заборонити ШІ повністю?

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

Чи є надійний AI-detector?

Немає підстав вважати будь-який detector універсальним і безпомилковим для всіх мов, моделей та типів тексту. Результати сучасних інструментів покращуються, але дослідження 2026 року все одно показує суттєву різницю між продуктами й проблеми з hybrid/humanised text. Тому detector — сигнал для перевірки, не автоматичний доказ.

Як довести використання ШІ?

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

Чи треба вимагати всі промпти?

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

Чи можна використовувати одну політику для всіх факультетів?

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

Налаштування Moodle під політику ШІ

Якщо правила вже затверджені, наступний крок — зробити їх видимими й виконуваними в LMS: стандартизувати описи Assignment, submission statement, шаблони завдань і спосіб зберігання декларацій.

Для технічної реалізації дивіться послугу впровадження Moodle.

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

---

Джерела

• Закон України «Про академічну доброчесність» № 4742-IX
• МОН — «Штучний інтелект у закладах вищої освіти: рекомендації для викладачів, студентів і працівників ЗВО»

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