W zeszycie i na zdjęciach stron bywa wszystko naraz: nazwiska, oceny, uwagi wychowawcy, informacje o frekwencji, fragmenty prac domowych, czasem dane zdrowotne albo sytuacja rodzinna zapisana na marginesie. W kontekście szkoły takie zbiory są traktowane poważnie przez prawo ochrony danych, w UE ramy wyznacza RODO/GDPR, a edukacja jest wskazywana jako obszar o podwyższonym ryzyku przy chmurze, profilowaniu i narzędziach cyfrowych (GDPR in Schools, ochrona danych uczniów).

Nawet jeśli „to tylko historia nowożytna”, kontekst osobisty często przykleja się do pliku: nazwa klasy w nagłówku, zrzut z dziennika, zdjęcie tablicy z listą obecności. Im łatwiej wrzucić to do AI, tym łatwiej zapomnieć, że to nadal dane o człowieku.

Popularne narzędzia AI dla nauczycieli i uczniów bywają krytykowane właśnie za to, że treści z klasy lądują u zewnętrznego dostawcy, czasem z niejasnym retencjonowaniem, szkoleniem modeli albo szerokim dostępem po stronie vendorów. Relacje z terenu edukacji w USA opisują, jak dystrykty próbują ograniczać ryzyka, gdy nauczyciele wklejają prace uczniów do generatywnego AI (Chalkbeat: AI i prywatność danych uczniów). Przewodniki dla nauczycieli ostrzegają wprost: niektóre narzędzia mogą przechowywać wpisy długo i wykorzystywać dane klasowe do trenowania komercyjnych modeli, stąd konieczność czytania polityk prywatności przed użyciem (AI privacy in education, SchoolAI).

Organizacje nauczycielskie podkreślają też szerszy kontekst: instytucje edukacyjne trzymają unikalne, wrażliwe zbiory o uczniach i rodzinach, co czyni je celem cyberataków (NEA: Student and Educator Data Privacy). To nie argument „przeciw AI”. To argument „przeciw wrzucaniu wszystkiego w pierwszy lepszy chat bez pytania, gdzie ląduje treść”.

Rozmowa o prywatności w aplikacjach do nauki miesza często trzy różne rzeczy:

1. Zdjęcia i skany: surowy obraz stron. Najbardziej „ciężkie” pliki; łatwo zawierają tło (biurko, twarze, dokumenty obok).
2. Tekst po OCR: już czytelny dla maszyny. Wygodny do analizy, więc chętnie wysyłany dalej.
3. Zapytania do modelu AI: fragmenty notatek + instrukcja („zrób quiz”). Tu wybór dostawcy i klucza ma znaczenie.

Sensowna architektura pyta przy każdej warstwie: czy to musi opuścić telefon? Jeśli tak, do kogo, na jakich zasadach, czy da się to ograniczyć?

Klasyczny skrót „wyślij zdjęcie do OCR online” oznacza transfer obrazu na cudzy serwer. Alternatywa: model OCR działa lokalnie (np. Google ML Kit Text Recognition), tekst powstaje na telefonie, bez wysyłania skanu „tylko po to, by odczytać litery” (dokumentacja ML Kit).

Dla ucznia praktyka wygląda tak: robisz zdjęcie podręcznika → tekst pojawia się w aplikacji → zdjęcie nie musi podróżować do losowego OCR-as-a-service. To nie magiczna niewidzialność (telefon nadal jest urządzeniem z kontem, kopiami zapasowymi itd.), ale odcina jeden zbędny, ryzykowny skok w chmurę.

Warto też pamiętać o „cichych” uploadach: niektóre aplikacje skanujące synchronizują domyślnie do dysku w chmurze „dla wygody”. Sprawdź ustawienia kopii zapasowej galerii, zanim uznasz, że skan „został tylko u Ciebie”. Lokalny OCR w aplikacji do nauki nie zastąpi świadomego zarządzania zdjęciami w systemie operacyjnym.

BYOK oznacza: to Ty wklejasz klucz API do wybranego dostawcy AI. Aplikacja wywołuje model z Twojego urządzenia Twoim kluczem, zamiast zbierać notatki na własnym backendzie „w kolejce do naszego AI”.

Co to daje:

• Kontrolę dostawcy: wybierasz, z kim rozmawia telefon (i czytasz jego politykę, nie tylko opis aplikacji).
• Mniej pośredników: Studdly nie musi trzymać magazynu Twoich skanów, żeby uruchamiać AI w Twoim imieniu.
• Świadomy koszt / limit: klucz zwykle wiąże się z kontem u dostawcy; wiesz, że coś jest wysyłane, bo sam to skonfigurowałeś.

Czego BYOK nie załatwia automatycznie: treść, którą wyślesz do modelu, nadal podlega zasadom tego dostawcy. Dlatego zasada minimalizacji zostaje: wysyłaj tekst potrzebny do podtematów i quizów, nie całe albumy zdjęć z szatni w tle.

Dla rodzica BYOK jest też sygnałem przejrzystości: zamiast czarnej skrzynki „aplikacja sama jakoś ogarnia AI w chmurze”, widać moment konfiguracji. Możecie wspólnie wybrać dostawcę, ustawić limity w panelu konta i nauczyć nastolatka, że klucz API to jak hasło, nie wrzuca się go na grupowy Discord.

Uczeń, 22:40, sprawdzian jutro. Wkleja cały rozdział + nazwisko z dziennika do publicznego czata. Ryzyko: retencja, ewentualne trenowanie, wyciek przy kompromitacji konta. Lepszy wariant: lokalny OCR → krótki tekst → AI na własnym kluczu → quizy offline.

Rodzic patrzy na aplikację dziecka. Pytania, które warto zadać: Czy skany idą na serwer aplikacji? Czy OCR jest lokalny? Czy AI idzie przez backend vendora, czy BYOK? Czy po wygenerowaniu materiału da się uczyć bez netu? Jasne odpowiedzi biją marketingowe „dbamy o prywatność”.

Nauczyciel / korepetytor. Nie wklejaj prac z danymi osobowymi do narzędzi bez umowy i polityki szkoły. Anonimizuj albo używaj środowisk zaakceptowanych przez placówkę.

Studdly jest tak zaprojektowane, żeby notatki szkolne nie lądowały w kolejce na cudzym backendzie „pod AI”: OCR jest na telefonie, a wnioskowanie AI idzie z urządzenia do dostawcy, którego wybrałeś, z kluczem, który wkleiłeś (BYOK). Po analizie uczysz się offline.

Jeśli tematem jest prywatność, Studdly jest sensownym wyborem właśnie dlatego, że rozdziela warstwy: skan i tekst zostają lokalnie przy OCR, a chmura AI to świadomy wybór konta u dostawcy, nie ukryty upload całego zeszytu do nieznanej usługi edukacyjnej.

Dla ucznia i rodzica to konkretny model, nie slogan „dbamy o dane”. Szczegóły produktu: studdly.app.

• Nie wrzucaj do publicznych czatów skanów z widocznymi danymi z dziennika, opinii PPP czy korespondencji z wychowawcą.
• Nie zakładaj, że „tryb incognito” w przeglądarce chroni przed polityką retencji po stronie modelu.
• Nie udostępniaj klucza API kolegom „na chwilę”, to dostęp do Twojego konta i billingu.
• Nie myl lokalnego OCR z lokalnym AI: po BYOK tekst (lub jego fragment) i tak może wyjść do dostawcy, którego wybrałeś.

Dobra intuicja: pytaj o każdą warstwę osobno. Skan → OCR → AI → przechowywanie gotowych quizów. Im więcej warstw dzieje się na telefonie albo pod Twoim kluczem, tym mniej domyślasz się „co robi backend, którego nie widzę”.

1. Czy na skanie widać coś poza materiałem (ludzie, dokumenty, ekran dziennika)?
2. Czy OCR musi być w chmurze, czy da się lokalnie?
3. Czy znam dostawcę AI i mam własny klucz (BYOK)?
4. Czy wysyłam minimum tekstu potrzebnego do quizu / wyjaśnienia?
5. Czy po wygenerowaniu mogę ćwiczyć offline?

Jeśli na któreś pytanie nie umiesz odpowiedzieć, zatrzymaj się na chwilę. Sprawdzian można zdać bez oddawania całego zeszytu pierwszej lepszej chmurze.