Wprowadzenie
Sztuczna inteligencja bardzo szybko przestała być ciekawostką. W polskich organizacjach jest już realnym narzędziem pracy: według raportu UODO z 28 stycznia 2026 r. 17% badanych organizacji już korzysta z AI, a wiele kolejnych jest na etapie testów lub przygotowań do wdrożenia. To oznacza, że pytanie nie brzmi już „czy używać AI?”, ale „jak robić to bezpiecznie i zgodnie z prawem?”.
Najczęstszy błąd polega na tym, że firmy koncentrują się na jakości odpowiedzi modelu, a nie na bezpieczeństwie całego procesu. Tymczasem europejskie i branżowe wytyczne są zgodne: AI może zwiększać produktywność, ale jednocześnie otwiera nowe wektory ataku, nowe ryzyka prywatności i nowe obowiązki organizacyjne. ENISA zwraca uwagę, że AI ma „podwójną rolę” w cyberbezpieczeństwie – może wspierać ochronę, ale może też tworzyć nowe możliwości manipulacji i nadużyć. Z kolei NIST, EDPB i OWASP podkreślają, że generatywne AI wymaga osobnego podejścia do zarządzania ryzykiem, a nie dopięcia go „na końcu projektu”.
Spis treści
Największe ryzyko nie leży w samym modelu, tylko w przepływie danych
W praktyce firmowej najgroźniejsze nie jest to, że model „się pomyli”. Najgroźniejsze jest to, że pracownik wklei do narzędzia AI dane, których organizacja nie powinna wypuszczać poza swój kontrolowany ekosystem: dane klientów, dokumentację kadrową, fragmenty umów, kod źródłowy, klucze API, opisy incydentów bezpieczeństwa, dane finansowe albo informacje objęte tajemnicą przedsiębiorstwa. EDPB podkreśla, że ryzyka prywatności pojawiają się różnie w zależności od modelu usługi – SaaS, rozwiązania „off-the-shelf”, wdrożenia własnego czy systemów agentowych – dlatego trzeba rozumieć dokładny przepływ danych w całym cyklu życia AI.
To bardzo ważne, bo „wysłanie promptu” nie jest jednorazowym aktem znikającym w próżni. Dane mogą pojawić się w logach, systemach monitoringu, warstwach bezpieczeństwa, mechanizmach feedbacku, integracjach z innymi aplikacjami i usługami zewnętrznymi. EDPB wskazuje wprost, że logi z monitoringu mogą przechowywać dane osobowe z interakcji użytkownika, że dane bywają używane do dalszych aktualizacji systemu, a integracje z API, pluginami, chmurą czy bazami wiedzy dodają kolejne warstwy przepływu danych, które trzeba zmapować i zabezpieczyć.
Co naprawdę może pójść nie tak?
Pierwszy poziom ryzyka to naruszenie prywatności i ochrony danych osobowych. Jeżeli pracownik wklei do modelu dane klienta, dane pracownika albo dokument medyczny, problemem nie jest wyłącznie sam transfer. Problemem jest też brak pełnej kontroli nad tym, jak dane będą użyte, jak długo będą przechowywane, komu mogą zostać ujawnione i czy nie pojawią się później w odpowiedziach lub metadanych. EDPB wskazuje m.in. ryzyko niezamierzonego ujawnienia informacji w odpowiedziach, ryzyko reidentyfikacji oraz ryzyko ataków typu membership inference i attribute inference.
Drugi poziom ryzyka to wyciek informacji poufnych biznesowo. W języku firmowym „dane wrażliwe” to nie tylko szczególne kategorie danych osobowych w rozumieniu RODO, ale też wszystko to, co daje przewagę konkurencyjną albo tworzy ekspozycję prawną: roadmapy produktowe, oferty handlowe, marże, warunki kontraktów, architektura systemów, logi bezpieczeństwa, dane o lukach czy kod źródłowy. OWASP wymienia wśród kluczowych zagrożeń dla aplikacji LLM m.in. ujawnienie informacji wrażliwych, podatności łańcucha dostaw, niebezpieczne użycie pluginów oraz kradzież modeli. To pokazuje, że problem nie ogranicza się do „czatu”, tylko obejmuje cały ekosystem AI.
Trzeci poziom ryzyka to atak na sam proces korzystania z AI. Jeżeli model ma dostęp do wewnętrznych danych, narzędzi lub akcji, rośnie znaczenie prompt injection, jailbreaking i niebezpiecznej obsługi odpowiedzi modelu. OWASP uznaje prompt injection za najważniejszą kategorię ryzyka dla LLM, a EDPB zaznacza, że obecnie nie istnieją niezawodne, stuprocentowo skuteczne metody obrony przed prompt injection i jailbreakingiem. To oznacza, że firma nie może opierać bezpieczeństwa wyłącznie na „dobrych intencjach modelu” albo prostym komunikacie systemowym.
Czwarty poziom ryzyka to nadmierne zaufanie do odpowiedzi AI. Nawet poprawnie zabezpieczony model może halucynować, upraszczać albo pomijać kontekst. Komisja Europejska w materiałach dotyczących AI literacy wskazuje wprost, że nawet przy tak prostych zastosowaniach jak pisanie tekstów marketingowych pracownicy powinni znać ryzyka, na przykład halucynacje. OWASP nazywa to overreliance – zbytnią zależnością od modelu bez krytycznej weryfikacji wyniku. W firmie taki błąd może skończyć się nie tylko błędnym mailem, ale złą decyzją zarządczą, wadliwą analizą prawną albo niebezpieczną zmianą w kodzie.
Najgroźniejszy scenariusz: pracownik „tylko na chwilę” wkleja dane do publicznego AI
Wiele incydentów nie zaczyna się od złośliwego działania, tylko od pośpiechu. Ktoś chce szybciej streścić umowę, poprawić ofertę, przeanalizować reklamację klienta albo wygenerować odpowiedź do kandydata w procesie rekrutacji. Wkleja więc pełny dokument do publicznego narzędzia AI. Z perspektywy bezpieczeństwa to może oznaczać jednocześnie: ujawnienie danych osobowych zewnętrznemu dostawcy, utrwalenie ich w logach, ekspozycję na dodatkowe podmioty przetwarzające, ryzyko transferu poza EOG, a przy integracjach także dalsze przekazanie do usług trzecich. EDPB zaleca tu m.in. weryfikację lokalizacji usług zewnętrznych, ocenę transferów, stosowanie odpowiednich zabezpieczeń kontraktowych oraz ograniczanie retencji danych.
Dlatego najważniejsza zasada brzmi: publiczne lub niezatwierdzone narzędzie AI nie może być domyślnym miejscem pracy na danych wrażliwych. To nie jest bezpieczny schowek, roboczy notatnik ani zamiennik wewnętrznego systemu obiegu dokumentów. Bez wcześniejszej oceny ryzyka, właściwej konfiguracji i umowy z dostawcą firma działa po prostu na ślepo.
Jak korzystać z AI bezpiecznie?
1. Rozdziel narzędzia „publiczne”, „firmowo zatwierdzone” i „dopuszczone do danych wrażliwych”.
Nie każde AI w firmie musi mieć ten sam poziom uprawnień. Narzędzie do generowania pomysłów marketingowych to co innego niż system analizujący dokumenty klientów. EDPB wskazuje, że ryzyko zależy od modelu usługi, integracji i danych, więc polityka dostępu powinna być warstwowa.
2. Zdefiniuj listę danych, których nie wolno wklejać do AI bez wyjątku.
Na takiej liście powinny znaleźć się m.in. dane zdrowotne, kadrowe, dane finansowe, pełne dane klientów, tajemnice przedsiębiorstwa, klucze, hasła, tokeny, nieopublikowany kod, raporty z incydentów i niejawne fragmenty umów. EDPB zaleca ograniczanie zbierania danych do niezbędnego minimum oraz anonimizację i preprocessing wejścia przed przekazaniem go do systemu.
3. Minimalizuj dane zanim trafią do modelu.
Najbezpieczniejszy prompt to nie „pełny dokument”, ale wersja zanonimizowana, z pseudonimizacją identyfikatorów i usunięciem wszystkiego, co nie jest konieczne do wykonania zadania. To nie jest kosmetyka, tylko podstawowy środek ochrony. EDPB wprost rekomenduje anonimizację, pseudonimizację i ograniczanie zakresu danych w wejściu.
4. Sprawdź dostawcę tak samo poważnie, jak każdego innego procesora.
Trzeba wiedzieć, gdzie dane są przetwarzane, jak długo są przechowywane, jakie są zasady logowania i retencji, czy występują podprocesorzy, jakie są zabezpieczenia API, jakie są mechanizmy kontroli dostępu i jakie warunki obowiązują przy transferach międzynarodowych. EDPB zaleca m.in. szyfrowanie danych w transmisji i spoczynku, adekwatną kontrolę dostępu, RBAC, MFA, due diligence dostawcy, klauzule umowne i – przy transferach – ocenę wpływu transferu.
5. Załóż, że prompt injection kiedyś się wydarzy.
Jeżeli model ma połączenie z bazą wiedzy, pocztą, CRM-em, plikami lub narzędziami wykonującymi akcje, architektura musi zakładać separację uprawnień, walidację wejścia i wyjścia, monitorowanie oraz zasadę najmniejszych uprawnień. Nie wolno zakładać, że instrukcja systemowa „wystarczy”. OWASP i EDPB są tu jednoznaczne: prompt injection i niebezpieczna obsługa odpowiedzi należą do kluczowych, praktycznych ryzyk.
6. Wprowadź obowiązkową weryfikację człowieka dla wyników o znaczeniu biznesowym, prawnym i bezpieczeństwa.
AI może przyspieszać pracę, ale nie powinno samodzielnie podejmować decyzji, których skutki ponosi firma lub klient. OWASP ostrzega przed overreliance, a unijne podejście do AI akcentuje przejrzystość i nadzór człowieka.
7. Traktuj szkolenie pracowników jako element compliance, nie benefit.
AI literacy nie jest już miękkim dodatkiem. Zgodnie z AI Act obowiązek podejmowania działań na rzecz odpowiedniego poziomu kompetencji AI wszedł w życie 2 lutego 2025 r., a Komisja Europejska wskazuje, że dotyczy to także organizacji używających narzędzi pokroju ChatGPT do codziennych zadań. Nadzór i egzekwowanie tych obowiązków ruszają od sierpnia 2026 r.
Bezpieczne AI to nie zakaz, tylko kontrola
Firmy, które próbują „zakazać AI”, zwykle przegrywają z rzeczywistością. Powstaje wtedy shadow AI: pracownicy i tak używają przypadkowych narzędzi, tylko poza wiedzą działu IT, bezpieczeństwa i compliance. Znacznie lepsza strategia polega na tym, by udostępnić zatwierdzone rozwiązania, jasno opisać zasady korzystania, wdrożyć filtry i kontrole, a następnie szkolić ludzi na konkretnych scenariuszach. To zresztą jest zgodne z podejściem NIST do zarządzania ryzykiem AI oraz z europejskim trendem wzmacniania odpowiedzialnego wdrażania AI w organizacjach.
Podsumowanie
Największe zagrożenie związane z AI w firmie nie polega na tym, że model napisze słabszy tekst. Polega na tym, że organizacja potraktuje model jak neutralne narzędzie biurowe i zacznie zasilać go danymi, nad którymi traci realną kontrolę. Gdy do AI trafiają dane osobowe, tajemnice przedsiębiorstwa albo informacje o architekturze i bezpieczeństwie, ryzyko przestaje być teoretyczne. Staje się problemem prawnym, operacyjnym i reputacyjnym. Bezpieczne korzystanie z AI zaczyna się więc nie od wyboru „najlepszego modelu”, ale od odpowiedzi na trzy pytania: jakie dane wolno wysyłać, do jakiego narzędzia, na jakich warunkach. Dopiero wtedy AI staje się wsparciem biznesu, a nie nowym źródłem incydentów.
Zapraszamy do kontaktu z naszym zespołem, który jest gotowy na rozwiązanie Twoich problemów związanych z infrastrukturą informatyczną.
