Dlaczego firmy sięgają po ChatGPT i gdzie zaczyna się ryzyko
Najczęstsze zastosowania ChatGPT w firmie
ChatGPT wszedł do firm po cichu, najczęściej przez pojedynczych pracowników szukających szybszego sposobu na napisanie maila, poprawienie treści oferty czy przetłumaczenie dokumentu. Z czasem narzędzie zaczyna być wykorzystywane w dziesiątkach procesów: od prostych podpowiedzi po elementy automatyzacji.
Najbardziej typowe scenariusze w organizacjach to:
tworzenie i redagowanie tekstów (maile, oferty, opisy produktów, raporty, streszczenia dokumentów);
wsparcie w analizie tekstu (wyciąganie kluczowych tez, generowanie list z długich dokumentów, porównywanie zapisów umów);
pomoc programistyczna (podpowiedzi w kodzie, refaktoryzacja, generowanie testów jednostkowych);
tworzenie materiałów szkoleniowych i prezentacji (agendy, skrypty szkoleń, opisy slajdów);
research i porządkowanie wiedzy (wstępne rozeznanie tematu, struktury do dalszych analiz).
Na początku wszystko wygląda niewinnie: pojedynczy użytkownicy kopiują fragmenty tekstów do okna czatu i korzystają z powstałych podpowiedzi. Z perspektywy bezpieczeństwa organizacji kluczowe jest jednak nie to, co ChatGPT generuje, ale jakie dane otrzymuje w promptach i jak są one później traktowane.
Prywatnie kontra służbowo – inny poziom odpowiedzialności
W użyciu prywatnym pracownik ryzykuje co najwyżej własnym czasem lub jakością swojego tekstu. W firmie stawka rośnie: dochodzi odpowiedzialność za dane klientów, reputację marki, zgodność z regulacjami sektorowymi oraz konsekwencje finansowe błędnych decyzji opartych na generowanych treściach.
Różnice są szczególnie widoczne w trzech obszarach:
skala oddziaływania – błędna odpowiedź w prywatnym mailu to jedno, błędna interpretacja przepisów podatkowych zastosowana do setek klientów to coś zupełnie innego;
rodzaj danych – prywatnie rzadko operuje się dużymi zestawami danych osobowych czy poufnymi umowami; w firmie to codzienność;
regulacje i audyty – w biznesie w grę wchodzą RODO, przepisy branżowe, wymogi regulatorów, polityki bezpieczeństwa, które zwykle nie istnieją w życiu prywatnym.
Dlatego to, co jest „wystarczająco bezpieczne” jako prywatne użycie ChatGPT, w firmie może być poważnym naruszeniem polityki bezpieczeństwa lub prawa. Punkt wyjścia musi więc uwzględniać nie tylko użyteczność narzędzia, ale też odpowiedzialność za dane oraz procesy, których dotyka.
Najczęstsze obawy zarządów i działów IT
Gdy zarząd i dział IT zaczynają interesować się ChatGPT, zderzają się zazwyczaj z trzema grupami obaw:
ryzyko wycieku danych – pracownicy mogą nieświadomie wklejać do czatu dane klientów, fragmenty kodu czy dokumenty wewnętrzne, które trafiają poza organizację;
jakość i prawdziwość treści – generatywna AI potrafi tworzyć treści przekonujące, ale niekoniecznie poprawne („halucynacje” modeli), co może prowadzić do poważnych błędów biznesowych lub prawnych;
brak kontroli i śladu audytowego – organizacja nie wie, kto, kiedy i do jakich celów używa narzędzia, a w razie incydentu trudno cokolwiek odtworzyć.
W tle pojawiają się także obawy wizerunkowe: ryzyko upublicznienia poufnych danych w wyniku błędnego użycia, czy też generowania treści niezgodnych z wartościami firmy (np. uprzedzonych, dyskryminujących, naruszających prawa autorskie). To wszystko wymaga innego podejścia niż proste „pozwolić vs zabronić”.
Dwa zespoły, dwa podejścia – prosty kontrast
Dobry obraz różnicy między „żywiołowym” a ustrukturyzowanym korzystaniem z ChatGPT daje porównanie dwóch zespołów pracujących w podobnych warunkach.
W pierwszym zespole każdy używa ChatGPT, jak chce. Dane klientów wklejane są do czatu, żeby szybciej napisać odpowiedź, fragmenty kodu wrzuca się do modelu w celu debugowania, a umowy wysyła bez zastanowienia, by otrzymać streszczenie. Zespół jest zadowolony z produktywności, ale dział IT nie ma żadnego wglądu w to, co w praktyce „wypływa” na zewnątrz.
Drugi zespół korzysta z ChatGPT z prostym zbiorem zasad: zakaz wklejania danych osobowych i identyfikujących klientów, zakaz wrzucania pełnych dokumentów umów, obowiązek anonimizacji nazw projektów i firm, konkretna instrukcja, jak krok po kroku maskować dane. Narzędzie jest używane intensywnie, ale według ustalonej „higieny bezpieczeństwa”.
Różnica nie polega na całkowitym zakazie czy nakazie, ale na jakości reguł i świadomości użytkowników. Oba zespoły korzystają z tej samej technologii; inny jest poziom ryzyka, śladu audytowego i gotowości do obrony decyzji przed audytorem lub regulatorem. To dokładnie ten obszar, gdzie dział IT i bezpieczeństwa powinny wejść w rolę partnera, a nie wyłącznie blokującego strażnika.
Modele korzystania z ChatGPT w organizacji – od „dzikiego zachodu” do pełnej kontroli
Trzy podstawowe podejścia do wdrożenia
Firmy zwykle lądują w jednym z trzech modeli korzystania z ChatGPT: pełna swoboda, podejście hybrydowe albo centralnie zarządzane wdrożenie. Każdy wariant ma swoich zwolenników i przeciwników.
1. Pełna swoboda – organizacja nie definiuje formalnych zasad. Pracownicy sami zakładają konta, używają wersji webowej, czasem z własnych urządzeń. Dział IT ma niewielką lub żadną kontrolę nad tym, co się dzieje.
2. Podejście hybrydowe – firma akceptuje korzystanie z ChatGPT, ale wyznacza jasne ramy. Istnieje prosty regulamin korzystania, wybrane zespoły otrzymują konta firmowe (np. w ChatGPT Team), dział IT wprowadza pierwsze mechanizmy kontroli, ale nie jest to jeszcze pełnoprawne, scentralizowane wdrożenie.
3. Centralnie zarządzane wdrożenie – organizacja korzysta z ChatGPT w modelu Team/Enterprise lub przez API, integruje narzędzie ze swoim SSO, zarządza dostępami i politykami, opiera się na oficjalnych umowach z dostawcą. Użytkownicy działają w wydzielonym, firmowym środowisku, a spontaniczne użycie wersji „publicznej” jest ograniczane.
Plusy i minusy – szybkość kontra kontrola
Porównanie modeli dobrze widać, gdy zestawi się podstawowe kryteria: czas wdrożenia, kontrolę nad danymi, koszty i realne bezpieczeństwo.
Model
Szybkość uruchomienia
Kontrola nad danymi
Bezpieczeństwo
Koszt początkowy
Pełna swoboda
Bardzo szybka
Niska
Niskie/nieznane
Niski (pozornie)
Hybrydowy
Średnia
Średnia
Średnie/dobre
Średni
Centralnie zarządzany
Wolniejsza
Wysoka
Wysokie
Wyższy
Model „pełna swoboda” kusi brakiem formalności. Pracownicy szybko wdrażają narzędzie do codziennych zadań, a organizacja korzysta na produktowości praktycznie bez inwestycji. Ceną jest jednak całkowity brak kontroli: trudno mówić o polityce bezpieczeństwa AI, gdy nie wiadomo, kto i do czego używa narzędzia, a każdy reguluje ustawienia prywatności po swojemu.
Podejście hybrydowe jest krokiem w stronę dojrzałości. Firma wyznacza zasady, daje część kont firmowych, jednocześnie nie blokując całkowicie innych form użycia, ale je ograniczając. Ten model bywa najbardziej realistyczny dla organizacji w fazie „eksploracji”, gdy chcą korzystać z potencjału AI, ale nie są jeszcze gotowe na pełne wdrożenie enterprise.
Wariant centralnie zarządzany to wybór organizacji, które podchodzą do ChatGPT jak do każdego innego krytycznego systemu IT: z umowami, SLA, SSO, monitoringiem i pełnym procesem zarządzania zmianą. Z zewnątrz wydaje się „ciężki”, ale jednocześnie najbardziej przewidywalny i najlepiej broni się w kontekście audytów, RODO i wymogów branżowych.
Dobór modelu do wielkości i branży
Mikrofirma działająca w sektorze kreatywnym, która nie przetwarza wrażliwych danych osobowych, ma zupełnie inną sytuację niż bank lub duża spółka medyczna. Dobór modelu korzystania z ChatGPT powinien bazować na kilku prostych kryteriach:
regulacje branżowe – finanse, medycyna, sektor publiczny, energetyka – tu próg wymagań jest zwykle najwyższy i naturalnie pcha w stronę modelu hybrydowego lub enterprise;
wielkość organizacji – im więcej pracowników, tym trudniej kontrolować „dziki zachód”; skala sama wymusza większą formalizację;
wrażliwość danych – firmy pracujące na dużych bazach danych klientów lub wrażliwych informacjach technicznych (R&D, projekty infrastrukturalne) szybko dostrzegają konieczność centralnej kontroli;
dojrzałość procesów IT – organizacje z już ułożonym IAM, SSO, procesem zarządzania dostępami i audytami mają niższy próg wejścia w wariant enterprise.
Mała agencja marketingowa może przez jakiś czas działać w lekkim modelu hybrydowym, z prostym regulaminem i kilkoma kontami team. Bank, który przeszedł kilka kontroli regulatora, praktycznie z góry skazany jest na podejście centralnie zarządzane, jeśli w ogóle ma korzystać z generatywnej AI w pracy z danymi klientów.
Kultura organizacyjna i kompetencje cyfrowe
Poza „twardymi” kryteriami jak RODO czy regulacje branżowe, duże znaczenie ma kultura organizacyjna i poziom umiejętności cyfrowych pracowników. W organizacjach, które promują eksperymentowanie, ale jednocześnie mają jasno zakorzenioną odpowiedzialność za bezpieczeństwo, model hybrydowy jest naturalnym etapem dojrzewania.
Tam, gdzie kultura jest mocno hierarchiczna, a decyzje technologiczne zapadają wyłącznie centralnie, pracownicy i tak będą korzystać z narzędzi AI „bokiem”, jeśli IT wszystko blokuje. Paradoksalnie pełny zakaz może więc zwiększyć ryzyko, bo zmusza ludzi do szukania nieautoryzowanych dróg dostępu.
Jednym z praktycznych wskaźników, który model ma sens, jest odpowiedź na pytanie: „Na ile u nas ludzie rzeczywiście czytają i stosują polityki bezpieczeństwa?”. Jeśli dotychczasowe procedury działały dobrze (np. w obszarze VPN, pracy zdalnej, haseł), to rozszerzenie ich o AI ma duże szanse powodzenia. Jeśli natomiast polityki funkcjonują tylko „na papierze”, sam wybór modelu wdrożenia ChatGPT niewiele zmieni bez równoległych działań edukacyjnych.
Dla firm, które łączą temat AI z szerszym podejściem do infrastruktury, naturalnym rozwinięciem są także kwestie sieciowe, takie jak segmentacja ruchu czy VPN; osoby odpowiedzialne za IT często szukają tu więcej o informatyka, żeby spójnie zbudować cały ekosystem bezpieczeństwa.
Co ChatGPT widzi i zapamiętuje – fakty, mity i konfiguracja prywatności
Jak przetwarzane są dane w ChatGPT
Podstawowe nieporozumienia wokół bezpiecznego korzystania z ChatGPT w firmie wynikają z braku zrozumienia, co się dzieje z danymi po stronie dostawcy. Z punktu widzenia bezpieczeństwa i RODO kluczowe są trzy poziomy:
kontekst rozmowy – model analizuje ciąg wiadomości, aby generować kolejne odpowiedzi; to właśnie dlatego poprzednie pytania i odpowiedzi wpływają na kolejne;
logi i metadane – platforma zapisuje informacje techniczne o użyciu (czas, IP, rodzaj przeglądarki, konta użytkownika, itp.), które są potrzebne do utrzymania usługi, rozliczeń i bezpieczeństwa;
wykorzystanie danych do trenowania modeli – w zależności od konfiguracji i rodzaju konta, przesyłane treści mogą (lub nie) być używane do dalszego poprawiania modeli.
Istotne jest także, że dostawca może przechowywać dane przez określony czas, nawet jeśli nie wykorzystuje ich do trenowania. To umożliwia np. przywracanie historii rozmów, analizę nadużyć czy generowanie statystyk użycia. Dział IT powinien znać te mechanizmy z dokumentacji dostawcy i przełożyć je na konkretne wytyczne w polityce bezpieczeństwa AI.
Wersja konsumencka, płatna, Team/Enterprise i API – kluczowe różnice
Bezpieczne korzystanie z ChatGPT w firmie w dużej mierze zależy od tego, z jakiego wariantu usługi korzystają pracownicy. Różnice między kontem „zwykłym” a firmowym są zarówno techniczne, jak i prawne.
Konto konsumenckie (bezpłatne/płatne „osobiste”):
użytkownik sam akceptuje regulamin i politykę prywatności;
Różne poziomy prywatności w zależności od typu konta
Konto konsumenckie (bezpłatne lub „osobiste” płatne) w kontekście firmy jest odpowiednikiem prywatnej skrzynki e‑mail wykorzystywanej do zadań służbowych. Da się, ale z punktu widzenia bezpieczeństwa i compliance to rozwiązanie tymczasowe, a nie docelowe.
użytkownik samodzielnie akceptuje regulamin, który z punktu widzenia firmy bywa niekorzystny (brak DPA, brak gwarancji lokalizacji danych);
ustawienia prywatności (np. czy dane rozmów mogą być użyte do trenowania modeli) konfiguruje każdy użytkownik osobno;
brak centralnego wglądu w historię użycia – dział IT nie widzi, jakie dane są wprowadzane i przez kogo;
mechanizmy logowania często nie są spięte z firmowym SSO, co zwiększa ryzyko słabych haseł lub wielokrotnego użycia tego samego hasła.
Konto firmowe w modelu Team/Enterprise przypomina służbową skrzynkę e‑mail: podlega regułom organizacji, integruje się z tożsamością korporacyjną i ma jasne ramy umowne.
możliwość centralnego wyłączenia użycia danych organizacji do trenowania modeli dostawcy;
rozbudowane logi i statystyki użycia – przydatne przy audytach i reagowaniu na incydenty;
zarządzanie użytkownikami przez SSO/IAM, z kontrolą dostępu i szybkim odcięciem konta po odejściu pracownika;
DPA i inne dokumenty prawne na poziomie organizacji, a nie pojedynczego użytkownika.
API to z kolei warstwa „silnika” bez standardowego interfejsu użytkownika. Najbliżej mu do mikrousługi uruchomionej w chmurze:
dane są przesyłane programistycznie, często z systemów produkcyjnych lub hurtowni danych;
to organizacja decyduje, jakie pola w ogóle trafiają do modelu (np. pseudonimizacja lub maskowanie danych przed wysłaniem);
w zależności od dostawcy można w pełni wyłączyć wykorzystanie danych z API do trenowania modeli;
ryzyko zależy bardziej od tego, jak API jest wpięte w architekturę niż od samego dostawcy.
Zestawiając te trzy warianty, organizacja zwykle przechodzi drogę: od kont konsumenckich „po cichu” używanych przez pracowników, przez formalne konta team, aż do wykorzystania API w krytycznych procesach. Im wyżej na tej skali, tym większa kontrola, ale też większe wymagania wobec działu IT i bezpieczeństwa.
Konfiguracja prywatności po stronie użytkownika i administratora
Warstwa techniczna prywatności w ChatGPT ma dwa poziomy: indywidualny (użytkownik) i organizacyjny (administrator). Oba trzeba ustawić spójnie, inaczej polityka bezpieczeństwa będzie dziurawa.
Na poziomie użytkownika indywidualnego istotne elementy to:
czy historia czatów jest zapisywana i dostępna z poziomu konta;
czy dane z rozmów mogą być wykorzystywane do trenowania i ulepszania modeli;
jakie dane użytkownik faktycznie wprowadza do narzędzia (to w praktyce najważniejszy „przełącznik”).
W modelu firmowym wiele z tych opcji może być nadpisanych przez administratora. To właśnie poziom organizacyjny powinien:
wymusić spójne ustawienia prywatności dla wszystkich kont (np. globalne wyłączenie trenowania na danych organizacji);
określić okres przechowywania historii i możliwości jej eksportu/anonimizacji;
zintegrować logowanie z SSO/MFA, aby minimalizować ryzyko przejęcia konta użytkownika;
zdefiniować, które funkcje są włączone (np. przesyłanie plików, dostęp do internetu, wtyczki).
Z punktu widzenia RODO i wewnętrznego compliance bardziej niebezpieczna jest rozbieżność: centralnie wyłączona nauka na danych, ale brak edukacji użytkowników, którzy wprowadzają do systemu dane, których w ogóle nie powinni tam umieszczać. Sama konfiguracja po stronie dostawcy nie zastąpi świadomości po stronie ludzi.
Mity dotyczące „pamięci” ChatGPT
W rozmowach o bezpieczeństwie AI często mieszają się pojęcia „pamięci” modelu, historii czatów oraz treningu. Z perspektywy działu IT przydaje się proste rozróżnienie trzech poziomów:
kontekst sesji – to, co model „pamięta” w ramach jednego czatu; po zamknięciu lub przekroczeniu limitu tokenów ten kontekst znika;
historia użytkownika – zapisywane w systemie dostawcy rozmowy, do których użytkownik może wrócić; mogą być technicznie przechowywane, nawet jeśli nie są wykorzystywane do trenowania;
wiedza modelu – dane wbudowane w parametry modelu po procesie trenowania, których nie da się „odwinąć” do poziomu pojedynczego klienta.
Konflikty z działem prawnym biorą się często z niezrozumienia, na którym z tych poziomów operuje dana funkcja. Przykładowo: wyłączenie „training on your content” nie usuwa historii z serwera od razu, lecz zabrania dostawcy używania jej do poprawy modeli. To istotna różnica w rozmowie o ryzyku wycieku czy obowiązkach informacyjnych wobec osób, których dane mogą się pojawić w treści promptów.
Źródło: Pexels | Autor: Thirdman
Dane wrażliwe, tajemnice firmy i RODO – gdzie jest czerwona linia
Trzy kategorie danych z perspektywy ChatGPT
Żeby realnie ocenić ryzyko, przydaje się prosta klasyfikacja danych wprowadzanych do ChatGPT na trzy grupy:
Dane publiczne lub przeznaczone do publikacji – treści marketingowe, instrukcje dla klientów, artykuły, dokumentacja produktowa już dostępna publicznie.
Dane wewnętrzne, ale niewrażliwe – ogólne procedury, szablony dokumentów, teksty e-maili, które nie zawierają danych osobowych ani tajemnicy przedsiębiorstwa.
Dane wrażliwe i poufne – dane osobowe (zwłaszcza szczególne kategorie), informacje objęte tajemnicą przedsiębiorstwa, dane regulowane (np. tajemnica bankowa, medyczna, adwokacka).
Pierwsza grupa generuje najmniejsze ryzyko – w wielu przypadkach można je bezpiecznie wprowadzać nawet w mniej „sztywnych” konfiguracjach, oczywiście z zachowaniem zdrowego rozsądku. Druga wymaga już przemyślanej konfiguracji narzędzia i wyraźnych zasad, ale bywa akceptowalna w modelu team/enterprise. Trzecia powinna mieć najbardziej restrykcyjne zasady, często włącznie z całkowitym zakazem wprowadzania takich danych do ChatGPT.
RODO a korzystanie z generatywnej AI
Z punktu widzenia RODO kluczowe jest jedno pytanie: czy wprowadzane do ChatGPT treści zawierają dane osobowe? Jeśli tak, organizacja staje się administratorem tych danych również w kontekście ich przekazania dostawcy usługi chmurowej.
Dla działu IT oznacza to m.in.:
konieczność sprawdzenia, czy dostawca jest procesorem w rozumieniu RODO i czy podpisuje umowy powierzenia (DPA);
weryfikację, gdzie fizycznie i prawnie są przetwarzane dane (lokalizacja centrów danych, transfer do państw trzecich, standardowe klauzule umowne);
dostosowanie okresów retencji danych do wewnętrznych polityk i wymogów regulacyjnych;
zapewnienie, że użytkownicy nie wprowadzają do narzędzia więcej danych osobowych, niż jest to absolutnie konieczne do realizacji celu.
Różnica między firmą pracującą wyłącznie na danych pseudonimizowanych a firmą kopiującą całe tabelki z danymi klientów do prompta jest fundamentalna. W pierwszym przypadku ChatGPT bywa traktowany jak każde inne narzędzie wspierające analitykę, w drugim – jak potencjalny punkt wycieku danych osobowych na zewnątrz.
Tajemnica przedsiębiorstwa i know-how
RODO to tylko część układanki. W wielu branżach równie istotne są przepisy o ochronie tajemnicy przedsiębiorstwa oraz zobowiązania kontraktowe wobec klientów i partnerów. Tutaj punkt odniesienia jest inny: czy ujawnienie tej informacji na zewnątrz zaszkodzi firmie lub naruszy umowę?
Typowe przykłady ryzykownych treści:
szczegółowe informacje o infrastrukturze IT (adresy IP, konfiguracje zabezpieczeń, diagramy sieci);
harmonogramy i budżety dużych projektów, zwłaszcza przed ogłoszeniem ich publicznie;
postanowienia umów, które objęte są klauzulą poufności.
Nawet jeśli dostawca deklaruje, że nie wykorzysta tych danych do trenowania modeli, sama ich obecność poza kontrolowanym środowiskiem może być problemem: od ryzyka wycieku po konieczność zgłaszania incydentu bezpieczeństwa do kontrahenta lub regulatora.
Minimalizacja danych: jak „odchudzić” prompt
Jednym z najpraktyczniejszych podejść jest systematyczna minimalizacja danych. Zamiast pytać ChatGPT:
„Przeanalizuj załączony plik z danymi wszystkich klientów z 2023 r. (PESEL, adres, kwota kredytu) i wskaż 10 najbardziej ryzykownych przypadków.”
lepiej przygotować:
zestawienie wstępnie zanonimizowane (identyfikator techniczny zamiast nazwiska/PESEL);
agregaty statystyczne (grupy wiekowe, przedziały kwot, regiony zamiast dokładnych adresów);
pytania ogólne o metodologię („Jakie cechy zazwyczaj biorą pod uwagę modele oceny ryzyka kredytowego?”) zamiast przesyłania surowych danych klientów.
Z punktu widzenia jakości odpowiedzi różnica bywa niewielka, a z perspektywy bezpieczeństwa – ogromna. Organizacja ma też wtedy większą swobodę w wyborze modelu usługi (Team vs API) i lokalizacji danych.
Rola działu IT, bezpieczeństwa i compliance – kto za co odpowiada
Podział ról: kto „posiada” ChatGPT w firmie
ChatGPT nie mieści się wygodnie w tradycyjnych szufladkach „system HR”, „CRM” czy „poczta”. Żeby uniknąć chaosu, przydaje się jasne przypisanie odpowiedzialności:
IT/infrastruktura – odpowiada za wybór i konfigurację techniczną rozwiązania, integrację z istniejącym środowiskiem (SSO, sieć, proxy, DLP), monitorowanie dostępności;
bezpieczeństwo (security) – definiuje wymagania bezpieczeństwa (kontrole dostępu, logowanie zdarzeń, klasyfikacja danych, integracja z SIEM), prowadzi analizę ryzyka i reaguje na incydenty;
compliance/prawo – weryfikuje zgodność z RODO, regulacjami branżowymi, umowami z klientami, prowadzi ocenę skutków dla ochrony danych (DPIA) tam, gdzie jest potrzebna;
business owner (np. COO, dyrektor transformacji cyfrowej) – definiuje zakres użycia ChatGPT w procesach biznesowych i sponsoruje inicjatywę.
W mniejszych organizacjach te role łączą się w kilku osobach, ale logika podziału zostaje: ktoś dba o stronę techniczną, ktoś o prawną, a ktoś o to, by narzędzie rzeczywiście wspierało biznes, a nie było kolejnym „gadżetem”.
Jak security i IT patrzą inaczej na to samo wdrożenie
Często widać różnicę perspektyw: IT chce „żeby działało”, a security „żeby było bezpieczne”. W przypadku ChatGPT te napięcia bywają mocniejsze niż przy klasycznych systemach, bo:
użytkownik może wprowadzić praktycznie dowolne dane – system nie ma z góry zdefiniowanych pól jak typowy formularz;
modele generatywne są trudniejsze do przewidzenia i przetestowania pod kątem „wszystkich możliwych scenariuszy”;
użytkownicy szybko widzą korzyści, a ryzyka są często niewidoczne, dopóki coś się nie wydarzy.
Rozwiązaniem jest wspólne zaprojektowanie modelu użycia: security określa, w jakiej klasie danych narzędzie może pracować (np. brak danych osobowych, brak tajemnicy przedsiębiorstwa), a IT dobiera i konfiguruje technologię, która te założenia umożliwia. Tam, gdzie w grę wchodzą dane bardziej wrażliwe, wchodzi konieczność użycia API, dodatkowej warstwy anonimizacji lub zbudowania własnego modelu w zamkniętym środowisku.
Rola compliance: od „hamulcowego” do partnera projektowego
W wielu organizacjach pierwszą reakcją działu compliance na ChatGPT jest blokada. To zrozumiałe w początkowej fazie, ale na dłuższą metę nieskuteczne: użytkownicy i tak znajdą drogę, zwykle poza kontrolą IT.
Bardziej efektywny model to:
wczesne włączenie compliance do dyskusji o celach wdrożenia (jakie procesy, jakie dane, jakie rynki);
wspólne wypracowanie mapy ryzyka: które przypadki użycia są „zielone”, które „żółte” (wymagają dodatkowych zabezpieczeń), które „czerwone” (zakaz);
przygotowanie prostych wytycznych dla użytkowników końcowych w języku biznesu, a nie prawniczym.
Taki model zmniejsza liczbę „szarych stref”, w których użytkownicy nie są pewni, co wolno, więc wolą nie pytać i działają na własną rękę.
Projektowanie bezpiecznego wdrożenia ChatGPT – krok po kroku z punktu widzenia IT
1. Inwentaryzacja nieformalnego użycia
2. Wybór modelu wdrożenia: ChatGPT w przeglądarce vs integracja API
Z perspektywy IT pierwsza decyzja brzmi: czy użytkownicy będą korzystać z ChatGPT przez interfejs webowy (np. ChatGPT Team/Enterprise), czy przez integracje API w istniejących systemach. Oba podejścia różnią się profilem ryzyka i nakładem pracy.
Proste porównanie:
Interfejs webowy (ChatGPT Team/Enterprise) Plusy: szybki start, brak prac developerskich, gotowe mechanizmy SSO, prosty onboarding użytkowników. Minusy: trudniejsza granularna kontrola kontekstu (użytkownik widzi „pełne” narzędzie), ograniczone możliwości automatyzacji i integracji z procesami biznesowymi.
API + własne aplikacje Plusy: precyzyjna kontrola danych trafiających do modelu (możliwość automatycznej pseudonimizacji), integracja z istniejącymi systemami, lepsza skalowalność i automatyzacja. Minusy: potrzeba zespołu developerskiego i testów, konieczność utrzymania kodu, wyższy próg wejścia.
W praktyce wiele organizacji łączy te podejścia: interfejs webowy do zastosowań ogólnych (tworzenie treści, tłumaczenia, pomoc w kodowaniu) oraz API do procesów z danymi wrażliwymi, gdzie można wdrożyć dodatkową warstwę anonimizacji i kontroli dostępu.
3. Definiowanie „złotych zasad” użycia na poziomie technicznym
Zanim pojawią się szczegółowe regulaminy, potrzebny jest prosty zestaw zasad, które można przełożyć na konfigurację. Typowy zestaw dla działu IT i security obejmuje:
jakiej klasy danych nie wolno wprowadzać (np. brak danych szczególnych kategorii, brak danych kart płatniczych, brak danych medycznych w planie podstawowym);
jakie lokalizacje użytkowników i systemów mają dostęp (np. wyłącznie z sieci firmowej lub za pośrednictwem VPN/proxy);
jakie funkcje są dostępne (np. blokada wgrywania plików w otwartym dostępie, a dopuszczenie tego wyłącznie w środowisku API z dodatkowymi filtrami);
jak długo przechowywane są logi i transkrypty, kto ma do nich wgląd i w jakim celu (audyt, rozliczanie kosztów, analiza adopcji).
Te zasady są punktem wyjścia do konfiguracji samego narzędzia (plan, region danych, retencja) oraz elementów otoczenia: proxy, CASB, DLP, SIEM. Im lepiej są nazwane i zrozumiałe, tym mniejsza szansa, że IT będzie je interpretować inaczej niż bezpieczeństwo czy compliance.
4. Integracja z tożsamością i dostępem (SSO, RBAC)
ChatGPT w trybie „anonimowego” konta to koszmar audytora. W firmie sens ma tylko model, w którym:
każdy użytkownik jest jednoznacznie identyfikowany (SSO, SAML, OpenID Connect);
obowiązują spójne z resztą ekosystemu polityki haseł i MFA;
role i uprawnienia są przypisane centralnie (RBAC, grupy z katalogu AD/Azure AD itp.).
Dwa typowe modele:
Jeden plan firmowy, różne role – użytkownicy biznesowi mają standardowe uprawnienia, zaawansowani (np. developerzy) mogą dodatkowo zarządzać zestawami danych, pluginami, integracjami.
Oddzielne „workspaces” dla działów – np. osobne środowisko dla zespołu developerów, gdzie dopuszczony jest kod, oraz bardziej restrykcyjne środowisko dla działu obsługi klienta.
Wybór zależy od skali i złożoności firmy. Jedna przestrzeń jest prostsza w utrzymaniu, ale trudniej w niej rozdzielić bardzo różne profile ryzyka. Osobne workspaces ułatwiają dopasowanie polityk, ale zwiększają złożoność administracji.
5. Ochrona perymetru: proxy, CASB i DLP
ChatGPT jako usługa w chmurze przecina się z dotychczasowymi rozwiązaniami bezpieczeństwa na poziomie sieci i ruchu wychodzącego. W praktyce najczęściej stosowane są trzy warstwy:
Proxy / firewall aplikacyjny – centralny punkt wyjścia do internetu, przez który przechodzi ruch do domen OpenAI / dostawcy. Pozwala:
ograniczyć dostęp tylko do zatwierdzonych planów/adresów;
blokować użycie nieautoryzowanych instancji (np. osobiste konta poza planem firmowym);
zbierać logi na potrzeby audytu i monitoringu anomalii.
CASB (Cloud Access Security Broker) – bardziej „świadoma” warstwa, która:
rozpoznaje konkretne działania w chmurze (upload pliku, czat, admin);
pozwala stosować polityki kontekstowe (np. „pracownicy działu X nie mogą wysyłać załączników do usług AI”);
integruje się z DLP i SIEM.
DLP (Data Loss Prevention) – filtr treści wychodzącej:
skanuje tekst i załączniki pod kątem wzorców danych wrażliwych (PESEL, karty, numery polis);
może blokować lub maskować treść zanim trafi do ChatGPT;
generuje alerty do zespołu security przy próbie naruszenia zasad.
Duże organizacje zwykle łączą te elementy. Mniejsze często zaczynają od proxy z logowaniem, a dopiero później dokładają CASB i DLP, gdy adopcja AI rośnie i trudniej „ręcznie” reagować na incydenty.
6. Konfiguracja środowiska API: warstwa pośrednia (middleware)
Przy pracy z API pojawia się dodatkowa możliwość: wdrożenie middleware, które pośredniczy między systemami firmy a modelem. Taka warstwa może:
anonimizować lub pseudonimizować dane (np. usuwać nazwiska, skracać adresy, zamieniać identyfikatory klientów na kody techniczne);
wymuszać politykę długości i formatu promptów (np. odrzucać zapytania zawierające długie ciągi cyfr podobne do PESEL/NR karty);
logować metadane (kto, kiedy, jaki typ zapytania, bez treści wrażliwych);
kategoryzować przypadki użycia (np. „obsługa klienta”, „analiza kodu”, „analiza dokumentu prawnego”) w celu różnicowania zasad bezpieczeństwa.
Prosty przykład z praktyki: w pewnym banku middleware usuwa z promptów ciągi znaków pasujące do wzorca numeru konta lub karty, a użytkownik dostaje komunikat, że tego rodzaju dane trzeba zastąpić identyfikatorem technicznym. Taki mechanizm mniej irytuje niż „goły zakaz”, bo od razu podpowiada, jak obejść problem w sposób bezpieczny.
7. Testy bezpieczeństwa i kontrola jakości
Dla klasycznych aplikacji testy bezpieczeństwa koncentrują się na podatnościach technicznych. W kontekście ChatGPT dochodzi element zachowania modelu. Pojawiają się więc dwa nurty weryfikacji:
Testy techniczne – standard:
testy penetracyjne integracji API i portali, w których osadzono ChatGPT;
weryfikacja autoryzacji i separacji danych między użytkownikami;
kontrola konfiguracji SSO, logowania, retencji.
Testy zachowania modelu – nowy obszar:
próby „wyciągnięcia” z modelu danych z poprzednich sesji (czy dochodzi do nieszczelności kontekstu);
sprawdzanie, czy model nie generuje treści sprzecznych z politykami firmy (np. porady prawne dla klientów, których firma nie chce udzielać).
Zespół security może przygotować zestaw scenariuszy testowych, które będą regularnie odpalane na środowisku – zwłaszcza po dużych aktualizacjach lub zmianach konfiguracji. To nie daje stuprocentowej gwarancji, ale pozwala wychwycić przynajmniej najbardziej oczywiste regresje.
8. Monitoring, logowanie i reagowanie na incydenty
ChatGPT generuje nowy rodzaj logów: konwersacje, metadane, statystyki użycia. Trzeba zdecydować:
co logujemy – pełną treść promptów i odpowiedzi, czy tylko metadane (użytkownik, czas, kategoria zapytania, długość);
kto ma wgląd – czy administrator widzi treści konwersacji, czy wyłącznie dane zagregowane;
jak długo trzymamy logi – i jak to się ma do RODO i polityki retencji w innych systemach.
Są dwie skrajne szkoły:
Maksymalna transparentność i audytowalność – pełne logi treści, które można przeszukiwać przy incydentach, szkoleniach, ocenach jakości. Lepsze narzędzie dochodzeniowe, ale większe ryzyko naruszenia prywatności pracowników i klientów.
Minimalizacja logów – tylko metadane techniczne i zagregowane statystyki, pełna treść pozostaje w narzędziu i nie jest kopiowana do SIEM/DLP. Mniej danych do ochrony, ale ograniczona możliwość analizy konkretnych zdarzeń.
Wybór zwykle zależy od branży i dojrzałości organizacji. Branże ściśle regulowane częściej idą w kierunku pełnych logów, ale równolegle wdrażają jasne zasady, jak i w jakich przypadkach można te logi przeglądać.
9. Governance i cykliczne przeglądy przypadków użycia
Modele generatywne zmieniają się szybciej niż większość systemów firmowych. To, co dziś jest „eksperymentem”, za pół roku może być krytycznym narzędziem w procesie sprzedaży czy obsługi klienta. Dział IT razem z właścicielami biznesowymi potrzebują lekkiego, ale stałego mechanizmu zarządzania:
rejestr przypadków użycia – kto, w jakim procesie i na jakim poziomie skali korzysta z ChatGPT (pilotaż, produkcja, krytyczny proces);
cykliczne przeglądy (np. co kwartał) – czy przypadek jest nadal zgodny z politykami, czy trzeba zmienić plan, region danych, warstwę API;
proces zgłaszania nowych pomysłów – prosto opisany formularz, który zamiast hamować inicjatywę, pomaga ludziom zgłosić ją w sposób uporządkowany.
Dobrze, gdy takie governance jest lekkie – kilka stron procesu zamiast kilkudziesięciu. Inaczej użytkownicy wrócą do „dzikiego zachodu” i prywatnych kont, gdzie czują, że nikt ich nie spowalnia.
Zasady bezpiecznego „promptowania” – jak użytkownik końcowy może sam ograniczać ryzyka
Praktyczna mapa: trzy poziomy ostrożności
Technika to jedno, ale ostatnią linią obrony jest zachowanie użytkownika. Prosty, zrozumiały model dla pracownika to podział promptów na trzy poziomy ostrożności:
Poziom zielony – treści, które i tak mogłyby trafić do internetu (ogólne pytania, publiczne instrukcje, materiały marketingowe). Tu minimalne ryzyko; podstawą jest niepodawanie danych osobowych czy numerów identyfikacyjnych.
Poziom żółty – treści wewnętrzne, niewrażliwe, ale nieprzeznaczone do publikacji (wewnętrzne procedury, szablony maili, drafty dokumentów). Tu konieczne jest korzystanie z firmowego konta i stosowanie podstawowej anonimizacji.
Poziom czerwony – dane osobowe, tajemnice przedsiębiorstwa, poufne ustalenia kontraktowe. W większości organizacji w ogóle nie wolno ich wpisywać do ChatGPT, chyba że istnieje dedykowane, wyraźnie oznaczone środowisko z dodatkowymi zabezpieczeniami.
Taki podział jest łatwiejszy do zapamiętania niż szczegółowe tabele w polityce bezpieczeństwa. Działy IT i bezpieczeństwa mogą później spiąć go z konkretną konfiguracją narzędzia i filtrów DLP.
Jak formułować prompt bez ujawniania zbyt wielu danych
Użytkownik nie musi znać wszystkich technicznych niuansów, ale kilku prostych zasad może się trzymać w codziennej pracy:
Zastępuj dane osobowe pseudo-identyfikatorami
Zamiast: „Napisz odpowiedź dla pana Jana Kowalskiego z ulicy… w sprawie reklamacji”,
lepiej: „Napisz profesjonalną odpowiedź na reklamację klienta [KLIENT_123], który jest niezadowolony z opóźnionej dostawy”.
Stosuj opis kontekstu, a nie kopiuj całych dokumentów
Zamiast wklejać całą umowę z klientem, można streścić ją neutralnym językiem: „Umowa na świadczenie usług IT, czas określony, wysokie kary umowne za opóźnienia – jak poprawnie opisać ryzyka w raporcie dla zarządu?”.
Wycinaj pola z wrażliwymi danymi przed wklejeniem
Przed skopiowaniem tabeli z Excela usuń kolumny z imieniem, nazwiskiem, PESEL, numerami dokumentów. Pozostaw wyłącznie cechy potrzebne do analizy.
Nie używaj prawdziwych nazw projektów i klientów w przykładach
Zamiast nazwy dużego klienta użyj neutralnego oznaczenia: „klient z branży motoryzacyjnej, projekt wdrożenia systemu ERP”.
Najczęściej zadawane pytania (FAQ)
Jak bezpiecznie używać ChatGPT w pracy z danymi klientów?
Podstawowa zasada: nie wklejaj do ChatGPT żadnych danych, które pozwalają zidentyfikować osobę lub konkretnego klienta. Chodzi m.in. o imię i nazwisko, numer telefonu, e‑mail, PESEL, NIP, numery umów, wewnętrzne identyfikatory czy pełne treści wrażliwych dokumentów. Zamiast tego stosuj anonimizację: zamieniaj nazwy na etykiety typu „Klient A”, „Projekt X”, usuwaj szczegóły adresowe i kwoty, jeśli nie są kluczowe dla odpowiedzi.
Przykład: zamiast wklejać pełną reklamację klienta z danymi osobowymi, wyodrębnij samą treść problemu i poproś ChatGPT o przygotowanie neutralnej odpowiedzi. W razie wątpliwości przyjmij zasadę „bezpieczniej nie wkleić” i skonsultuj się z działem IT lub bezpieczeństwa.
Czy korzystanie z ChatGPT w firmie jest zgodne z RODO?
Może być zgodne, ale zależy to od sposobu użycia i wybranego modelu wdrożenia. Chaotyczne, „prywatne” logowanie się pracowników na własne konta i wklejanie danych klientów to najgorszy scenariusz z perspektywy RODO – trudno wtedy mówić o kontroli, podstawie prawnej przetwarzania czy śladzie audytowym.
Bardziej bezpieczne są dwa warianty: podejście hybrydowe (jasny regulamin, częściowo kontrolowane konta firmowe) oraz centralnie zarządzane wdrożenie (ChatGPT Team/Enterprise lub API) spięte z politykami bezpieczeństwa, SSO i umowami powierzenia przetwarzania danych. Im wyższy poziom centralizacji i kontroli, tym łatwiej udowodnić zgodność podczas audytu.
Jakie są największe ryzyka związane z użyciem ChatGPT w organizacji?
W praktyce zwykle pojawiają się trzy główne grupy ryzyk: wyciek danych, jakość generowanych treści oraz brak kontroli nad tym, kto i do czego używa narzędzia. W pierwszej grupie problemem jest nieświadome wklejanie danych klientów, kodu lub poufnych dokumentów do publicznej wersji usługi. W drugiej – halucynacje modeli, czyli przekonująco brzmiące, lecz błędne informacje, które mogą trafić do ofert, umów czy analiz.
Trzecia grupa to kwestie organizacyjne: brak śladu audytowego, niejednolite ustawienia prywatności na kontach pracowników i brak spójnych zasad. Różnica między „dzikim zachodem” a kontrolowanym użyciem polega więc nie na samej technologii, ale na tym, czy firma ma czytelne reguły, monitoring i jasno określoną odpowiedzialność.
Czym się różni prywatne korzystanie z ChatGPT od służbowego?
W użyciu prywatnym konsekwencje zwykle ograniczają się do jakości własnego tekstu czy straconego czasu. W firmie stawka jest wyższa: dochodzą dane klientów, reputacja marki, wymogi regulatorów i realne straty finansowe wynikające z błędnych decyzji opartych na treściach generowanych przez model.
Różni się też skala – jedna zła odpowiedź w prywatnym mailu do znajomego to co innego niż błędna interpretacja przepisów podatkowych wykorzystana w komunikacji do setek klientów. Dlatego poziom „zdrowego rozsądku”, który wystarcza w życiu prywatnym, w firmie trzeba uzupełnić formalnymi zasadami i szkoleniem użytkowników.
Jaki model wdrożenia ChatGPT wybrać: pełna swoboda, hybrydowy czy centralnie zarządzany?
Model „pełna swoboda” sprawdza się głównie w bardzo małych, niskosformalizowanych firmach, które nie przetwarzają wrażliwych danych i akceptują wysoki poziom niepewności. Plusem jest szybkość i brak biurokracji, minusem – praktycznie zerowa kontrola nad tym, co wypływa na zewnątrz.
Model hybrydowy jest rozsądnym kompromisem dla organizacji w fazie eksploracji: są podstawowe zasady, część kont firmowych i pierwsze mechanizmy kontroli, ale pozostaje przestrzeń na eksperymenty. Centralnie zarządzane wdrożenie ma najwyższą barierę wejścia (czas, procesy, koszty), za to oferuje najlepszą kontrolę nad danymi, integrację z SSO, umowy z dostawcą i argumenty na audyt czy kontrolę regulatora.
Jakie proste zasady „higieny” wdrożyć dla pracowników korzystających z ChatGPT?
Dobry zestaw minimalnych reguł powinien obejmować: zakaz wklejania danych osobowych i identyfikujących klientów, ograniczenie przesyłania pełnych treści umów i dokumentów wewnętrznych, obowiązek anonimizacji nazw projektów i firm oraz instrukcję krok po kroku, jak maskować dane przed wysłaniem promptu.
Warto też jasno zaznaczyć, że odpowiedzi modelu są propozycją wymagającą weryfikacji, a nie źródłem „prawdy”. Pracownik powinien wiedzieć, że w przypadku tematów prawnych, podatkowych czy regulacyjnych ChatGPT może służyć do szkiców i porządkowania myśli, ale ostateczna wersja musi przejść przez specjalistę lub dział merytoryczny.
Jak dział IT może mieć kontrolę nad użyciem ChatGPT, nie blokując całkowicie narzędzia?
Najprostszy sposób to przejście z modelu „każdy robi, co chce” na minimum podejścia hybrydowego: firmowe konta (np. ChatGPT Team), wspólne ustawienia prywatności, spójny regulamin użycia i podstawowy monitoring. IT nie musi wybierać między pełnym zakazem a całkowitą swobodą – może wprowadzić stopniową kontrolę, zaczynając od zespołów pilotażowych.
Przy centralnie zarządzanym wdrożeniu dochodzi integracja z SSO, nadawanie uprawnień na poziomie ról, logowanie operacji i łatwiejsze szacowanie ryzyka. Różnica między „blokującym strażnikiem” a partnerem polega na tym, że IT pomaga zdefiniować bezpieczne sposoby korzystania z narzędzia, zamiast jedynie je wyłączać.
