Академічна доброчесність: вимоги закону до закладу освіти

З 31 липня 2026 року Закон України «Про академічну доброчесність» № 4742-IX введено в дію. Для закладів освіти це означає не лише потребу мати положення чи кодекс, а й необхідність забезпечити робочі процедури: приймати та розглядати повідомлення, фіксувати рішення, оприлюднювати визначену інформацію, використовувати програмні засоби для виявлення ознак порушень і підтримувати внутрішню систему академічної доброчесності.

Правові вимоги варто звіряти безпосередньо з Законом України «Про академічну доброчесність» та офіційними роз’ясненнями МОН і Державної служби якості освіти. У цій статті ми не тлумачимо санкції або правові наслідки. Наш фокус — технічна реалізація: які цифрові процеси мають працювати, де виникають типові прогалини й у якій послідовності їх доцільно закривати.

Зміст

1. Що змінилося 31 липня
2. Шість вимог, які треба закривати технічно
   • Дієва внутрішня система
   • Перевірка робіт і фіксація авторства
   • Чесне оцінювання
   • Врегулювання використання ШІ
   • Оприлюднення й зберігання робіт
   • Оприлюднення документів і канал повідомлень
3. З чого почати: аудит готовності
4. Типова помилка: положення є, системи немає
5. Реалістичний графік впровадження
6. FAQ

Що змінилося 31 липня

Закон № 4742-IX ухвалено 18 грудня 2025 року. Він набрав чинності 1 лютого 2026 року, а основний масив його норм введено в дію 31 липня 2026 року. Перехідний період становив шість місяців від дня опублікування: цей час був потрібний для приведення нормативної бази й внутрішніх процесів у відповідність до нової рамки.

Стан введення в дію підтверджує картка документа на сайті Верховної Ради. ДСЯО у матеріалах для закладів освіти також зазначає, що Закон введено в дію 31 липня 2026 року. МОН, описуючи зміст Закону, окремо виділяє внутрішню систему забезпечення академічної доброчесності, внутрішні політики та процедури, порядок розгляду повідомлень, оприлюднення внутрішніх актів і результатів розгляду, а також використання програмних засобів для виявлення ознак порушень.

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

Шість вимог, які треба закривати технічно

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

Дієва внутрішня система

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

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

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

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

Перевірка робіт і фіксація авторства

МОН прямо зазначає використання програмних засобів для виявлення ознак порушень академічної доброчесності. Це не означає, що будь-який відсоток схожості автоматично доводить порушення. Технічний інструмент має давати дані для подальшого розгляду, а не підміняти рішення уповноважених осіб.

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

Чесне оцінювання

MoodleDocs описує штатні звіти курсу, зокрема журнали подій, звіт активності, звіт участі та моніторинг подій. Це не «система доказування» сама по собі, але вона дає технічні дані, які можуть бути потрібні під час внутрішнього розгляду.

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

Врегулювання використання ШІ

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

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

Оприлюднення й зберігання робіт

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

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

Оприлюднення документів і канал повідомлень

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

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

Для доопрацювання такого публічного контуру окремо описана послуга сайти для закладів освіти.

З чого почати: аудит готовності

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

Перевірте 12 пунктів:

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

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

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

Типова помилка: положення є, системи немає

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

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

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

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

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

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

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

Реалістичний графік впровадження

Не всі компоненти потрібно міняти одночасно. Практичніше рухатися від видимих і критичних прогалин до глибших інтеграцій.

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

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

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

FAQ

Чи стосується Закон шкіл?

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

Чи обов’язковий антиплагіат?

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

Що має бути на сайті?

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

Хто відповідає за впровадження в закладі?

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

---

Технічний дисклеймер. Матеріал має інформаційний характер і не є юридичною консультацією. Нормативні формулювання та обсяг обов’язків конкретного закладу потрібно звіряти з чинною редакцією законодавства й офіційними роз’ясненнями. Стаття описує цифрові процеси та варіанти технічної реалізації.

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

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