Jak trenować model na danych szkolnych i nie naruszyć prywatności uczniów

Dlaczego trenowanie modeli na danych szkolnych jest szczególnie wrażliwe

Specyfika danych edukacyjnych a ryzyko naruszenia prywatności

Dane szkolne należą do najbardziej wrażliwych kategorii informacji. Łączą w sobie dane osobowe (imię, nazwisko, PESEL, numer dziennika, e‑mail, identyfikator e‑dziennika) z danymi o postępach edukacyjnych (oceny, wyniki testów, frekwencja, informacje o specjalnych potrzebach edukacyjnych, opinie z poradni). Dodatkowo często zawierają dane o zachowaniu, sytuacji rodzinnej, a czasem kwestie zdrowotne wpływające na proces uczenia się.

Trening modelu uczenia maszynowego na takich danych bez kontroli może doprowadzić do ujawnienia informacji o konkretnym uczniu – nawet jeśli imię i nazwisko zostały usunięte. Modele, szczególnie duże i złożone, mają zdolność zapamiętywania fragmentów danych treningowych. W pewnych scenariuszach (tzw. model inversion, membership inference) te fragmenty można w przybliżeniu „wyciągnąć” z modelu poprzez odpowiednio skonstruowane zapytania.

W praktyce oznacza to, że źle zaprojektowany system adaptacyjnej nauki może nieświadomie ujawniać, że konkretny uczeń miał kiedyś opinię z poradni, określony wynik z testu psychologicznego czy długotrwałe nieobecności z powodu choroby. To nie jest tylko problem techniczny – to realne naruszenie godności ucznia i zaufania rodziców.

Regulacje prawne: RODO, prawo oświatowe i odpowiedzialność

Na gruncie RODO (GDPR) dane szkolne to dane osobowe, a często także dane szczególnych kategorii, jeśli dotyczą zdrowia, niepełnosprawności lub pochodzenia. Szkoła (lub organ prowadzący) jest administratorem danych, a dostawca systemu AI do nauki pełni zazwyczaj rolę procesora (podmiotu przetwarzającego). Obie strony mają konkretne obowiązki i ryzyka.

Kluczowe obowiązki wynikające z RODO przy trenowaniu modelu na danych szkolnych to między innymi:

• zasada minimalizacji danych – nie wolno zbierać i przetwarzać więcej, niż jest konieczne do celu (np. personalizacji nauki),
• ograniczenie celu – dane zebrane do bieżącej pracy z uczniem nie mogą być automatycznie użyte do trenowania kolejnych modeli bez właściwej podstawy prawnej i poinformowania,
• privacy by design i privacy by default – ochrona danych uczniów ma być wbudowana w projekt systemu od początku, a nie dokładana na końcu,
• rozliczalność – administrator musi być w stanie wykazać, jak dane są wykorzystywane i zabezpieczane na każdym etapie trenowania modeli.

Do tego dochodzi polskie prawo oświatowe, wytyczne MEN/MEiN, lokalne polityki samorządów, a często także wewnętrzne regulaminy szkół. Każde naruszenie może skutkować nie tylko karą administracyjną, ale także utratą zaufania dyrekcji, rodziców, a nawet koniecznością wycofania systemu ze szkoły.

Typowe pułapki przy trenowaniu modeli na danych uczniów

Najczęstsze błędy pojawiają się już na etapie koncepcji i architektury rozwiązania. Kilka szczególnie niebezpiecznych schematów:

• trening modelu na pełnych, niezanonimizowanych eksportach z e‑dziennika (w tym z nazwiskami, numerami PESEL, pełną historią ocen),
• mieszanie danych z różnych szkół w jednym zbiorze bez kontroli, które pola umożliwiają identyfikację konkretnej klasy lub ucznia,
• udostępnianie danych do trenowania w chmurze dostawcy, który reużywa je do innych celów (np. trenowania własnych dużych modeli),
• brak formalnej Data Protection Impact Assessment (DPIA, ocena skutków dla ochrony danych) przed wdrożeniem adaptacyjnego systemu nauki,
• logowanie pełnych danych wejściowych i odpowiedzi w celach debugowania bez ich pseudonimizacji i ograniczenia czasu przechowywania.

W efekcie nawet przy najszczerszych intencjach mały projekt pilotażowy w kilku szkołach może generować poważne ryzyka. Odpowiednio zaprojektowany proces trenowania modelu na danych szkolnych pozwala uniknąć tych pułapek, a jednocześnie osiągnąć realne korzyści edukacyjne.

Jakie dane szkolne naprawdę są potrzebne do trenowania modelu

Minimalizacja zakresu danych: co jest kluczowe, a co zbędne

Punktem wyjścia powinna być analiza, jakie dokładnie decyzje lub rekomendacje ma generować model. Inny zakres danych będzie potrzebny do prostego systemu rekomendacji zadań, a inny do zaawansowanego modelu predykcji ryzyka nieukończenia szkoły.

Dla większości zastosowań edukacyjnych (rekomendacje materiałów, adaptacyjne quizy) wystarczą zwykle:

• informacje o interakcjach z materiałami: które zadania były otwierane, które ukończone, ile czasu zajęło rozwiązanie, liczba podejść,
• zsyntetyzowane wyniki: poziom opanowania danej umiejętności, procent poprawnych odpowiedzi, poziom trudności zadań,
• ogólne parametry kontekstowe: poziom klasy (np. 4 klasa SP), ewentualnie przedział wieku, język nauczania,
• ewentualnie trudności sygnalizowane przez ucznia (np. „za trudne”, „za łatwe”, „nie rozumiem polecenia”) zapisane w formie zanonimizowanej.

W takim modelu nie jest konieczne przesyłanie i przechowywanie imion, nazwisk, numerów PESEL, pełnych adresów, notatek wychowawców, szczegółowych uwag o zachowaniu czy danych wrażliwych związanych ze zdrowiem. Te informacje mogą być potrzebne w dzienniku elektronicznym, ale niekoniecznie w systemie trenowania modelu.

Dane osobowe vs dane zanonimizowane: różnica praktyczna

Często pojawia się przekonanie, że „wystarczy usunąć imię i nazwisko” i dane są anonimowe. Niestety, w kontekście danych szkolnych to zazwyczaj zbyt mało. Połączenie informacji takich jak:

• szkoła i klasa,
• data urodzenia lub dokładny wiek,
• nietypowe wyniki (bardzo wysokie lub bardzo niskie),
• specyficzne informacje o frekwencji,

często pozwala zidentyfikować konkretną osobę, szczególnie w mniejszych placówkach. Z perspektywy RODO nadal są to dane osobowe, tylko pseudonimizowane. Oznacza to, że:

• ciągle obowiązują wszystkie zasady ochrony danych,
• ciągle wymagane są umowy powierzenia przetwarzania,
• nadal trzeba prowadzić rejestr czynności przetwarzania.

Prawdziwa anonimizacja zaczyna się dopiero wtedy, gdy:

• nie ma bezpośrednich identyfikatorów,
• nie da się pośrednio dojść do konkretnego ucznia przy racjonalnie dostępnych środkach,
• nawet administrator szkoły nie jest już w stanie powiązać rekordu z konkretną osobą.

Dla trenowania modeli często wystarczy przejść z danych osobowych do solidnie pseudonimizowanych – ale trzeba to zrobić świadomie i technicznie poprawnie.

Przykładowe transformacje danych szkolnych przed treningiem

Przed przekazaniem danych do trenowania modelu na serwerach dostawcy warto zastosować zestaw powtarzalnych transformacji. W dobrze zaprojektowanym procesie ETL (Extract–Transform–Load) te kroki wykonuje się automatycznie.

Tak przygotowany zbiór danych nadal może być bardzo wartościowy do trenowania modeli przewidujących trudności w nauce, sugerujących kolejne ćwiczenia czy analizujących efektywność różnych typów zadań – a jednocześnie nie niesie w sobie bezpośrednich danych osobowych.

Pseudonimizacja i anonimizacja w praktyce szkolnej

Bezpieczne identyfikatory techniczne zamiast danych osobowych

Większość adaptacyjnych systemów uczy się na poziomie jednostki – pojedynczy uczeń, jego historia, jego interakcje. Z technicznego punktu widzenia potrzebny jest więc identyfikator, który spina wszystkie rekordy dotyczące tej osoby. Nie musi to być jednak PESEL ani szkolny numer ucznia.

Bezpieczny schemat może wyglądać tak:

1. Szkolny system (np. e‑dziennik) generuje lokalny identyfikator techniczny dla każdego ucznia (np. losowy 128‑bitowy token).
2. Ten identyfikator jest przechowywany tylko lokalnie; nie zawiera żadnych informacji o uczniu (brak logiki, jak w numerze PESEL).
3. Do systemu trenowania modelu trafiają dane z tym identyfikatorem, ale bez mapy „ID – uczeń”.
4. Mapa powiązań jest przechowywana osobno, najlepiej zaszyfrowana i z dostępem tylko dla uprawnionych administratorów szkoły.

Taki układ pozwala trenować modele na danych sekwencyjnych (historia ucznia), a jednocześnie utrudnia zewnętrznemu podmiotowi odtworzenie, kogo dane dotyczą. W razie wycieku danych treningowych identyfikatory techniczne nie pozwalają na proste połączenie z konkretnymi uczniami.

Agregacja i kategoryzacja zamiast szczegółów

Istotnym narzędziem ochrony prywatności jest redukcja precyzji danych. Zamiast pojedynczych precyzyjnych wartości lepiej używać kategorii lub zanonimizowanych przedziałów. Kilka przykładów:

• zamiast dokładnej daty urodzenia – przedział wiekowy,
• zamiast dokładnego wyniku procentowego – poziom (np. „niski”, „średni”, „wysoki”),
• zamiast szczegółowego opisu trudności – krótkie kody kategorii (np. „koncentracja”, „czytanie ze zrozumieniem”),
• zamiast pojedynczych lekcji – agregacja na poziomie tygodnia/miesiąca, jeśli wystarczy do danego celu.

Taka kategoryzacja często nie szkodzi skuteczności modelu, a nawet może ją poprawić, redukując szum. Jednocześnie mocno ogranicza możliwość odtworzenia indywidualnego profilu ucznia przez osobę nieuprawnioną.

Warto unikać przechowywania „surowych” tekstów wpisów wychowawców, notatek z rozmów czy komentarzy zadań zawierających dane wprost wpisane przez nauczyciela lub ucznia. Jeśli takie informacje mają wartość analityczną, lepiej zastosować automatyczną klasyfikację tekstu na kategorie i zachować wyłącznie te etykiety.

Differential privacy: ochronna szumem, która działa

Dla projektów na większą skalę dobrym kierunkiem jest implementacja technik różnicowej prywatności (differential privacy). W uproszczeniu polega ona na celowym dodawaniu kontrolowanego „szumu” statystycznego do danych lub do wyników obliczeń tak, by:

• model nauczył się ogólnych wzorców na poziomie populacji,
• dodanie lub usunięcie danych jednego ucznia nie wpływało znacząco na wynik modelu,
• nie dało się z sensowną pewnością stwierdzić, czy dane konkretnej osoby były użyte w treningu.

W praktyce różnicową prywatność można realizować na kilku poziomach:

• na etapie trenowania – algorytmy typu DP‑SGD (stochastic gradient descent z różnicową prywatnością),
• na etapie zapytań – dodawanie szumu do agregowanych statystyk (np. raportów o skuteczności materiałów),
• na poziomie systemu – ograniczanie liczby zapytań, przycinanie skrajnych wartości itp.

To rozwiązanie wymaga wsparcia ze strony zespołu technicznego, ale znacząco zmniejsza ryzyko wycieku informacji o pojedynczych uczniach, szczególnie w dużych, scentralizowanych projektach (np. system dla wielu szkół lub całego regionu).

Role i odpowiedzialności: szkoła, dostawca, zespół techniczny

Administrator danych (szkoła) a trenowanie modelu

Obowiązki szkoły jako administratora danych

Dyrektor szkoły (lub organ prowadzący) pozostaje administratorem danych nawet wtedy, gdy przetwarzanie odbywa się na zewnętrznych serwerach dostawcy technologii. Oznacza to, że to szkoła:

• ustala cele i sposoby przetwarzania (np. „personalizacja ćwiczeń matematycznych”, „prognozowanie ryzyka niezdania klasy”),
• podejmuje decyzję, jakie dane są przekazywane do trenowania modelu i w jakiej postaci,
• odpowiada wobec organu nadzorczego (np. UODO) za legalność i bezpieczeństwo przetwarzania,
• zapewnia, że przetwarzanie jest ujęte w rejestrze czynności przetwarzania oraz w politykach ochrony danych szkoły.

Jeśli system ma być używany regularnie i na szeroką skalę (np. w kilku klasach lub całej szkole), decyzja o rozpoczęciu trenowania modeli na danych uczniów powinna być:

• udokumentowana (np. uchwała rady pedagogicznej, zarządzenie dyrektora),
• poprzedzona analizą ryzyka i ewentualnie DPIA (oceną skutków dla ochrony danych),
• skonsultowana z inspektorem ochrony danych (IOD) szkoły lub organu prowadzącego.

W praktyce dobrze działa prosty schemat: zespół pedagogiczny opisuje potrzebę (np. „system, który podpowiada zestawy zadań”), zespół techniczny lub zewnętrzny dostawca wyjaśnia wymagania techniczne, a IOD sprawdza, czy proponowane rozwiązanie da się pogodzić z przepisami i zasadą minimalizacji.

Rola dostawcy systemu a powierzenie przetwarzania

Dostawca systemu adaptacyjnego lub platformy e‑learningowej jest zazwyczaj procesorem (podmiotem przetwarzającym), działającym na podstawie umowy powierzenia. Tylko wyjątkowo staje się współadministratorem – np. gdy samodzielnie decyduje o celach wtórnego trenowania modelu dla innych klientów.

Dobrze przygotowana umowa powierzenia dla systemu trenowanego na danych szkolnych powinna przynajmniej:

• ściśle określać cele przetwarzania – np. „świadczenie usługi adaptacyjnej nauki matematyki uczniom szkoły X”,
• limitować możliwość dalszego użycia danych na potrzeby trenowania modeli dla innych szkół lub celów marketingowych, chyba że szkoła wyraźnie się na to zgodzi,
• opisywać środki techniczne i organizacyjne – szyfrowanie, pseudonimizacja, logowanie dostępu, kopie zapasowe, procedury reagowania na incydenty,
• regulować okres przechowywania danych treningowych oraz zasady ich usuwania/anonymizacji po zakończeniu współpracy,
• przewidywać możliwość audytu lub przynajmniej uzyskania informacji o podwykonawcach i lokalizacji centrów danych.

Szkoła powinna jasno wymagać, by dostawca wskazał, czy i w jaki sposób dane są wykorzystywane do trenowania modeli globalnych (dla wszystkich klientów), oraz jakie mechanizmy prywatności (np. differential privacy, separacja zbiorów) są przy tym stosowane.

Zespół techniczny i pedagodzy: współpraca zamiast silosów

Modele uczą się na danych, które tworzą nauczyciele i uczniowie. Zespół techniczny nie jest w stanie sensownie zaprojektować schematów danych, progów agregacji czy etykiet kategorii bez zrozumienia realiów pracy w klasie. Z drugiej strony pedagodzy zazwyczaj nie znają szczegółów implementacyjnych pseudonimizacji czy różnicowej prywatności.

Dobrze jest powołać małą grupę roboczą, w której znajdą się:

• przedstawiciele nauczycieli (najlepiej różnych przedmiotów),
• osoba techniczna (administrator IT, informatyk w szkole lub zewnętrzny specjalista),
• inspektor ochrony danych lub osoba wyznaczona do kontaktu z IOD.

Taki zespół może razem przejść „ścieżkę danych”: od momentu wpisania informacji przez nauczyciela, przez ich transformację i przesłanie, aż po trening modelu i prezentację wyników. Po jednym wspólnym warsztacie często okazuje się, że:

• część pól w ogóle nie jest potrzebna modelowi i można je od razu usunąć,
• niektóre dane wystarczy reprezentować w mocno zagregowanej formie,
• nauczyciele mogą minimalnie zmienić sposób wpisywania uwag, aby ułatwić automatyczną kategoryzację i ograniczyć obecność danych wrażliwych.

Projektowanie procesu trenowania krok po kroku

Definiowanie celu modelu i metryk

Najgorszy scenariusz to zbieranie „na wszelki wypadek wszystkiego”, a dopiero potem zastanawianie się, co z tym zrobić. Bez jasnego celu nie da się ani prawidłowo dobrać danych, ani obronić projektu przed zarzutem nadmiernej ingerencji w prywatność.

Na początku trzeba odpowiedzieć sobie precyzyjnie na pytanie: co konkretnie ma robić model? Przykłady:

• prognozować ryzyko, że uczeń nie opanuje określonego zagadnienia w ciągu najbliższych dwóch tygodni,
• proponować kolejne zestawy zadań na podstawie historii rozwiązań,
• analizować, które typy zadań są najskuteczniejsze dla danej grupy uczniów.

Dopiero z tak zdefiniowanym celem można przejść do listy koniecznych danych wejściowych i zastanowić się, jak je przetworzyć, aby były jak najmniej wrażliwe. W wielu przypadkach wystarczą:

• czas i wynik rozwiązania zadania,
• poziom trudności zadania,
• przedział wiekowy ucznia,
• rodzaj aktywności (np. quiz, zadanie otwarte, film).

Analiza ryzyka i DPIA dla projektu szkolnego

Gdy model ma być trenowany na szerokiej populacji uczniów, a dane dotyczą zachowania, postępów i potencjalnych trudności, projekt często wymaga oceny skutków dla ochrony danych (Data Protection Impact Assessment – DPIA).

Nawet uproszczona DPIA w szkole może być bardzo praktyczna. Typowy schemat:

1. Opis systemu: jakie dane, jaki model, jakie funkcje dla nauczycieli i uczniów.
2. Identyfikacja ryzyk: np. błędne etykietowanie uczniów, wyciek danych treningowych, profilowanie bez właściwych zabezpieczeń.
3. Ocena prawdopodobieństwa i skutków: osobno dla prywatności, reputacji, dobrostanu uczniów.
4. Dobór środków zaradczych: pseudonimizacja, ograniczenie zakresu danych, dodatkowe szkolenia nauczycieli, silniejsze logowanie dostępu.
5. Ustalenie, kto kontroluje i aktualizuje DPIA w czasie (np. co rok lub po każdej większej zmianie systemu).

W małych szkołach DPIA nie musi być rozbudowanym dokumentem, ważne jednak, by decyzje miały logiczne uzasadnienie i by dało się później pokazać, że zagrożenia zostały rzeczywiście przeanalizowane.

Projektowanie pipeline’u danych szkolnych

Proces przepływu danych z klasy do modelu opłaca się zaprojektować jak prosty pipeline, nawet jeśli technicznie jest realizowany przez zewnętrznego dostawcę. Minimalne etapy:

1. Wejście: dane z dziennika elektronicznego, systemu zadań domowych, platformy testów.
2. Transformacja lokalna: pseudonimizacja ID, usunięcie pól wrażliwych, agregacja, kategoryzacja.
3. Przesłanie: szyfrowany kanał (np. HTTPS/TLS), najlepiej z dodatkowym szyfrowaniem plików.
4. Przetwarzanie po stronie dostawcy: walidacja, dalsze przekształcenia, trening modelu.
5. Wynik: zwrot zagregowanych parametrów modelu lub rekomendacji, bez zwrotu surowych danych wejściowych.

Dobrą praktyką jest rozdzielenie ról: osoba odpowiedzialna za dane w szkole (np. administrator IT) nadzoruje etap transformacji lokalnej i loguje, co konkretnie zostało wysłane. Z kolei dostawca opisuje w sposób zrozumiały dla szkoły, jak dane są dalej przetwarzane, przechowywane i usuwane.

Logowanie i audyt wykorzystania danych

Model nie powinien być „czarną skrzynką”, do której dane wpadają bez śladu. Aby mieć kontrolę nad prywatnością, trzeba wiedzieć:

• kiedy, jakie zbiory danych zostały użyte do treningu,
• jakie transformacje zostały wykonane,
• kto miał dostęp do wyników i na jakiej podstawie.

Elementarny poziom to prowadzenie dziennika operacji, w którym zapisuje się m.in.:

• daty kolejnych przebiegów treningu,
• zakres danych (np. klasy, przedziały czasowe, typy danych),
• informację, czy użyto danych nowych czy ponownie wykorzystano dane historyczne,
• podsumowanie zmian w modelu (np. poprawa/obniżenie skuteczności).

Przydatne jest także umożliwienie IOD lub wyznaczonej osobie okresowego przeglądu logów i procedur – choćby raz w roku, w ramach przeglądu bezpieczeństwa IT szkoły.

Ograniczanie dostępu i bezpieczne korzystanie z wyników modelu

Kontrola uprawnień nauczycieli i administracji

Nawet najlepiej zanonimizowane dane treningowe nie wystarczą, jeżeli wyniki modelu i raporty są później szeroko udostępniane bez kontroli. System powinien wspierać zasadę minimalnych uprawnień:

• nauczyciel widzi jedynie informacje potrzebne do pracy z własnymi uczniami,
• wychowawca ma szerszy wgląd, ale wciąż ograniczony do swojej klasy,
• dyrekcja może oglądać raporty zagregowane na poziomie szkoły, lecz bez wejścia w szczegóły pojedynczego ucznia, jeśli nie jest to niezbędne.

Dobrze, jeśli system oferuje domyślne role powiązane z funkcjami w szkole oraz wymusza silne hasła, dwuskładnikowe uwierzytelnianie i automatyczne wylogowanie po okresie bezczynności.

Ostrożne korzystanie z predykcji dotyczących uczniów

Modele predykcyjne działają statystycznie, a nie deterministycznie. Informacja, że „uczeń ma wysoki poziom ryzyka trudności z matematyką w najbliższym semestrze”, powinna być traktowana jako sygnał do wsparcia, a nie etykieta przylepiona do ucznia.

Kilka praktycznych zasad:

• predykcje nie powinny być jedyną podstawą decyzji o ocenach, promocji czy karań – to narzędzie pomocnicze,
• nauczyciel powinien móc zakwestionować lub skorygować wniosek modelu na podstawie własnej wiedzy o uczniu,
• w raportach dla rodziców nie warto eksponować technicznych metryk modelu, lecz raczej przełożyć je na zrozumiałe wskazówki (np. „zachęcamy do dodatkowego ćwiczenia zadań tekstowych”).

Jeśli model wskazuje na ryzyko trudności, proces wsparcia powinien być z góry przemyślany: np. dodatkowe rozmowy, materiały, konsultacje. Chodzi o to, by algorytm prowadził do realnej pomocy, a nie stygmatyzacji ucznia.

Anonimowe raporty i statystyki dla całej szkoły

Z trenowanego modelu da się wyciągnąć cenne informacje na poziomie szkoły czy gminy – np. które typy zadań są najskuteczniejsze, jaki jest rozkład trudności między rocznikami. Takie raporty powinny być jednak anonimowe i zagregowane.

Dobry standard to:

• raporty zbiorcze zawierają dane dopiero od określonej liczby uczniów (np. grupa < 5 osób nie jest raportowana osobno),
• w małych klasach unika się łączenia zbyt wielu szczegółowych wymiarów jednocześnie (np. klasa, płeć, kategoria wiekowa, typ trudności),
• zastosowane są mechanizmy wygładzania czy szumów, gdy istnieje ryzyko identyfikacji pojedynczych uczniów.

Takie podejście pozwala dyrekcji i organowi prowadzącemu podejmować decyzje o programach wsparcia czy szkoleniach nauczycieli bez odsłaniania indywidualnych historii uczniów.

Uczeń i rodzic w centrum: transparentność i prawa podmiotów danych

Informowanie o wykorzystaniu danych do trenowania modeli

Uczniowie (a w przypadku młodszych – ich rodzice lub opiekunowie) mają prawo wiedzieć, w jaki sposób ich dane są wykorzystywane. Nie wystarczy ogólny zapis „dane mogą być przetwarzane w systemach informatycznych”. Trzeba jasno opisać:

• jakie kategorie danych trafiają do systemu adaptacyjnego lub analitycznego,
• w jakim celu są używane (np. „dobór poziomu trudności zadań”, „statystyki skuteczności form nauczania”),
• kto jest dostawcą systemu i gdzie (w jakim kraju) znajdują się serwery,

Zakres zgody i podstawy prawne przetwarzania

W projektach szkolnych kluczowe jest rozróżnienie między danymi niezbędnymi do prowadzenia nauczania (np. dziennik elektroniczny) a dodatkowymi usługami analitycznymi czy adaptacyjnymi. Dla tych drugich trzeba jasno wskazać podstawę prawną przetwarzania danych – w szczególności, czy jest nią:

• realizacja zadania realizowanego w interesie publicznym (np. podniesienie jakości kształcenia), czy
• zgoda rodzica/opiekuna lub pełnoletniego ucznia.

Przy korzystaniu ze zgody istotne jest, aby była ona:

• konkretna – osobno na określony system lub funkcjonalność, bez ogólnych „zgadzam się na analizy danych”,
• dobrowolna – brak zgody nie może skutkować gorszym traktowaniem ucznia ani utrudniać mu dostępu do materiałów podstawowych,
• odwoływalna – rodzic lub uczeń musi wiedzieć, jak wycofać zgodę i jakie będą skutki dla wykorzystania danych w modelu.

Praktyczny sposób to udostępnienie krótkiej, zrozumiałej informacji na osobnej kartce lub ekranie systemu, z wyraźnym opisem, co daje zgoda (np. „bardziej dopasowane zestawy zadań”) oraz co się stanie po jej wycofaniu (np. „uczeń dalej korzysta z platformy, ale bez personalizacji treści”).

Realizacja prawa do dostępu, sprostowania i usunięcia

Jeżeli dane ucznia są używane do trenowania modeli, mechanizmy obsługi praw podmiotów danych muszą uwzględniać również ten aspekt. Chodzi zwłaszcza o:

• dostęp – informacja, czy i w jakim zakresie dane danego ucznia zostały wykorzystane do treningu (np. „angażował się w moduł matematyczny w okresie wrzesień–grudzień”),
• sprostowanie – możliwość poprawienia ewidentnie błędnych danych wejściowych (np. mylnie wprowadzone wyniki testów),
• ograniczenie przetwarzania lub usunięcie – jeżeli rodzic lub uczeń skutecznie zgłosi sprzeciw albo wycofa zgodę, kolejne treningi nie powinny już wykorzystywać nowych danych tej osoby.

Technicznie pełne „wymazanie z modelu” bywa nierealne, ponieważ parametry są już uśrednione wśród wielu uczniów. W takich przypadkach szkoła powinna jasno komunikować, że:

• dane w systemach źródłowych i logach są usuwane lub pseudonimizowane,
• model od momentu wycofania zgody nie będzie dalej aktualizowany przy użyciu danych danego ucznia,
• w razie poważnych zastrzeżeń przetwarzanie może zostać wstrzymane dla całego projektu, jeśli IOD uzna to za konieczne.

Przejrzyste wyjaśnianie działania systemu uczniom i rodzicom

Nawet zaawansowany system można opisać prostym językiem. Dobrą praktyką jest przygotowanie dwóch wersji wyjaśnienia:

• krótkiej, obrazowej – dla uczniów (np. „system śledzi, które zadania są dla ciebie łatwe, a które trudniejsze, i na tej podstawie dobiera kolejne ćwiczenia”),
• szczegółowej – dla rodziców i osób dorosłych (z wyszczególnieniem kategorii danych, czasu przechowywania, rodzaju algorytmów, dostawców).

Warto przewidzieć miejsce na pytania – choćby raz w roku podczas zebrań z rodzicami lub godzin wychowawczych. Krótkie demo systemu, pokazujące przykładowy ekran ucznia i nauczyciela, zmniejsza nieufność i ułatwia rozmowę o prywatności.



Techniki ochrony prywatności w uczeniu maszynowym

Pseudonimizacja i anonimizacja w praktyce szkolnej

Najprostszym środkiem ochrony jest zastąpienie imion i nazwisk uczniów identyfikatorami technicznymi. Pseudonimizacja powinna być jednak zaprojektowana tak, aby odwrócenie procesu było możliwe tylko lokalnie w szkole, a nie po stronie dostawcy.

Przykładowy schemat:

1. Każdy uczeń w dzienniku elektronicznym ma wewnętrzny numer (ID).
2. Na potrzeby modelu generuje się dodatkowy, losowy identyfikator (model_ID), przechowywany w osobnej, dobrze chronionej tabeli mapowania tylko w systemie szkolnym.
3. Do dostawcy trafiają wyłącznie dane z model_ID, bez możliwości łatwego powiązania z konkretną osobą bez dostępu do tabeli mapowania.

Anonimizacja, w której usuwane są wszelkie powiązania z osobą, sprawdza się przy raportach zbiorczych. Wtedy dane:

• są agregowane po grupach (np. klasy, roczniki, przedziały wiekowe),
• nie zawierają kombinacji cech, które pozwoliłyby odtworzyć tożsamość pojedynczego ucznia (np. bardzo rzadkie połączenia zainteresowań i trudności).

Minimalizacja cech wejściowych modeli

Częsty błąd to gromadzenie zbyt wielu cech „na zapas”: zainteresowań, danych socjoekonomicznych, historii frekwencji, szczegółowych informacji o rodzinie. W wielu przypadkach model osiągnie podobną lub lepszą skuteczność przy znacznie mniejszej liczbie atrybutów.

Praktyczne podejście:

• zbudować wstępny zestaw cech oparty głównie na danych edukacyjnych (zadania, wyniki, czas pracy, typ aktywności),
• w fazie pilotażowej porównać modele z dodatkowymi, bardziej wrażliwymi cechami i bez nich,
• jeśli dodatkowe cechy nie wnoszą wyraźnej poprawy lub dają ryzyko dyskryminacji (np. status socjalny), całkowicie z nich zrezygnować.

Takie testy najlepiej wykonywać na zanonimizowanych próbkach danych i udokumentować ich wyniki w DPIA lub wewnętrznej dokumentacji projektu.

Trenowanie federacyjne zamiast centralnego gromadzenia danych

W bardziej zaawansowanych wdrożeniach można rozważyć federacyjne uczenie (federated learning). W tym podejściu:

• dane uczniów pozostają na serwerze szkoły lub nawet na urządzeniach końcowych,
• do szkół wysyłany jest „pusty” model, który lokalnie dopasowuje swoje parametry do danych,
• następnie do dostawcy wracają jedynie zaktualizowane parametry modelu (np. wagi sieci), a nie surowe dane uczniów.

Dostawca łączy parametry z wielu szkół i tworzy uogólniony model, nigdy nie widząc konkretnych odpowiedzi ucznia. W praktyce ten schemat wymaga dobrej infrastruktury IT po stronie szkoły oraz współpracy z dostawcą, który taką technikę wspiera, ale istotnie ogranicza ryzyko wycieku danych.

Dodawanie szumu i progi agregacji

Tam, gdzie wyniki modelu mają służyć do analiz zbiorczych (np. trendów dla klasy, rocznika), przydaje się dodawanie kontrolowanego szumu. Można to zrealizować prostymi metodami:

• zaokrąglanie wyników do przedziałów (np. „20–30% uczniów ma trudność z ułamkami” zamiast dokładnego odsetka),
• łączenie małych grup uczniów w większe kategorie, aby utrudnić identyfikację jednostek,
• wprowadzenie minimalnej liczby obserwacji, od której w ogóle generowany jest raport (np. co najmniej 10 uczniów).

Dla projektów o większej skali można rozważyć bardziej zaawansowane techniki z obszaru prywatności różnicowej, ale nawet proste rozwiązania znacząco podnoszą poziom ochrony.

Unikanie stronniczości i dyskryminacji w modelach szkolnych

Identyfikacja uprzedzeń w danych treningowych

Dane szkolne często odzwierciedlają istniejące nierówności: różny dostęp do wsparcia domowego, korepetycji, sprzętu. Jeżeli model będzie bezrefleksyjnie trenowany na takich danych, istnieje ryzyko utrwalenia lub nawet wzmocnienia tych różnic.

Przydatne kroki:

• sprawdzić, czy wyniki modelu nie są systematycznie gorsze dla określonych grup (np. uczniów z określonym językiem ojczystym, z orzeczeniem, z mniejszych miejscowości),
• analizować, czy model nie obniża oczekiwań wobec uczniów z już słabszymi wynikami zamiast proponować im intensywniejsze wsparcie,
• wyeliminować cechy, które w oczywisty sposób mogą prowadzić do dyskryminacji (np. informacje o sytuacji rodzinnej) – gdy nie są absolutnie konieczne.

Testy symulacyjne i „przypadki graniczne”

Zanim model zostanie wdrożony w całej szkole, warto przeprowadzić serię testów symulacyjnych. Mogą to być:

• przypadki graniczne – np. uczeń bardzo zdolny, ale o niskiej frekwencji; uczeń systematyczny, lecz wolno pracujący,
• scenariusze rzadkie – nagły spadek wyników po okresie wysokich ocen, powrót ucznia po dłuższej nieobecności.

Zespół nauczycieli, wychowawca i IOD mogą wspólnie przeanalizować, jakie rekomendacje w takich sytuacjach zwraca system. Jeśli widać, że algorytm reaguje w sposób niespójny z etyką szkoły, konieczne są modyfikacje – czy to samych danych, czy sposobu prezentowania wyników.

Łączenie prognoz algorytmu z oceną nauczyciela

Model może być pomocny, ale decyzje pedagogiczne powinny pozostać w rękach człowieka. Sprawdza się prosty mechanizm:

• system generuje rekomendacje (np. „zaproponuj dodatkowe zadania tekstowe z fizyki”),
• nauczyciel potwierdza, modyfikuje lub odrzuca rekomendacje, krótko uzasadniając,
• informacja o odrzuceniu wraca do zespołu projektowego/dostawcy jako sygnał do poprawy modelu.

W ten sposób algorytm pełni funkcję asystenta, a nie automatycznego decydenta. Jednocześnie tworzy się baza wiedzy o tym, kiedy i dlaczego prognozy były nieadekwatne.

Organizacja projektu trenowania modelu w szkole

Zespół projektowy i podział odpowiedzialności

Aby model był rozwijany odpowiedzialnie, potrzebny jest jasno określony zespół projektowy. Zwykle w jego skład wchodzą:

• przedstawiciel dyrekcji – podejmuje decyzje organizacyjne i budżetowe,
• koordynator merytoryczny (np. nauczyciel z doświadczeniem w TIK) – łączy perspektywę dydaktyczną i techniczną,
• administrator IT – dba o bezpieczeństwo techniczne i integrację systemów,
• IOD lub osoba odpowiedzialna za ochronę danych – opiniuje rozwiązania pod kątem prawnym i prywatności,
• opcjonalnie przedstawiciel samorządu uczniowskiego lub rady rodziców – wnosi punkt widzenia użytkowników.

Na początku prac zespół uzgadnia cele projektu, zakres danych, sposób informowania rodziców i uczniów oraz kryteria sukcesu (np. poprawa frekwencji na zajęciach pozalekcyjnych, szybsze wykrywanie trudności).

Pilotaż na ograniczonej grupie

Zanim model obejmie całą szkołę, bezpieczniej jest rozpocząć od pilotażu – jednej klasy, rocznika lub wybranych przedmiotów. Taki etap pozwala:

• sprawdzić, czy dane są poprawnie zbierane i przetwarzane,
• ocenić, jak nauczyciele radzą sobie z interpretacją raportów,
• zebrać opinie uczniów o odczuwalnym wpływie systemu na naukę.

Po kilku miesiącach pilotażu zespół projektowy może:

• wprowadzić korekty (np. zmniejszyć częstotliwość raportów, uprościć interfejs),
• doprecyzować zasady komunikacji z rodzicami,
• zaktualizować DPIA, uwzględniając faktyczne, a nie tylko hipotetyczne ryzyka.

Szkolenia dla nauczycieli i wsparcie użytkowników

Nauczyciel korzystający z wyników modelu potrzebuje czegoś więcej niż instrukcji obsługi. Istotne jest:

• omówienie ograniczeń modelu (co robi dobrze, gdzie się myli),
• przećwiczenie na przykładach pracy z raportami – jak interpretować sygnały ryzyka, jak je łączyć z własną obserwacją,
• wyjaśnienie procedur zgłaszania błędów lub wątpliwości (np. formularz w systemie, kontakt do koordynatora).

Przydaje się także krótki poradnik dla uczniów i rodziców – jak korzystać z narzędzi adaptacyjnych, co zrobić, gdy coś budzi niepokój, jak zgłaszać prośbę o usunięcie lub korektę danych.

Regularne przeglądy i aktualizacje modelu

Model trenowany na danych sprzed kilku lat może przestać odpowiadać aktualnym realiom – zmieniają się podstawy programowe, narzędzia, a nawet styl pracy uczniów. Z tego powodu warto zaplanować:

Najczęściej zadawane pytania (FAQ)

Czy mogę trenować model AI na danych z e‑dziennika bez zgody rodziców?

Co do zasady nie. Dane z e‑dziennika to dane osobowe, a często także dane szczególnych kategorii (np. informacje o zdrowiu czy niepełnosprawności). Wykorzystanie ich do trenowania modeli to inny cel przetwarzania niż bieżąca obsługa procesu nauczania.

Żeby legalnie trenować model na danych uczniów, potrzebujesz:

• jasno określonej podstawy prawnej (np. zgody, prawnie uzasadnionego interesu – po analizie, czy jest to dopuszczalne w danym scenariuszu),
• poinformowania rodziców i uczniów o nowym celu przetwarzania,
• odpowiednich umów z dostawcą systemu (powierzenie przetwarzania).

Bez tego trenowanie modeli na danych z e‑dziennika może być uznane za naruszenie RODO.

Jakie dane szkolne są naprawdę potrzebne do trenowania systemu adaptacyjnej nauki?

Do większości zastosowań edukacyjnych nie są potrzebne pełne dane osobowe uczniów. Wystarczą zwykle dane o interakcjach z materiałami oraz zagregowane wyniki uczenia się.

Przykładowo system adaptacyjny typowo wykorzystuje:

• informacje o zadaniach: które zadania były otwierane, ukończone, ile trwało rozwiązanie, liczba podejść,
• wyniki: procent poprawnych odpowiedzi, poziom trudności, poziom opanowania umiejętności,
• kontekst: poziom klasy (np. klasa 4 SP), przedmiot, język nauczania,
• opcjonalnie proste sygnały od ucznia („za trudne”, „za łatwe”).

Imiona, nazwiska, PESEL, uwagi wychowawcze czy dane zdrowotne z reguły nie są konieczne do trenowania takich modeli.

Na czym polega różnica między anonimizacją a pseudonimizacją danych uczniów?

Pseudonimizacja to usunięcie bezpośrednich identyfikatorów (np. imienia, nazwiska, PESEL) i zastąpienie ich identyfikatorem technicznym. Jednak wciąż można z dużym prawdopodobieństwem odtworzyć, którego ucznia dotyczą dane, np. łącząc informacje o szkole, klasie, wieku i nietypowych wynikach. Z perspektywy RODO to nadal dane osobowe.

Anonimizacja oznacza, że przy racjonalnie dostępnych środkach nie da się przypisać rekordu do konkretnego ucznia – ani dostawca systemu, ani sama szkoła nie jest w stanie „odwrócić” procesu. Dopiero wtedy dane przestają być danymi osobowymi. W praktyce w projektach edukacyjnych częściej stosuje się poprawną pseudonimizację, pamiętając, że nadal obowiązują wszystkie wymagania RODO.

Jakie są najczęstsze błędy przy trenowaniu modeli na danych szkolnych?

Błędy zwykle pojawiają się już na etapie projektowania rozwiązania. Kilka szczególnie ryzykownych praktyk to:

• trenowanie modelu na pełnych eksportach z e‑dziennika (nazwiska, PESEL, pełna historia ocen, uwagi),
• łączenie danych z wielu szkół bez kontroli, czy konkretne pola nie umożliwiają identyfikacji uczniów lub klas,
• udostępnianie danych dostawcy chmury, który reużywa je do trenowania innych, własnych modeli,
• brak DPIA (oceny skutków dla ochrony danych) przed wdrożeniem systemu adaptacyjnego,
• logowanie „surowych” danych wejściowych i odpowiedzi ucznia bez pseudonimizacji i bez ograniczenia czasu przechowywania.

Unikanie tych pułapek wymaga zaplanowania ochrony prywatności od początku projektu.

Jak w praktyce przygotować dane szkolne do bezpiecznego treningu modelu?

Przed przekazaniem danych do trenowania modelu warto wdrożyć powtarzalny proces transformacji (ETL), który usuwa lub modyfikuje pola niosące ryzyko identyfikacji ucznia.

Typowe kroki obejmują:

• usunięcie imion, nazwisk, PESEL i numerów dokumentów,
• zamianę daty urodzenia na wiek lub przedział wiekowy (np. 10–11 lat),
• zakodowanie szkoły i klasy (np. losowym identyfikatorem lub hashem), a w małych szkołach – rozważenie całkowitego ukrycia tych informacji,
• usunięcie pełnych tekstów uwag nauczyciela i zastąpienie ich kategoryzacją (np. „brak pracy domowej”, „spóźnienia”),
• usunięcie lub silne zagregowanie danych wrażliwych (orzeczenia, opinie, informacje zdrowotne), jeśli nie są absolutnie niezbędne.

Taki proces powinien być zautomatyzowany i opisany w dokumentacji przetwarzania danych.

Czy da się całkowicie wyeliminować ryzyko wycieku danych uczniów z modelu AI?

Ryzyko można znacząco zminimalizować, ale trudno je całkowicie wyeliminować. Nowoczesne modele mogą zapamiętywać fragmenty danych treningowych, co przy specjalnych atakach (np. model inversion, membership inference) może prowadzić do rekonstrukcji części informacji.

W praktyce bezpieczeństwo zwiększa się poprzez:

• solidną pseudonimizację lub anonimizację danych wejściowych,
• ograniczenie zakresu danych do absolutnego minimum,
• stosowanie technik prywatności (np. privacy by design, ewentualnie differential privacy),
• regularne testy bezpieczeństwa i przeglądy modeli pod kątem „wycieku” danych,
• jasne umowy z dostawcą systemu dotyczące tego, do czego dane mogą (i nie mogą) być używane.

Celem jest takie obniżenie ryzyka, by było ono akceptowalne z punktu widzenia szkoły, rodziców i regulatorów.

Wnioski w skrócie

• Dane szkolne są wyjątkowo wrażliwe, bo łączą dane osobowe z informacjami o wynikach w nauce, zachowaniu, sytuacji rodzinnej i zdrowiu, co znacząco zwiększa ryzyko naruszenia prywatności uczniów.
• Modele uczenia maszynowego mogą zapamiętywać fragmenty danych treningowych, dlatego nawet pozornie zanonimizowane zbiory (bez imienia i nazwiska) mogą prowadzić do ujawnienia informacji o konkretnym uczniu.
• RODO wymaga m.in. minimalizacji danych, ograniczenia celu przetwarzania, podejścia privacy by design/by default oraz pełnej rozliczalności, a naruszenia mogą skutkować sankcjami prawnymi i utratą zaufania do szkoły i dostawcy systemu.
• Typowe błędy to m.in. trenowanie na pełnych eksportach z e‑dziennika, mieszanie danych z wielu szkół bez kontroli identyfikatorów, powierzanie danych chmurom reużywającym je do innych celów, brak DPIA oraz niekontrolowane logowanie pełnych danych.
• W większości zastosowań edukacyjnych wystarczy analiza interakcji z materiałami, zagregowane wyniki i ogólne parametry kontekstowe – nie ma potrzeby używania imion, PESEL-i, szczegółowych uwag wychowawców czy danych zdrowotnych.
• Usunięcie imienia i nazwiska rzadko daje pełną anonimowość – kombinacja szkoły, klasy, wieku, nietypowych wyników czy wzorców frekwencji może umożliwić identyfikację ucznia, zwłaszcza w małych placówkach.
• Bezpieczne trenowanie modeli na danych szkolnych wymaga świadomego projektowania procesu (od analizy celu po DPIA i architekturę techniczną), aby osiągnąć korzyści edukacyjne bez naruszania prywatności i godności uczniów.

Przeczytaj również:

• 

  Kiedy nauczyciel udostępnia dane ucznia przez pomyłkę

• 

  Jakie dane są zbierane w szkołach i na uczelniach?

• 

  10 zasad bezpiecznego przetwarzania danych w szkołach

• 

  Kto ma dostęp do danych Twojego dziecka w szkole?

• 

  RODO w szkole – jak legalnie analizować dane uczniów?

• 

  Przewodnik: budowanie bazy danych ucznia pod uczenie…