Środki techniczne i organizacyjne

Niniejsze tłumaczenie udostępniono dla wygody. Wiążąca jest wyłącznie wersja angielska dostępna pod adresem /p/technical-and-organisational-measures.

1. Zakres i zasada

Niniejszy dokument opisuje środki techniczne i organizacyjne („Środki TOM"), które LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polska, NIP PL7252266190 („Operator") stosuje przy prowadzeniu reactive.chat („Usługa"). Stanowi on Załącznik B do Umowy powierzenia przetwarzania („Umowa powierzenia") i służy dokumentacji wymaganej przez art. 32 RODO. Pojęcia zdefiniowane w Umowie powierzenia („Klient", „Odwiedzający", „Dane Klienta") mają tu to samo znaczenie.

Zasada. Każdy opisany tu środek jest wdrożony. Tam, gdzie środek ma swoje granice, granica jest podana obok niego, a nie pominięta, aby Klient mógł ocenić, czy poziom ochrony jest odpowiedni dla danych, które powierza Usłudze. Ryzyka pozostające po zastosowaniu tych środków oceniono w ocenie skutków dla ochrony danych Operatora; same operacje przetwarzania wymieniono w jego rejestrze czynności przetwarzania. Żaden z tych dokumentów nie jest publikowany; Operator udostępnia je organowi nadzorczemu oraz, na żądanie, Klientom.

Kontekst. Usługę prowadzi osobiście właściciel Operatora. Działa ona na jednym serwerze będącym własnością Operatora (Raspberry Pi 5) w pomieszczeniach Operatora w Łodzi. Usługa działa w instalacji produkcyjnej oddzielonej od jej instalacji deweloperskiej na tej samej maszynie (pkt 2.4). Ta sama maszyna obsługuje również inne usługi Operatora. Modele językowe działają na odrębnych komputerach Operatora („węzły AI") w tej samej sieci lokalnej. Codzienna zaszyfrowana kopia serwera jest przechowywana poza siedzibą w Google Cloud Storage w Warszawie (pkt 5.1). Środki organizacyjne są dostosowane do działalności prowadzonej przez jedną osobę: nie ma odrębnego zespołu bezpieczeństwa ani rozdziału obowiązków między rozwojem, eksploatacją i kontrolą.

Środki uporządkowano według kategorii art. 32 RODO: poufność (pkt 2 i 3), integralność (pkt 4), dostępność i odporność (pkt 5), zdolność do przywrócenia (pkt 6), procedury regularnego testowania (pkt 7), kontrola przetwarzania w imieniu Klienta (pkt 8) oraz środki właściwe dla funkcji AI (pkt 9).

2. Poufność – dostęp

2.1 Kontrola dostępu fizycznego

• Serwer i węzły AI są sprzętem będącym własnością Operatora i znajdują się w pomieszczeniach Operatora w Łodzi. W prowadzeniu Usługi nie uczestniczy żadne zewnętrzne centrum danych ani dostawca hostingu. Dostęp do internetu zapewnia Toya Sp. z o.o., Łódź, jako wyłącznie operator sieci bez dostępu do przechowywanych danych.
• Pomieszczenia są zamykane; dostęp ma wyłącznie Operator (oświadczenie Operatora).
• Pamięć masowa serwera nie jest szyfrowana na poziomie dysku. Ochrona danych w spoczynku przed kradzieżą sprzętu opiera się więc na środkach fizycznych. Kopie zapasowe przesyłane poza siedzibę są szyfrowane (pkt 5.1); lokalna kopia najnowszych kopii zapasowych na dysku podłączonym do serwera nie jest szyfrowana (pkt 5.1).

2.2 Kontrola dostępu do systemów (uwierzytelnianie)

Konta Klientów

• Hasła są przechowywane wyłącznie jako skróty bcrypt o współczynniku kosztu 12 i automatycznie przeliczane przy zmianie algorytmu. Hasło musi mieć co najmniej 10 znaków; popularne hasła oraz hasła utworzone z imienia, nazwiska lub adresu użytkownika są odrzucane.
• Logowanie trwa tyle samo niezależnie od tego, czy konto istnieje, aby nie można było ustalić, które adresy e-mail są zarejestrowane. Rejestracja jest chroniona w ten sam sposób.
• Po 5 nieudanych próbach logowania konto jest blokowane na 15 minut. Niezależnie od tego ograniczona jest liczba prób logowania z jednego adresu IP (30 na 15 minut), a także rejestracji (10 na godzinę z jednego adresu IP), wniosków o reset hasła (10 na 15 minut) i zgłoszeń do wsparcia.
• Google reCAPTCHA v3 sprawdza formularze logowania, rejestracji, resetu hasła i wsparcia pod kątem zautomatyzowanych nadużyć (zob. stronę Podwykonawcy przetwarzania, pkt 3). Nie jest używana w widżecie czatu. Jeżeli Google jest nieosiągalne lub nie skonfigurowano klucza, formularze są przyjmowane bez sprawdzenia; logowanie bez tokenu reCAPTCHA jest również przyjmowane, ponieważ obowiązują dla niego blokada konta i limity na adres.
• Uwierzytelnianie dwuskładnikowe za pomocą jednorazowego hasła opartego na czasie (TOTP, RFC 6238) jest dostępne dla każdego użytkownika, z ochroną przed ponownym użyciem kodu oraz z jednorazowymi kodami odzyskiwania przechowywanymi jako skróty; wspólny sekret jest przechowywany w postaci zaszyfrowanej (pkt 3.2). Dla kont Klientów jest ono dobrowolne; obszar roboczy nie może obecnie go wymusić. Dla obszaru administracyjnego Operatora jest obowiązkowe (zob. Administracja serwerem).
• W planie Agency można skonfigurować logowanie przez własnego dostawcę tożsamości Klienta (single sign-on, OpenID Connect) i uczynić je obowiązkowym dla obszaru roboczego.
• Sesje istnieją wyłącznie na serwerze. Identyfikator sesji ma 256 bitów losowości; od 17 października 2026 r. w bazie danych przechowywany jest wyłącznie jego skrót SHA-256 (także w odwołaniu tokenu „nie wylogowuj mnie”), plik cookie zawiera wartość losową, a kopia bazy danych nie zawiera żadnej użytecznej sesji. Sesja wygasa po 14 dniach nieużywania, token „nie wylogowuj mnie" po 60 dniach. Wygasłe sesje i tokeny usuwa codzienny przebieg dzień po ich wygaśnięciu. Pliki cookie sesji mają atrybuty HttpOnly, SameSite=Lax i Secure. Użytkownicy widzą swoje aktywne urządzenia i mogą wylogować się wszędzie; reset hasła kończy wszystkie sesje, zmiana hasła – wszystkie pozostałe.
• Linki do resetu hasła i potwierdzenia adresu e-mail są przechowywane wyłącznie jako skróty, są ważne 60 minut i można ich użyć jednokrotnie.

API i dostęp w czasie rzeczywistym

• Klucze API są przechowywane wyłącznie jako skróty. Każdy klucz należy do dokładnie jednego obszaru roboczego, ma zakresy uprawnień ograniczające to, co wolno mu robić, może zostać w każdej chwili unieważniony i jest ograniczony do 120 żądań na 60 sekund. Powtarzające się użycie nieważnych kluczy z jednego adresu IP jest blokowane.
• Połączenie agenta z serwerem czasu rzeczywistego wymaga krótkotrwałego biletu wydawanego przez aplikację po sprawdzeniu uprawnień; uprawnienia do projektu oblicza aplikacja i przekazuje je wraz z biletem. Bilet do konsoli na żywo na stronie internetowej Klienta jest ważny dla jednej rozmowy i przez 90 sekund.

Administracja serwerem

• Operator administruje serwerem przez SSH; logowanie hasłem nie jest wyłączone. Aktywna jest zapora sieciowa hosta (UFW). fail2ban jest zainstalowany, ale jego filtr SSH nie rozpoznaje obecnie nieudanych logowań zainstalowanej wersji OpenSSH, dlatego powtarzające się nieudane logowania SSH nie są jeszcze automatycznie blokowane.
• Obszar administracyjny Operatora w Usłudze jest dostępny wyłącznie dla kont, które Operator wskazał w konfiguracji serwera; przy pustej liście nikt nie ma dostępu. Od 16 października 2026 r. konta te otrzymują uprawnienia Operatora tylko wtedy, gdy uwierzytelnianie dwuskładnikowe jest skonfigurowane i zostało potwierdzone w tej samej sesji (token „Nie wylogowuj mnie” przenosi potwierdzenie, najwyżej przez 60 dni; logowanie jednokrotne się nie liczy); konto bez niego jest kierowane do jego konfiguracji. Obowiązek można wyłączyć wyłącznie w konfiguracji serwera, jako wyjście awaryjne.

2.3 Kontrola dostępu do danych (autoryzacja)

• Jedna macierz uprawnień określa, co może każda rola. Role to owner, admin, member (agent) i viewer. Obszar roboczy może dodatkowo ograniczyć uprawnienia ról member i viewer, ale nigdy ich nie rozszerzyć. Dostęp użytkownika można ograniczyć do wybranych projektów.
• Uprawnienia są sprawdzane centralnie na serwerze dla każdej strony i każdej czynności, a nie tylko w interfejsie. Admin nie może usunąć ani zmienić ownera; roli owner nie można nadać przez zaproszenie ani zmianę roli.
• Włączenie integracji, które wysyłają dane do podmiotów trzecich, wymaga odrębnego uprawnienia, które mają tylko ownerzy i admini.
• Obszar administracyjny Operatora służy do obsługi kont, planów, przełączników eksploatacyjnych i wsparcia. Nie wyświetla treści rozmów. Jako administrator serwera Operator ma jednak techniczny dostęp do bazy danych i systemu plików. Dostęp ten jest wykorzystywany wyłącznie do prowadzenia Usługi, obsługi zgłoszenia Klienta do wsparcia, obsługi incydentu lub wypełnienia obowiązku prawnego. Nie jest rejestrowany w dziennikach aplikacji (pkt 4.2).

2.4 Kontrola rozdzielności

• Każdy obszar roboczy i każdy projekt jest rozdzielony logicznie. W panelu obszar roboczy jest pobierany z sesji, a członkostwo jest sprawdzane przy każdej zmianie; w API obszar roboczy jest pobierany wyłącznie z klucza API; identyfikatory rozmów w ścieżkach API są zawsze sprawdzane względem tego obszaru roboczego.
• Na serwerze czasu rzeczywistego agent ma dostęp wyłącznie do rozmów strony, dla której wydano bilet; Odwiedzający ma dostęp wyłącznie do własnych rozmów, co potwierdza losowy token wydany przez serwer tej przeglądarce (dowód odwiedzającego). Nieznane lub dezaktywowane klucze strony są odrzucane.
• Załączniki plików są przechowywane w odrębnym katalogu dla każdego obszaru roboczego i każdej rozmowy.
• Usługa działa w instalacji produkcyjnej (reactive.chat) oddzielonej od jej instalacji deweloperskiej (dev.reactive.chat): własny katalog programu, własna baza danych z własnym użytkownikiem bazy danych bez dostępu do bazy deweloperskiej, własna baza Redis i własne procesy usług, w tym odrębne instancje workerów na węzłach AI z własnym kluczem. Zmiany w kodzie zaczynają działać w instalacji deweloperskiej natychmiast; do instalacji produkcyjnej trafiają wyłącznie w drodze przeniesienia stałej wersji (pkt 6). Obie instalacje działają na tej maszynie i korzystają z tych samych węzłów AI; są rozdzielone programowo, a nie sprzętowo. Instalacja deweloperska jest chroniona hasłem na serwerze WWW; wyłączone z tego są jej widżet, API, serwer czasu rzeczywistego i Smart Answer.

3. Poufność – minimalizacja, pseudonimizacja i szyfrowanie

3.1 Pseudonimizacja i minimalizacja danych

• Odwiedzający są rozróżniani za pomocą losowych identyfikatorów. Bez sygnału zgody z narzędzia do zarządzania zgodami Klienta widżet nie tworzy trwałego identyfikatora odwiedzającego, a jedynie identyfikator sesji, i przechowuje swój stan w sessionStorage, który jest czyszczony po zamknięciu karty. Po wyrażeniu zgody stan jest przenoszony do localStorage. Widżet nie ustawia plików cookie. Pojedynczy bit „nie śledź ponownie" jest zapisywany w localStorage po tym, jak Odwiedzający usunie swoje dane, również bez zgody.
• Adres IP Odwiedzającego jest wykorzystywany do zestawienia połączenia, do ustalenia kraju na podstawie lokalnej bazy danych na serwerze (bez zapytania do podmiotów trzecich; odczytywany jest wyłącznie kod kraju, a adres nie jest w tym celu zapisywany; kraj ten jest zapisywany wraz z sesją, a od 16 października 2026 r. wykorzystują go także funkcje działające na żywo, które zależą od kraju – informacje o kraju przesyłane przez przeglądarkę nie są wykorzystywane, a jeżeli kraju nie można ustalić, wymagana jest zgoda) oraz do ochrony przed nadużyciami. Rekord rozmowy przechowuje kraj, a nie adres IP. Pełne adresy IP są przechowywane tam, gdzie służą celom dowodowym lub bezpieczeństwu: w zapisie decyzji Odwiedzającego dotyczącej zgody, w czasowych blokadach na czas ich trwania, w dzienniku bezpieczeństwa serwera czasu rzeczywistego (ostatnie 500 wpisów), w dziennikach dostępu serwera WWW i w dzienniku systemowym (pkt 4.2) oraz – w przypadku użytkowników konta Klienta – w dzienniku logowań. Licznik Smart Answer przechowuje adres IP wyłącznie w postaci skróconej (pkt 3.4).
• Wiadomości Odwiedzających i agentów są oczyszczane na serwerze przed zapisaniem. Adresy e-mail, numery kart płatniczych (sprawdzenie algorytmem Luhna), numery IBAN (sprawdzenie według ISO 7064), numery telefonów zapisane z początkowym + lub 0, niemieckie numery podatkowe, numery identyfikacji podatkowej i numery dowodów osobistych oraz sekrety, takie jak hasła lub klucze, są zastępowane symbolem zastępczym; rodzaj i liczba zastąpień są zapisywane przy wiadomości. Numery telefonów bez początkowego + lub 0 oraz polskie numery NIP i PESEL nie są rozpoznawane. Oczyszczanie dotyczy widżetu i podłączonych kanałów. Nie dotyczy wiadomości, które Klient zapisuje w rozmowie bezpośrednio przez REST API, ani wartości odpowiedzi w formularzach, które Klient świadomie zbiera w formularzu; są one przechowywane w postaci przesłanej.
• Zanim rozmowa zostanie przekazana do modelu językowego w celu przygotowania projektu odpowiedzi, podsumowania lub przeredagowania dla agenta, dodatkowo zastępowane są adresy e-mail, numery telefonów i ciągi co najmniej sześciu cyfr, a linki tracą parametry i kotwice. Imiona i nazwiska agentów, identyfikatory odwiedzających i adresy stron nie są przekazywane.
• Obrazy, które ma obejrzeć asystent AI, są przed przekazaniem do modelu zmniejszane do 768 pikseli i ponownie kodowane; osadzone metadane, takie jak dane lokalizacyjne EXIF, są usuwane. W jednym żądaniu przekazywany jest tylko jeden obraz.
• Kampanie w widżecie prowadzą liczniki dla Odwiedzającego wyłącznie pod jednokierunkowym skrótem identyfikatora odwiedzającego lub sesji, z okresami powiązanymi z kampanią (bez daty zakończenia najwyżej 90 dni po ostatnim kontakcie); znacznik powracającego odwiedzającego również jest skrótem. Po rezygnacji z WhatsApp i następującym po niej żądaniu usunięcia pozostaje jedynie utworzony z kluczem skrót numeru jako adnotacja blokująca.
• Lista odwiedzających na żywo powstaje wyłącznie z danych, które i tak zawiera sesja. Nigdy nie pokazuje adresów IP, surowej identyfikacji przeglądarki, identyfikatorów kliknięć sieci reklamowych ani nazwisk, pełny wiersz dla Odwiedzających z obszaru RODO i o nieznanym kraju pokazuje wyłącznie za zgodą i jest przechowywana w pamięci podręcznej najwyżej przez 90 sekund.
• Przez serwer MCP, bez dodatkowego uprawnienia do danych Odwiedzających, imiona i nazwiska są skracane do inicjałów, adresy e-mail maskowane, numery telefonów skracane do dwóch ostatnich cyfr, a teksty filtrowane; adresy IP Odwiedzających nigdy nie są przekazywane.
• Oceny mogą pokazywać agentów pod pseudonimami. Ocena AI w kontroli jakości nigdy nie jest przypisywana agentowi; jej dane wejściowe przechodzą przez filtr danych osobowych, a znane imiona i nazwiska są zastępowane.

3.2 Szyfrowanie

• W trakcie przesyłania: zob. pkt 4.1.
• Dane dostępowe, które Klient zapisuje dla integracji, kanałów, single sign-on, akcji bota, weryfikacji tożsamości i własnego węzła AI, są szyfrowane algorytmem AES-256-GCM i powiązane z celem za pomocą dodatkowych danych uwierzytelnianych. Klucz jest przechowywany w konfiguracji serwera, poza bazą danych; chroni przed kopią bazy danych, a nie przed przejęciem samego serwera.
• Wspólny sekret uwierzytelniania dwuskładnikowego jest szyfrowany algorytmem AES-256-GCM własnym kluczem wyprowadzonym z tego samego klucza serwera i powiązany z kontem. Sekrety zapisane przed 16 października 2026 r. w postaci jawnej są szyfrowane przy następnym poprawnym kodzie, a postać jawna jest usuwana. Podobnie jak opisany wyżej klucz chroni to przed kopią bazy danych, a nie przed przejęciem samego serwera.
• Dane zamówień importowane ze sklepu Klienta na potrzeby odpowiedzi w czacie są przechowywane w postaci zaszyfrowanej i wygasają po 90 dniach.
• Hasła, klucze API, identyfikatory sesji (od 17 października 2026 r.), kody odzyskiwania i linki jednorazowe są przechowywane wyłącznie jako skróty (pkt 2.2).
• Kopie zapasowe opuszczają serwer wyłącznie w postaci zaszyfrowanej (pkt 5.1).
• Poza tym dane w bazie danych i w systemie plików nie są szyfrowane w spoczynku (pkt 2.1).

3.3 Załączniki plików

• Odwiedzający i agenci mogą dołączać pliki w czacie. Akceptowane są obrazy (PNG, JPEG, WebP, HEIC/HEIF, SVG), pliki PDF, tekstowe i CSV. Serwer sprawdza pierwsze bajty każdego pliku względem zadeklarowanego typu i odrzuca pliki, które do niego nie pasują; pliki SVG są sprawdzane w całości.
• Przesłanie pliku wymaga podpisanego, ograniczonego w czasie zezwolenia wydanego dla jednej konkretnej rozmowy. Limity wielkości pliku i łącznej przestrzeni obowiązują w zależności od planu (2 MB na plik i 1 GB na obszar roboczy w planie bezpłatnym, 15 MB i 50 GB w planach płatnych).
• Pliki są przechowywane poza katalogiem dokumentów serwera WWW, w katalogu dla każdego obszaru roboczego i rozmowy, z uprawnieniami wykluczającymi innych użytkowników systemu. Są udostępniane wyłącznie pod podpisanym adresem, którego nie można odgadnąć, z polityką Content Security Policy zakazującą wszelkiej aktywnej treści; pliki niebędące obrazami są oferowane do pobrania.
• Pliki nie są skanowane pod kątem złośliwego oprogramowania. Sprawdzenie typu zapobiega podszywaniu się pod inny typ pliku, ale nie wykrywa szkodliwej treści wewnątrz dozwolonego typu. Agenci powinni traktować załączniki z taką samą ostrożnością jak załączniki e-mail.
• Wyciąg tekstu z plików PDF, tekstowych i CSV jest przekazywany asystentowi AI tylko wtedy, gdy odpowiada on na powiązaną wiadomość, maksymalnie 2500 znaków na wiadomość i po oczyszczeniu. Tekst rozpoznany na obrazach (OCR) służy wyłącznie do sprawdzania liczb i rozpoznawania aplikacji o pracę (pkt 9) i nie jest przekazywany żadnemu modelowi językowemu.
• Załączniki są automatycznie usuwane po upływie okresu przechowywania właściwego dla planu Klienta (plan bezpłatny: 7 dni, plany płatne: 90 dni, umowy indywidualne: uzgodniony okres), a wcześniej razem z ich rozmową, projektem lub obszarem roboczym. Usuwanie nigdy nie podąża za dowiązaniami symbolicznymi.

3.4 Smart Answer

• Na zapytania Smart Answer odpowiada usługa Answely Operatora, odrębna usługa tego samego podmiotu na tym samym serwerze. Przeglądarka przekazuje adresy stron bez parametrów i kotwic; usługa wysyła pytania i adresy stron do węzłów AI tak jak czat. Jeżeli Klient włączył zapisywanie, przechowuje wygenerowaną odpowiedź (tekst i źródła, pytanie wyłącznie jako hash) przez 24 godziny w pamięci podręcznej, aby ponownie odpowiedzieć na to samo pytanie.
• Pytanie jest skracane do najwyżej 300 znaków. Jeżeli zapisywanie jest wyłączone, pytanie i odpowiedź znajdują się wyłącznie w pamięci operacyjnej na czas przetwarzania, w drodze między serwerem a węzłami AI najwyżej 180 sekund, i nie są zapisywane.
• Jej dzienniki nie zawierają ani pytania, ani odpowiedzi i nie tworzy ona wpisów w dzienniku AI. Każde żądanie tworzy wpis licznika z czasem, skróconym adresem IP (IPv4 bez ostatniego oktetu, IPv6 do sieci /48), identyfikatorem strony, długością pytania i wynikiem, usuwany automatycznie po 7 dniach.
• Publiczny interfejs udostępnia odpowiedzi przeglądarkom wyłącznie dla domen zarejestrowanych dla projektu (CORS) i ogranicza liczbę żądań z jednego adresu IP i dla jednej strony.

4. Integralność

4.1 Kontrola przekazywania

• Wszystkie połączenia ze stroną internetową, panelem, widżetem, API i serwerem czasu rzeczywistego są szyfrowane protokołem TLS 1.2 lub TLS 1.3; starsze protokoły są wyłączone. Certyfikaty wydaje Let's Encrypt i są one odnawiane automatycznie. Nagłówek HTTP Strict Transport Security jest wysyłany dla hostów strony internetowej i panelu.
• Aplikacja wysyła politykę Content Security Policy z losowym jednorazowym kodem (nonce) dla skryptów przy każdym żądaniu, zabrania osadzania w ramkach innych stron oraz ogranicza cele formularzy i adresy bazowe. Wysyła również nagłówki X-Content-Type-Options, Referrer-Policy i Permissions-Policy. Polityka dopuszcza arkusze stylów osadzone w stronie.
• Każde żądanie zmieniające stan w panelu, w obszarze administracyjnym i na stronach logowania jest chronione tokenem CSRF powiązanym z sesją; webhooki, kanały i API są uwierzytelniane własnymi podpisami lub kluczami.
• Serwer czasu rzeczywistego przyjmuje połączenia przeglądarek dla danego projektu wyłącznie z domen zarejestrowanych dla tego projektu, o ile Klient zarejestrował domeny. Bez zarejestrowanych domen połączenie jest przyjmowane z dowolnego źródła. Sprawdzenie źródła działa wobec przeglądarek, nie wobec innych klientów.
• Żądania wychodzące Usługi kierowane na adresy wybrane przez Klienta (kanały, webhooki, integracje, interfejsy sklepów, dostawcy tożsamości) są chronione przed fałszowaniem żądań po stronie serwera (SSRF): nazwa jest rozwiązywana, każdy uzyskany adres musi być publiczny, a połączenie jest nawiązywane ze sprawdzonym adresem. Powiadomienia push są wysyłane wyłącznie do usług push producentów przeglądarek z ustalonej listy nazw hostów. Robot indeksujący bazę wiedzy sprawdza każdy host i każde przekierowanie od nowa i respektuje plik robots.txt.
• Własne akcje bota wywołują wyłącznie adresy HTTPS na porcie 443, których wszystkie rozwiązane adresy są publiczne, z przypiętym sprawdzonym adresem; przekierowania są obsługiwane tylko przy żądaniach odczytu i najwyżej dwukrotnie; limit czasu wynosi 5 sekund (2 sekundy na nawiązanie połączenia), a odpowiedź najwyżej 64 kB. Ich sekrety są szyfrowane algorytmem AES-256-GCM. Akcje, które coś zmieniają, są wykonywane dopiero po kliknięciu Odwiedzającego i tylko raz.
• Dane opuszczają infrastrukturę Operatora wyłącznie do odbiorców wymienionych na stronie Podwykonawcy przetwarzania oraz do kanałów i integracji, które włącza Klient (pkt 8).

4.2 Kontrola wprowadzania danych i rejestrowanie

• Dziennik audytu. Logowania (także przez single sign-on), nieudane próby logowania, czynności na koncie i każde wywołanie narzędzia MCP (bez treści) są zapisywane w dzienniku audytu wraz z użytkownikiem, obszarem roboczym, czasem, czynnością i pełnym adresem IP. Ownerzy i admini widzą zmiany w swoim obszarze roboczym z ustalonej listy, bez adresów IP i bez logowań członków zespołu, i mogą je wyeksportować. Wybierają okres jego przechowywania (90, 180, 365 lub 730 dni albo do usunięcia obszaru roboczego, co jest ustawieniem domyślnym); okres ten dotyczy wszystkich wpisów obszaru roboczego. Wpisy bez obszaru roboczego są usuwane po 90 dniach: zdarzenia logowania, drugiego składnika, hasła i single sign-on oraz nieudane próby konta, a także wszystkie wpisy nienależące do żadnego konta (np. nieudane próby logowania z adresem e-mail, dla którego nie istnieje konto, oraz blokady adresów IP), z wyjątkiem znaczników usunięcia i czynności Operatora; pozostałe wpisy konta są przechowywane do usunięcia konta.
• Czynności Operatora. Czynności w obszarze administracyjnym Operatora (np. blokowanie, odblokowanie lub usuwanie użytkowników, zmiana planów) są rejestrowane.
• Dziennik odczytów (plan Agency). Rejestruje, który użytkownik otworzył którą rozmowę, kiedy i jaką drogą (panel, konsola na żywo, dziennik AI), bez adresu IP i treści, najwyżej raz na użytkownika, rozmowę i drogę w ciągu dziesięciu minut; wpisy są usuwane po 731 dniach. Dostęp Operatora oraz dostęp przez API nie są w nim rejestrowane.
• Dziennik AI. Dla każdej odpowiedzi AI Usługa zapisuje, z jakich źródeł skorzystano, jakie kontrole przeprowadzono oraz który model i który węzeł odpowiedział, bez kopii tekstu (pkt 9).
• Zmiany oprogramowania. Zmiany kodu źródłowego są śledzone w systemie kontroli wersji. Zmiany w instalacji deweloperskiej są wprowadzane bezpośrednio w jej katalogu roboczym i mogą tam działać, zanim zostaną zatwierdzone w repozytorium. Do instalacji produkcyjnej przenoszone są wyłącznie wersje zatwierdzone; skrypt przeniesienia zapisuje dla każdego przeniesienia raport z wersją, plikami i migracjami bazy danych i przechowuje go razem z kopią zapasową wykonaną przed przeniesieniem (pkt 6). Zmiany nie są sprawdzane przez drugą osobę.
• Dzienniki serwera WWW. Dzienniki dostępu zawierają adres IP, czas, żądanie, stronę odsyłającą i identyfikację przeglądarki. Są rotowane codziennie i przechowywane maksymalnie 15 dni (14 rotacji plus bieżący dzień).
• Dziennik systemowy i dzienniki aplikacji. Dziennik systemowy zawiera również komunikaty serwera czasu rzeczywistego z adresami IP; jest ograniczony wyłącznie rozmiarem (500 MB), bez limitu czasu. Dzienniki procesów działających w tle Usługi nie są obecnie automatycznie rotowane i nie mają okresu usuwania; zawierają komunikaty eksploatacyjne, a w pojedynczych przypadkach adresy IP lub adresy e-mail posiadaczy kont.

5. Dostępność i odporność

5.1 Kopie zapasowe

Istnieją dwie ścieżki tworzenia kopii zapasowych.

Kopia całego serwera (poza siedzibą, zaszyfrowana). Codziennie około godziny 03:00 zautomatyzowane zadanie tworzy zrzut wszystkich baz danych serwera oraz archiwum katalogów WWW, do których należą załączniki plików, pliki bazy wiedzy i logotypy firm Usługi.

• Kopia jest szyfrowana na serwerze przed przesłaniem (rclone crypt); szyfrowane są również nazwy plików i katalogów. Klucze pozostają na serwerze; dostawca przestrzeni otrzymuje wyłącznie zaszyfrowane bloki.
• Jest przesyłana do Google Cloud Storage, zasobnik w regionie europe-central2 (Warszawa, Polska); dostawca Google Cloud EMEA Limited, Dublin (zob. Podwykonawcy przetwarzania, pkt 2.1).
• Okres przechowywania: kopie dzienne 7 dni, kopia tygodniowa (niedziela) 364 dni. Od 10. dnia kopie są przenoszone do chłodniejszej klasy przechowywania.
• Ta sama kopia jest dodatkowo przechowywana przez około 8 dni na dysku podłączonym do serwera. Ta lokalna kopia nie jest szyfrowana; chronią ją uprawnienia plików na serwerze i środki fizyczne (pkt 2.1).

Kopia bazy danych Usługi. Codziennie o godzinie 03:05 drugie zadanie zapisuje skompresowany zrzut bazy danych Usługi na dysku systemowym serwera, czytelny wyłącznie dla jego właściciela, i przechowuje go przez 30 dni. Nie jest on szyfrowany i nie zawiera plików.

Skutki. Dane usunięte w systemie produkcyjnym pozostają w kopiach zapasowych do ich wygaśnięcia: maksymalnie 364 dni w tygodniowych kopiach poza siedzibą, maksymalnie 30 dni w lokalnych zrzutach bazy danych. Selektywne usuwanie wewnątrz kopii zapasowej nie jest wykonywane, ponieważ każda kopia jest zamkniętym obrazem jednego momentu. Kopie zapasowe służą wyłącznie do przywrócenia systemu po utracie; nie są przeszukiwane, analizowane ani ujawniane. Jeżeli kopia zapasowa musi zostać odtworzona, Operator ponownie wykona usunięcia dokonane po dacie kopii, zanim Usługa powróci do normalnego działania (pkt 6).

5.2 Ochrona przed nadużyciami i przeciążeniem

• Serwer czasu rzeczywistego ogranicza każde połączenie: ramki maksymalnie 64 KiB, 120 ramek i 20 wiadomości na 10 sekund, 3 połączenia na sesję, łącznie 1000 połączeń, 5 sekund na identyfikację po nawiązaniu połączenia; wiadomości dłuższe, niż pozwala plan (1000 znaków w planie bezpłatnym, w pozostałych 4000), są odrzucane. Serwer może automatycznie i czasowo blokować naruszające zasady adresy IP i identyfikatory odwiedzających; Operator prowadzi ręczne listy blokad.
• Agenci mogą zablokować Odwiedzającego dopuszczającego się nadużyć poleceniem /ban w panelu na okres do 365 dni (domyślnie 24 godziny). Blokada obejmuje identyfikator i adres IP Odwiedzającego (w przypadku IPv6 całą sieć /64, która może obejmować inne urządzenia tego samego łącza); blokada adresu IP dotyczy całego serwera czasu rzeczywistego, a nie tylko strony Klienta.
• Asystent AI ma budżet na stronę i minutę oraz limit na rozmowę i plan; po jego przekroczeniu Odwiedzający otrzymuje stałą wiadomość zamiast odpowiedzi AI.
• Serwer WWW ogranicza rozmiar żądań i czas ich odczytu; fail2ban blokuje na godzinę adresy, które szukają sekretów lub wysyłają nadmiernie duże żądania.
• Operator może natychmiast wyłączyć AI globalnie lub dla projektu (wyłącznik awaryjny) oraz wyłączyć dla projektu każdą z 24 funkcji (np. przesyłanie plików, tłumaczenie, połączenia, kampanie).

5.3 Monitorowanie

• Kontrola stanu działa co minutę dla środowiska, w którym działa Usługa. Sprawdza komponenty Usługi, w tym stronę internetową i węzły AI, i przy zmianie stanu powiadamia Operatora przez Telegram. Alerty zawierają wyłącznie nazwy komponentów i dane eksploatacyjne, bez danych osobowych.
• Alerty eksploatacyjne obejmują m.in. niedostępne węzły AI, wysoki odsetek odrzuconych żądań AI, wyłącznik awaryjny, liczbę połączeń w czasie rzeczywistym, obciążenie i pamięć serwera oraz liczbę błędów krytycznych.
• Publiczna strona statusu pokazuje zmierzony stan wraz z historią z 90 dni.
• Kontrola działa na serwerze, który nadzoruje. Nie może zgłosić całkowitej awarii tego serwera ani łącza internetowego; takie awarie zauważa człowiek.

6. Zdolność do przywrócenia

• Systemy i dane można przywrócić z kopii zapasowych opisanych w pkt 5.1: bazę danych z codziennego zrzutu (lokalnego lub poza siedzibą), pliki z kopii poza siedzibą. Procedury odtwarzania i postępowania w sytuacjach awaryjnych są udokumentowane wewnętrznie.
• Przeniesienie do instalacji produkcyjnej Operator uruchamia ręcznie na serwerze, na innym koncie użytkownika niż serwer WWW; sam proces serwera WWW nie ma prawa zapisu do plików programu instalacji produkcyjnej. Skrypt eksportuje stałą, zatwierdzoną wersję (a nie katalog roboczy instalacji deweloperskiej), najpierw wykonuje kopię zapasową plików programu, bazy danych i zaplanowanych zadań instalacji produkcyjnej, następnie stosuje migracje bazy danych i kopiuje stałą listę plików; przy pierwszym błędzie przerywa działanie. Zastąpione pliki programu można przywrócić jednym poleceniem; zmiany w bazie danych są addytywne i są korygowane naprzód, a samą bazę danych można odtworzyć z kopii zapasowej wykonanej przed przeniesieniem. Dawne przenoszenie na zlecenie w obszarze Operatora nie jest już używane.
• Zanim Usługa po odtworzeniu powróci do normalnego działania, Operator ponownie wykonuje usunięcia dokonane po dacie odtworzonej kopii, w tym żądania usunięcia danych zgłoszone przez Odwiedzających oraz usunięte obszary robocze i konta. Od 16 października 2026 r. każde usunięcie wykonywane w związku z konkretnym zdarzeniem – żądanie usunięcia lub wycofanie zgody przez Odwiedzającego, usunięcie obszaru roboczego, projektu lub konta – jest w chwili wykonania odnotowywane w dzienniku usunięć prowadzonym poza bazą danych (rodzaj, identyfikatory, tryb i czas, bez treści, adresów ani adresów IP; przechowywany przez 400 dni), a skrypt ponownie wykonuje odnotowane usunięcia tymi samymi funkcjami; usunięcia wynikające z okresów przechowywania nadrabiają się same przy następnym przebiegu. Nie są objęte: usunięcia zgłoszone po dacie kopii, których 30-dniowy okres karencji jeszcze biegł, oraz – w razie utraty samego serwera – usunięcia po ostatniej kopii zapasowej dziennika (do 24 godzin).
• Nie jest gwarantowany docelowy czas odtworzenia, a regularne testy odtwarzania nie są jeszcze udokumentowane.

7. Procedury regularnego testowania, mierzenia i oceniania

7.1 Przegląd niniejszych środków

• Operator dokonuje przeglądu Środków TOM, gdy infrastruktura, podwykonawcy przetwarzania lub Usługa ulegają istotnym zmianom, a co najmniej raz w roku.
• Aktualizacje nie obniżają poziomu ochrony. Aktualna wersja jest publikowana na tej stronie; Umowa powierzenia odsyła do wersji obowiązującej w chwili przetwarzania.
• Kod źródłowy zawiera zautomatyzowane zestawy testów, m.in. dla macierzy uprawnień, uwierzytelniania dwuskładnikowego i ochrony przed nadużyciami.
• Niniejszy dokument nie powołuje się na żadną niezależną certyfikację ani zewnętrzny test penetracyjny. Jeżeli zostanie on przeprowadzony w przyszłości, zostanie tu wymieniony.

7.2 Naruszenia ochrony danych osobowych

• Operator prowadzi pisemną procedurę postępowania w przypadku naruszeń ochrony danych. Obejmuje ona wykrywanie, ocenę, ograniczanie skutków, zgłaszanie i dokumentowanie oraz traktuje jako naruszenie nie tylko ujawnienie, lecz także utratę i zmianę danych.
• Naruszenie dotyczące Danych Klienta jest zgłaszane Klientowi bez zbędnej zwłoki, nie później niż w ciągu 48 godzin od jego stwierdzenia przez Operatora, aby Klient mógł dotrzymać własnego 72-godzinnego terminu wynikającego z art. 33 RODO. Zgłoszenie jest wysyłane na adres e-mail właściciela konta (ownera) i zawiera, w zakresie, w jakim są znane, informacje wymienione w art. 33 ust. 3 RODO; pozostałe są przekazywane etapami.
• Każde naruszenie i każda ocena, w wyniku której stwierdzono brak naruszenia, są dokumentowane wraz ze skutkami i podjętymi działaniami.

7.3 Uwzględnianie ochrony danych w fazie projektowania i domyślna ochrona danych

• Bez sygnału zgody widżet działa w trybie podstawowym (pkt 3.1). Przy poziomie zgody „wymagana" widżet wysyła kontekst strony, tekst strony i dane przekazane przez Klienta dopiero po wyrażeniu zgody.
• Odwiedzający może usunąć swoje dane w widżecie („Twoje dane", „Usuń wszystko"), wycofać zgodę i poprosić na piśmie o usunięcie; serwer realizuje te żądania w ciągu kilku minut.
• Dla rozmów nie ustawiono domyślnego automatycznego okresu usuwania. Klient ustala go dla każdego projektu (od 0 do 3650 dni, gdzie 0 oznacza brak limitu) i wybiera, czy rozmowy po upływie okresu są usuwane, czy anonimizowane. Operator może ustalić okres maksymalny dla wszystkich projektów.
• Oczyszczanie odbywa się automatycznie na serwerze przed zapisaniem; nie zależy od Odwiedzających ani agentów (z wyjątkami opisanymi w pkt 3.1).

7.4 Organizacja

• Odpowiedzialność za ochronę danych i bezpieczeństwo informacji spoczywa osobiście na właścicielu Operatora. Nie ma odrębnego zespołu bezpieczeństwa ani rozdziału obowiązków; Operator informuje o tym, aby Klienci mogli to uwzględnić.
• Osoby upoważnione do dostępu do Danych Klienta są zobowiązane do zachowania poufności.
• Procedury dotyczące naruszeń, odtwarzania, sytuacji awaryjnych i wdrożeń są udokumentowane wewnętrznie.
• Pytania dotyczące tych środków i zgłoszenia problemów z bezpieczeństwem: contact@lukaswojcik.com.

8. Kontrola przetwarzania w imieniu Klienta (kontrola powierzenia)

• Operator przetwarza Dane Klienta wyłącznie na polecenie Klienta, zgodnie z Umową powierzenia; ustawienia wybrane przez Klienta w panelu stanowią część tych poleceń.
• Operator korzysta wyłącznie z podwykonawców przetwarzania wymienionych na stronie Podwykonawcy przetwarzania. Każdy z nich jest związany umową zawierającą obowiązki w zakresie ochrony danych zgodnie z art. 28 ust. 4 RODO. Zmiany są zapowiadane z 30-dniowym wyprzedzeniem; Klient może zgłosić sprzeciw.
• Kanały i integracje, które Klient włącza przy użyciu własnych kont i danych dostępowych, przesyłają dane na polecenie Klienta do jego własnych dostawców. Mogą je włączyć wyłącznie ownerzy i admini. Pozostają one poza kontrolą Operatora nad podwykonawcami przetwarzania.
• Jeżeli Klient podłączy własny węzeł AI, treść rozmów na potrzeby żądań AI trafia do tego węzła i do modelu, który Klient na nim uruchamia; węzeł ten jest własnym podmiotem przetwarzającym Klienta.

9. Środki właściwe dla funkcji AI

• Wyłącznie własne modele. Modele językowe własnej AI Operatora (jeden model czatu na węzłach drugiego poziomu i drugi jako rezerwa na węźle pierwszego poziomu, każdy w wersji instrukcyjnej, skwantyzowany do 4 bitów) i jej model osadzeń są modelami na otwartych licencjach, hostowanymi samodzielnie, które działają w niezmienionej postaci na węzłach AI Operatora w sieci lokalnej. Żadna zewnętrzna usługa AI nie otrzymuje Danych Klienta.
• Rejestr węzłów, domyślnie zamknięty. Zadania AI otrzymują wyłącznie węzły wpisane do rejestru i aktywowane. Węzeł niewpisany jest odrzucany; jeżeli rejestru nie można odczytać, żaden węzeł nie otrzymuje pracy.
• Brak trenowania. Dane Klienta nie są wykorzystywane do trenowania ani dostrajania modeli. Pojedyncze żądania mogą być wykorzystywane wewnętrznie do porównania wersji modeli przed aktualizacją; nie są wykorzystywane do trenowania i nie są przekazywane dalej.
• Nadzór człowieka i przełączniki. Klient może wyłączyć asystenta AI dla każdego projektu. Gdy tylko agent przejmie rozmowę, asystent milknie. Jeżeli asystent nie znajdzie wiarygodnej podstawy, przekazuje rozmowę człowiekowi. Operator dysponuje globalnym wyłącznikiem awaryjnym oraz wyłącznikiem dla każdego projektu (pkt 5.2).
• Oznaczanie. Widżet informuje Odwiedzających przed pierwszą wiadomością AI, że rozmawiają z asystentem AI, i oznacza każdą wiadomość AI plakietką „AI". Klientowi nie wolno usuwać ani zasłaniać tego oznaczenia (pkt 13 Umowy powierzenia).
• Kontrole przed modelem i po nim. Żądania próbujące wykorzystać asystenta do niezwiązanych zadań są rozpoznawane za pomocą reguł przed wywołaniem modelu; odpowiedzi są sprawdzane pod kątem kodu i stwierdzeń sprzecznych ze źródłami (np. dni tygodnia, liczby, „bezpłatnie"). Niektóre funkcje w ogóle nie korzystają z modelu: żądania usunięcia danych, pytania o przechowywanie danych i propozycje konfiguracji są obsługiwane według stałych reguł.
• Brak przetwarzania aplikacji o pracę. Aplikacje są rozpoznawane na podstawie stałych wzorców w tekście, załącznikach i nazwach plików, zanim zostanie wywołany jakikolwiek model – w czacie, w Smart Answer, w ocenie AI w kontroli jakości i w przebiegach testowych, w projektach dotyczących luk w wiedzy i w asystencie wsparcia; rozmowa nie otrzymuje wtedy już żadnego zadania modelu poza tłumaczeniem, a ocena AI ani propozycja odpowiedzi nie są zlecane. Drugą barierą jest instrukcja na początku każdego promptu systemowego, z wyjątkiem tłumaczeń. Nazwy plików są rozpoznawane niezależnie od spacji, podkreśleń, łączników, kropek, wielkości liter, wielkich liter wewnątrz nazwy i znaków diakrytycznych, w dowolnym miejscu nazwy („CV Anna.pdf”, „AnnaŻyciorys.pdf”), także gdy są zapisane wyłącznie jako tekst; krótkie słowa, takie jak „CV”, „resume” czy „Zeugnis”, liczą się tylko jako osobne słowo, a w tekście za nazwę pliku uznaje się słowo z rozszerzeniem i najwyżej cztery słowa przed nim. Rozpoznawanie może przeoczyć aplikacje, których sformułowań lub nazw plików nie zna; drugą barierą pozostaje wtedy instrukcja dla modelu. Nie ma przełącznika.
• Brak oceny Członków Zespołu przez AI. Ocena AI w kontroli jakości jest wystawiana wyłącznie dla rozmów bez udziału człowieka i nigdy nie jest przypisywana agentowi; oceny w podziale na agentów są regułowe.
• Baza wiedzy. Asystent odpowiada na podstawie bazy wiedzy dostarczonej przez Klienta, a jeżeli nic w niej nie znajdzie, może odpowiedzieć na podstawie wiedzy ogólnej. Treść bazy wiedzy i stron Klienta trafia do modelu w postaci, w jakiej została dostarczona; Usługa nie filtruje jej pod kątem osadzonych poleceń. To Klient decyduje o jej zawartości.
• Rekordy zadań. Rekord zadania AI zawiera polecenie i tekst rozmowy. Jest usuwany wraz z rozmową; rekordy bez rozmowy są usuwane po 30 dniach. Zadania z danymi zamówień, akcjami bota, symulacjami, klasyfikacją routingu, oceną AI w kontroli jakości oraz projekty odpowiedzi, podsumowania, przeredagowania i tłumaczenia dla agentów są oznaczone jako poufne i opróżniane, gdy tylko wynik zostanie dostarczony, a w przeciwnym razie po około dziesięciu minutach. Dziennik AI nie zawiera tekstu (pkt 4.2).
• Osadzenia bazy wiedzy są przechowywane w pamięci podręcznej serwera przez 30 dni i odbudowywane po zmianie bazy wiedzy.

10. Stan i wersja

Niniejszy dokument sporządzono w języku angielskim. Tłumaczenia na język niemiecki (/p/technische-und-organisatorische-massnahmen) i polski (/p/srodki-techniczne-i-organizacyjne) udostępniono dla wygody; wersja angielska ma pierwszeństwo.

Wersja 2.0 zastępuje wersję 1.4 z 7 października 2026 r. Zmiany: dokument uporządkowano według kategorii art. 32 RODO i rozszerzono o dostęp do systemów i danych, szyfrowanie, monitorowanie, odtwarzanie, kontrolę powierzenia i środki dotyczące AI; kopia zapasowa poza siedzibą w Google Cloud Storage z kopiami tygodniowymi do 364 dni zastępuje stwierdzenie „kopie zapasowe do 30 dni, bez hiperskalera"; usunięto lub poprawiono stwierdzenia niezgodne z rzeczywistym działaniem (SSH wyłącznie z imiennymi kluczami, fizycznie rozdzielone środowisko deweloperskie i produkcyjne, obowiązkowe potwierdzenie adresu e-mail, blokady IP przez Klientów w panelu, usuwanie tekstów zadań AI po około dziesięciu minutach, oczyszczanie bez wyjątków, zmniejszanie obrazów przed przesłaniem); wskazano granice (brak szyfrowania dysków, brak skanowania antywirusowego, brak rozdziału obowiązków).

Wersja 2.1 zastępuje wersję 2.0 z 11 października 2026 r. Zmiany: minimalizacja danych w kampaniach, liście odwiedzających na żywo, MCP i ocenach (3.1); ograniczenia dla własnych akcji bota (4.1); dziennik audytu z single sign-on i wywołaniami MCP (4.2); blokada aplikacji o pracę i brak oceny Członków Zespołu przez AI (9).

Wersja 2.2 zastępuje wersję 2.1 z 11 października 2026 r. Poprawiono: nie istnieje jeszcze odrębne środowisko produkcyjne, Usługa działa w swojej instalacji deweloperskiej (1, 2.4, 4.2, 5.3, 6); SSH z logowaniem hasłem, fail2ban nieskuteczny dla SSH (2.2); ograniczenia reCAPTCHA (2.2); oczyszczanie numerów telefonów i identyfikatorów, dziennik systemowy z adresami IP (3.1, 4.2); OCR również do rozpoznawania aplikacji o pracę (3.3); Smart Answer przez Answely z 24-godzinną pamięcią podręczną odpowiedzi (3.4); usługi push z ustalonej listy hostów (4.1); wpisy dziennika audytu bez konta nie są usuwane (4.2); /ban dla IPv6 na całą sieć /64, fail2ban na godzinę (5.2); poufne zadania narzędzi AI dla agentów (9).

Wersja 2.3 zastępuje wersję 2.2 z 12 października 2026 r. Poprawiono: licznik Smart Answer ze skróconym adresem IP, długość pytania i maksymalny czas w drodze (3.1, 3.4); modele czatu własnej AI Operatora z modelem rezerwowym (9); blokada aplikacji o pracę na wszystkich ścieżkach modeli z wyjątkiem tłumaczenia (9); okresy z 16 października 2026 r.: usuwanie wygasłych sesji i tokenów (2.2), wpisy dziennika audytu bez obszaru roboczego usuwane po 90 dniach (4.2). Uzupełniono 16 października 2026 r.: kraj na potrzeby funkcji działających na żywo ustalany na podstawie adresu IP (3.1); nazwy plików zapisane jako tekst (9). Ponadto uzupełniono 16 października 2026 r.: obowiązkowy drugi składnik dla obszaru administracyjnego Operatora (2.2); zaszyfrowany sekret uwierzytelniania dwuskładnikowego (2.2, 3.2); dziennik usunięć do ponownego wykonania usunięć po odtworzeniu (6); nazwy plików rozpoznawane niezależnie od spacji i innych separatorów, pisowni i znaków diakrytycznych (9).

Wersja 2.4 zastępuje wersję 2.3 z 16 października 2026 r. Zmiany: identyfikatory sesji przechowywane w bazie danych wyłącznie jako skróty SHA-256 (2.2, 3.2).

Wersja 2.5 zastępuje wersję 2.4 z 17 października 2026 r. Zmiany: AI jest opisywana jednolicie jako własna, hostowana samodzielnie AI Operatora; usunięto nazwy modeli i oprogramowania, fakty pozostają bez zmian (9).

Wersja 2.6 zastępuje wersję 2.5 z 17 października 2026 r. Poprawiono: przeniesienie do instancji produkcyjnej nie zabezpiecza zastępowanego stanu ani nie przywraca go automatycznie; sposób zlecania i wykonywania takiego przeniesienia oraz to, że jest ono obecnie zablokowane (6).

Wersja 2.7 zastępuje wersję 2.6 z 18 października 2026 r. Zmiany: odrębna instalacja produkcyjna z własnym użytkownikiem bazy danych, własną bazą Redis i własnymi instancjami workerów AI (1, 2.4); przenoszenie do instalacji produkcyjnej wyłącznie zatwierdzonych wersji, ręcznie, z wcześniejszą kopią zapasową i przywracaniem plików programu (4.2, 6); rejestr czynności przetwarzania i ocena skutków dla ochrony danych są dostępne na żądanie zamiast publikacji (1).

Wersja 2.7 – obowiązuje od 19 października 2026 r.