ШІ в Moodle 5.2 і вимоги AI Act: що врахувати закладу

Вступ

ШІ в Moodle 5.2 — це вже не окремий експериментальний сервіс поруч із LMS. Адміністратор може підключити підтримуваного AI-провайдера, дозволити потрібні сценарії та зробити їх доступними викладачам або студентам без переходу в сторонній інтерфейс. Але технічне ввімкнення — лише початок.

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

Це важливо і для внутрішнього управління ризиками, і — коли заклад або конкретний сценарій підпадає під територіальну сферу дії — для виконання вимог EU AI Act. Нижче розбираємо Moodle та регуляторну частину окремо, без припущення, що будь-яке використання ШІ автоматично є високоризиковим.

Що з'явилось у Moodle 5.2

Почати варто з важливого уточнення: AI subsystem з'явився в Moodle не у версії 5.2, а ще в Moodle 4.5. Він створює стандартний шар між інтерфейсом LMS і різними AI-провайдерами. У Moodle 5.2 цей механізм розширено: до ядра інтегровано провайдери Google Gemini та Amazon Bedrock.

Офіційна документація Moodle описує три основні частини цієї архітектури: placements визначають, де користувач бачить AI-функцію; actions — що саме він може зробити; providers — через який зовнішній AI-сервіс Moodle виконує запит. Загальний опис доступний у MoodleDocs про AI tools.

У стандартній конфігурації Moodle 5.2 доступні чотири практичні дії:

генерація тексту;
генерація зображення;
підсумовування тексту;
пояснення тексту.

Генерація тексту й зображень працює через редактор. Підсумовування та пояснення належать до course assistance і можуть використовуватися на сторінках курсу.

Важливий управлінський момент: AI placements за замовчуванням вимкнені. Адміністратор вирішує, які з них активувати. Далі доступ можна обмежувати на рівні курсу, активності та ролей. Тобто Moodle дозволяє не обирати між двома крайнощами — «ШІ вимкнений для всіх» або «ШІ доступний усім».

Перед першою AI-дією користувач також має прийняти окрему AI User Policy Moodle. Це корисний контроль у самій LMS, але його не слід трактувати як автоматичне виконання всіх вимог щодо персональних даних або AI Act. Правова підстава обробки, прозорість і правила використання залежать від конкретного сценарію.

Що це дає викладачам

Найсильніша сторона AI-інтеграції Moodle — не в тому, що вона «сама веде курс», а в скороченні дрібних повторюваних операцій там, де результат усе одно контролює людина.

Чернетки навчального тексту

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

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

Пояснення й підсумовування матеріалу

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

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

Зображення й допоміжні матеріали

Генерація зображень може прискорити створення ілюстративних матеріалів. Але зображення також потребують перевірки: ШІ може відтворювати некоректні деталі, спотворювати схеми або створювати візуально правдоподібні, але предметно неправильні елементи.

Окремо варто виправити поширене перебільшення: у стандартному наборі AI actions Moodle 5.2 немає спеціальної функції «генерувати питання для тесту». Генератор тексту можна використати як допоміжний інструмент для підготовки чернеток формулювань, але це не окремий механізм автоматичного створення й перевірки банку тестових питань.

Де виникають регуляторні вимоги

Наявність AI-функції в Moodle сама по собі не означає, що кожен український заклад автоматично підпадає під усі вимоги EU AI Act. Спочатку потрібно визначити територіальну сферу дії.

AI Act охоплює, зокрема, deployers, які розташовані або мають місце діяльності в ЄС, а також окремі випадки, коли provider або deployer перебуває поза ЄС, але результат роботи AI-системи використовується в ЄС. Тому для українського ЗВО відповідь залежить від конкретної моделі роботи, а не просто від факту використання Gemini, Bedrock чи іншої моделі.

Якщо AI Act застосовується, заклад, який використовує AI-систему під своєю організаційною відповідальністю, зазвичай виступає deployer — користувачем AI-системи в термінології Регламенту. Саме визначення deployer міститься в чинному тексті AI Act.

Для Moodle-проєкту важливі три групи питань.

AI literacy персоналу

Стаття 4 AI Act застосовується з 2 лютого 2025 року, але після змін, що набули чинності в липні 2026 року, її формулювання стало точнішим. Providers і deployers мають вживати заходів для підтримки розвитку AI literacy працівників та інших осіб, які працюють з AI-системами від їхнього імені. При цьому Регламент прямо не вимагає гарантувати кожній людині певний конкретний рівень AI literacy.

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

Докладніше ця вимога винесена в окремий матеріал «AI literacy у закладі освіти: як виконати статтю 4 AI Act».

Прозорість

AI Act не встановлює універсального правила «маркувати абсолютно все, що створено ШІ». Стаття 50 містить конкретні обов'язки для окремих сценаріїв: прямої взаємодії людини з AI-системою, певного синтетичного контенту, deepfake та окремих публікацій тексту на теми суспільного інтересу.

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

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

Рівень ризику конкретного сценарію

Генерація ілюстрації для лекції та автоматизована оцінка студента — не однакові з точки зору AI Act. Регламент класифікує ризик за призначенням і способом використання системи, а не за фактом наявності логотипа AI у Moodle.

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

Персональні дані студентів

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

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

Перед увімкненням провайдера закладу варто перевірити:

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

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

Окреме прийняття AI User Policy у Moodle є корисним інтерфейсним механізмом, але не замінює визначення правової підстави обробки персональних даних, якщо така обробка відбувається і відповідне законодавство застосовується.

Автоматизоване оцінювання: червона зона

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

Annex III AI Act відносить до освітніх high-risk use cases, зокрема, AI-системи, призначені для:

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

Для таких Annex III систем основний блок high-risk вимог застосовуватиметься з 2 грудня 2027 року.

Але тут принципово не робити зворотний висновок: будь-який AI-текст у Moodle не стає high-risk лише тому, що система використовується в університеті. Article 6 містить винятки для окремих вузьких, підготовчих або допоміжних задач, які не створюють істотного ризику й не впливають суттєво на результат рішення. Класифікація залежить від intended purpose і фактичної ролі AI у процесі.

Практична межа проходить приблизно так.

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

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

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

Чекліст перед увімкненням ШІ в Moodle

Перед production-запуском AI-функцій корисно пройти коротку приймальну перевірку.

Опишіть сценарії. Не «використовуємо Gemini», а «генеруємо чернетки описів», «студенти підсумовують сторінки», «AI допомагає з feedback».
Перевірте сферу регулювання. Визначте, чи застосовуються AI Act, GDPR та інші релевантні вимоги саме до закладу й сценарію.
Оцініть провайдера. Перевірте умови обробки, зберігання та передачі даних.
Встановіть правила для персональних даних. Визначте, що дозволено й заборонено передавати в prompt.
Обмежте доступ за ролями. Не відкривайте кожну AI-дію всім користувачам лише тому, що Moodle це дозволяє.
Сформуйте політику використання ШІ. Розмежуйте дозволені, умовно дозволені та заборонені сценарії.
Підготуйте персонал. AI literacy має відповідати реальним інструментам і ризикам, а не бути загальним курсом «що таке ШІ».
Визначте правила прозорості. Зафіксуйте, коли студент має знати про використання AI і як позначається AI-assisted контент.
Не автоматизуйте критичні рішення без окремої оцінки. Оцінювання, вступ, освітня траєкторія та прокторинг потребують підвищеної уваги.
Почніть із пілота. Обмежена група курсів дає змогу перевірити педагогічний ефект, роботу політик і проблеми з даними до масштабування.

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

FAQ

Чи можна оцінювати студентські роботи через ШІ?

ШІ можна використовувати як допоміжний інструмент, якщо викладач контролює результат і правила закладу це дозволяють. Але система, призначена для оцінювання результатів навчання або суттєвої підтримки рішення про оцінку, може потрапити до high-risk категорії Annex III AI Act. Конкретний сценарій потребує окремої оцінки; автоматично передавати моделі фінальне рішення не варто.

Чи треба повідомляти студентів про використання ШІ?

Єдиного правила «повідомляти про кожну AI-дію» AI Act не встановлює. Вимоги залежать від сценарію: Article 50 охоплює конкретні випадки прозорості, а для high-risk систем, що приймають або допомагають приймати рішення щодо людей, діють окремі інформаційні обов'язки. Навіть поза юридичним мінімумом закладу доцільно мати зрозумілу політику інформування.

Які дані передаються AI-провайдеру з Moodle?

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

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

Чи треба одразу вмикати Gemini або Bedrock на всіх курсах?

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

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