Środki techniczne i organizacyjne (TOM)

1. Zakres i cel

Niniejszy dokument opisuje środki techniczne i organizacyjne (TOM), którymi MousePlayer zapewnia stopień bezpieczeństwa odpowiadający ryzyku zgodnie z art. 32 RODO. Dotyczy on każdego przetwarzania danych użytkowników końcowych w imieniu administratora (Klienta).

Operator usługi: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Polska · NIP PL7252266190.

2. Poufność – dostęp fizyczny, systemowy i uprawnienia

2.1 Kontrola dostępu fizycznego

Usługa działa na własnym sprzęcie w Łodzi, w Polsce. W samym utrzymaniu nie uczestniczy żaden dostawca centrum danych, chmury ani hostingu. Serwery są eksploatowane we własnym zakresie, w zamkniętych pomieszczeniach na terenie Polski. Dostęp ma wyłącznie sam administrator. Pomieszczenie jest zamykane na klucz i objęte monitoringiem wizyjnym; inne osoby — w tym wynajmujący czy serwis sprzątający — nie mają dostępu (oświadczenie administratora, 17.08.2026). Dokładny adres celowo nie jest tu podany.

2.2 Kontrola dostępu do systemu

• Dostęp do aplikacji wymaga indywidualnego konta użytkownika z hasłem; hasła przechowywane są jako solone skróty, nigdy jawnie.
• Interfejsy administracyjne są oddzielone od aplikacji klienckiej i dostępne wyłącznie dla superadministratorów; uprawnienie jest sprawdzane po stronie serwera.
• Żądania zmieniające stan w zalogowanym interfejsie WWW są chronione tokenami CSRF; interfejsy programistyczne uwierzytelniają się własnymi kluczami.
• Administracja serwerem odbywa się przez SSH z uwierzytelnianiem kluczem.
• Logowanie można opcjonalnie chronić drugim składnikiem (jednorazowe kody czasowe zgodnie z RFC 6238). Sekret przechowywany jest w postaci zaszyfrowanej, a kody odzyskiwania wyłącznie jako skróty; kod już użyty nie jest przyjmowany po raz drugi, a powtarzające się nieudane próby czasowo blokują drugi składnik konta.
• Każde logowanie jest prowadzone osobno (login_sessions). Właściciel konta widzi listę w ustawieniach i może unieważnić pojedyncze logowania lub wszystkie pozostałe; unieważnienie kończy także trwającą sesję i zapisany znacznik zapamiętanego logowania. Zmiana hasła kończy wszystkie pozostałe logowania. Jeżeli konto zaloguje się z nieznanego urządzenia (odcisk z przeglądarki, systemu operacyjnego, rodzaju urządzenia i zakresu sieci /24 lub /48 adresu IP), właściciel otrzymuje e-mail.

2.3 Kontrola uprawnień

• Model ról (owner, admin, viewer) określa, co użytkownik może zobaczyć i zrobić w danym obszarze roboczym. Usuwanie i udostępnianie są zastrzeżone dla ról owner i admin; ograniczenie działa po stronie serwera, nie tylko w interfejsie.
• Każde zapytanie o dane sesji jest związane z obszarem roboczym konta pytającego. Cudzego nagrania nie da się wskazać nawet przy znajomości identyfikatora.
• Linki udostępniające (pkt 4.3) są jedyną drogą do nagrania bez logowania. Tworzy je świadomie uprawniony użytkownik, można je unieważnić i mogą mieć datę ważności.

2.4 Rozłączność danych

• Dane klientów są rozdzielone logicznie według obszaru roboczego i projektu (kanału). Każda ścieżka odczytu i zapisu niesie to ograniczenie.
• Środowisko deweloperskie i produkcyjne działają w odrębnych instalacjach z odrębnymi bazami danych.

3. Pseudonimizacja i minimalizacja danych

• Brak przetwarzania przed zgodą. Skrypt nagrywający nie identyfikuje, nie zapisuje, nie ustawia ciasteczka i nie nawiązuje połączenia, dopóki nie ma sygnału zgody. Brak sygnału traktowany jest jako odmowa, nie jako przyzwolenie.
• Global Privacy Control. Sygnał GPC z przeglądarki jest respektowany na całym świecie i ma pierwszeństwo przed każdym innym sygnałem.
• Identyfikatory pseudonimowe. Odwiedzający rozróżniani są losowo generowanymi tokenami. Usługa sama nie zbiera imion, adresów e-mail ani numerów telefonu.
• Adresy IP. Pełny adres IP odwiedzającego jest wykorzystywany w pamięci operacyjnej serwera nagrywającego do zestawienia połączenia, ustalenia kraju, miasta i operatora sieci oraz obrony przed nadużyciami; do bazy danych zapisywany jest wyłącznie w postaci skróconej (w przypadku IPv4 a.b.c.xxx), a w panelu nigdy nie pojawia się pełny adres IP odwiedzającego. Wyjątki: w celu wykrywania zalewu połączeń adres jest przez dziesięć sekund zliczany w Redis; jeżeli uruchomi automatyczną blokadę, przechowywany jest w pełnej postaci do 24 godz. jako wpis blokady w Redis (mp_autoban:), a ta instancja Redis zapisuje dane na dysk w trybie AOF. Wywołania linków udostępniających są rejestrowane z pełnym adresem IP (share_views) i usuwane razem z linkiem.
• Czyszczenie adresów URL. Wartości parametrów typowo niosących dane osobowe lub dane dostępowe (np. ?email=, ?token=, ?code=) są usuwane przed zapisem – zarówno w części zapytania adresu, jak i za znakiem #, gdzie usługi logowania umieszczają dane dostępowe (np. #access_token=). Trasy aplikacji jednostronicowych i kotwice na stronie pozostają bez zmian.
• Dane z formularzy – trzy poziomy, najostrzejszy domyślnie. Pełne maskowanie (domyślne) zastępuje każdy znak każdego wpisu, zanim opuści przeglądarkę. Maskowanie selektywne utrzymuje pełne maskowanie imion, adresów, e-maili, telefonów, pól płatniczych i pól tekstu swobodnego, a w pozostałych zastępuje tylko cyfry, dzięki czemu frazy wyszukiwania nadają się do analizy. Brak maskowania nagrywa dane tak, jak zostały wpisane. Dwa słabsze poziomy nie są do włączenia samodzielnie: każdy wymaga naszej pisemnej zgody dla tej konkretnej własności, zapisanej wraz z czasem i osobą udzielającą. Egzekwowanie odbywa się po stronie serwera – jeśli zapisany poziom przekracza zgodę, zostaje do niej ograniczony, zanim wartość dotrze do przeglądarki. Ustawienie pola wprost niczego więc nie daje.
• Granica, której nie podnosi żadna zgoda. Pola rozpoznane jako hasła lub dane płatnicze pozostają w pełni zamaskowane na każdym poziomie. Rozpoznanie czyta nazwę, id, typ oraz atrybut autocomplete i obejmuje określenia angielskie, niemieckie i polskie. Nic z tego nie sięga tego, co strona sama wypisuje na stronie; obszary oznaczone data-mp-mask pozostają całkowicie poza nagraniem.
• Lista wykluczeń. Administrator może wyłączyć z nagrywania całe ścieżki (np. koszyk lub obszar konta). Wykluczenie działa po stronie serwera i obejmuje również przejście aplikacji jednostronicowej na wykluczoną ścieżkę bez nowego połączenia.

4. Integralność – przekazywanie i wprowadzanie

4.1 Transmisja

• Połączenia z internetu są szyfrowane TLS; TLS kończy się w nginx na serwerze. Nieszyfrowane wywołania na porcie 80 są przekierowywane na HTTPS. Skrypt nagrywający łączy się domyślnie przez WSS (/mp_wss/). Jeżeli WebSocket w ogóle nie dojdzie do skutku, przechodzi na tunel HTTP przez HTTPS (/mp_wst), który przechodzi te same kontrole po stronie serwera; bardzo duże migawki strony przesyła przez HTTPS z podpisanym, ograniczonym czasowo dostępem (/mp_dom), a nieudane połączenia WebSocket zlicza punkt pomiarowy bez identyfikatora odwiedzającego (/mp_wsfail). Za nginx serwer WebSocket nasłuchuje wyłącznie na interfejsie loopback serwera, bez TLS.
• W naszej własnej sieci lokalnej, w tym samym miejscu, połączenia z bazą danych (MariaDB) i pamięcią podręczną (Redis) nie są szyfrowane; szyfrowanie transmisji tych połączeń nie jest skonfigurowane. Oba mają ograniczony dostęp i są osiągalne wyłącznie z własnej sieci lokalnej (brak przekierowania portów); instancja Redis aplikacji nasłuchuje wyłącznie na interfejsie loopback.
• Certyfikaty są odnawiane automatycznie. Wygasły certyfikat aplikacji zostałby wykryty przez cominutową kontrolę z drugiej maszyny (zob. punkt 5), która odpytuje przez HTTPS z weryfikacją certyfikatu; odrębnego monitorowania ważności certyfikatów nie ma.

4.2 Kontrola wprowadzania

• Czynności administracyjne są rejestrowane wraz z kontem, czasem i rodzajem działania.
• Każda zmiana stanu zgody zapisywana jest jako osobny rekord wraz ze źródłem (wyraźne API, Consent Mode, TCF, adapter CMP, GPC). Stan z chwili nagrania pozostaje dzięki temu wykazywalny.

4.3 Przekazywanie dalej

• Skrypt nagrywający przesyła dane wyłącznie do własnej infrastruktury MousePlayer. W zwykłym trybie nagrywania nie jest kontaktowany żaden podmiot trzeci.
• Opcjonalne interfejsy (webhooki, BigQuery, systemy CRM, e-mail marketingu i zgłoszeń, arkusze i magazyny obiektów, interfejsy konwersji sieci reklamowych) konfiguruje sam administrator; trafiają one do wybranych przez niego systemów, bez jego włączenia pozostają nieaktywne i przekazują pojedyncze dane; jedynie eksport do BigQuery może w planie Enterprise na życzenie obejmować także surowe zdarzenia nagrania (mouse_events). Jeżeli administrator włączy most do narzędzia, które sam osadził na swojej stronie (np. czat, śledzenie błędów lub analityka internetowa), skrypt przekazuje temu narzędziu w przeglądarce pojedyncze dane, takie jak odnośnik do nagrania; do jego dostawcy przesyła je własny skrypt tego narzędzia. Odbiorcy nie są dalszymi podmiotami przetwarzającymi MousePlayer.
• Wygenerowane teksty formułuje model językowy na własnych komputerach z kartą graficzną, w tej samej sieci lokalnej i w tym samym miejscu co serwer. Pobierają one obliczone ustalenia przez HTTPS, podpisując każde zapytanie własnym sekretem; samo nagranie do nich nie trafia, a do zewnętrznej usługi AI nie trafia nic – także wtedy, gdy taki komputer jest wyłączony z powodu prac konserwacyjnych: zlecenia czekają wówczas, a interfejs pokazuje wersję obliczoną.
• Linki udostępniające przekazują dane wyłącznie posiadaczowi linku. O ich utworzeniu decyduje administrator.

5. Dostępność i odporność

• Codziennie o 03:00 tworzona jest pełna kopia bazy danych, katalogu aplikacji oraz – od 06.10.2026 – archiwum nagrań; do 11.08.2026 powstawała o 02:00.
• Lokalny okres przechowywania kopii: 7 dni. Kopia lokalna leży nieszyfrowana na podłączonym nośniku; szyfrowanie następuje przy przenoszeniu poza siedzibę. Nieszyfrowane zrzuty z okresu sprzed przestawienia zostały tam usunięte 12.08.2026, dzięki czemu katalog lokalny zawiera już wyłącznie zrzuty powstałe po przestawieniu, a ten okres go obejmuje. Poza kopią lokalną codzienna kopia zapasowa jest przenoszona poza siedzibę – od 5 września 2026 r. do zasobnika Google Cloud Storage w regionie europe-central2 (Warszawa); wcześniej na prywatne konto Google Drive; kopie tam umieszczone zostały usunięte 6 września 2026 r., po sprawdzeniu odtworzenia z nowego miejsca docelowego. Okres przechowywania: kopie dzienne 7 dni, kopie tygodniowe (niedziela) 364 dni. Obie liczby są ustawieniem, a nie stałą w skrypcie: kopia zapasowa odczytuje je z tego samego wiersza konfiguracji, który cytuje niniejsze zdanie, dzięki czemu opublikowana informacja i rzeczywiste zachowanie nie mogą się rozejść. Kopia zawiera pełną bazę danych. Po 7 dniach zdarzenia nagrania są przenoszone z bazy danych do archiwum. Od 06.10.2026 archiwum to jest częścią codziennej kopii zapasowej; wcześniej nie było nią objęte, a nagrania starsze niż 7 dni nie miały kopii zapasowej. Archiwum znajduje się na tym samym dysku co system; przed awarią tego dysku chronią kopia lokalna na odrębnym nośniku oraz kopia wyniesiona. Od 11.08.2026 kopia jest szyfrowana na naszym własnym serwerze przed przesłaniem (rclone crypt); zaszyfrowane są także nazwy plików i katalogów, dzięki czemu u dostawcy pozostają wyłącznie bloki bez rozpoznawalnego znaczenia. Klucze znajdują się w dwóch plikach na naszym własnym serwerze, dostępnych do odczytu i zapisu wyłącznie dla ich właściciela (uprawnienia 600); dostawca ich nie ma i nie może odczytać treści. Odszyfrowanie takiej kopii zostało sprawdzone. Dotychczasowy, nieszyfrowany katalog docelowy z pełnymi kopiami sprzed 11.08.2026 został usunięty 12.08.2026. Od 19.08.2026 powodzenie transferu jest monitorowane automatycznie. Kopia zapasowa zapisuje swój wynik do pliku stanu, a czujnik pyta o ostatni udany przebieg, a nie o ostatni przebieg – skrypt, który startuje każdej nocy i każdej nocy przerywa, ma świeży znacznik czasu i nie ma kopii. Jeżeli przez czas dłuższy niż ustawiony okres nie było udanego przebiegu (domyślnie 36 godzin, co dopuszcza dokładnie jeden opuszczony przebieg dzienny), wysyłane jest ostrzeżenie pocztą elektroniczną, najwyżej raz dziennie.
• Dane usunięte w systemie produkcyjnym pozostają w kopiach do czasu wygaśnięcia danej kopii – najdłużej 364 dni po trwałym usunięciu; potem nie ma go już także w żadnej kopii. To nieunikniona druga strona posiadania kopii w ogóle; żądania usunięcia realizowane przez administrację od razu wyłączają dane z przetwarzania (zarchiwizowane, ukryte, już nienagrywane) i trwale je usuwają najpóźniej po 30 dniach, a na wyraźne żądanie bez oczekiwania; żądanie złożone na stronie danych /moje-dane jest wykonywane bez archiwizacji, z reguły w ciągu kilku minut. Wybiórcze usuwanie wewnątrz kopii nie jest prowadzone: kopia to jedno zapieczętowane archiwum, którego celem jest wierne odwzorowanie jednego punktu w czasie, a otwarcie go, zmiana i ponowne zapieczętowanie zniszczyłoby tę właściwość oraz możliwość wykazania, że nikt przy nim nie manipulował. Kopie zapasowe nie służą żadnemu innemu celowi niż odtworzenie systemu po utracie danych; nie są przeszukiwane, analizowane ani ujawniane. Jeżeli kopia zostanie odtworzona, żądania usunięcia zapisane dla użytkowników końcowych zostaną wykonane ponownie, zanim system wróci do pracy – zapis żądania przetrwa usunięcie właśnie po to, by można je było powtórzyć. W przypadku usuniętego konta klienta jest inaczej: jego usunięcie świadomie nie pozostawia zapisu, który by je oznaczał, więc odtworzona kopia zawierałaby konto usunięte po dacie tej kopii.
• Monitorowanie. Proces czujnika sprawdza co minutę bazę danych wraz z przetwarzaniem zdarzeń, serwer WebSocket, interfejs webowy, aktualność bazy geolokalizacji, dzienny przebieg usuwania, powodzenie kopii zapasowej oraz wolne miejsce na dysku systemowym i nośniku kopii. Każdy wynik zapisywany jest we wspólnym stanie i pokazywany w panelu administracyjnym; każda nieudana kontrola zgłaszana jest pocztą elektroniczną najwyżej raz dziennie – czujnik, który wysyła pocztę co minutę, zostaje wyłączony, a wtedy nie zgłasza również prawdziwej awarii. Przed 19.08.2026 sprawdzanych było tylko pierwsze pięć z tych punktów, a alarm wywoływał wyłącznie przebieg usuwania; reszta była ręczna, i niniejszy dokument to stwierdzał.
• Czego to monitorowanie nie potrafi – powiedziane wprost, a nie przemilczane: działa ono na tej samej maszynie, którą obserwuje, więc nie może zgłosić jej całkowitej awarii. Od 2 października 2026 r. druga maszyna w tym samym miejscu co minutę sprawdza, czy aplikacja przyjmuje nagrania – bazę danych, pamięć podręczną, serwer WebSocket, procesy w tle, kolejkę i skrypt śledzący – i po dwóch kolejnych nieudanych kontrolach alarmuje przez Telegram. Łączy się z serwerem przez sieć lokalną: awarii łącza internetowego, routera lub DNS nie wykrywa i nadal zauważa ją człowiek, a nie czujnik. Zakładany czas odtworzenia (RTO): nie więcej niż 24 godziny. Testy odtworzenia: odtworzenie z wyniesionej kopii zapasowej sprawdzono 5 i 6 września 2026 r. oraz 7 października 2026 r. (pełne odtworzenie danych); stały harmonogram nie został ustalony.
• Przeciążenie i ataki. nginx ogranicza liczbę żądań i równoczesnych połączeń na adres; adres, który uporczywie przekracza limit, jest przez fail2ban odrzucany na zaporze przez jedną godzinę. Serwer WebSocket automatycznie blokuje na 24 godz. adresy generujące zalew połączeń; blokady ustawione ręcznie przez operatora zapisane są w bazie danych.

6. Procedury regularnego przeglądu

• Środki opisane w tym dokumencie są weryfikowane przy każdej zmianie przetwarzania, a poza tym w odstępie wskazanym w punkcie 10.
• Kontrola instalacji sprawdza dla każdego projektu klienta, czy skrypt jest poprawnie osadzony i czy nagrania przychodzą z zapisem zgody. Projekty bez takiego zapisu są oznaczane w panelu.
• Zewnętrzne testy penetracyjne nie są obecnie zlecone i nie posiadamy certyfikatów bezpieczeństwa. Jest to napisane wprost, a nie pominięte: dokument TOM, który o tym milczy, czyta się tak, jakby takie badania istniały.
• Liczba obserwowanych łącznie u wszystkich klientów użytkowników końcowych mierzona jest codziennie i zestawiana z progiem, od którego ocenę z art. 37 RODO należy powtórzyć (100000 miesięcznie; zob. sekcja 9 Rejestru czynności przetwarzania). Wielkość tę wyznacza ruch na witrynach klientów, a nie my; pozostawienie jej bez obserwacji oznaczałoby ciche zdezaktualizowanie się oceny. Coroczne powtórzenie nadzoruje ten sam proces.

7. Podmioty przetwarzające dalej

MousePlayer korzysta z dalszych podmiotów przetwarzających wyłącznie na podstawie ogólnej pisemnej zgody wynikającej z DPA. Aktualna lista wraz z celem, kategoriami danych i miejscem przetwarzania publikowana jest osobno:

• Lista podmiotów przetwarzających dalej

W samym nagrywaniu nie uczestniczy żaden podmiot trzeci: skrypt nagrywający przesyła dane wyłącznie do własnej infrastruktury. W odniesieniu do danych użytkowników końcowych istnieje poza tym jeden odbiorca: codzienna kopia całej bazy danych i archiwum nagrań — wraz z nagraniami sesji — przechowywana jest u Google (Google Cloud Storage, zasobnik w Warszawie). Od 11.08.2026 jest tam przechowywana w postaci zaszyfrowanej: szyfrowanie odbywa się na naszym własnym serwerze przed przesłaniem (rclone crypt) i obejmuje także nazwy plików i katalogów; klucze pozostają u MousePlayer. Google ich nie otrzymuje i nie może odczytać treści, pozostaje jednak dalszym podmiotem przetwarzającym — szyfrowanie jest środkiem technicznym, nie zmienia roli. Dotychczasowy, nieszyfrowany katalog docelowy z kopiami sprzed 11.08.2026 został usunięty 12.08.2026.

8. Przechowywanie i usuwanie

Okres przechowywania nagrań sesji zależy od planu taryfowego Klienta:

• Free: 7 dni · Small: 30 dni · Business: 90 dni · Enterprise: według indywidualnej umowy.
• Po przejściu na niższy plan obowiązuje okres ochronny wynoszący co najmniej 30 dni, w którym utrzymywany jest dłuższy okres z planu dotychczasowego. Przejście na wyższy plan nigdy nie skraca przechowywania.
• Dziennik aplikacji usuwany jest po 60 dniach, dzienniki serwera WWW po 14 dniach, dzienniki bezpieczeństwa po 72 godzinach.
• W przypadku sesji rozpoznanych jako zautomatyzowany dostęp nagranie jest czyszczone po 1 dniu, a sesja usuwana po 14 dniach. W przypadku konta w planie Free oznaczonego jako podejrzane o nadużycie nagrywana jest tylko część wizyt, a nagrania są usuwane po 1 dniu.
• Dziennik dostarczeń integracji usuwany jest po 30 dniach. Znajduje się w Redis, a nie w bazie danych, i wygasa tam sam; lista jest dodatkowo ograniczona do 25 wpisów na projekt. Nie jest więc również częścią codziennej kopii zapasowej.
• Usuwanie po upływie okresu przechowywania przebiega automatycznie i bez nadzoru; nie musi być uruchamiane ręcznie.

Z chwilą zakończenia konta Klienta wszystkie związane z nim dane osobowe usuwane są w ciągu 30 dni, chyba że prawo Unii lub państwa członkowskiego wymaga dłuższego przechowywania. Usunięcie uruchamia sam Klient w ustawieniach konta; wniosek e-mailem nie jest potrzebny. Najpierw konto zostaje zarchiwizowane: dostęp kończy się natychmiast, nic nie jest już nagrywane ani wyświetlane, a przez 30 dni możemy je na wniosek przywrócić, jeżeli usunięcie nastąpiło przez pomyłkę. Po upływie tego okresu konto zostaje trwale usunięte; uruchamiając usunięcie, Klient może też od razu wybrać trwałe usunięcie. Projekt lub obszar roboczy usunięty przez Klienta również zostaje najpierw zarchiwizowany na 30 dni i w tym czasie można go przywrócić w panelu. Trzy rzeczy pozostają celowo zachowane, ponieważ wymaga tego prawo albo ponieważ dokumentują decyzję, a nie osobę: dowód akceptacji tych dokumentów, dziennik bezpieczeństwa i zmian (bez odniesienia do osoby) oraz zgłoszenia do wsparcia. Wyjątkowo konto w planie Free, które nie było używane przez 24 miesięcy, jest trwale usuwane bez wcześniejszej archiwizacji 30 dni po doręczonym powiadomieniu.

Zapisy zgód pozostają po usunięciu samego nagrania. Nie zawierają danych behawioralnych, a jedynie fakt, czas i źródło decyzji o zgodzie, i służą wykazaniu rozliczalności z art. 5 ust. 2 RODO.

9. Naruszenie ochrony danych osobowych

MousePlayer zawiadamia administratora bez zbędnej zwłoki, nie później niż w ciągu 48 godzin od powzięcia wiadomości o naruszeniu ochrony danych osobowych dotyczącym jego danych. Zawiadomienie zawiera informacje potrzebne administratorowi do wypełnienia własnego obowiązku z art. 33 RODO.

Adres do zgłaszań incydentów bezpieczeństwa: office@mouseplayer.com

10. Stan i wersja

• Wersja: 1.5 · Obowiązuje od: 16.10.2026 · Następny przegląd: 19.08.2027 · zastępuje wersję 1.4 z 07.10.2026. Zmiany: punkt 2.2 wskazuje logowanie dwuskładnikowe, listę aktywnych logowań z możliwością unieważnienia oraz powiadomienie o logowaniu; punkt 2.3 wskazuje role owner, admin i viewer; punkt 3 wskazuje wyjątki dotyczące pełnych adresów IP; punkt 4.1 opisuje drogi transmisji skryptu oraz nieszyfrowane połączenia w sieci lokalnej zamiast stwierdzenia, że nie istnieje ścieżka nieszyfrowana; punkt 4.3 wskazuje pozostałe interfejsy; punkt 5 odnotowuje, że archiwum nagrań jest objęte kopią zapasową od 06.10.2026, oraz wskazuje przeprowadzone testy odtworzenia i ograniczenia przeciążenia; punkt 8 uzupełnia okresy przechowywania i usuwanie nieaktywnych kont. Ponadto punkt 2.2 podaje stan logowania przez SSH, a czas automatycznej blokady podany jest jako ustawienie. Wersja 1.4 zastąpiła wersję 1.3 z 17.09.2026. Zmiany: punkty 5 i 8 stanowią, że usunięcie najpierw archiwizuje dane – od razu wyłączone z przetwarzania – i trwale je usuwa najpóźniej po 30 dniach. Wersja 1.3 zastąpiła wersję 1.2 z 19.08.2026. Zmiany: punkt 4.3 wskazuje komputery, na których działa model językowy dla generowanych tekstów, sposób, w jaki trafiają do nich ustalenia, oraz to, co dzieje się w czasie prac konserwacyjnych. Wersja 1.2 zastąpiła wersję 1.1 z 11.08.2026. Zmiany: punkt 5 podaje okresy przechowywania kopii jako ustawienie, a nie stałą, opisuje, co dzieje się z usunięciami przy odtworzeniu, i odnotowuje, że powodzenie kopii zapasowej oraz miejsce na dysku są od teraz monitorowane automatycznie; punkt 6 dodaje pomiar progu z art. 37.
• W razie rozbieżności między wersjami językowymi rozstrzyga wersja angielska.