Ochrona Danych Wrażliwych przed Narzędziami Generatywnej Sztucznej Inteligencji

Cześć, witamy w Data Zen AI Podcast, miejscu tworzonym przez społeczność Data Zen. Pomagamy tutaj zrozumieć sztuczną inteligencję, no i przede wszystkim, jak jej używać bezpiecznie i, no, efektywnie. Pamiętajcie, że jesteśmy dostępni w wielu językach, na różnych platformach, więc można słuchać praktycznie wszędzie. Dzisiaj bierzemy na warsztat temat, który, no cóż, robi się coraz gorętszy. Ochrona danych wrażliwych. Bo te narzędzia AI jak ChatGPT, Copilot, Gemini są super potężne. Ale co jeśli zetkną się z naszymi, powiedzmy, poufnymi informacjami? No właśnie, co się dzieje z tymi danymi? Jak są przechowywane? Czy AI się na nich uczy i co najważniejsze, jak się chronić? Zastanowimy się, co to są te dane wrażliwe dla AI, jak łatwo je niechcący ujawnić, jak bezpiecznie korzystać z AI w pracy, no i jak robią to duże firmy, te z Azure AI, AWS Bedrock czy Google Cloud AI.

Spojrzymy też na kilka, no, głośnych wpadek. Myślę, że to szczególnie ważne dla ludzi z branży IT, deweloperów, product managerów, analityków, testerów, zwłaszcza w korporacjach, gdzie dane to świętość. Dobra, zaczynajmy. Zacznijmy może od podstaw. Te narzędzia są świetne, ale, jak mówiłyśmy, jest ryzyko. Co to właściwie są te dane wrażliwe w kontekście AI? Czy tylko PESEL i numer karty? Oj, zdecydowanie nie tylko. To pojęcie jest znacznie szersze niż samo PII, czyli te dane osobowe. W firmie to mogą być, no wiesz, dane finansowe, jakieś prognozy sprzedaży, strategie marketingowe. Oczywiście kod źródłowy to przecież własność intelektualna firmy. Jasne.

Ale też wewnętrzna komunikacja, maile, wiadomości na Teamsach o problemach z produktem, dane pracowników, informacje o planowanych fuzjach, bazach klientów, dokumenty prawne, dane medyczne, jeśli firma takie przetwarza. Właściwie wszystko, co nie powinno wyjść na zewnątrz. Nawet, powiedzmy, harmonogram projektu może być wrażliwy. Ok, czyli lista jest długa. A jak te dane najczęściej wyciekają? Czy to jakieś skomplikowane ataki hakerskie na serwery AI? Czasem pewnie tak, ale zaskakująco często problem leży po naszej stronie użytkowników. Najprostszy scenariusz. Po prostu wklejamy coś do okna czatu. Tak? Po prostu? Tak, ktoś kopiuje fragment kodu, żeby AI pomogło znaleźć błąd.

Albo notatki ze spotkania, żeby zrobiło podsumowanie. Zdarza się, że ludzie wklejają dane klientów, fragmenty arkusza Excela. No wiesz, żeby było szybciej. Słyszałem o tej historii w Samsungu. Że pracownicy wklejali tam wewnętrzny kod, notatki. Czy to częste? Niestety takie sytuacje mają miejsce. Często to wynika z pośpiechu albo braku świadomości ryzyka. I tu jest sedno. Te modele AI, one się uczą na danych, które dostają. Czyli nasze wpisy mogą posłużyć do treningu. Dokładnie, informacje od jednego użytkownika mogą potencjalnie trafić do danych treningowych modelu, a to nawet niechcący może potem wpłynąć na odpowiedzi dla kogoś innego. Szczególnie trzeba uważać na darmowe wersje tych narzędzi.

One często domyślnie, jakby z automatu, wykorzystują dane do treningu, a badania pokazują, że spora część ludzi, mówi się nawet o ponad 60% w przypadku chat GPT, korzysta właśnie z darmowej wersji. Nie zawsze wiedzą, że tak to działa. Jest też ryzyko, że model coś zapamięta i potem odtworzy fragment wrażliwych danych, nawet jeśli pochodziły one z ogólnych danych treningowych, a nie z naszej konkretnej rozmowy. Skoro tak, to może powiedzmy wprost, czego absolutnie nie wolno wrzucać do takich publicznych narzędzi AI. Zdecydowanie lista jest długa, ale najważniejsze, żadnych poufnych danych firmowych, o których mówiłyśmy, własność intelektualna, kod, fragmenty książki, którą piszemy, informacje finansowe, numery kont, karty, dane osobowe, PESEL, adresy, telefony, to oczywiste.

Hasła. to niby banalne, ale trzeba powtarzać. I co może mniej oczywiste, historia naszych własnych rozmów z chatbotem. Jeśli ktoś ją przechwyci, może dużo wywnioskować albo użyć przeciwko nam. To od razu nasuwa się pytanie, czy te modele AI naprawdę pamiętają to, co im piszemy? Jak długo trzymają nasze rozmowy? No właśnie, to jest złożona sprawa. I co ciekawe, ostatnio, przynajmniej jeśli chodzi o OpenAI, zaszła tu dość istotna zmiana. Do czerwca 2025 roku polityka była taka, że rozmowy w chat GPT były przechowywane, ale użytkownik mógł je usunąć ze swojej historii. Tak, chociaż nawet po usunięciu pewne logi mogły zostać dłużej ze względów bezpieczeństwa czy prawnych.

Ale czytałem też o chyba jeszcze większej wpadce w Microsoftcie. Tam wyciekło podobno aż 38 TB danych zespołu AI. I to nie przez chatbota, prawda? Zgadza się. To świetny przykład, że ryzyko nie leży tylko w samym czacie. W Microsoftie problemem był błąd konfiguracji. Chodziło o taki specjalny link token SaaS do usługi Azure Storage, czyli chmury Microsoftu. Token dostępu. On miał dawać dostęp do pewnych modeli open source udostępnionych na Githubie. Ale przez błąd, zamiast dawać tylko ograniczony dostęp do odczytu, dawał pełne uprawnienia zapis, usuwanie do całego konta przechowywania danych. A tam były nie tylko te publiczne modele, ale mnóstwo wewnętrznych rzeczy zespołu.

Co konkretnie wyciekło? No właśnie. To było poważne. Wyciekły kopie zapasowe komputerów dwóch pracowników z ich hasłami i kluczami prywatnymi, ponad 30 tysięcy wiadomości z wewnętrznego komunikatora Teams od setek pracowników. Co gorsza, istniało ryzyko, że ktoś mógłby użyć tego tokena, żeby zmodyfikować kod źródłowy albo same modele AI. To już prosta druga do ataku na łańcuch dostaw. Ten przypadek pokazuje, jak krytyczne jest pilnowanie uprawnień i konfiguracji. Przerażające. Czytałem też o włamaniu do OmniBTPT. To był jakiś agregator AI. Tak, narzędzie, które pozwalało korzystać z różnych modeli w jednym miejscu. Niestety wyciekło stamtąd ponad 34 miliony zapisów rozmów użytkowników.

Pełne czaty, dane logowania, klucze API, nawet pliki, które ludzie tam przesyłali, finanse, dane klientów. Ojej. I co ciekawe, wiele firm, których pracownicy tego używali, nawet nie wiedziało, że takie narzędzie jest w obiegu w organizacji. To idealnie ilustruje problem Shadow AI, narzędzi wprowadzanych po cichu przez pracowników bez zgody IT. Jest też ten przykład studenta z Misurii, który przyznał się chatbotowi do wandalizmu. Rzeczywiście, policja uzyskała dostęp do logów tej rozmowy i to był dowód w sprawie. To pokazuje, że AI to nie jest cyfrowy konfesjonał. Te rozmowy nie są prywatne i mogą mieć realne konsekwencje prawne. Poza tymi głośnymi wpadkami są też bardziej ukryte ścieżki wycieku.

Na przykład integracja AI z innymi systemami, przez API, CRM, systemem do zarządzania projektami. Mogą nieświadomie udostępniać dane, omijając firmowe zabezpieczenia. Wtyczki do przeglądarek też są ryzykowne. Czyli dodatki, które mają pomagać. Tak, niby ulepszają AI, ale mogą zbierać dane. No i samo przechowywanie danych w chmurze przez dostawców AI. Kwestia współdzielenia infrastruktury, czyli multitenancy. Lokalizacja danych, jeśli narzędzie jest hostowane powiedzmy w Chinach. Lokalne prawo może zmusić dostawcę do udostępnienia danych. No i logi systemowe, które mogą zawierać fragmenty naszych zapytań. Dobrze. To w obliczu tych wszystkich zagrożeń, co można zrobić?

Jak się chronić? Co mogą zrobić użytkownicy, zespoły, a co firmy? Zacznijmy od nas samych, od zespołów. Absolutna podstawa. Nie wprowadzać żadnych danych wrażliwych do publicznych, ogólnodostępnych narzędzi AI. I trzeba jasno w firmie określić, co jest wrażliwe. Kod, dane klientów, finanse, strategie. To musi być jasne dla wszystkich. Potem ustawienia prywatności. Wyłączajmy zgodę na trening modeli tam, gdzie się da. Zrozummymy, jak działa retencja danych, zwłaszcza po tych zmianach w OpenAI. I wielka ostrożność z darmowymi, nieznanymi narzędziami i wtyczkami. No i podstawy cyberhigieny. Silne, unikalne hasła, włączone MFA, czyli uwierzytelnianie wieloskładnikowe.

Zasada minimalnych uprawnień. Generalnie traktujmy publiczne AI jak pomocnego, ale jednak obcego. Nie powierzamy mu firmowych sekretów. Nie mogą robić na co dzień. Dla nich kilka rzeczy jest kluczowych. Po pierwsze, zawsze przegląd kodu przed wklejeniem czegokolwiek do AI, nawet do pomocy w debugowaniu. Po drugie, jeśli AI ma analizować dane, to te dane muszą być zaanonimizowane lub zamaskowane. Żadnych danych osobowych czy firmowych. Po trzecie, najważniejsze, używać tylko narzędzi zatwierdzonych przez firmę. Zwykle to będą te bezpieczniejsze wersje Enterprise z gwarancjami typu ZR. Ok, to przejdźmy na poziom firmy. Jak przedsiębiorstwa mogą systemowo chronić się przed wyciekami, gdy pracownicy używają AI?

Tutaj potrzebujemy już bardziej systemowych rozwiązań. Widzę cztery główne obszary. Cztery filary? Tak, po pierwsze, jasne polityki użytkowania AI, co wolno, czego nie wolno, jakie dane są zakazane, lista zatwierdzonych narzędzi tych enterprise'owych, jak Azure OpenAI, AWS Bedrock, Google Vertex AI, OpenAI Enterprise, Gemini Advanced, no i konsekwencje łamania zasad. Po drugie, szkolenia i świadomość. Polityka to jedno, ale ludzie muszą rozumieć ryzyko. Regularne szkolenia to podstawa. Po trzecie, kontrole techniczne. Tu wchodzą konkretne technologie. Narzenia DLP, Data Loss Prevention, tacy cyfrowi strażnicy, którzy blokują wysyłanie wrażliwych danych do niedozwolonych miejsc. Jak to działa w praktyce? Rozpoznaje numer karty?

Tak, na przykład. Albo fragmenty kodu, słowa kluczowe. Dalej, wzmacnianie wejść i wyjść, input-output hardening, filtrowanie promptów, żeby chronić przed prompt injection i odpowiedzi modelu, żeby usuwać wrażliwe dane. Oczywiście szyfrowanie danych , kontrola dostępu , kontrole sieciowe , ochrona punktów końcowych . No i dokładna ocena ryzyka dostawców AI oraz wdrożenie klasyfikacji danych w firmie. Wspomniałaś o DLP, tych wszystkich kontrolach. Czy to jest realne dla mniejszych firm?

Nie brzmi to tanio ani prosto. To dobre pytanie. Pełen pakiet może być wyzwaniem, ale wiele z tych narzędzi jak DLP czy ochrona endpointów staje się coraz bardziej dostępnych często w ramach szerszych pakietów bezpieczeństwa. Niektóre rzeczy jak RBAC czy szyfrowanie to już standard. Kluczowe jest podejście oparte na ryzyko zidentyfikować, co jest najważniejsze dla naszej firmy i wdrożyć te kontrole, które dają najwięcej ochrony w stosunku do kosztów. Nie wszystko na raz. Czasem dobra polityka i szkolenia są ważniejsze na początek. I czwarty filar – ciągłe monitorowanie i testowanie. To nie jest jednorazowy wysiłek. Trzeba audytować logi, robić testy penetracyjne specyficzne dla AI. Pojawiają się nowe techniki, jak CART , które automatycznie szukają luk, jak wyciek danych czy model inversion.

Tradycyjne cyberbezpieczeństwo to za mało dla AI. Często pada też pytanie, zwłaszcza w firmach pracujących dla klientów, czy można bezpiecznie używać AI do przetwarzania danych tych klientów? Generalnie używanie publicznych narzędzi AI do danych klientów jest ekstremalnie ryzykowne i zazwyczaj niedopuszczalne. Bezpieczeństwo można uzyskać tylko przy wersjach Enterprise z gwarancjami typu Zero Data Retention . Dostawca wtedy zobowiązuje się nie przechowywać ani nie używać tych danych. Ale nawet wtedy często potrzebna jest zgoda klienta i pełna transparentność. Bez tego ryzyko jest po prostu zbyt duże. To naprawdę masa ważnych informacji.

Mam wrażenie, że dobrze rozebraliśmy ten temat ochrony danych w kontekście AI. Mam nadzieję, że było to pomocne dla słuchacy. Dziękujemy, że byliście z nami w Data Zen AI Podcast. Pamiętajcie o subskrypcji na Spotify, Apple Podcasts czy gdziekolwiek słuchacie, żeby nie przegapić kolejnych odcinków. Podzielcie się też swoimi opiniami. Może macie pomysły na tematy związane z AI, które chcielibyście usłyszeć? Dajcie znać, chętnie posłuchamy. Zapraszamy też na stronę datazentop.pl. Tam znajdziecie więcej treści od społeczności Data Zen, o spotkaniach, artykuły, wywiady. Na koniec może taka myśl. Skoro nawet usunięte rozmowy z AI mogą potencjalnie żyć wiecznie w systemach dostawcy, co tak naprawdę oznacza dzisiaj prywatność cyfrowa, jak poza technologią możemy o nią dbać na co dzień?