DLP dla GenAI: 10 zasad, które realnie ograniczają wyciek promptów i plików

1. Dlaczego DLP w erze GenAI: nowe kanały wycieku (prompty, pliki, zrzuty ekranu) i model zagrożeń

Generatywna AI zmienia dynamikę wycieku danych: zamiast pojedynczych, rzadkich incydentów (np. błędny adresat e‑maila) mamy częste, interaktywne przekazywanie informacji do narzędzi zewnętrznych i wewnętrznych. Użytkownik „rozmawia” z modelem, testuje warianty, dopina pliki, wkleja fragmenty dokumentów, a następnie eksportuje wyniki dalej. To powoduje, że klasyczne DLP oparte wyłącznie na skanowaniu poczty i magazynów plików przestaje obejmować cały rzeczywisty przepływ informacji.

W praktyce GenAI dokłada trzy szczególnie problematyczne kanały: prompty (tekst), pliki przesyłane do narzędzi oraz zrzuty ekranu/ekspozycję na ekranie. Każdy z nich omija część dotychczasowych zabezpieczeń, bo dzieje się „w locie” i często poza tradycyjnymi repozytoriami.

Nowe kanały wycieku: co jest inne niż wcześniej

• Prompty i odpowiedzi — prompt jest de facto nowym dokumentem: może zawierać streszczenia umów, fragmenty kodu, dane klienta, tajemnice przedsiębiorstwa, a także kontekst z wielu źródeł. Kluczowa różnica polega na tym, że dane są przesyłane jako tekst w interfejsie webowym lub aplikacji, często bez śladu w systemach plikowych. Dodatkowo odpowiedź modelu może nieświadomie skonsolidować wrażliwe informacje w łatwiejszej do wyniesienia formie.
• Pliki dołączane do czatów i agentów — użytkownicy przyzwyczajają się do „wrzucania PDF-a” czy arkusza do analizy. To tworzy ryzyko wycieku zarówno przez sam upload, jak i przez późniejsze przechowywanie/retencję po stronie dostawcy, cache w przeglądarce, synchronizację klienta desktopowego lub dalsze udostępnienia linkiem.
• Zrzuty ekranu i ekspozycja na ekranie — gdy kontrola uploadu plików i wklejania tekstu działa, użytkownik może obejść ograniczenia przez zrzut ekranu, zdjęcie telefonu lub udostępnienie ekranu na spotkaniu. W GenAI to częste, bo wyniki czatu są „na ekranie”, a nie w pliku objętym polityką.

Dlaczego tradycyjne DLP nie wystarcza

Klasyczne podejście do DLP było projektowane wokół kanałów typu e‑mail, udziały plikowe, endpoint i druk. W erze GenAI pojawiają się problemy:

• Interakcyjność i szybkość — dane są wprowadzane i wynoszone w krótkich cyklach, co wymaga kontroli w czasie rzeczywistym, a nie tylko audytu po fakcie.
• „Rozproszone” ślady danych — fragmenty wrażliwych informacji lądują w czatach, w historii przeglądarki, w logach narzędzi, w notatkach lub w kopiuj‑wklej; nie zawsze tam, gdzie organizacja standardowo skanuje treści.
• Granice organizacji zacierają się — pracownik korzysta z narzędzi firmowych i prywatnych, wersji webowych, wtyczek, rozszerzeń i integracji. To tworzy wiele punktów wyjścia, z których część nie jest objęta dotychczasowymi kontrolami.
• Nowa „jednostka ryzyka”: kontekst — nawet jeśli pojedynczy fragment nie wygląda na wrażliwy, złożony prompt może ujawnić procesy, architekturę, cenniki czy dane klientów przez połączenie wielu drobnych elementów.

Model zagrożeń dla GenAI: na co realnie trzeba patrzeć

Skuteczny DLP dla GenAI zaczyna się od prostego, praktycznego modelu zagrożeń, który łączy kto może wynosić dane, jak to robi i gdzie dane trafiają.

• Aktorzy:
  • Nieumyślni użytkownicy — wklejają fragmenty umów lub danych klientów, bo chcą szybciej przygotować mail, streszczenie, analizę lub kod.
  • Użytkownicy obchodzący zasady — wiedzą, że nie wolno przesłać pliku, więc przerabiają go na tekst, zrzut ekranu albo „opisują” dane w promptach.
  • Insiderzy z intencją — wykorzystują GenAI jako kanał eksfiltracji (łatwość masowego przepisania/streściowania, ujednolicenie danych, szybsze wynoszenie).
  • Dostawcy i łańcuch narzędzi — ryzyko nie musi wynikać ze złej woli; czasem to efekt retencji, trenowania, błędnej konfiguracji tenantów, uprawnień lub integracji.
• Wektory:
  • Wklejanie tekstu do czatu (prompty), w tym dane osobowe, dane finansowe, tajemnice handlowe, fragmenty kodu źródłowego.
  • Upload plików, synchronizacja lub udostępnianie linków do źródeł, z których agent/czat pobiera dane.
  • Kopiuj‑wklej z odpowiedzi modelu do narzędzi zewnętrznych, ticketów, CRM, e‑maili.
  • Zrzuty ekranu, nagrywanie ekranu, udostępnianie ekranu, zdjęcia z telefonu.
• Miejsca „lądowania” danych:
  • Historia czatów, przestrzenie robocze i projekty w narzędziach GenAI.
  • Logi i telemetria narzędzi (po stronie dostawcy lub w firmie).
  • Pamięć podręczna przeglądarki i artefakty endpointu.
  • Dalsze aplikacje, do których użytkownik przenosi wynik (dokumenty, repozytoria kodu, komunikatory).

Co w DLP dla GenAI jest celem, a co pułapką

Celem nie jest „zablokować AI”, tylko zmniejszyć prawdopodobieństwo wycieku przy zachowaniu użyteczności. DLP w kontekście GenAI powinno:

• chronić dane w momencie ich wprowadzania i wynoszenia (prompty, upload, kopiowanie),
• uwzględniać, że użytkownik często nie postrzega promptu jako danych firmowych,
• minimalizować „ciche” wynoszenie przez kanały wizualne (ekran),
• redukcję ryzyka opierać na jasnych zasadach i komunikatach, a nie na samych zakazach.

Pułapką jest natomiast skupienie się wyłącznie na jednym kanale (np. blokada uploadu), bo w GenAI użytkownicy naturalnie przechodzą na alternatywy: tekst zamiast pliku, zrzut ekranu zamiast tekstu, albo przenoszenie wyników do innych aplikacji. Dlatego model zagrożeń powinien obejmować wszystkie trzy kanały równolegle i traktować je jako powiązany system naczyń połączonych.

2. Fundamenty programu DLP pod GenAI: klasyfikacja danych, etykiety wrażliwości i minimalny zestaw polityk

Skuteczne DLP dla GenAI zaczyna się nie od blokad, ale od jednoznacznego nazwania danych i nadania im reguł obchodzenia się z nimi. Bez tego kontrola promptów i uploadów staje się zbiorem przypadkowych wyjątków: raz zbyt restrykcyjnym (blokuje pracę), raz zbyt luźnym (przepuszcza to, co naprawdę wrażliwe). Fundamenty to trzy elementy: klasyfikacja, etykiety wrażliwości oraz minimalny zestaw polityk, które da się utrzymać operacyjnie. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Klasyfikacja danych: co chronimy w kontekście GenAI

W klasycznym DLP często myśli się o „plikach i mailach”. W GenAI zakres rozszerza się o treści ulotne i kontekst: prompt, fragmenty dokumentów wklejane do czatu, streszczenia, odpowiedzi modelu oraz metadane (np. nazwy projektów w treści zapytania). Dlatego klasyfikacja powinna obejmować nie tylko typy dokumentów, ale też rodzaje informacji, które w promptach pojawiają się najczęściej.

• Dane identyfikujące osoby (np. dane kontaktowe, identyfikatory, informacje kadrowe) — ryzyko naruszeń prywatności i regulacji.
• Tajemnice przedsiębiorstwa i know-how (np. specyfikacje, algorytmy, wewnętrzne procedury, dane o kosztach) — ryzyko utraty przewagi konkurencyjnej.
• Dane klientów i kontrakty (np. warunki cenowe, zapisy umowne, SLA) — ryzyko prawne i reputacyjne.
• Klucze, tokeny, konfiguracje, sekrety — ryzyko natychmiastowego przejęcia systemów.
• Dane finansowe i raportowe (przed publikacją) — ryzyko manipulacji informacją i naruszeń obowiązków informacyjnych.

W praktyce warto zacząć od najczęściej wyciekających „kawałków”: danych osobowych, sekretów dostępowych oraz fragmentów umów/ofert. To są treści, które użytkownicy najłatwiej wklejają do promptów „na chwilę”, a potem trudno je odtworzyć w audycie, jeśli nie ma mechanizmów wykrywania.

Etykiety wrażliwości: wspólny język dla plików i tekstu

Etykiety wrażliwości (sensitivity labels) działają jak kontrakt między biznesem a technologią: określają, jak z danymi wolno postępować. Kluczowa różnica względem samej klasyfikacji jest taka, że klasyfikacja opisuje (co to jest), a etykieta steruje (co wolno z tym zrobić). W erze GenAI etykieta powinna „nieść się” przez typowe przepływy: tworzenie pliku, udostępnienie, kopiowanie treści do promptu, przesyłanie do usług webowych oraz synchronizację.

Dobrze działający zestaw etykiet jest mały i zrozumiały. Nadmiar poziomów wrażliwości kończy się tym, że użytkownicy wybierają losowo albo nie etykietują wcale. Typowy, minimalny schemat to:

• Publiczne — może trafić do narzędzi GenAI bez dodatkowych ograniczeń.
• Wewnętrzne — dozwolone przy zachowaniu podstawowych zasad (np. zatwierdzone narzędzia, brak danych klientów).
• Poufne — ograniczenia w wysyłaniu poza organizację; szczególna ostrożność w promptach i uploadach.
• Ściśle poufne — domyślnie brak zgody na użycie w usługach GenAI, chyba że spełnione są warunki wyjątkowe (np. środowisko izolowane, zatwierdzone przypadki użycia).

Kluczowe jest, aby etykieta nie była tylko „naklejką” na dokument. Powinna wiązać się z automatycznym wykrywaniem (np. gdy w treści pojawia się określony typ danych), zachowaniem użytkownika (podpowiedzi i uzasadnienia) oraz egzekwowaniem (wymuszenie ograniczeń przy udostępnianiu i wysyłce). Szczegóły egzekwowania w konkretnych kanałach to temat późniejszych scenariuszy; na poziomie fundamentów chodzi o to, by etykieta była źródłem decyzji.

Minimalny zestaw polityk DLP pod GenAI: mniej, ale skuteczniej

W DLP dla GenAI łatwo wpaść w pułapkę tworzenia dziesiątek wyjątków („ta aplikacja tak, ta nie”, „ten zespół może”, „ten typ pliku czasem”). Lepszym podejściem na start jest mały zestaw polityk z jasnym celem: zatrzymać najdroższe wycieki i jednocześnie zebrać dane o tym, jak ludzie naprawdę używają narzędzi GenAI.

• Polityka „sekrety i dostęp” — wykrywanie i blokowanie wysyłki lub wklejania informacji uwierzytelniających (klucze, tokeny, hasła, konfiguracje). To najszybsza ścieżka do redukcji ryzyka technicznego.
• Polityka „dane osobowe” — wykrywanie i kontrola ekspozycji danych identyfikujących osoby, szczególnie w promptach i przy uploadzie plików. Zwykle wymaga też czytelnych komunikatów dla użytkownika.
• Polityka „dane klientów i umowy” — ograniczenie wynoszenia treści kontraktowych i ofertowych do narzędzi niezatwierdzonych; często zaczyna się od trybu monitorowania, by poznać skalę i kontekst.
• Polityka „ściśle poufne poza organizację” — prosta zasada oparta o etykietę: jeśli dane mają najwyższy poziom wrażliwości, domyślnie nie opuszczają środowiska firmowego (w tym do usług GenAI), chyba że spełnione są zatwierdzone warunki.
• Polityka „shadow AI” — identyfikacja użycia niezatwierdzonych narzędzi i domen, aby móc przejść od niekontrolowanego użycia do zarządzanego dopuszczenia bez paraliżowania pracy.

Różnica między „polityką DLP” a „konfiguracją techniczną” jest istotna: polityka to reguła biznesowa (co jest zabronione/dozwolone), a konfiguracje to sposoby jej realizacji w kanałach (przeglądarka, endpoint, chmura). Na etapie fundamentów należy doprecyzować jeszcze trzy rzeczy, które decydują o powodzeniu programu:

• Tryby działania: monitoruj → ostrzegaj/uzasadnienie → blokuj. Dojrzałość buduje się etapowo, a nie od razu „na twardo”.
• Własność i proces wyjątków: kto zatwierdza odstępstwa, na jak długo i na jakich warunkach. Brak procesu wyjątków szybko zamienia DLP w „narzędzie do omijania”.
• Jednoznaczne komunikaty dla użytkownika: informacja, co zostało wykryte (kategoria), dlaczego to ryzykowne i co zrobić zamiast (np. użyć zatwierdzonego narzędzia lub zanonimizować dane).

Jeśli klasyfikacja jest prosta, etykiety konsekwentne, a polityki minimalne i mierzalne, reszta wdrożenia staje się kwestią „gdzie i jak egzekwować”. Bez tych fundamentów każde narzędzie DLP będzie generować hałas, a nie realne ograniczenie wycieków.

3. 10 praktycznych zasad DLP dla GenAI: przegląd i mapa do scenariuszy

DLP dla GenAI różni się od klasycznego DLP przede wszystkim tym, że dane „uciekają” krótkimi porcjami (fragmenty tekstu, prompt, wynik), często bez załącznika, a decyzje muszą być podejmowane w czasie rzeczywistym (przed wysłaniem do usługi). Poniższe zasady są zaprojektowane tak, by obejmowały trzy główne kanały: pliki, tekst/prompt oraz ekspozycję na ekranie (w tym zrzuty ekranu) — i żeby dało się je mierzyć.

Mapa zasad: co chroni i gdzie działa

10 zasad w praktyce: po co, jak wdrożyć, typowe błędy, jak mierzyć

1) Zdefiniuj „dozwolone użycie GenAI” jako politykę DLP

Po co: DLP działa lepiej, gdy nie jest zbiorem wyjątków, tylko przekłada politykę użycia na decyzje (co wolno wysłać, komu, gdzie, w jakiej formie).

• Jak wdrożyć: opisz kategorie danych (np. publiczne/wewnętrzne/poufne) i dozwolone operacje (prompt, upload, eksport). Przypisz akcje: zezwól, ostrzeż, wymagaj uzasadnienia, blokuj.
• Typowe błędy: jedynie „blokuj wszystko” albo „pozwól wszystko”; brak rozróżnienia kanału (tekst vs plik).
• Jak mierzyć: odsetek zdarzeń w trybie „warn” vs „block”, liczba wyjątków, trend naruszeń na użytkownika/aplikację.

2) Kontroluj kanał: blokuj nieautoryzowane aplikacje i domeny GenAI

Po co: nawet najlepsze reguły treści nie pomogą, jeśli użytkownicy wysyłają dane do narzędzi poza kontrolą (shadow AI).

• Jak wdrożyć: allowlista zatwierdzonych usług i integracji; blokady domen/aplikacji; różne poziomy dostępu dla ról (np. tylko przeglądanie vs prompt + upload).
• Typowe błędy: próba blokowania wyłącznie po słowach kluczowych; ignorowanie aplikacji „pośrednich” (rozszerzenia przeglądarki, integracje wtyczek).
• Jak mierzyć: liczba prób wejścia na nieautoryzowane domeny, top źródła shadow AI, skuteczność blokad (spadek w czasie).

3) Egzekwuj etykiety wrażliwości i „minimum metadanych”

Po co: GenAI przyspiesza przepływ treści; bez etykiet/klasyfikacji DLP staje się ślepe lub nadreaktywne.

• Jak wdrożyć: wymagaj etykiety przy tworzeniu/udostępnianiu pliku; automatyczne etykietowanie dla oczywistych wzorców (np. dane osobowe, tajemnice handlowe); dziedziczenie etykiet w kopiach.
• Typowe błędy: zbyt wiele etykiet; etykiety „na honor”; brak powiązania etykiety z akcjami DLP.
• Jak mierzyć: pokrycie etykietami (% dokumentów), liczba dokumentów „Unlabeled”, zgodność etykiety z regułami (ile incydentów dotyczy danych bez etykiety).

4) Wprowadź redakcję (maskowanie) danych w promptach

Po co: prompt często zawiera fragmenty danych wrażliwych „wklejone dla wygody”. Redakcja ogranicza ryzyko, zachowując użyteczność (np. tokenizacja identyfikatorów).

• Jak wdrożyć: reguły wykrywania PII/sekretów + zastępowanie (np. [EMAIL], [ACCOUNT_ID]); tryby: automatyczne maskowanie albo „podpowiedz redakcję i poproś o akceptację”.
• Typowe błędy: maskowanie bez kontekstu (psuje sens zadania); brak rozróżnienia między danymi testowymi a produkcyjnymi.
• Jak mierzyć: liczba zredagowanych promptów, % promptów z PII, spadek zdarzeń blokad dzięki redakcji, czas do ukończenia zadania (użyteczność).

5) Zasady kopiuj–wklej i schowka (clipboard)

Po co: kopiuj–wklej jest najczęstszym „nieformalnym API” do GenAI. Kontrola schowka ogranicza przenoszenie danych między strefami (np. z aplikacji firmowej do czatu webowego).

• Jak wdrożyć: ogranicz kopiowanie z aplikacji o wysokiej wrażliwości; wymuś ostrzeżenie/uzasadnienie przy wklejaniu do przeglądarki; rozważ limit długości wklejanego tekstu dla wybranych klas danych.
• Typowe błędy: globalne wyłączenie schowka (paraliż pracy); brak wyjątków dla ról (np. wsparcie techniczne).
• Jak mierzyć: liczba zdarzeń copy/paste zablokowanych vs ostrzeżonych, top aplikacje źródłowe, wpływ na liczbę zgłoszeń do helpdesku.

6) Kontroluj upload i synchronizację plików do GenAI

Po co: upload jest „hurtowym” wyciekiem: jeden plik może zawierać wiele rekordów, załączników i metadanych.

• Jak wdrożyć: polityki per etykieta/typ danych: blokuj poufne, pozwalaj na wewnętrzne do zatwierdzonych usług; wymuszaj skanowanie zawartości przed wysyłką; ogranicz typy plików i archiwa.
• Typowe błędy: kontrola tylko rozszerzeń (łatwe obejście); brak wykrywania danych w obrazach/PDF; nieuwzględnianie synchronizacji (np. dyski, „przeciągnij i upuść”).
• Jak mierzyć: liczba prób uploadu wg etykiety, wielkość zablokowanych transferów, top źródła danych (repozytoria), wskaźnik fałszywych alarmów.

7) Ogranicz „pamięć” i retencję po stronie narzędzia

Po co: wyciek to nie tylko „wysłanie”, ale też utrwalenie danych w historii rozmów, logach, pamięci narzędzia lub treningu (zależnie od konfiguracji).

• Jak wdrożyć: wyłącz/ogranicz historię i długoterminową pamięć tam, gdzie to możliwe; ustal zasady retencji; wymuś użycie kont firmowych zamiast prywatnych.
• Typowe błędy: traktowanie ustawień prywatności jako zamiennika DLP; brak rozróżnienia środowisk (test/prod).
• Jak mierzyć: % sesji na kontach zarządzanych, zgodność ustawień retencji, liczba incydentów z danymi znalezionymi w historii rozmów.

8) Zabezpiecz wyniki: gdzie wolno zapisywać output

Po co: output GenAI bywa mieszanką danych wejściowych i wiedzy firmowej; ryzyko rośnie, gdy wynik trafia do niekontrolowanych miejsc (notatniki, prywatne dyski, komunikatory).

• Jak wdrożyć: traktuj output jak nowy artefakt: wymuszaj zapis do zatwierdzonych repozytoriów; automatycznie etykietuj wynik zgodnie z kontekstem; reguły udostępniania (zewnętrzne linki, publiczne paste).
• Typowe błędy: ochrona tylko wejścia (prompt/upload) bez ochrony wyjścia; brak kontroli udostępniania linkami.
• Jak mierzyć: liczba prób zapisu/udostępnienia w niezatwierdzone lokalizacje, udział outputów z etykietą, incydenty „public link”.

9) Ogranicz przechwytywanie obrazu i ekspozycję na ekranie

Po co: nawet przy blokadach tekstu i plików użytkownik może wynieść dane przez zrzut ekranu lub nagranie (zwłaszcza gdy GenAI wyświetla wrażliwe treści).

• Jak wdrożyć: polityki ograniczania zrzutów/nagrań dla aplikacji i sesji wysokiej wrażliwości; separacja środowiska (np. przeglądarka zarządzana/izolacja); zasady „no-peek” dla wybranych ról i ekranów.
• Typowe błędy: założenie, że DLP treści rozwiązuje problem ekranów; brak segmentacji (te same restrykcje dla wszystkich).
• Jak mierzyć: liczba prób przechwytywania ekranu, zdarzenia dostępu do wrażliwych widoków, korelacja z incydentami udostępnień.

10) Mierz, testuj i koryguj: metryki, wyjątki, tuning

Po co: DLP dla GenAI wymaga strojenia: zmieniają się narzędzia, zachowania użytkowników i formaty danych (np. multimodalność).

• Jak wdrożyć: zacznij od trybu monitorowania dla nowych reguł, potem „warn”, a dopiero na końcu „block”; zarządzaj wyjątkami przez proces (czasowe, z uzasadnieniem); testuj reguły na reprezentatywnych próbkach.
• Typowe błędy: brak pętli informacji zwrotnej; „wieczne wyjątki”; brak rozdzielenia metryk bezpieczeństwa od metryk produktywności.
• Jak mierzyć:
  • Skuteczność: spadek incydentów o wysokiej wadze, MTTD/MTTR dla zdarzeń DLP, pokrycie kanałów (tekst/plik/ekran).
  • Jakość reguł: false positive rate, odsetek alertów bez akcji, liczba reguł generujących 80% hałasu.
  • Użyteczność: wskaźnik obejść (np. wzrost zrzutów ekranu po blokadzie copy/paste), liczba zgłoszeń do helpdesku, czas wykonania typowych zadań.

Minimalny „pakiet startowy” (kolejność wdrażania)

1. Kontrola kanału (zasada 2) + podstawowa polityka użycia (zasada 1).
2. Pliki: etykiety (zasada 3) + kontrola uploadu (zasada 6).
3. Prompt/tekst: redakcja (zasada 4) + clipboard (zasada 5).
4. Output i retencja: zapis wyników (zasada 8) + ograniczenie pamięci/retencji (zasada 7).
5. Ekran: ograniczenia przechwytywania (zasada 9) dla najwyższej wrażliwości.
6. Stałe strojenie: metryki i tuning (zasada 10).

Scenariusz 1 — Pliki: kontrola uploadu/synchronizacji, szyfrowanie, watermarking i egzekwowanie etykiet

W GenAI „wyciek pliku” rzadko wygląda jak klasyczne wysłanie załącznika mailem. Częściej to upload do czatu, podsunięcie dokumentu do analizy, synchronizacja przez dysk w chmurze albo import do wtyczki/łącznika. W tym scenariuszu DLP musi działać na styku: użytkownik–urządzenie–przeglądarka–aplikacja–chmura, bo plik może opuścić organizację kilkoma równoległymi kanałami.

1) Gdzie realnie „uciekają” pliki w kontekście GenAI

• Upload w interfejsie webowym (przeciągnij i upuść, „Attach”, „Upload”).
• Synchronizacja (foldery synchronizowane, klienci dysków chmurowych, udostępnienia linkiem).
• Integracje i konektory (np. wtyczki do przeglądarki, dodatki do aplikacji, „podłącz dysk/drive”).
• Eksport/konwersja (pobranie wyniku i ponowny upload jako „podkład” do kolejnego narzędzia).

Kluczowa różnica względem klasycznych kanałów: plik bywa przekazywany do usługi, która przetwarza treść, a więc ryzyko dotyczy nie tylko transferu, ale też tego, czy i gdzie dane będą dalej przechowywane oraz kto może je odzyskać.

2) Kontrola uploadu i synchronizacji: trzy tryby reakcji

Dla plików najczęściej stosuje się trzy poziomy egzekwowania, zależnie od wrażliwości danych i tolerancji na tarcie użytkownika:

W praktyce oznacza to polityki typu: „pliki z etykietą Wysoka wrażliwość nie mogą być uploadowane do niezatwierdzonych usług” oraz „pliki nieoznaczone mogą być wysyłane tylko po oznaczeniu”. W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami, bo granica między „blokuj” a „warunkuj” zwykle decyduje o tym, czy polityka będzie realnie przestrzegana.

Szczegóły reguł zależą od tego, jak organizacja rozróżnia aplikacje zatwierdzone (managed) i niezatwierdzone (unmanaged) oraz jak identyfikuje usługi GenAI w ruchu sieciowym.

3) Szyfrowanie: ochrona treści, a nie tylko kanału

W kontekście GenAI szyfrowanie jest najczęściej używane w dwóch rolach:

• Szyfrowanie pliku (persistent) — plik pozostaje chroniony także po pobraniu i skopiowaniu. To podejście wspiera model: „dane mogą wyjść, ale tylko w kontrolowanej postaci”.
• Szyfrowanie w tranzycie — standardowe zabezpieczenie kanału (TLS/VPN). Pomaga, ale nie rozwiązuje problemu przekazania treści do zewnętrznej usługi, która może ją przechowywać.

Różnica praktyczna: szyfrowanie „pliku” często wymaga zgodności aplikacyjnej (czy odbiorca/usługa potrafi pracować z chronionym dokumentem). Dlatego w scenariuszach GenAI zwykle szyfrowanie jest stosowane selektywnie — tam, gdzie plik ma krążyć między znanymi tożsamościami i narzędziami.

4) Watermarking: zniechęcanie i dochodzenie, nie „magiczna blokada”

Watermarking (znaki wodne) dla plików działa głównie jako mechanizm odpowiedzialności i odstraszania oraz wsparcie dochodzeń:

• Widoczny watermark (np. na PDF/druk) — zmniejsza ryzyko „przypadkowego” dalszego udostępnienia.
• Niewidoczny/ukryty (metadane/znaczniki) — ułatwia identyfikację źródła wycieku, ale nie zatrzyma uploadu.

W przypadku GenAI watermark jest szczególnie przydatny, gdy organizacja dopuszcza współpracę zewnętrzną, ale chce utrzymać ślad pochodzenia dokumentu. Nie należy go traktować jako substytutu blokad lub szyfrowania — to inny typ kontroli.

5) Egzekwowanie etykiet: warunek skuteczności polityk plikowych

Polityki DLP dla plików działają najczytelniej, gdy opierają się o etykiety wrażliwości (np. Publiczne/Wewnętrzne/Poufne/Ściśle poufne). W scenariuszu GenAI egzekwowanie etykiet zwykle obejmuje:

• Wymóg etykiety przed uploadem — pliki bez etykiety traktowane są jako niezgodne do czasu oznaczenia.
• Różne konsekwencje dla różnych etykiet — np. „Wewnętrzne” tylko do zatwierdzonych narzędzi, „Poufne” blokada lub tylko do środowisk kontrolowanych.
• Ochrona etykiety przed degradacją — ograniczenie ręcznego obniżania klasyfikacji bez uzasadnienia.

To podejście ma prostą zaletę: zamiast próbować odgadywać „co jest w środku” przy każdym transferze, organizacja wymusza spójny sygnał decyzyjny na poziomie pliku. Najczęstszy problem wdrożeniowy to sytuacja, gdy etykiety istnieją, ale nie są realnie używane (brak wymuszeń, brak automatyki, brak konsekwencji w procesach).

6) Minimalny zestaw decyzji projektowych dla tego scenariusza

Żeby ten scenariusz zadziałał bez nadmiernego tarcia, warto z góry odpowiedzieć na kilka pytań, które determinują polityki:

• Jakie usługi GenAI są zatwierdzone do przetwarzania plików (i dla jakich etykiet)?
• Czy dopuszczamy upload plików do narzędzi zewnętrznych w ogóle, czy tylko do wersji korporacyjnych/zarządzanych?
• Co robimy z plikami nieoznaczonymi: blokada, wymuszenie etykiety, czy tylko ostrzeżenie?
• Jak traktujemy synchronizację: czy wolno synchronizować pliki wrażliwe na urządzenia niezarządzane?
• Jaką rolę ma szyfrowanie: ochrona zawsze dla wybranych etykiet, czy tylko dla udostępnień poza organizację?

Odpowiedzi na te pytania pozwalają zbudować proste, zrozumiałe zasady: kto może przesłać jaki plik, dokąd i pod jakimi warunkami — bez konieczności podejmowania decyzji ad hoc przy każdym uploadzie.

7) Krótki przykład logiki polityki (pseudoreguła)

IF file.sensitivity IN {"Poufne", "Ściśle poufne"}
AND destination.app NOT IN approved_genai_apps
THEN block_upload
ELSE IF file.sensitivity IS NULL
THEN prompt_user_to_label_and_retry
ELSE allow_and_log

Taka logika oddziela trzy elementy: klasyfikację (etykieta), kontekst (dokąd plik trafia) i akcję (blokuj/warunkuj/monitoruj). W dalszych pracach kluczowe jest dopracowanie wyjątków biznesowych, aby „warunkuj” było częstsze niż „blokuj”, ale bez otwierania drogi do niekontrolowanych uploadów.

Scenariusz 2 — Prompt/tekst: redakcja, polityki kopiuj-wklej, allowlist domen, blokady i komunikaty dla użytkownika

Wyciek przez prompt jest podstępny, bo rzadko wygląda jak „udostępnianie pliku”. Najczęściej to zwykłe wklejenie fragmentu maila, logów, specyfikacji, kodu lub danych klienta do okna czatu. DLP dla GenAI w tym scenariuszu musi działać w czasie rzeczywistym, na krótkich porcjach tekstu i w kontekście miejsca docelowego (konkretna domena/aplikacja AI) — inaczej użytkownik zdąży wysłać dane zanim system zareaguje.

Co tu chronimy: „prompt” jako nowy kanał exfiltracji

• Dane wrażliwe wklejane ad hoc (PII, dane finansowe, tajemnice przedsiębiorstwa, fragmenty umów, ticketów, incydentów).
• Wiedza operacyjna (konfiguracje, adresy IP, nazwy hostów, opisy podatności) — często nie jest formalnie sklasyfikowana, ale zwiększa ryzyko.
• Kontekst, który „skleja” informacje: pojedyncze zdanie może być nieszkodliwe, ale kilka wiadomości w wątku tworzy pełny obraz procesu, architektury lub klienta.

Cztery dźwignie kontroli: redakcja, kopiuj-wklej, allowlist, blokady

Najpraktyczniejszy model to połączenie czterech mechanizmów. Każdy odpowiada na inny nawyk użytkownika i inny punkt kontrolny.

Redakcja: „zachowaj sens, usuń identyfikatory”

Redakcja w scenariuszu promptów polega na automatycznym usunięciu lub zamianie wrażliwych elementów na tokeny (np. [EMAIL], [ACCOUNT_NO]) zanim tekst opuści urządzenie/użytkownika. Kluczowe jest rozróżnienie:

• Redakcja deterministyczna (ten sam identyfikator → ten sam token w obrębie sesji): ułatwia analizę, ale trzeba pilnować, by tokenizacja nie dała się odwrócić poza kontrolowanym środowiskiem.
• Redakcja selektywna (tylko określone typy danych): zwykle lepszy kompromis użyteczności.

Minimalna praktyka: redaguj sekrety i identyfikatory (klucze API, hasła, tokeny sesyjne, numery dokumentów, konta bankowe) oraz dane osobowe, jeśli trafiają do narzędzi poza kontrolą organizacji.

Kopiuj-wklej i schowek: kontrola „najkrótszej ścieżki”

Użytkownik najczęściej nie „wysyła danych” — on je wkleja. Dlatego polityka powinna patrzeć na kierunek: z aplikacji firmowej → do okna promptu (w przeglądarce lub kliencie desktop). Najczęstsze warianty kontroli:

• Blokuj wklejanie, gdy schowek zawiera wzorce wrażliwe (np. klucz prywatny, token, dane klienta).
• Zezwalaj z ostrzeżeniem, gdy treść jest „podejrzana”, ale nie krytyczna (soft-block).
• Zezwalaj po redakcji, gdy można bezpiecznie usunąć identyfikatory i zachować sens promptu.

Warto od razu rozdzielić przypadki: kopiuj-wklej wewnątrz firmowych narzędzi (zwykle dozwolone) vs. kopiuj-wklej do zewnętrznej usługi AI (często ograniczane).

Allowlist domen i aplikacji: „gdzie wolno używać GenAI”

Allowlist nie jest tylko kontrolą sieciową. W praktyce chodzi o spójne wymuszenie: z jakimi usługami AI wolno pracować oraz w jakim trybie (np. w ramach konta organizacyjnego). Dla DLP to ważne, bo:

• inne ryzyko ma czat w publicznym serwisie, a inne w narzędziu przypiętym do tenanta z kontrolą dostępu i logowaniem,
• to pozwala budować reguły „surowsze na zewnątrz, łagodniejsze wewnątrz”,
• ułatwia komunikację dla użytkownika: „używaj tylko zatwierdzonych miejsc”.

Dobrym podejściem jest allowlist oparta o kategorie (np. „zatwierdzone narzędzia AI”, „pozostałe”) zamiast ręcznej listy setek adresów URL, ale bez wchodzenia w szczegóły implementacji kluczowe jest jedno: polityki promptów muszą rozróżniać destination.

Blokady i komunikaty: mniej „policy”, więcej „dlaczego”

Skuteczność DLP dla promptów rośnie, gdy blokada ma sensowny komunikat. Użytkownik powinien dostać krótką odpowiedź na trzy pytania: co wykryto, dlaczego to ryzyko i co zrobić zamiast. Przykładowe typy reakcji:

• Hard block: treść nie może zostać wysłana (np. wykryto klucz prywatny/hasło/token).
• Soft block z uzasadnieniem: możliwość kontynuacji po potwierdzeniu (gdy ryzyko umiarkowane i dopuszczalne biznesowo).
• Guidance: bez blokady, ale z sugestią redakcji/anonimizacji, gdy wykryto dane potencjalnie wrażliwe.

Najważniejsza różnica względem klasycznego DLP dla poczty: tutaj decyzja dzieje się w trakcie pracy, więc komunikat ma być krótki i operacyjny, inaczej użytkownik przerwie zadanie lub poszuka obejścia.

Minimalny zestaw reguł dla promptów (bez przeinwestowania)

• Blokuj sekrety: klucze API, hasła, tokeny, prywatne klucze, ciągi o wysokiej entropii pasujące do sekretów.
• Kontroluj PII: co najmniej podstawowe identyfikatory i dane kontaktowe, zwłaszcza przy wysyłce do niezatwierdzonych domen.
• Reguły „destination-aware”: inne progi/reakcje dla zatwierdzonych narzędzi AI i dla reszty internetu.
• Redakcja jako preferowany kompromis w przypadkach, gdy użytkownik potrzebuje pomocy na danych „podobnych”, a nie prawdziwych.

Krótki przykład: komunikat użytkownika i redakcja

// Przykładowa logika (pseudokod) reakcji na prompt
if (destination not in approved_ai_domains) {
  if (containsSecrets(prompt)) block("Wykryto sekret (token/klucz). Usuń go lub użyj sejfu/menedżera sekretów.");
  else if (containsPII(prompt)) redactAndAllow("Zredagowano dane osobowe przed wysyłką.");
  else allow();
} else {
  if (containsSecrets(prompt)) block("Wykryto sekret. Nie wolno wysyłać sekretów do narzędzi AI.");
  else allowWithNotice("Pamiętaj: nie wklejaj danych klienta. Jeśli to możliwe, użyj danych zanonimizowanych.");
}

Intencją nie jest „idealne wykrywanie wszystkiego”, tylko ustawienie kilku reguł, które realnie odcinają największe ryzyka i jednocześnie nie zabijają produktywności.

6. Scenariusz 3 — Zrzuty ekranu i ekspozycja na ekranie: izolacja przeglądarki, ochrona sesji i ograniczanie przechwytywania

Wyciek do GenAI nie musi oznaczać uploadu pliku ani wklejenia tekstu. Coraz częściej „kanałem DLP” staje się ekran: użytkownik pokazuje wrażliwe dane w oknie czatu, w aplikacji biznesowej lub w narzędziu analitycznym, a potem treść trafia dalej jako zrzut ekranu, zdjęcie telefonu, nagranie ekranu lub udostępnianie okna podczas spotkania. To trudniejsze do kontroli niż ruch sieciowy, bo informacja „zamienia się w obraz”.

Jak wygląda zagrożenie w praktyce (model ryzyka dla „ekranu”)

• Zrzut ekranu / nagranie ekranu z widocznym promptem, odpowiedzią modelu, danymi klienta, wynikami raportu, fragmentem kodu lub błędem z tokenem/API key.
• Udostępnianie ekranu (spotkania, webinary) — przypadkowe pokazanie czatu GenAI, panelu administracyjnego, danych w CRM/ERP.
• Shoulder surfing i zdjęcia telefonem — kanał poza kontrolą systemów DLP opartych o sieć.
• Przeglądarka jako punkt wycieku: wrażliwe treści pojawiają się w aplikacji web (w tym GenAI), a użytkownik wynosi je „na obrazku”.

W tym scenariuszu celem nie jest wyłącznie „zablokować print screen” (często nierealne w 100%), ale zmniejszyć ekspozycję i podnieść koszt wyniesienia danych, jednocześnie zachowując użyteczność narzędzi GenAI.

Trzy podejścia obrony: izolacja, ochrona sesji, ograniczanie przechwytywania

Praktyka pokazuje, że skuteczna kontrola „ekranu” zwykle składa się z trzech warstw, które warto rozumieć jako różne zastosowania, a nie zamienniki:

• Izolacja przeglądarki (browser isolation) — ogranicza ryzyko wyniesienia treści z aplikacji web poprzez uruchamianie sesji w izolowanym środowisku i kontrolę tego, co trafia na urządzenie użytkownika.
• Ochrona sesji — zabezpiecza dostęp do aplikacji GenAI i systemów źródłowych (kontekst urządzenia/użytkownika, warunki dostępu, ograniczenia działań w sesji), aby zmniejszyć prawdopodobieństwo, że wrażliwe dane w ogóle pojawią się na ekranie.
• Ograniczanie przechwytywania — próby wykrywania/utrudniania zrzutów i nagrań, oraz budowanie odstraszania (np. watermark), tam gdzie blokada jest możliwa lub biznesowo uzasadniona.

Porównanie: co daje każda technika i kiedy ją stosować

Izolacja przeglądarki: redukcja ekspozycji „na urządzeniu”

Izolacja przeglądarki jest przydatna wtedy, gdy kluczowe ryzyko to: użytkownik wchodzi w GenAI lub aplikację web z wrażliwymi danymi, a następnie wynosi je lokalnie. W podejściu izolacyjnym treść strony/rendering jest kontrolowany w środowisku pośrednim, a endpoint dostaje ograniczony „widok” sesji.

• Kiedy ma największy sens: dostęp do GenAI z urządzeń prywatnych, zewnętrznych, tymczasowych; praca B2B; sytuacje, gdzie nie możesz w pełni ufać endpointowi.
• Na co uważać: izolacja pomaga na przepływy „web → endpoint”, ale nie rozwiązuje problemu fotografowania ekranu. Dlatego często łączy się ją z watermarkiem i/lub kontrolami sesji.

Ochrona sesji: mniej wrażliwych danych na ekranie

Jeśli dane nie pojawią się w sesji, nie będzie czego „zrzucać”. Ochrona sesji skupia się na tym, kto, skąd i w jakich warunkach używa GenAI oraz systemów, z których te dane pochodzą. W praktyce oznacza to ograniczanie funkcjonalności lub dostępów w zależności od ryzyka (np. urządzenie niezarządzane, brak zgodności, nietypowa lokalizacja).

• Typowe zastosowanie: dostęp warunkowy do GenAI i aplikacji źródłowych, ograniczenia dla sesji z wysokim ryzykiem, ochrona przed przejęciem konta.
• Efekt DLP: zmniejszenie liczby sytuacji, w których wrażliwy prompt/wynik modelu jest widoczny na ekranie osoby niepowołanej.

Ograniczanie przechwytywania: blokady, wykrywanie i odstraszanie

Kontrola zrzutów ekranu i nagrań jest kusząca, ale trzeba ją traktować realistycznie: w środowiskach heterogenicznych nie da się zagwarantować pełnej skuteczności. Z tego powodu stosuje się ją selektywnie — dla najbardziej wrażliwych ról, aplikacji i danych.

• Blokady i ograniczenia: tam, gdzie platforma i narzędzia na to pozwalają, ogranicza się możliwość przechwytywania ekranu dla określonych aplikacji/okien lub w trybach pracy z danymi wrażliwymi.
• Wykrywanie sygnałów ryzyka: identyfikacja prób screen recordingu lub nietypowych zachowań (np. masowe przełączanie okien podczas pracy z danymi wrażliwymi) jako sygnał do dodatkowych kontroli.
• Watermark (znak wodny) na ekranie: działa odstraszająco i ułatwia dochodzenie powłamaniowe; szczególnie przy pracy z GenAI i danymi klienta, gdy „wyniesienie obrazem” jest realnym scenariuszem.

Minimalny, praktyczny zestaw zasad dla „ekranu” w kontekście GenAI

• Wyznacz aplikacje GenAI i systemy źródłowe jako „ekrany wysokiego ryzyka” (w szczególności: czaty, repozytoria dokumentów, systemy raportowe) i stosuj dla nich ostrzejsze warunki sesji.
• Stosuj izolację przeglądarki dla dostępu do GenAI z urządzeń niezarządzanych oraz dla ról, które mają kontakt z danymi wrażliwymi.
• Wymuś ochronę sesji: tylko zgodne urządzenia, silne uwierzytelnianie, ograniczenia działań w sesji przy podwyższonym ryzyku.
• Dodaj watermark na ekranie w krytycznych aplikacjach/sesjach (co najmniej: identyfikator użytkownika i czas), aby ograniczyć „bezkarność” wycieku obrazem.
• Wprowadź jasne komunikaty użytkownika w momentach wysokiego ryzyka (np. wejście do GenAI z danymi klienta) — w tym scenariuszu edukacja i tarcie w odpowiednim miejscu często daje lepszy efekt niż agresywne blokady.

Jak mierzyć skuteczność (bez wchodzenia w implementacyjne detale)

• Pokrycie: odsetek sesji do GenAI i kluczowych aplikacji web realizowanych w trybie izolowanym / z wymaganiami sesji.
• Ekspozycja: liczba przypadków, w których wrażliwe dane były renderowane w sesji wysokiego ryzyka (np. na urządzeniu niezgodnym) przed i po wdrożeniu.
• Incydenty „na ekranie”: zgłoszenia i wykrycia dotyczące nagrań/screenshotów oraz przypadków nieautoryzowanego udostępniania okna/ekranu.
• Tarcie: wpływ na UX (czas dostępu, liczba przerwań sesji) — kluczowe, by kontrola nie wypchnęła użytkowników do obejść.

Scenariusz „zrzuty ekranu” wymaga myślenia o DLP szerzej niż klasyczne reguły treści. Najlepsze rezultaty daje podejście warstwowe: mniej danych na ekranie dzięki ochronie sesji, mniej danych na endpoint dzięki izolacji oraz mniej łatwe przechwytywanie dzięki selektywnym ograniczeniom i watermarkowi.

7. Integracje i wdrożenie w praktyce: M365/Purview, Google (Workspace), punkty integracji (CASB/SSE/endpoint) i architektura

DLP dla GenAI nie jest „jednym przełącznikiem”. Skuteczne ograniczanie wycieków promptów i plików wymaga połączenia kilku warstw: polityk w chmurze (SaaS), kontroli ruchu do aplikacji GenAI, mechanizmów na endpointach oraz spójnych etykiet wrażliwości. Największa różnica względem klasycznego DLP polega na tym, że dane „uciekają” nie tylko w plikach i mailach, ale też w tekście interakcji (prompty, odpowiedzi) i w kanałach trudnych do przechwycenia (np. przeglądarka, schowek, udostępnianie ekranu).

M365 + Purview: gdzie ma sens i co realnie daje

W ekosystemie Microsoft naturalnym centrum sterowania jest Microsoft Purview: etykiety wrażliwości, zasady DLP, ochrona informacji oraz monitoring zdarzeń. Z perspektywy GenAI najmocniejsze zastosowania to:

• Kontrola danych w M365 (SharePoint, OneDrive, Exchange, Teams): ograniczanie nieautoryzowanego udostępniania i wynoszenia plików, które później trafiają jako załączniki do narzędzi GenAI.
• Spójne etykiety i polityki: jeśli organizacja już etykietuje dokumenty, łatwiej egzekwować „co wolno” w scenariuszach kopiowania treści i udostępniania plików.
• Widoczność i audyt: szybkie ustalenie, skąd pochodzą dane użyte w promptach (źródło w repozytoriach M365) oraz kto je wyniósł z kontrolowanych obszarów.

Kluczowe ograniczenie praktyczne: wiele interakcji GenAI odbywa się w przeglądarce lub w aplikacjach firm trzecich, więc sama polityka „w M365” nie wystarczy. Purview jest silny w źródłach danych i ich cyklu życia, ale do kontroli „na wyjściu” zwykle potrzebujesz dodatkowej warstwy (SSE/CASB/endpoint).

Google Workspace: inne punkty ciężkości

W środowisku Google ciężar przesuwa się w stronę kontroli współdzielenia i przepływu danych w Drive, Gmail i Chat oraz egzekwowania reguł wokół linków, uprawnień i domen zewnętrznych. Dla GenAI typowe zastosowania obejmują:

• Ograniczenie wynoszenia z Drive: udostępnianie na zewnątrz, pobieranie, synchronizacja na urządzeniach niezarządzanych.
• Kontrola treści w komunikacji: wycieki promptów w mailach i czatach, zwłaszcza gdy użytkownicy proszą o „pomoc w redakcji” i wklejają wrażliwe fragmenty.
• Zasady oparte o kontekst: kto, z jakiego urządzenia i z jakiej lokalizacji ma dostęp oraz czy może eksportować dane poza Workspace.

Różnica praktyczna w porównaniu do M365 jest taka, że implementacja „jednego modelu etykiet” bywa trudniejsza do przeniesienia między narzędziami, a częściej buduje się spójność przez reguły dostępu, sharingu i sygnały kontekstowe oraz przez integracje z warstwą SSE/endpoint.

Punkty integracji: CASB, SSE i endpoint — po co aż tyle?

Najczęstszy błąd wdrożeniowy to próba rozwiązania całego problemu w jednym miejscu. DLP dla GenAI działa, gdy obejmuje najważniejsze punkty styku użytkownika z danymi i z aplikacjami GenAI:

• SSE (Security Service Edge) jako warstwa egzekwowania dostępu do aplikacji webowych: przydaje się do kontrolowania ruchu do serwisów GenAI, domen, wtyczek przeglądarkowych oraz do wymuszania trybu „bezpiecznego” dla sesji. W praktyce to często najlepsze miejsce na egzekwowanie polityk „gdzie wolno wklejać tekst” i „gdzie wolno uploadować pliki”.
• CASB jako kontrola korzystania z aplikacji SaaS: szczególnie gdy masz wiele narzędzi GenAI (oficjalnych i „shadow IT”) i chcesz wiedzieć, które są używane, kto ich używa i jakie ryzyko generują. CASB pomaga też tam, gdzie SaaS ma własne logi i API do inspekcji zdarzeń.
• Endpoint DLP / EDR jako kontrola na urządzeniu: kluczowe w scenariuszach, których nie „zobaczy” chmura, np. kopiuj-wklej między aplikacjami, lokalne pliki, schowek, drukowanie do PDF, aplikacje desktopowe i część aktywności offline. Endpoint bywa też jedyną realną dźwignią przy ochronie zrzutów ekranu i przechwytywania obrazu.

W praktyce organizacje łączą te elementy tak, aby polityki były spójne, ale egzekwowane tam, gdzie to ma sens. Jeśli kontrolujesz tylko SaaS, użytkownicy „wyniosą” dane przez przeglądarkę lub urządzenie. Jeśli kontrolujesz tylko endpoint, nie masz pełnego kontekstu aplikacji webowej ani zarządzania sesją.

Architektura docelowa: minimalna, ale kompletna

Dobrą architekturę dla DLP pod GenAI można opisać jako trzy warstwy, które dzielą odpowiedzialność:

• Warstwa danych źródłowych: repozytoria firmowe (M365/Google), gdzie egzekwujesz etykiety, uprawnienia i zasady udostępniania. Cel: ograniczyć możliwość wynoszenia „surowych” dokumentów.
• Warstwa dostępu do GenAI: kontrola tego, do jakich narzędzi GenAI wolno się łączyć i w jakich warunkach (konto służbowe, urządzenie zarządzane, dozwolone domeny, tryb przeglądarki). Cel: zamknąć niekontrolowane kanały wycieku, zanim użytkownik w ogóle wprowadzi dane.
• Warstwa użytkownika (endpoint): kontrola operacji na treści (kopiowanie, wklejanie, upload, eksport) oraz wymuszanie ograniczeń na poziomie systemu i aplikacji. Cel: zabezpieczyć „ostatnią milę”, gdzie najłatwiej obejść polityki.

Spójność między warstwami utrzymuje się przez wspólne sygnały: etykiety/klasy danych, kontekst urządzenia oraz tożsamość użytkownika. Bez tego powstają „dziury”: dokument oznaczony jako wrażliwy jest chroniony w repozytorium, ale jego fragment można wkleić do publicznego modelu, bo warstwa dostępu nie zna kontekstu.

Wdrożenie krok po kroku: jak zacząć bez wielomiesięcznego projektu

W praktyce najlepiej zacząć od wdrożenia, które od razu redukuje ryzyko, a dopiero potem rozszerzać pokrycie i precyzję:

• Zidentyfikuj „oficjalne” kanały GenAI i zdecyduj, które są dozwolone, a które blokowane lub ograniczane (zwłaszcza publiczne serwisy bez umów i kontroli danych).
• Ustal punkty egzekwowania: co robisz w M365/Workspace (udostępnianie, download), co w SSE/CASB (dostęp do domen i aplikacji), a co na endpointach (kopiuj-wklej, upload, lokalne pliki).
• Wprowadź podstawową obserwowalność: wspólne logowanie zdarzeń, korelacja tożsamości i urządzenia, alerty dla krytycznych klas danych. Bez tego nie odróżnisz „fałszywych alarmów” od realnych incydentów promptowych.
• Ustandaryzuj komunikaty i wyjątki: użytkownik musi rozumieć, dlaczego akcja została zablokowana i jak bezpiecznie osiągnąć cel (np. użyć narzędzia zatwierdzonego lub zredagować dane).

Jak ocenić, czy integracja działa

DLP dla GenAI jest skuteczne wtedy, gdy polityki są egzekwowalne w miejscach, gdzie faktycznie zachodzi praca z modelami. Sygnały, że architektura jest dobrze spięta, to:

• spójne decyzje dla tej samej klasy danych niezależnie od kanału (plik, wklejony fragment, upload),
• widoczność „od źródła do wycieku” (skąd dane pochodziły i jaką drogą opuściły organizację),
• możliwość ograniczenia ryzyka bez paraliżowania pracy: blokady tylko tam, gdzie są konieczne, a w pozostałych przypadkach kontrolowane wyjątki i ścieżki alternatywne.

Operacjonalizacja i pomiar skuteczności: audyt, metryki, testy kontrolowane i ciągłe doskonalenie

DLP dla GenAI nie jest projektem „wdrożeniowym” z datą końcową, tylko procesem operacyjnym: reguły muszą nadążać za zmianami narzędzi (nowe modele, wtyczki, integracje), zachowań użytkowników (promptowanie, kopiuj-wklej), oraz danych (nowe typy dokumentów i repozytoria). Skuteczność nie wynika z liczby polityk, ale z tego, czy organizacja potrafi mierzyć ryzyko, korygować ustawienia i uczyć użytkowników na podstawie realnych zdarzeń.

1) Audyt i odpowiedzialności: kto „posiada” DLP dla GenAI

W praktyce program działa dobrze tylko wtedy, gdy jest jasno określone:

• właścicielstwo (kto podejmuje decyzje o wyjątkach, progach i dopuszczalnych kanałach użycia GenAI),
• obsługa incydentów (kto analizuje alerty i jak szybko reaguje na ryzykowne zdarzenia),
• zarządzanie zmianą (kto zatwierdza nowe polityki i aktualizacje istniejących),
• ścieżka eskalacji (kiedy zdarzenie jest „błędem użytkownika”, a kiedy incydentem bezpieczeństwa).

Audyt powinien obejmować nie tylko konfigurację reguł, ale też dowody działania: czy alerty są przeglądane, czy wyjątki mają uzasadnienie i termin ważności, czy istnieje rejestr zmian polityk i ich efektów.

2) Metryki, które mają sens przy promptach i plikach

W GenAI klasyczne metryki DLP trzeba uzupełnić o perspektywę „tekstową” (prompty) oraz „interaktywną” (kopiowanie, wklejanie, streszczenia). Warto mierzyć:

• pokrycie: jaki odsetek kanałów użycia GenAI jest objęty kontrolą (w tym przeglądarka, aplikacje, integracje z chmurą i urządzenia końcowe),
• jakość detekcji: poziom false positives (niepotrzebne blokady) i false negatives (przepuszczone wycieki),
• skuteczność egzekwowania: udział zdarzeń zrealizowanych jako „blokada” vs „ostrzeżenie” vs „audyt”,
• czas reakcji: od wykrycia do analizy, oraz od analizy do korekty reguły lub działań z użytkownikiem,
• trend ryzyka: czy liczba incydentów o wysokiej wrażliwości spada, a nie tylko rośnie liczba alertów,
• wpływ na biznes: liczba i czas wyjątków, skargi użytkowników, porzucone zadania, obejścia (np. przeniesienie do prywatnych kont lub alternatywnych kanałów).

Kluczowe jest rozdzielenie „szumu” od realnego ryzyka: wysoka liczba alertów może oznaczać zarówno skuteczną widoczność, jak i źle dobrane progi lub zbyt ogólne wzorce.

3) Pętla jakości: triage alertów i redukcja szumu

Operacyjnie DLP dla GenAI wymaga szybkiego triage’u: najpierw klasyfikujesz zdarzenia według wrażliwości danych, kontekstu (kanał, aplikacja, domena), oraz intencji (próba obejścia vs pomyłka). Dobrą praktyką jest regularne przeglądanie reprezentatywnej próbki zdarzeń, aby:

• wyłapywać nowe wzorce promptów i treści, które wymykają się detekcji,
• korygować reguły generujące masowe false positives,
• ustalać, które przypadki lepiej obsłużyć edukacją i komunikatem, a które blokadą,
• zamykać luki procesowe (np. brak etykiet, niejednolite nazewnictwo, błędne klasyfikacje).

Najczęstszy błąd: dążenie do „zero alertów”. Celem jest kontrolowany poziom sygnału, który pozwala wykrywać realne nadużycia i uczy organizację, jak zmienia się ryzyko.

4) Testy kontrolowane: sprawdzanie, czy polityki działają w realnym użyciu

W GenAI testy muszą symulować zachowania użytkowników, a nie tylko „czy reguła się odpala”. W praktyce warto wykonywać cykliczne testy kontrolowane, które sprawdzają:

• czy dane wrażliwe są wykrywane w typowych formach (fragmenty, streszczenia, parafrazy),
• czy blokady i ostrzeżenia pojawiają się w odpowiednim momencie (przed wysyłką, przed uploadem),
• czy wyjątki i allowlisty nie tworzą niezamierzonych „dróg na skróty”,
• czy zdarzenia są poprawnie rejestrowane i możliwe do wyjaśnienia po fakcie (audytowalność).

Testy nie muszą być rozbudowane; ważniejsze jest, by były powtarzalne i prowadziły do konkretnych poprawek konfiguracji oraz materiałów komunikacyjnych dla użytkowników.

5) Ciągłe doskonalenie: zmiany w politykach, wyjątki i edukacja

DLP dla GenAI jest wrażliwe na „rozjechanie się” praktyki i polityki: użytkownicy znajdują obejścia, zespoły wdrażają nowe narzędzia, a modele i interfejsy się zmieniają. Dlatego program powinien mieć rytm doskonalenia:

• przegląd wyjątków (z terminem ważności, uzasadnieniem i właścicielem),
• kalibracja progów w oparciu o trendy i analizy false positives/negatives,
• aktualizacja komunikatów w ostrzeżeniach/blokadach tak, aby tłumaczyły „dlaczego” i „co zrobić zamiast”,
• krótkie interwencje edukacyjne oparte o realne przypadki (bez piętnowania),
• przegląd pokrycia po każdej istotnej zmianie narzędzi lub architektury.

Warto też rozróżniać działania „twarde” (blokady) od „miękkich” (ostrzeżenia, uzasadnienie biznesowe, wskazanie bezpiecznej ścieżki). W GenAI często skuteczniejsze jest prowadzenie użytkownika do właściwego kanału niż bezwzględne odcinanie.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

6) Kryteria dojrzałości: kiedy można powiedzieć, że DLP dla GenAI działa

Program jest operacyjnie skuteczny, gdy spełnia kilka prostych warunków:

• alerty są mierzalne, priorytetyzowane i mają właściciela,
• organizacja potrafi wskazać, które kanały są kontrolowane i gdzie są „dziury”,
• jakość detekcji jest regularnie weryfikowana testami, a wyniki wpływają na polityki,
• wyjątki nie żyją wiecznie i nie stają się cichym mechanizmem omijania kontroli,
• ryzyko wycieku najwrażliwszych danych spada, a użytkownicy mają jasną, bezpieczną alternatywę pracy z GenAI.

Copilot w Excelu 2026: 9 zadań, które dalej robi źle (i jak to obejść formułami) 27 marca 2026

SPSS czy RStudio do analiz ankiet NPS/CSAT? Porównanie workflow i raportowania 25 marca 2026