W wielu organizacjach rozmowa o bezpiecznym korzystaniu z sztucznej inteligencji zatrzymuje się na jednym pytaniu: czy mamy politykę AI. To ważny element, ale zdecydowanie niewystarczający. Z perspektywy compliance, ochrony danych i odpowiedzialnego zarządzania technologią, spisanie dokumentu jest dopiero początkiem drogi, a nie jej końcem.
W cyberbezpieczeństwie od lat mówi się o trzech filarach: procesach, narzędziach i ludziach. Dokładnie tak samo należy podejść do dużych modeli językowych w organizacji. Pierwszy filar to procesy, czyli polityka AI i powiązane procedury. Drugi filar to narzędzia, między innymi systemy DLP oraz rozwiązania typu CASB lub SSE, które realnie egzekwują zasady zapisane w dokumentach. Trzeci filar to ludzie, czyli szkolenia i budowanie świadomości użytkowników. Jeśli brakuje choć jednego z tych elementów, ryzyko wycieku danych, naruszeń RODO czy ujawnienia tajemnicy przedsiębiorstwa pozostaje bardzo wysokie, niezależnie od jakości samej polityki.
1. Procesy: polityka AI jako punkt wyjścia, a nie docelowe rozwiązanie
Polityka AI jest potrzebna z kilku powodów. Przede wszystkim wyznacza ramy korzystania z modeli językowych. Określa, jakie kategorie danych mogą być wprowadzane do narzędzi AI, w jakich sytuacjach wolno używać rozwiązań publicznych, a kiedy konieczne jest korzystanie wyłącznie z narzędzi firmowych albo działających w środowisku kontrolowanym. Pozwala także rozdzielić odpowiedzialności pomiędzy zarząd, IT, bezpieczeństwo, biznes i compliance. Wskazuje, kto decyduje o wdrażaniu nowych narzędzi, kto nadzoruje ich zgodność z regulacjami oraz kto odpowiada za reakcję na incydenty.
Problem pojawia się wtedy, gdy polityka AI pozostaje wyłącznie dokumentem formalnym. W praktyce oznacza to, że pracownicy nadal wklejają treści umów, opisy procesów czy dane klientów do publicznych chatbotów, działy biznesowe testują kolejne serwisy typu AI as a Service bez wiedzy działu bezpieczeństwa, a zarząd ma nieuzasadnione poczucie, że temat jest zamknięty, bo dokument istnieje.
Dlatego polityka AI powinna od początku być projektowana tak, aby dało się ją technicznie wyegzekwować. Musi jasno odnosić się do narzędzi, które wspierają ograniczenia opisane w dokumencie. Na tym etapie pojawia się drugi filar, czyli systemy ochrony danych.
2. Narzędzia: DLP jako realne egzekwowanie zasad
Aby zasady przyjęte w polityce AI przełożyły się na praktykę, organizacja potrzebuje narzędzi, które potrafią zauważyć, rozpoznać i zareagować. Po pierwsze, takich, które widzą, kiedy i w jaki sposób pracownicy korzystają z narzędzi AI, zarówno firmowych, jak i publicznych. Po drugie, takich, które potrafią wykryć, czy w kierunku tych narzędzi nie wyciekają dane osobowe, informacje poufne czy dokumenty chronione. I po trzecie, takich, które potrafią zareagować zgodnie z polityką, na przykład zablokować wysłanie danych, ostrzec użytkownika, przynajmniej zalogować incydent.
Systemy DLP (Data Leak Prevention) oraz rozwiązania typu CASB (Cloud Access Security Broker) tutaj rolę filtra i strażnika. Producenci opisują ich możliwości hasłami w rodzaju Control Shadow AI, Stop Data Exfiltration via AI. Za tymi marketingowymi sloganami stoją bardzo konkretne scenariusze działań.
2.1. Control Shadow AI, czyli widoczność i kontrola nad nieautoryzowanymi narzędziami
Shadow AI oznacza korzystanie przez pracowników z narzędzi AI, które nie zostały formalnie zatwierdzone przez organizację. Mogą to być darmowe chatboty, wtyczki przeglądarki, generatory treści, usługi piszące kod programistyczny lub narzędzia, które automatycznie analizują dane tekstowe.
Dzięki systemom DLP oraz CASB można zidentyfikować, z jakich usług AI faktycznie korzystają użytkownicy. Widać, czy pojawia się ruch do nowych serwisów, czy przesyłane są do nich pliki, fragmenty tekstu lub zrzuty ekranu. Na tej podstawie można klasyfikować poszczególne usługi jako dopuszczone, warunkowo dopuszczone lub zakazane.
Dobrym przykładem jest sytuacja, w której dział marketingu zaczyna korzystać z nowego serwisu generującego treści sprzedażowe na podstawie informacji o klientach. Bez rozwiązań CASB taka aktywność mogłaby pozostać niezauważona. Przy odpowiedniej konfiguracji bezpieczeństwo widzi pojawienie się nowego narzędzia, może tymczasowo ograniczyć do niego dostęp, uruchomić ocenę ryzyka i analizę zgodności, a dopiero po jej zakończeniu podjąć decyzję, czy i w jakim zakresie serwis może być używany.
2.2. Stop Data Exfiltration via AI, czyli zatrzymanie wycieku danych do LLM
Drugi kluczowy scenariusz dotyczy ochrony przed wynoszeniem danych za pomocą LLM. System DLP działa tu jak strażnik, który analizuje treści wklejane do przeglądarki lub wysyłane w formularzach na stronach ChatGPT, Copilota albo innych narzędzi. Rozpoznaje wzorce charakterystyczne dla danych osobowych, takie jak numery PESEL, numery dokumentów, numery rachunków bankowych, a także dane kart płatniczych czy charakterystyczne fragmenty umów i klauzul poufności. Jeśli wykryje te treści, reaguje zgodnie z polityką.
Przykład z codziennej pracy wygląda następująco. Pracownik działu obsługi klienta zaznacza w systemie CRM listę klientów wraz z opisem zgłoszeń, a następnie próbuje wkleić ten fragment do ChatGPT, aby szybko przygotować odpowiedź. Reguła DLP zainstalowana na stacji roboczej rozpoznaje w schowku dane osobowe oraz fakt, że celem wklejenia jest strona publicznego chatbota. System blokuje wysłanie danych, wyświetla komunikat informujący o zakazie umieszczania danych klientów w narzędziach publicznych i rejestruje zdarzenie do dalszej analizy. W efekcie zakaz z polityki AI zostaje realnie wyegzekwowany.
3. Ludzie: szkolenia jako ostatnia, ale krytyczna linia obrony
Trzeci filar obejmuje użytkowników. Nawet najlepiej zaprojektowana polityka i najbardziej zaawansowany system DLP nie wystarczą, jeśli pracownicy nie rozumieją, dlaczego nie powinni wklejać treści umów do publicznych chatbotów, nie potrafią ocenić, kiedy użycie LLM jest neutralne, a kiedy rodzi poważne ryzyko, i traktują blokady jako przeszkodę, a nie element ochrony wspólnego interesu.
Dlatego konieczny jest przemyślany program szkoleń. Dla pracowników biznesowych warto przygotować materiały oparte na prostych, realistycznych przykładach. Dla menedżerów przydatne są szkolenia pokazujące powiązania między wykorzystaniem AI, przepisami o ochronie danych, tajemnicą przedsiębiorstwa oraz odpowiedzialnością zarządu. Natomiast dla działów IT i bezpieczeństwa kluczowa jest wiedza o tym, jak konkretnie konfigurować reguły DLP, jak korzystać ze scenariuszy typu Control Shadow AI, Stop Data Exfiltration via AI oraz jak budować spójny ekosystem rozwiązań.
Takie działania nie mogą być jednorazowe. Narzędzia AI szybko się zmieniają, pojawiają się nowe funkcje, nowe integracje i nowe modele. Program edukacyjny powinien być procesem ciągłym, aktualizowanym wraz z rozwojem technologii i wytycznych regulacyjnych.
Trzy filary bezpiecznego LLM w organizacji
Bezpieczne korzystanie z dużych modeli językowych w firmie wymaga równoczesnego zadbania o procesy, narzędzia i ludzi. Procesy obejmują politykę AI i procedury, które jasno określają zasady korzystania z LLM. Narzędzia, w tym systemy DLP oraz CASB zapewniają kontrolę nad Shadow AI, zatrzymują wyciek danych i pozwalają korzystać z generatywnej AI w sposób przewidywalny i zgodny z regulacjami. Ludzie, czyli świadomi użytkownicy, stanowią ostatnią linię obrony i jednocześnie warunek konieczny, aby techniczne i formalne zabezpieczenia działały w praktyce.
Sama polityka AI, nawet bardzo dopracowana, nie zatrzyma wklejania danych klientów do publicznego chatbota, nie wykryje nowego nieautoryzowanego narzędzia ani nie pokaże, czy model naprawdę korzysta tylko z danych, które wolno mu przetwarzać. Dopiero połączenie trzech filarów pozwala zamienić LLM z potencjalnego źródła problemów w bezpieczne i kontrolowane narzędzie rozwoju biznesu.
