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.