W biurze często wystarczy chwila pośpiechu: klient przysyła długi opis problemu, pracownik ma przygotować odpowiedź, a najprościej byłoby wkleić całą wiadomość do ChatGPT i poprosić o jej uporządkowanie. Podobnie wygląda praca z umową, reklamacją, logiem systemowym albo listą zgłoszeń. Technicznie jest to łatwe. Prawnie i organizacyjnie może jednak oznaczać przekazanie zewnętrznemu dostawcy danych osobowych, informacji poufnych albo tajemnicy przedsiębiorstwa.
Odpowiedź na pytanie, czy można wklejać dane klientów do ChatGPT, nie brzmi po prostu „tak” albo „nie”. Zależy od rodzaju danych, używanej wersji narzędzia, ustawień prywatności, podstawy prawnej, umów z dostawcą oraz zasad przyjętych w firmie. Najbezpieczniejsza reguła jest prosta: do publicznego lub konsumenckiego okna czatu nie wkleja się surowych danych klientów. Jeżeli zadanie da się wykonać po usunięciu identyfikatorów, trzeba najpierw przygotować oczyszczony materiał.
W praktyce pytania pojawiające się przy takim użyciu AI są bardzo konkretne: czy imię i nazwisko wystarczy, aby uznać tekst za dane osobowe, czy zamiana nazwiska na „Klient A” rzeczywiście chroni prywatność, czy adres e-mail można zostawić, czy płatny plan automatycznie rozwiązuje problem oraz co zrobić, gdy dane zostały już przypadkowo wysłane. Każda z tych kwestii wymaga osobnej oceny.
Codzienna pokusa w biurze: co dzieje się z tekstem wklejonym do ChatGPT?
Okno czatu nie jest prywatnym notatnikiem
Wyszukiwarka internetowa i model generatywny działają inaczej. Wyszukiwarka zwykle otrzymuje zapytanie, aby znaleźć i zaprezentować istniejące strony. Model językowy analizuje natomiast tekst wejściowy, rozpoznaje zależności między jego elementami i tworzy nową odpowiedź na podstawie wzorców wyuczonych wcześniej oraz treści przekazanej w rozmowie. Oznacza to, że dane wpisane w prompt nie są tylko chwilowym poleceniem w rodzaju „znajdź mi stronę”. Stają się materiałem przetwarzanym przez usługę dostawcy. [4]
Gdy pracownik wkleja wiadomość klienta, system może otrzymać jednocześnie imię i nazwisko, numer zamówienia, adres, opis sytuacji, dane dotyczące zdrowia, informacje o płatności i prywatną korespondencję. Nawet jeśli użytkownik prosi wyłącznie o poprawę stylu, cały przekazany tekst staje się częścią przetwarzania. Model nie rozumie, że fragment jest „tylko przykładem” albo „nie powinien być zapamiętany”, jeśli użytkownik nie korzysta z funkcji i konfiguracji, które przewidują odpowiednie ograniczenia.
Pamięć rozmowy a trenowanie modeli AI
Trzeba odróżnić kilka zjawisk, które bywają wrzucane do jednego worka. Po pierwsze, model może korzystać z treści wcześniejszych wiadomości w ramach bieżącej rozmowy, aby zachować kontekst. Po drugie, niektóre usługi mają funkcję pamięci pozwalającą zachowywać wybrane informacje przydatne w kolejnych konwersacjach. Po trzecie, dostawca może wykorzystywać rozmowy z określonych planów lub ustawień do ulepszania usług, w tym do trenowania albo dostrajania modeli. [1]
Te mechanizmy nie są tym samym. Usunięcie rozmowy z interfejsu nie musi oznaczać, że firma może natychmiast wycofać każdy techniczny ślad przetwarzania. Wyłączenie historii może ograniczyć sposób przechowywania lub wykorzystywania rozmów, ale nie zastępuje analizy umowy, lokalizacji przetwarzania i zasad dostawcy. Funkcja „pamięci” również nie jest równoznaczna z trenowaniem modelu.
W przypadku narzędzi komercyjnych szczegółowe zasady zależą od produktu i aktualnej dokumentacji. Wersje przeznaczone dla konsumentów mogą mieć inne ustawienia wykorzystania treści niż plany biznesowe lub rozwiązania API. Dlatego samo zalogowanie do ChatGPT na firmowym adresie e-mail nie daje automatycznie takich samych gwarancji jak formalnie skonfigurowana usługa dla organizacji. [2]
Czy model może „zapamiętać” dane klienta?
Model językowy nie przechowuje rozmowy w taki sam sposób jak człowiek, który pamięta konkretną kartkę. Nie zmienia to faktu, że treść może być zapisana w systemach dostawcy, dostępna w historii, objęta logowaniem, analizą bezpieczeństwa lub wykorzystana zgodnie z warunkami danej usługi. Z punktu widzenia firmy nie wystarczy więc założyć, że „AI tylko wygenerowało odpowiedź”. Trzeba ustalić, gdzie dane trafiły, kto jest ich administratorem lub procesorem i jak długo mogą być przechowywane. [3]
Badania nad wcześniejszymi modelami językowymi pokazywały, że przy specyficznych zapytaniach można było odtwarzać fragmenty danych, na których model był trenowany. Nie oznacza to, że każde pytanie ujawni cudzą rozmowę ani że współczesny system będzie bezpośrednio cytował przesłane dane. Jest to jednak dobry powód, aby nie traktować modelu jak bezpiecznego sejfu. Dane, których firma nie może ujawnić dostawcy usługi, nie powinny trafiać do zwykłego czatu.
RODO i tajemnica przedsiębiorstwa – kiedy prompt staje się problemem prawnym
Dane osobowe nie ograniczają się do numeru PESEL
Dane osobowe to informacje odnoszące się do zidentyfikowanej lub możliwej do zidentyfikowania osoby. Oczywistymi przykładami są imię i nazwisko, adres e-mail, numer telefonu, adres zamieszkania, numer klienta czy identyfikator użytkownika. Jednak także opis sytuacji może identyfikować człowieka, jeśli dotyczy wyjątkowego zdarzenia, konkretnego zamówienia lub łatwo dostępnego kontekstu.
Przykładowo zdanie „Pani Anna Kowalska, zamieszkała przy ulicy X, złożyła reklamację na ekspres do kawy” zawiera dane osobowe wprost. Również zapis „klient z małej miejscowości, który w określonym dniu kupił nietypowy produkt i opisał konkretny wypadek” może pozwolić na identyfikację, nawet po usunięciu imienia. Ryzyko rośnie, gdy tekst zawiera numer zamówienia, adres dostawy, zdjęcie dokumentu, podpis lub dane dostępne w innym systemie firmy.
Osobną kategorię stanowią szczególne kategorie danych, potocznie nazywane danymi wrażliwymi. Informacje o zdrowiu, niepełnosprawności, przekonaniach religijnych, sytuacji rodzinnej czy przynależności związkowej wymagają szczególnej ostrożności. Wysłanie do modelu wiadomości klienta zawierającej opis choroby tylko po to, aby „napisać empatyczną odpowiedź”, może być zupełnie nieproporcjonalne do celu.
Powierzenie przetwarzania a zwykłe korzystanie z aplikacji
Jeżeli firma przekazuje dane osobowe zewnętrznemu dostawcy w celu wykonania usługi, może powstać relacja administrator–podmiot przetwarzający. W takim przypadku konieczne jest ustalenie, czy dostawca działa na udokumentowane polecenia firmy, jakie ma obowiązki, gdzie przetwarza dane, jak chroni informacje, czy korzysta z podwykonawców i jak pomaga realizować prawa osób, których dane dotyczą.
Nie każda konsumencka usługa AI jest skonstruowana jako narzędzie do przetwarzania danych klientów w imieniu przedsiębiorstwa. Regulamin użytkownika indywidualnego może nie zastępować umowy powierzenia zgodnej z wymaganiami RODO. Nie wystarczy też argument, że „dostawca jest dużą firmą” albo że aplikacja ma płatny wariant. Liczy się konkretny produkt, konkretne warunki i konfiguracja.
Przed wdrożeniem trzeba sprawdzić między innymi dokumentację prywatności, warunki przetwarzania danych, listę podprocesorów, mechanizmy transferu poza Europejski Obszar Gospodarczy, okresy retencji, zasady usuwania danych oraz dostępne ustawienia administracyjne. W razie istotnego zakresu przetwarzania pomocna może być ocena skutków dla ochrony danych. Nie jest to zadanie do wykonania wyłącznie przez osobę, która chce szybciej redagować e-maile.
Tajemnica przedsiębiorstwa jest szersza niż dane osobowe
Wklejenie do ChatGPT danych klienta może naruszać RODO, ale nawet tekst bez danych osobowych może być poufny. Dotyczy to między innymi cen negocjowanych z kontrahentem, warunków umowy, planów produktu, marż, kodu źródłowego, procedur reklamacyjnych, informacji o podatnościach i niepublicznych strategii sprzedaży.
Firma powinna ocenić nie tylko to, czyje dane wysyła, lecz także jaką wartość ma informacja. Zanonimizowana umowa może nadal zawierać tajemnicę handlową. Usunięcie nazwy kontrahenta nie chroni przed ujawnieniem nietypowego cennika, sposobu naliczania rabatu czy warunków odstąpienia od współpracy.
Transfer poza EOG i odpowiedzialność organizacji
Usługi chmurowe często korzystają z infrastruktury rozproszonej geograficznie. Użytkownik może nie wiedzieć, w jakim regionie przetwarzana jest konkretna rozmowa ani którzy podwykonawcy mają do niej dostęp. Jeżeli dane trafiają poza Europejski Obszar Gospodarczy, firma musi uwzględnić reguły transferu danych, odpowiednie zabezpieczenia i ocenę ryzyka.
Odpowiedzialność nie znika dlatego, że prompt wysłał pracownik, a nie zarząd. Organizacja powinna zapewnić instrukcje, ograniczyć uprawnienia, przeszkolić personel i reagować na incydenty. Pracownik może naruszyć wewnętrzne zasady, ale brak polityki AI, brak kontroli dostępu i zezwalanie na korzystanie z przypadkowych kont również zwiększają ryzyko po stronie firmy.
Rodzaj informacji
Przykład
Ocena przed wysłaniem do AI
Dane jawne
Opublikowany regulamin, treść komunikatu dostępnego na stronie
Zwykle niższe ryzyko poufności, ale nadal trzeba sprawdzić warunki usługi
Dane identyfikacyjne
Imię, nazwisko, e-mail, telefon, adres
Usunąć lub zastąpić placeholderami, chyba że zatwierdzona usługa i podstawa są odpowiednie
Dane szczególnie chronione
Informacje o zdrowiu, sytuacji rodzinnej lub przekonaniach
Nie wysyłać do zwykłego czatu; rozważyć całkowite pominięcie
Tajemnica przedsiębiorstwa
Niepubliczne ceny, plany, umowy, kod, procedury
Chronić niezależnie od tego, czy tekst zawiera dane osobowe
Trzy codzienne scenariusze pracy: ryzyko i bezpieczniejsze alternatywy
Scenariusz 1: redagowanie odpowiedzi na trudną reklamację
Pracownik działu obsługi otrzymuje wiadomość: klient opisuje wadę produktu, podaje numer zamówienia, adres, telefon i szczegóły dotyczące zdrowia. Prosi ChatGPT: „Napisz spokojną, empatyczną odpowiedź, zaproponuj rozwiązanie i powołaj się na nasze zasady reklamacji”. Wklejenie całej wiadomości może ujawnić znacznie więcej, niż model potrzebuje do wykonania zadania.
Błędny prompt mógłby wyglądać tak:
Napisz odpowiedź do pani Anny Kowalskiej, zamówienie 54821, e-mail anna.kowalska@example.com. Klientka mieszka przy ul. [...] i twierdzi, że po użyciu produktu wystąpiły u niej problemy zdrowotne. Wklejam całą korespondencję: [...]
Bezpieczniejsza wersja usuwa identyfikatory i informacje zbędne dla celu:
Przygotuj projekt odpowiedzi na reklamację dotyczącą wadliwego produktu.
Kontekst: klient zgłasza problem z działaniem produktu i oczekuje wyjaśnienia oraz informacji o dalszej procedurze.
Cel odpowiedzi: zachować spokojny, empatyczny ton, nie przesądzać wyniku postępowania i wskazać, jakie informacje należy przekazać klientowi.
Zasady: nie przywołuj danych osobowych, numerów zamówień ani informacji o stanie zdrowia. Nie obiecuj uznania reklamacji. Pozostaw miejsca na uzupełnienie przez pracownika zgodnie z wewnętrzną procedurą.
Taki prompt ogranicza zakres informacji do tego, co rzeczywiście potrzebne do stworzenia stylu i struktury wiadomości. Pracownik może później uzupełnić zatwierdzony szablon danymi klienta już w firmowym systemie, a nie w narzędziu AI. Warto też osobno sprawdzić, czy wygenerowana odpowiedź nie zawiera obietnicy, przyznania odpowiedzialności albo błędnej podstawy prawnej.
Scenariusz 2: podsumowanie zgłoszeń z działu obsługi
Drugi częsty przypadek pojawia się wtedy, gdy menedżer chce szybko ustalić, jakie problemy powtarzają się w zgłoszeniach. Naturalnym odruchem jest skopiowanie do czatu całej listy ticketów wraz z nazwami klientów, adresami e-mail, numerami spraw i pełną treścią korespondencji.
Ryzyko nie wynika wyłącznie z liczby rekordów. Duży zbiór może ujawniać skalę problemu, zachowania konkretnych klientów, dane dotyczące zakupów albo informacje o produkcie, który nie został jeszcze publicznie opisany. Ponadto model może nadać etykietę na podstawie niepełnych danych, pominąć istotny kontekst lub połączyć dwa pozornie podobne zgłoszenia.
Bezpieczniejszym rozwiązaniem jest przygotowanie wcześniej ograniczonego zestawu danych, na przykład:
identyfikator klienta zastąpić losowym kodem technicznym albo całkowicie usunąć, jeśli nie jest potrzebny;
usunąć dane kontaktowe, adresy, numery przesyłek i szczegóły płatności;
zastąpić pełną wiadomość krótkim opisem problemu;
usunąć informacje zdrowotne, rodzinne i inne szczególne kategorie danych;
ograniczyć zakres czasowy i liczbę rekordów do próby wystarczającej do analizy;
przekazać modelowi jasno określone kryteria kategoryzacji oraz polecenie, aby sygnalizował niepewność.
Przykładowe polecenie może brzmieć:
Na podstawie poniższych, pozbawionych danych identyfikacyjnych opisów zgłoszeń:
1. pogrupuj problemy według prawdopodobnej przyczyny,
2. wskaż trzy najczęstsze kategorie,
3. zaznacz opisy niejednoznaczne,
4. nie twórz wniosków o konkretnych osobach ani o zasadności pojedynczej reklamacji.
Dane:
- ZG-001: opóźnienie dostawy o kilka dni, klient oczekuje informacji o statusie.
- ZG-002: produkt nie uruchamia się po rozpakowaniu, brak dodatkowych objawów.
- ZG-003: naliczono inną kwotę niż prezentowana w koszyku, potrzebna weryfikacja transakcji.
Jeżeli analiza ma wpływać na decyzje dotyczące pojedynczego klienta, wynik AI powinien być wyłącznie materiałem pomocniczym. Ostateczną ocenę powinien wykonać upoważniony pracownik, korzystając z pełnych danych w systemie, do którego model nie ma dostępu.
Scenariusz 3: analiza logu, dokumentu lub kodu przekazanego przez klienta
W dziale technicznym konsultant może chcieć wkleić do AI log błędu, fragment konfiguracji albo załącznik przesłany przez użytkownika. Taki materiał bywa szczególnie zdradliwy, ponieważ oprócz samego komunikatu technicznego może zawierać adresy IP, identyfikatory sesji, nazwy użytkowników, ścieżki plików, tokeny, klucze API lub dane zapisane w treści błędu.
Przed wysłaniem materiału należy oddzielić część potrzebną do diagnozy od elementów operacyjnych. Token, hasło lub klucz nie staje się bezpieczny tylko dlatego, że znajduje się w logu, a nie w formularzu logowania. W przypadku podejrzenia, że sekret został ujawniony, trzeba postępować zgodnie z procedurą incydentową, w szczególności rozważyć jego unieważnienie i wygenerowanie nowego.
Przykład oczyszczonego zapytania:
Przeanalizuj poniższy komunikat błędu aplikacji działającej w środowisku testowym.
Wskaż możliwe przyczyny, zaproponuj kolejność testów i oddziel hipotezy od pewnych obserwacji.
Zastąpione wartości w nawiasach kwadratowych są elementami usuniętymi przed analizą.
2025-03-08 10:14:22 ERROR
request_id=[ID ŻĄDANIA]
user=[UŻYTKOWNIK TESTOWY]
endpoint=/api/orders
response=500
message="timeout while connecting to database"
W tym scenariuszu nie wystarczy usunięcie nazwy klienta. Trzeba sprawdzić, czy po oczyszczeniu nie pozostały sekrety, dane środowiska produkcyjnego, elementy kodu objęte poufnością albo kombinacja informacji pozwalająca odtworzyć konkretną operację. Przy analizie kodu bezpieczniej jest przekazać mały, samodzielny fragment z fikcyjnymi nazwami niż cały projekt lub plik konfiguracyjny.
Sztuka bezpiecznego promptowania: anonimizacja, pseudonimizacja i dane syntetyczne
Usunięcie imienia nie zawsze oznacza anonimizację
W praktyce słowo „anonimizacja” bywa używane na określenie każdej modyfikacji tekstu. To uproszczenie może prowadzić do błędnych decyzji. Anonimizacja powinna sprawić, że osoby nie można już zidentyfikować przy użyciu rozsądnie dostępnych środków. Samo skasowanie imienia, zamiana nazwiska na inicjał albo wstawienie określenia „klient” często nie wystarcza.
Jeżeli rekord nadal zawiera dokładną datę, nietypowy produkt, małą miejscowość, wyjątkowy opis zdarzenia i numer sprawy używany w innym systemie, identyfikacja może pozostać możliwa. Im więcej pól można połączyć z innymi źródłami, tym ostrożniej należy używać określenia „anonimowe”.
Pseudonimizacja pomaga ograniczyć ekspozycję, ale nie usuwa obowiązków
Pseudonimizacja polega na zastąpieniu bezpośrednich identyfikatorów innymi oznaczeniami, przy czym istnieje dodatkowa informacja pozwalająca odtworzyć powiązanie z osobą. Przykładem może być zamiana klienta na kod „K-1047” przy zachowaniu tabeli umożliwiającej powrót do prawdziwego rekordu.
To wartościowe zabezpieczenie organizacyjne, ale kod nadal może być daną osobową, jeśli firma ma możliwość przypisania go do konkretnej osoby. Pseudonimizowany tekst nie powinien więc trafiać do dowolnego narzędzia tylko dlatego, że nie zawiera nazwiska. Należy również chronić tabelę powiązań, ograniczyć do niej dostęp i nie wysyłać jej razem z treścią do modelu.
Placeholdery i generalizacja danych
Najprostszą techniką oczyszczania promptu jest zastąpienie informacji znacznikami, na przykład [KLIENT], [NUMER SPRAWY] albo [DATA]. Taki zabieg jest przydatny, ale jego skuteczność zależy od zakresu usuniętych danych. Jeśli pozostały dokładne szczegóły zdarzenia, dane medyczne, adres lub unikalny opis, samo użycie placeholdera nie daje pełnej ochrony.
W wielu zadaniach warto dodatkowo uogólnić informacje. Zamiast dokładnej daty można podać miesiąc, zamiast wieku – przedział, a zamiast adresu – region lub informację o kanale dostawy. Nie należy jednak generalizować w sposób, który zmienia sens potrzebny do analizy. Celem jest znalezienie najmniejszego zestawu danych pozwalającego wykonać konkretne zadanie.
Dane syntetyczne jako materiał do testów i nauki
Dane syntetyczne są tworzone na potrzeby ćwiczeń, testowania procedur lub budowania przykładowych promptów. Mogą przypominać prawdziwe przypadki, ale nie powinny być prostą kopią rzeczywistych rekordów z kosmetycznie zmienionymi nazwami. Jeśli zachowują wszystkie szczegóły prawdziwej sprawy, istnieje ryzyko, że nadal będzie można ją rozpoznać.
Dobry przykład syntetyczny opisuje typowy problem, a nie konkretną osobę. Można określić, że „klient otrzymał produkt z opóźnieniem i pyta o zwrot kosztu dostawy”, bez odwzorowywania rzeczywistej korespondencji, daty, kwoty i historii kontaktów. Do testów klasyfikacji warto przygotować kilka celowo zróżnicowanych przypadków, w tym przypadki niejednoznaczne, zamiast kopiować jeden prawdziwy zbiór.
Praktyczna kolejność oczyszczania promptu
Określ cel. Zapisz, czy potrzebujesz redakcji, streszczenia, klasyfikacji, pomysłów czy analizy technicznej.
Usuń pola niepotrzebne do tego celu. Nie przenoś całego rekordu, jeśli wystarczy krótki opis.
Zastąp identyfikatory. Użyj placeholderów albo pseudonimów, ale pamiętaj, że pseudonimizacja nie zawsze usuwa status danych osobowych.
Uogólnij kontekst. Ogranicz dokładność dat, lokalizacji, kwot i opisów, jeżeli nie jest potrzebna.
Sprawdź tekst po oczyszczeniu. Przeczytaj go jak osoba znająca realia firmy i oceń, czy nadal rozpoznałaby klienta lub sprawę.
Zweryfikuj wynik. Usuń z wygenerowanej odpowiedzi niepotwierdzone fakty, dane ujawnione przez przypadek i sugestie wykraczające poza polecenie.
Darmowy ChatGPT, wersje płatne i API – znaczenie planu, konfiguracji i warunków usługi
Samo oznaczenie „darmowy”, „płatny” albo „API” nie rozstrzyga, czy dane klientów można bezpiecznie przekazywać do usługi. Te warianty mogą różnić się ustawieniami prywatności, retencją, kontrolą administracyjną, sposobem wykorzystywania treści, dostępem do logów, możliwościami zarządzania użytkownikami oraz warunkami umownymi.
Darmowe konto konsumenckie
Darmowe konto jest wygodne do nauki i pracy z treściami publicznymi, lecz zwykle nie powinno być traktowane jako firmowe środowisko do obsługi danych klientów. Konto może nie zapewniać organizacji wymaganej kontroli nad użytkownikami, politykami, audytem i cyklem życia danych. Nie rozwiązuje problemu także używanie prywatnego konta do zadania służbowego.
Pracownik korzystający z takiego konta powinien ograniczyć się do materiałów publicznych, fikcyjnych lub odpowiednio oczyszczonych. Jeżeli firma dopuszcza użycie narzędzia konsumenckiego, zasady powinny jasno określać, jakich informacji nie wolno wprowadzać i w jakich zadaniach AI może być używane.
Plan płatny lub biznesowy
Wersja płatna może oferować dodatkowe zabezpieczenia, administrację i odmienne zasady wykorzystywania danych, ale nie należy wnioskować o nich wyłącznie na podstawie ceny. Przed użyciem trzeba sprawdzić, czy wybrany plan obejmuje organizację, czy administrator może zarządzać kontami i ustawieniami oraz jakie postanowienia dotyczą treści wprowadzanych przez użytkowników.
Istotne jest również wdrożenie konfiguracji, a nie tylko zakup licencji. Firma może mieć dostęp do ustawienia ograniczającego wykorzystanie rozmów, lecz pozostawić je niewłączone. Może też utworzyć przestrzeń zespołową bez określenia, kto ma prawo przesyłać informacje poufne i jak długo przechowywane są dane.
API i własna aplikacja
API daje większą kontrolę nad sposobem wywoływania modelu, filtrowaniem danych, integracją z systemami i projektowaniem interfejsu dla pracowników. Nie oznacza jednak automatycznie, że dane są anonimowe albo że firma spełnia wszystkie wymagania RODO. Odpowiedzialność za to, co aplikacja wysyła, zapisuje i wyświetla, nadal pozostaje po stronie organizacji.
Najczęściej zadawane pytania (FAQ)
Czy można wkleić imię i nazwisko klienta do ChatGPT?
Imię i nazwisko to dane osobowe. Nie należy wklejać ich do zwykłego czatu bez odpowiedniej podstawy, zatwierdzonej usługi i właściwej konfiguracji. Najbezpieczniej zastąpić je neutralnym oznaczeniem, takim jak „Klient A”.
Czy zamiana nazwiska na „Klient A” zawsze anonimizuje dane?
Nie. Tekst może nadal identyfikować osobę przez numer zamówienia, adres, wyjątkowe zdarzenie lub łatwy do ustalenia kontekst. Przed wysłaniem trzeba usunąć wszystkie informacje pozwalające na identyfikację.
Czy płatny plan ChatGPT automatycznie rozwiązuje problem ochrony danych?
Nie. Płatny plan nie zastępuje analizy konkretnego produktu, warunków przetwarzania, retencji danych, podprocesorów, transferów poza EOG ani zasad obowiązujących w firmie.
Czy dane dotyczące zdrowia klienta można wysłać do AI?
Informacje o zdrowiu należą do szczególnie chronionych kategorii danych. Nie powinny trafiać do zwykłego czatu, zwłaszcza gdy nie jest to konieczne do realizacji konkretnego celu.
Co zrobić, jeśli dane klienta zostały już przypadkowo wysłane?
Należy niezwłocznie zgłosić zdarzenie zgodnie z wewnętrzną procedurą, ustalić zakres przekazanych informacji i sprawdzić możliwości usunięcia danych oraz zasady dostawcy. Ocena, czy doszło do naruszenia ochrony danych, powinna zostać przeprowadzona przez osobę lub zespół odpowiedzialny za bezpieczeństwo i ochronę danych.
