Po co firmie ChatGPT i podobne narzędzia – spojrzenie z perspektywy IT
Najczęstsze scenariusze użycia w biznesie
Generatywna sztuczna inteligencja w firmie przestaje być ciekawostką, a staje się kolejnym narzędziem pracy – tak jak kiedyś poczta e‑mail czy system ticketowy. ChatGPT i podobne rozwiązania są dziś wykorzystywane w wielu obszarach organizacji, często bez wiedzy działu IT. Warto więc uporządkować typowe scenariusze.
W obszarze obsługi klienta narzędzia typu ChatGPT pomagają:
- przygotowywać szkice odpowiedzi na maile i zgłoszenia,
- tworzyć propozycje odpowiedzi w czatach live, które konsultant tylko koryguje,
- porządkować zgłoszenia klientów – streszczać, kategoryzować, wyciągać główne wątki,
- tłumaczyć wiadomości z i na inne języki.
W marketingu i komunikacji ChatGPT często jest wykorzystywany do generowania szkiców tekstów, komunikatów, opisów produktów, scenariuszy filmów, postów w social media. Z punktu widzenia IT oznacza to zwykle mniejsze ryzyka – pod warunkiem, że do promptów nie trafiają dane klientów, niepublikowane jeszcze kampanie ani szczegóły strategii.
W obszarze analityki i raportowania AI pomaga streszczać raporty, tłumaczyć wyniki analiz “na ludzki język” czy przygotowywać szkice prezentacji. Coraz częściej ChatGPT obsługiwany przez API jest też wykorzystywany do ekstrakcji danych z dokumentów: faktur, umów, pism urzędowych.
Co zyskuje organizacja, a co konkretnie dział IT
Z perspektywy zarządu ChatGPT to głównie:
- przyspieszenie pracy – mniej czasu na proste, powtarzalne zadania,
- niższe koszty – część pracy “białych kołnierzyków” można zautomatyzować,
- lepsza dostępność wiedzy – pracownik szybciej dociera do rozwiązania problemu.
Dla działu IT korzyści są nieco inne i bardzo konkretne. AI może wesprzeć:
- tworzenie i aktualizację dokumentacji technicznej (procedury, runbooki, wiki),
- pierwszą analizę logów, raportów z monitoringu, zgłoszeń użytkowników,
- pisanie i review skryptów, zapytań SQL, fragmentów kodu – oczywiście z kontrolą jakości,
- tworzenie szablonów komunikatów dla użytkowników (instrukcje, komunikaty o awarii).
Przykładowo: administrator może poprosić ChatGPT o wygenerowanie szkicu procedury restartu klastra czy checklisty po aktualizacji krytycznego systemu. Nadal musi to przejrzeć i poprawić, ale startuje od 70% gotowego tekstu, a nie od pustej kartki. W skali roku takie przyspieszenia kumulują się w setki godzin.
AI porządkuje też wiedzę rozproszoną po osobach. Gdy senior developer odchodzi, zostawia po sobie wiedzę w kodzie i w głowie. Jeśli wcześniej korzystał z ChatGPT do tworzenia dokumentacji i opisów, dział IT ma większe szanse na płynne przejęcie jego obowiązków.
Gadżet czy narzędzie produkcyjne – jak odróżnić
Z punktu widzenia bezpieczeństwa IT najważniejsze jest rozróżnienie: czy ChatGPT jest używany jako “pomocnik” pojedynczego pracownika, czy staje się elementem oficjalnego procesu biznesowego. Od tego zależy, jak głęboko trzeba go wpiąć w polityki bezpieczeństwa i nadzór.
Za gadżet można uznać sytuację, w której pracownik marketingu pisze tekst i czasem wspiera się ChatGPT, kopiując wygenerowany szkic do Worda. Nie ma tutaj integracji z systemami wewnętrznymi, nie ma automatycznego przetwarzania danych klientów, a prompt nie zawiera wrażliwych informacji.
Narzędzie produkcyjne zaczyna się w momencie, gdy:
- ChatGPT jest zintegrowany z firmowymi systemami (CRM, ERP, helpdesk),
- wykorzystuje się API do automatycznego przetwarzania danych,
- wyniki działania AI trafiają bezpośrednio do klientów (np. chatbot na stronie),
- proces biznesowy formalnie zależy od dostępności i jakości odpowiedzi AI.
W takim scenariuszu dział IT musi potraktować ChatGPT podobnie jak każdy system krytyczny: z kontrolą dostępu, monitoringiem, planem ciągłości działania i zabezpieczeniami przed wyciekiem danych. To nie jest już “fajny gadżet”, tylko komponent architektury IT.
Historia z praktyki: AI wprowadzona tylnymi drzwiami
W wielu firmach pierwsze użycie ChatGPT wygląda podobnie: ktoś z działu sprzedaży odkrywa narzędzie prywatnie, zachwyca się i zaczyna korzystać do przygotowywania ofert. Po chwili podsyła link kolegom. Po miesiącu pół zespołu wrzuca do ChatGPT treści umów, dane klientów i fragmenty strategii, bo “tak jest szybciej”. Dział IT nic o tym nie wie, dział prawny tym bardziej.
W pewnym momencie ktoś z bezpieczeństwa dostaje alert z rozwiązania CASB albo z proxy: rośnie ruch do domen dostawcy AI, w logach widać fragmenty adresów email, domeny klientów, a nawet identyfikatory z systemu CRM. Zaczyna się nerwowe sprawdzanie: co już wypłynęło, kto używał, w jakim zakresie.
Podstawowe ryzyka korzystania z ChatGPT w środowisku firmowym
Ujawnienie danych wrażliwych i tajemnic przedsiębiorstwa
Najbardziej oczywiste ryzyko to wrzucenie do promptu tego, co nigdy nie powinno opuścić organizacji. Pracownik działa w dobrej wierze: szuka pomocy przy sformułowaniu odpowiedzi, analizie tabeli czy poprawie kodu. Kopiuje więc do ChatGPT cały kontekst – maile od klienta, fragment umowy, zrzut ekranu z CRM, log z systemu produkcyjnego.
W takim promptcie bardzo często znajdują się:
- dane osobowe (imiona, nazwiska, adresy, numery telefonów, ID klienta),
- tajemnice przedsiębiorstwa (cenniki, marże, warunki umów, roadmapy produktów),
- informacje o infrastrukturze IT (adresy IP, nazwy hostów, topologia sieci, konfiguracje),
- fragmenty kodu źródłowego lub skrypty administracyjne.
Jeśli organizacja korzysta z wersji narzędzia, w której przesyłane dane mogą być wykorzystywane do dalszego trenowania modelu lub analityki dostawcy, to z perspektywy bezpieczeństwa wygląda jak kontrolowany wyciek informacji. Nawet jeśli dostawca deklaruje wysoki poziom zabezpieczeń, dane znajdują się poza bezpośrednią kontrolą firmy.
Dział IT powinien jasno zakomunikować, jakie kategorie danych są zakazane w promptach, przygotować przykłady bezpiecznych i niebezpiecznych zapytań oraz dopilnować, by ustawienia kont firmowych minimalizowały ryzyko ponownego wykorzystania danych do trenowania modelu.
Halucynacje i fałszywe informacje – ryzyko decyzyjne i reputacyjne
Drugie duże zagrożenie ma charakter merytoryczny, nie techniczny. Modele językowe generują odpowiedzi na podstawie wzorców w danych treningowych, a nie “wiedzy” w ludzkim rozumieniu. Potrafią więc z pełnym przekonaniem wygenerować kompletne bzdury – z poprawnymi cytatami, wymyślonymi referencjami czy nieistniejącymi klasami w API.
Jeśli pracownik traktuje ChatGPT jako nieomylne źródło, pojawia się ryzyko:
- podjęcia złej decyzji biznesowej (np. na podstawie błędnej interpretacji przepisu czy normy),
- negatywnego wpływu na bezpieczeństwo (wdrożenie błędnej konfiguracji, złych reguł firewalli),
- skompromitowania firmy (publikacja materiału z merytorycznymi błędami lub plagiatem).
Typowy przykład z IT: inżynier prosi ChatGPT o konfigurację firewalla dla konkretnego systemu. Dostaje wiarygodnie wyglądające reguły i wkleja je do produkcji. Problem w tym, że model nie rozumie kontekstu całej architektury sieci, a część portów otwiera zbyt szeroko. Niby drobiazg, a wprowadza poważną lukę bezpieczeństwa.
Dlatego kluczowe jest budowanie kultury “AI-assisted, not AI-driven”: model podpowiada i przyspiesza, ale to człowiek bierze odpowiedzialność za weryfikację i ostateczną decyzję.
Brak pełnej kontroli nad miejscem i sposobem przetwarzania danych
Generatywna AI działa zwykle w chmurze. Dane z promptów i odpowiedzi mogą trafiać do centrów danych w różnych krajach, obejmujących różne jurysdykcje i zestawy przepisów. Dla działu IT i działu prawnego pojawiają się pytania:
- w jakim kraju fizycznie przetwarzane są dane,
- czy dostawca korzysta z podwykonawców, a jeśli tak – jakich,
- jak długo przechowywane są logi i treści zapytań,
- czy dane mogą być wykorzystane do trenowania modelu.
W sektorach regulowanych (finanse, medycyna, administracja) brak jasnych odpowiedzi na te pytania uniemożliwia produkcyjne korzystanie z narzędzia. W innych branżach również może to naruszać zasady bezpieczeństwa informacji oraz wewnętrzne standardy klasyfikacji danych.
Dział IT razem z działem prawnym musi dokładnie przeanalizować dokumentację dostawcy, w tym warunki licencji, opisy architektury bezpieczeństwa, informacje o lokalizacji danych i praktykach retencji. Dopiero wtedy można z pełną świadomością określić, jakie typy danych mogą trafiać do ChatGPT, a jakie wymagają innego rozwiązania.
Uzależnienie biznesu od jednego dostawcy (vendor lock-in)
Kolejnym ryzykiem, które często pojawia się dopiero po czasie, jest uzależnienie procesów biznesowych od jednego dostawcy AI. Jeśli firma oprze krytyczne procesy na konkretnym API lub usłudze, zmiana dostawcy może okazać się bardzo kosztowna i skomplikowana.
Trzeba brać pod uwagę scenariusze, w których:
- dostawca zmienia drastycznie cennik,
- pojawiają się nowe wymagania prawne ograniczające korzystanie z danego rozwiązania,
- usługa ma poważną awarię lub jest okresowo niedostępna,
- dostawca modyfikuje regulamin w sposób nieakceptowalny dla organizacji.
Dlatego przy projektowaniu integracji z ChatGPT dział IT powinien:
- stosować warstwę abstrakcji – np. własną usługę pośredniczącą, która w razie potrzeby może przełączyć się na inny model,
- monitorować zmiany w dokumentacji i regulaminach dostawcy,
- regularnie oceniać alternatywne rozwiązania (inne modele, rozwiązania on-premises).
Przykład: kod produkcyjny w darmowej wersji narzędzia
Wyobraźmy sobie sytuację: programista nie może poradzić sobie z błędem w module obsługującym płatności. Kopiuje więc fragment kodu i wrzuca go do darmowej wersji ChatGPT z prywatnego konta, bez logowania służbowego. W promptcie pojawia się nazwa systemu, adres endpointu API, sposób obsługi tokenów.
Po pierwsze, dochodzi do naruszenia zasad tajemnicy przedsiębiorstwa – kod to często kluczowe IP firmy. Po drugie, część informacji o integracji płatności może pomóc potencjalnemu atakującemu (np. sposób walidacji podpisu). Po trzecie, organizacja nie ma żadnej kontroli nad tym, jak długo te dane będą przechowywane i do czego posłużą.
Od strony IT oznacza to konieczność wdrożenia jasnych wytycznych: kiedy wolno używać AI do analizy kodu, w jakim narzędziu (np. wersja enterprise, self‑hosted), z jakimi ograniczeniami, oraz jak wykrywać takie “ucieczki” do publicznych usług – np. poprzez inspekcję ruchu wychodzącego czy narzędzia CASB.
Ramy prawne i compliance – co musi ogarnąć dział IT wspólnie z prawnym
Ochrona danych osobowych: kiedy ChatGPT jest procesorem, a kiedy ryzykiem wycieku
W kontekście RODO / GDPR kwestia generatywnej AI sprowadza się do dwóch scenariuszy. Pierwszy: organizacja korzysta z ChatGPT do przetwarzania danych osobowych w sposób powtarzalny i zaplanowany (np. automatyczna analiza korespondencji z klientami). W takim wypadku dostawca AI staje się procesorem danych (podmiotem przetwarzającym) i wymaga formalnej umowy powierzenia przetwarzania danych.
Drugi scenariusz: pojedynczy pracownik incydentalnie wpisuje dane osobowe do ChatGPT bez zgody administratora danych i bez stosownych zabezpieczeń. Wtedy mamy do czynienia z nieuprawnionym ujawnieniem danych – potencjalnym naruszeniem ochrony danych osobowych, które trzeba ocenić, zgłosić wewnętrznie, a czasem również do organu nadzorczego.
Z punktu widzenia IT skutkiem jest konieczność:
- wypracowania zasad, czy i kiedy wolno przetwarzać dane osobowe w narzędziach AI,
- ustalenia, czy dostawca spełnia wymagania RODO jako procesor danych,
- włączenia ChatGPT do rejestru czynności przetwarzania danych (jeśli spełnia rolę procesora),
- wdrożenia mechanizmów kontroli, by zapobiegać “nielegalnym” promptom z danymi osobowymi.
- opracowania procedury reagowania na incydenty związane z AI – od zgłoszenia, przez analizę, po ewentualne notyfikacje regulatora i osób, których dane dotyczą.
Przy projektowaniu rozwiązań opartych na ChatGPT przydaje się też zasada minimalizacji: jeśli da się osiągnąć cel biznesowy bez wprowadzania danych osobowych do modelu, lepiej tak to zaplanować. Czasem wystarczy pseudonimizacja (np. zamiana “Jan Kowalski, ul. X” na “Klient A z miasta Y”), czasem anonimizacja, a w części przypadków – przetwarzanie danych w dwóch krokach, gdzie warstwa AI dostaje już “odszumioną”, pozbawioną identyfikatorów treść.
Dla działu IT to również dobry moment, żeby zsynchronizować się z IOD/Inspektorem Ochrony Danych. Wspólne wypracowanie wzorcowych scenariuszy użycia i “czerwonych linii” ułatwia później życie wszystkim: programistom, działowi obsługi klienta, marketingowi. Zamiast interpretować RODO za każdym razem od zera, firma ma jasny katalog: co wolno, na jakiej podstawie prawnej i w jakiej konfiguracji narzędzia.
Ten scenariusz powtarza się w wielu organizacjach, niezależnie od branży. Dlatego dział IT powinien zawczasu przygotować ramy korzystania z ChatGPT – zanim pracownicy zrobią to po swojemu. Świadome podejście do generatywnej AI staje się po prostu kolejną kompetencją w obszarze więcej o informatyka i zarządzania środowiskiem cyfrowym.
AI Act, regulacje sektorowe i wewnętrzne standardy
Unijne regulacje dotyczące sztucznej inteligencji (AI Act) nakładają dodatkowe obowiązki na organizacje korzystające z systemów AI, zwłaszcza tam, gdzie mowa o tzw. systemach wysokiego ryzyka. ChatGPT jako taki zwykle nie wpada do tej kategorii, ale rozwiązanie zbudowane na jego bazie – np. system wspierający decyzje kredytowe – już jak najbardziej może. Wtedy w grę wchodzą wymagania dotyczące dokumentacji, nadzoru człowieka, jakości danych treningowych i możliwości wyjaśnienia sposobu działania systemu.
Oprócz AI Act dochodzą regulacje branżowe: w finansach – wytyczne EBA i lokalnych nadzorców dotyczące outsourcingu IT i modeli ryzyka; w ochronie zdrowia – przepisy o dokumentacji medycznej i systemach klasy wyrobu medycznego; w administracji – zasady jawności, archiwizacji i dostępności. IT nie musi być ekspertem od każdego aktu prawnego, ale powinno umieć przełożyć wymagania na język architektury: gdzie potrzebny jest audyt logów, kiedy niezbędna jest walidacja danych wejściowych, jakie mechanizmy “human-in-the-loop” trzeba zaimplementować.
Rosnące znaczenie mają też wewnętrzne standardy organizacji: polityka bezpieczeństwa informacji, kodeks etyczny, wytyczne ESG. Jeśli firma deklaruje określony poziom przejrzystości algorytmów, to sposób integracji z ChatGPT nie może temu przeczyć. Przykład? Zespół HR korzysta z AI do wstępnej selekcji CV – trzeba udokumentować, jak wygląda proces, jakie dane trafiają do modelu i w jaki sposób ograniczane jest ryzyko dyskryminacji.
Praktycznym narzędziem stają się tu oceny wpływu (DPIA dla RODO, a coraz częściej osobne AI risk assessment). IT wspólnie z biznesem i prawnym opisuje planowane zastosowanie ChatGPT, klasy danych, możliwe skutki dla użytkowników i organizacji, a następnie dobiera środki techniczne i organizacyjne. Taki “przegląd przedprodukcyjny” spowalnia wdrożenie o kilka dni, ale w zamian chroni przed miesiącami gaszenia pożarów, jeśli rozwiązanie trafiłoby pod lupę regulatora albo klientów.
Dla działu IT generatywna AI to połączenie nowej zabawki i nowej odpowiedzialności. Z jednej strony potężne usprawnienia w codziennej pracy, z drugiej – zupełnie świeży zestaw ryzyk technicznych, prawnych i organizacyjnych. Im wcześniej powstaną sensowne zasady gry, tym łatwiej będzie korzystać z ChatGPT jak z dobrego, ale wymagającego narzędzia: takiego, które pomaga wygrywać projekty, zamiast dokładania kolejnych problemów do listy incydentów i audytów.
Jak zaprojektować politykę korzystania z ChatGPT w firmie – krok po kroku
Mapowanie zastosowań: od “fajnego gadżetu” do zdefiniowanych use case’ów
Zanim powstanie jakakolwiek formalna polityka, trzeba wiedzieć, do czego ludzie już używają ChatGPT i do czego chcą go używać. Jeśli IT i prawnicy zaprojektują zasady w próżni, pracownicy i tak znajdą drogę na skróty – prywatne konta, darmowe wersje, pluginy z nieznanym regulaminem.
Dobry start to krótki “spis ról” ChatGPT w organizacji. Przykładowo:
- asystent programisty (refaktoryzacja, generowanie testów, code review light),
- wsparcie działu obsługi klienta (propozycje odpowiedzi, streszczanie długich zgłoszeń),
- pomoc dla marketingu (szkice treści, pomysły na hasła, tłumaczenia),
- asystent analityka (porządkowanie danych tekstowych, generowanie zapytań SQL, streszczenia raportów),
- wewnętrzny “kopilot” dla użytkowników biznesowych (wyjaśnianie pojęć, tworzenie draftów procedur, maili).
Każdy z tych scenariuszy ma inne wymagania co do rodzaju danych, poziomu wrażliwości, potrzeby logowania i audytu. Dział IT powinien razem z biznesem zrobić prostą matrycę: kto, do czego, z jakimi danymi i w jakim narzędziu (przeglądarka, wtyczka IDE, integracja z systemem).
Klasyfikacja danych a dopuszczalne użycie AI
Większość średnich i dużych firm ma choćby szczątkowy system klasyfikacji informacji: “jawne / wewnętrzne / poufne / ściśle poufne” albo podobny. Polityka korzystania z ChatGPT powinna być bezpośrednio do niego podpięta. Użytkownik nie może się zastanawiać: “czy to już jest dane wrażliwe, czy jeszcze nie?”. Potrzebuje prostych, jasnych reguł.
Przykładowe podejście może wyglądać tak:
- Dane publiczne / marketingowe – można przetwarzać w ChatGPT (w ramach wskazanych narzędzi), z zachowaniem podstawowej ostrożności.
- Dane wewnętrzne o niskiej wrażliwości (np. anonimowe statystyki, dokumentacja techniczna bez kluczy i tajemnic) – dopuszczalne, jeśli używana jest wersja enterprise/firmowa z odpowiednimi gwarancjami kontraktowymi.
- Dane poufne (finanse, elementy IP, plany strategiczne) – tylko w ściśle określonych scenariuszach i wyłącznie w środowisku kontrolowanym (np. self-hosted, dedykowana instancja), często z dodatkowymi ograniczeniami.
- Dane ściśle poufne / wrażliwe (szczególne kategorie danych osobowych, tajemnice prawnie chronione, dane bezpieczeństwa) – całkowity zakaz używania w narzędziach generatywnych, chyba że specyficzny projekt został osobno przeanalizowany i zaakceptowany (np. DPIA, ocena ryzyka AI).
Kluczowe jest podanie prostych, życiowych przykładów w polityce: “Nazwiska klientów – NIE”, “opisy przypadków klientów po anonimizacji – TAK, pod warunkiem…”. Bez tego klasyfikacja pozostanie teorią.
Podział odpowiedzialności: kto za co odpowiada
ChatGPT w firmie to wspólne przedsięwzięcie. Jeśli wszystko “wrzuci się” na barki IT, skończy się blokadą lub chaosem. W polityce warto explicite rozpisać role:
- IT / bezpieczeństwo – wybór i konfiguracja narzędzi, integracje, kontrola dostępu, monitoring, reagowanie na incydenty, przegląd logów.
- Dział prawny / compliance / IOD – analiza umów z dostawcami, ocena ryzyka prawnego (RODO, AI Act, regulacje branżowe), wsparcie przy DPIA, definicja “czerwonych linii”.
- Biznes / właściciele procesów – opis zastosowań, ustalanie kryteriów jakości, ocena przydatności i skutków dla klientów, decyzje “czy w ogóle warto użyć AI w tym obszarze”.
- HR / szkolenia – edukacja użytkowników, materiały e‑learningowe, egzaminy potwierdzające znajomość zasad, włączenie AI do onboardingów.
- Użytkownicy końcowi – przestrzeganie zasad, zgłaszanie incydentów i wątpliwości, testowanie modeli w praktyce i feedback do IT.
Dobrą praktyką jest wyznaczenie “product ownera AI” lub małego zespołu, który spina temat całościowo: śledzi zmiany u dostawców, prowadzi backlog usprawnień, koordynuje przeglądy polityk.
Cykl życia polityki: od pilotażu do standardu organizacji
Polityka AI nie powstaje od razu w wersji “na lata”. Rozsądniej jest zacząć od ograniczonego pilotażu, kilku działów i jasno zdefiniowanych use case’ów. Na tej bazie da się szybko wychwycić absurdy (“tego punktu nikt nie potrafi zastosować w praktyce”) i luki (“zupełnie zapomnieliśmy o zespole sprzedaży”).
Prosty cykl może wyglądać tak:
- Wersja robocza zasad + pilotaż w 1–3 zespołach.
- Zbieranie feedbacku (ankiety, retro z zespołami, przegląd incydentów).
- Korekta polityki + doprecyzowanie przykładów dopuszczalnych i zakazanych promptów.
- Rozszerzenie na całą organizację, szkolenia obowiązkowe, włączenie do dokumentacji bezpieczeństwa.
- Cykliczny przegląd (np. co 6 lub 12 miesięcy) i aktualizacja w reakcji na zmiany u dostawcy, w prawie i w praktyce użytkowania.
Takie podejście pozwala uniknąć sytuacji, w której polityka jest piękna na papierze, ale kompletnie oderwana od rzeczywistości.
Minimalne standardy bezpieczeństwa technicznego przy korzystaniu z ChatGPT
Kontrolowany dostęp i integracja z identity management
Podstawą jest to, by korzystanie z ChatGPT w pracy nie opierało się na prywatnych kontach pracowników. Z perspektywy IT to niemal równoważne wysyłaniu fragmentów systemów firmowych na losowe adresy e‑mail. Konta służbowe, złączone z firmowym systemem tożsamości (SSO, Azure AD, Okta itp.), pozwalają:
- nadawać i odbierać dostęp centralnie (offboarding, zmiana roli),
- stosować MFA, polityki haseł, restrykcje lokalizacyjne i urządzeniowe,
- wiązać historię użycia narzędzia z konkretnym użytkownikiem w ramach audytu.
Jeśli ChatGPT jest używany przez API, ten sam standard powinien dotyczyć kluczy i tokenów: rotacja, przechowywanie w sejfie haseł/secret managerze, minimalne uprawnienia, odseparowane środowiska (dev/test/prod).
Konfiguracja prywatności i retencji po stronie dostawcy
Większość komercyjnych ofert AI dla biznesu daje wybór: czy dane klientów mają być używane do trenowania modeli ogólnych, jak długo przechowywane są logi, kto ma do nich dostęp po stronie dostawcy. To nie są techniczne detale, tylko kluczowe dźwignie ryzyka.
Dział IT powinien wspólnie z prawnym i IOD-em przeanalizować i skonfigurować m.in.:
- wyłączenie używania danych organizacji do trenowania globalnych modeli (o ile to możliwe kontraktowo),
- okres retencji logów i promptów – zbalansowany między audytem a minimalizacją danych,
- zakres dostępności logów dla supportu dostawcy (czy potrzebne są dodatkowe NDA, zasady maskowania),
- lokalizację przetwarzania danych (regiony, lokalne wymagania regulacyjne).
W wielu firmach te ustawienia ustala się raz na początku wdrożenia i później o nich zapomina. Tymczasem zmiany w regulaminach usług potrafią domyślne wartości zmodyfikować – stąd potrzeba regularnego przeglądu.
Segmentacja sieci i kontrola ruchu do usług AI
Jeśli ChatGPT jest używany wrażliwie (np. w procesach finansowych czy medycznych), warto potraktować połączenia z nim jak z każdą inną zewnętrzną usługą krytyczną. Oznacza to m.in.:
- kontrolę wychodzącego ruchu HTTP/HTTPS – blokowanie nieautoryzowanych endpointów AI,
- stosowanie proxy z możliwością inspekcji (w granicach dopuszczalnych prawnie) lub przynajmniej logowania metadanych,
- wydzielenie podsieci / stref (np. dla serwerów aplikacyjnych integrujących się z API),
- monitorowanie anomalii: nagłego wzrostu liczby zapytań, nietypowych godzin, nieznanych aplikacji korzystających z API.
Przykładowo: jeśli w logach nagle widać intensywny ruch z działu księgowości na domeny kilku darmowych chatbotów, to sygnał do działania – albo brak narzędzia firmowego, albo polityka nie dotarła do użytkowników.
Bezpieczna obsługa załączników i plików
Coraz częściej interfejsy AI pozwalają wrzucać pliki: PDF-y, arkusze, zrzuty baz danych. To wygodne, ale i potencjalnie zabójcze dla bezpieczeństwa informacji. Minimalne mechanizmy, które powinny być rozważone:
- ograniczenie typów plików – np. tylko tekst, PDF, CSV; blokada plików wykonywalnych, makr, archiwów wielopoziomowych,
- wstępne skanowanie antywirusowe i DLP (Data Loss Prevention) przed wysłaniem pliku do zewnętrznej usługi,
- maskowanie wybranych fragmentów dokumentów (np. PESEL, numery kart, identyfikatory klientów) przed przekazaniem ich do modelu,
- silne rozróżnienie trybów pracy: “analiza wewnętrzna offline” vs “wysyłka do zewnętrznego modelu”.
Dobrym kompromisem bywa stworzenie wew