FAQ

DLP pilnuje plików i załączników. Prompt to inny ruch — wklejony tekst w sesji HTTPS do serwisu, który wygląda jak zwykła strona.

Ważniejsza różnica: DLP blokuje, a blokada przenosi zadanie na telefon prywatny. Bramkarz przepuszcza pracę dalej, tylko w wersji, która nikogo nie identyfikuje. Te narzędzia się uzupełniają.

Umowa enterprise mówi, że dostawca nie użyje danych do trenowania modelu. To zobowiązanie umowne, a nie mechanizm zatrzymujący numer PESEL przed wysłaniem — dane objęte tajemnicą bankową nadal opuszczają bank.

Obejmuje też jednego dostawcę, a obok są darmowe czaty w przeglądarce, asystent w IDE i model w telefonie. Kontrola musi stać na granicy sieci.

W większości zastosowań tak, bo podmieniamy to, co identyfikuje osobę, a nie to, z czym model pracuje. Kwoty, daty, warunki umowy i samo polecenie zostają nietknięte. Tokeny są stabilne w rozmowie, więc model nie gubi wątku przy wielu podmiotach.

Są wyjątki — prośba o poprawienie odmiany nazwiska albo walidację numeru rachunku. Takie przypadki rozwiązuje polityka, a nie udawanie, że problemu nie ma.

PESEL, NIP, REGON, numer dowodu, IBAN i numery kart — weryfikowane sumą kontrolną, nie samym wzorcem, więc numer, który tylko wygląda jak PESEL, nie wywołuje alarmu.

Do tego dane bez sztywnego formatu: nazwiska, adresy, telefony, e-maile, nazwy podmiotów, identyfikatory wewnętrzne, kod źródłowy i dane uwierzytelniające. Zestaw ustala się osobno dla każdego wdrożenia.

Żaden system tej klasy nie wykrywa wszystkiego. Dlatego warstw jest kilka: sumy kontrolne na identyfikatory, słowniki Waszej organizacji, model językowy na przypadki nieregularne, a ponad tym reguły polityki działające niezależnie od detekcji.

Przy niskiej pewności żądanie trafia do trybu zachowawczego i zostaje w rejestrze — skuteczność da się mierzyć, zamiast o niej zapewniać.

Domyślnie ruch zostaje zatrzymany — fail-closed. System bezpieczeństwa, który po awarii przepuszcza wszystko, chroni tylko wtedy, gdy nic mu nie zagraża. Dostępność zapewnia klaster, a nie furtka.

Tryb można zmienić, ale wtedy jest to Wasza decyzja zapisana w konfiguracji i widoczna w rejestrze.

Domyślnie nie. Zapisujemy metadane — kto, kiedy, jaka klasa danych, jaka decyzja, jaki dostawca — bo bez nich nie ma dowodu dla audytora. Treść promptu i odpowiedź przez system przechodzą, ale w nim nie zostają.

We wdrożeniu on-premise wszystko dzieje się w Waszej infrastrukturze, a my nie mamy do niej ścieżki dostępu. Szczegóły na stronie Bezpieczeństwo i zgodność.

Nie — i każdy, kto twierdzi inaczej, sprzedaje Wam kłopot. Podmiana jest odwracalna, więc mówimy o pseudonimizacji w rozumieniu art. 4 pkt 5 RODO, a dane pseudonimizowane pozostają danymi osobowymi.

Zmienia się poziom ryzyka: poza organizację wychodzi zbiór, którego bez sejfu mapowań nie da się przypisać osobie, a sejf zostaje u Was. Pseudonimizacja jest przy tym wymieniona wprost w art. 32 ust. 1 lit. a RODO.

Nie podajemy liczby, bo byłaby zmyślona — zależy od Waszego sprzętu, długości promptów i zestawu detektorów.

Konstrukcyjnie: analizujemy prompt, a nie całą rozmowę, odpowiedź jest strumieniowana, a najcięższy detektor jest opcjonalny. Pomiar w Waszym środowisku to część pierwszego etapu wdrożenia.

Tak, i wtedy ruch w ogóle nie opuszcza Waszej sieci. Bramkarz nadal egzekwuje polityki i prowadzi rejestr, a ten sam mechanizm pozwala kierować sprawy wrażliwe do modelu lokalnego, a resztę do silniejszego modelu zewnętrznego.

Wtyczka do przeglądarki dla serwisów czatowych, podmiana adresu API dla aplikacji wewnętrznych — zwykle bez zmian w kodzie — i ten sam punkt dla asystentów w IDE. Nikt nie uczy się nowego narzędzia.

Na sprzęcie służbowym: kierowanie ruchu i lista dozwolonych domen. Ale bądźmy szczerzy — determinacja i telefon prywatny wygrywają z każdym rozwiązaniem technicznym.

Dlatego istotniejsze jest to, że Bramkarz nie odbiera ludziom narzędzia. Powód obchodzenia zabezpieczeń znika, kiedy droga zatwierdzona jest równie szybka.