Czy możemy wprowadzać dane klientów do narzędzi AI?

Zacznij od prawdziwego pytania, nie od narzędzia

Ludzie pytają „czy ChatGPT jest bezpieczny" albo „czy możemy używać AI." Na te pytania nie da się odpowiedzieć, bo bezpieczeństwo nie jest cechą narzędzia. Jest cechą kombinacji: tych danych, w tym planie, na mocy tych umów.

Przeformułuj to jako decyzję z trzema zmiennymi:

1. Jakie to dane. Publiczne, wewnętrzne, poufne, dane osobowe albo dane klienta objęte umową. Kategoria wyznacza dolną granicę tego, co wolno.
2. Które narzędzie i który plan. Darmowe konto osobiste i konto enterprise od tego samego dostawcy działają na zupełnie innych warunkach. Plan częściej ma znaczenie niż marka.
3. Co mówią twoje umowy. Twoje umowy powierzenia (DPA) z klientami, twoje NDA i klauzule dotyczące przetwarzania danych w umowach z klientami mogą zakazywać transferu, na który zgodziłyby się warunki samego dostawcy AI.

Tak wymaga, żeby wszystkie trzy elementy się zgadzały. Nie przy którymkolwiek z nich oznacza nie dla tego konkretnego przypadku, choć redakcja danych albo inny plan często potrafią zamienić to z powrotem w tak. Reszta tego przewodnika przechodzi po kolei przez każdą z tych zmiennych.

Zmienna pierwsza: jakiego rodzaju to dane

Zanim zrobisz cokolwiek innego, nazwij dane. Krótka, konkretna klasyfikacja robi większość roboty, bo zasada „nie wklejaj poufnych informacji" jest zbyt abstrakcyjna, żeby działać w danej chwili, podczas gdy „nie wklejaj list klientów klienta ani nieredagowanych umów do narzędzia poza planem enterprise" to coś, co można zastosować do konkretnej rzeczy przed sobą.

Zestaw kategorii, który działa w praktyce przy tej decyzji:

• Publiczne. Już opublikowane albo do tego przeznaczone. Teksty marketingowe, publiczna dokumentacja, materiały prasowe. Niska stawka w niemal każdym narzędziu.
• Wewnętrzne, niewrażliwe. Zwykły produkt pracy bez danych osobowych czy klienckich i bez ograniczeń umownych.
• Poufne dane biznesowe. Kod źródłowy, niepublikowane plany, cennik, dane finansowe jeszcze nieujawnione publicznie. Wrażliwe dla firmy, niekoniecznie regulowane.
• Dane osobowe. Wszystko, co identyfikuje żyjącą osobę: imiona i nazwiska, e-maile, dane klientów, dane pracowników. Tu wchodzi w grę RODO.
• Dane klienta objęte umową. Dane, które trzymasz dla klienta albo o kliencie, regulowane przez NDA albo umowę z klientem. Tu na wszystko inne nakładają się jeszcze umowy z podmiotami trzecimi.
• Dane szczególnej kategorii i regulowane. Dane zdrowotne, biometryczne, z sektora finansowego albo inne z własnym reżimem prawnym. Domyślnie traktuj jako najwyższy poziom.

Chodzi o to, że odpowiedź różni się w zależności od wiersza. Publiczny szkic jest w porządku w niemal każdym narzędziu. Dane klienta objęte umową mogą być zakazane nawet w pełni funkcjonalnym narzędziu enterprise, jeśli klient nigdy nie zatwierdził tego dostawcy. Większość sporów o użycie AI rozwiewa się, gdy ludzie przestają kłócić się o „AI" i zaczynają nazywać konkretny wiersz.

Zmienna druga: z którego planu faktycznie korzystasz

Druga zmienna to ta, którą ludzie pomijają, a zwykle jest decydująca.

Większość głównych dostawców AI prowadzi dwupoziomowy reżim danych. W planach darmowych i osobistych dane wejściowe zwykle domyślnie zasilają trenowanie modelu, czasem z ukrytą opcją rezygnacji. W płatnych planach biznesowych i enterprise trenowanie na danych klienta jest umownie wykluczone, a umowa powierzenia (DPA) jest dostępna. Na czerwiec 2026 ten wzorzec utrzymuje się w powszechnie używanych asystentach konsumenckich, głównych asystentach programistycznych oraz narzędziach do pisania i wyszukiwania, przy czym dokładne warunki i daty wejścia w życie różnią się między dostawcami i często się zmieniają.

Co to oznacza dla decyzji:

• Darmowe i osobiste konta to warunki konsumenckie, niezależnie od tego, kto z nich korzysta. Pracownik, który loguje się na konto osobiste prywatnym mailem, działa na warunkach konsumenckich, nawet jeśli firma ma umowę enterprise z tym samym dostawcą. Umowa enterprise nie obejmuje tego konta. To właśnie w tej luce siedzi większość realnej ekspozycji.
• Plany enterprise i biznesowe to miejsce, gdzie żyją ochronne ustawienia domyślne. Brak trenowania na twoich danych wejściowych, dostępna umowa powierzenia (DPA), retencja kontrolowana przez admina, a w niektórych przypadkach opcje rezydencji danych. To plany, które sprawiają, że dane poufne, osobowe czy klienckie da się bronić, gdy umowa jest podpisana.
• API ma własne zasady. Dane wejściowe zwykle nie są używane do trenowania, ale standardowe okna retencji API wciąż obowiązują dla monitoringu nadużyć, a tryby zerowej retencji zwykle wymagają osobnego kroku umownego. Nie zakładaj domyślnie, że API to najbardziej rygorystyczna opcja.

Praktyczna konsekwencja: te same dane mogą być jednoznacznym nie na osobistym darmowym koncie i jednoznacznym tak na firmowym tenancie enterprise. Zanim odpowiesz, zweryfikuj, na jakim koncie i planie faktycznie dzieje się ta praca.

Tryby enterprise i no-train

„Tryb enterprise" i „no-train" to zobowiązania, że dostawca nie użyje twoich danych wejściowych do trenowania swoich modeli i zwykle będzie przechowywał twoje dane w bardziej kontrolowanym reżimie. To fundament tego, żeby w ogóle móc wprowadzać wrażliwe dane do narzędzi AI.

Dwa zastrzeżenia. Po pierwsze, zobowiązanie musi być w umowie. Zdanie z centrum pomocy mówiące, że dostawca nie trenuje na danych biznesowych, to obecna praktyka, nie wiążąca gwarancja, i dostawca może ją zmienić. Wersja, która cię chroni, jest zapisana w DPA albo w umowie. Po drugie, brak trenowania różni się od braku retencji. Dostawca może odmówić trenowania na twoich danych, a mimo to przechowywać je przez okno retencji, co samo w sobie jest ekspozycją, jeśli dostawca zostanie naruszony albo zmuszony do ich wydania. Sprawdź obie rzeczy.

Zmienna trzecia: co już mówią twoje umowy

Trzecia zmienna to ta, która łapie ludzi, którzy zrobili wszystko inne dobrze. Nawet przy czystym narzędziu enterprise i podpisanej umowie DPA z dostawcą AI, twoje własne umowy z klientami mogą zakazywać transferu.

Łańcuch DPA i podprocesorzy

Gdy wprowadzasz dane osobowe do narzędzia AI, dostawca AI przetwarza je w twoim imieniu. Na gruncie RODO ty jesteś zwykle administratorem, a dostawca podmiotem przetwarzającym, a artykuł 28 wymaga pisemnej umowy, DPA, określającej przedmiot, czas trwania, charakter i cel przetwarzania, rodzaje danych oraz obowiązki obu stron. Administrator może korzystać tylko z podmiotu przetwarzającego, który daje wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych. Bez tej umowy nie możesz zgodnie z prawem przepuszczać danych osobowych przez narzędzie.

Teraz dodaj łańcuch. Dostawca AI niemal zawsze korzysta z własnych podprocesorów: chmury, na której działa, dostawcy modelu stojącego za funkcją, a często też dostawców analityki, moderacji treści albo bezpieczeństwa. Zgodnie z artykułem 28 podmiot przetwarzający nie może zaangażować kolejnego podmiotu przetwarzającego bez uprzedniej szczegółowej albo ogólnej pisemnej zgody administratora, a gdy stosowana jest zgoda ogólna, podmiot przetwarzający musi informować administratora o planowanych zmianach albo zastąpieniach, tak żeby administrator mógł się sprzeciwić. Te same obowiązki ochrony danych muszą być umownie przekazane w dół, do każdego podprocesora.

To ma znaczenie w dwóch kierunkach. W dół, musisz znać i akceptować podprocesorów dostawcy AI. W górę, twoi własni klienci mają wobec ciebie to samo prawo. Jeśli klient przekazał ci swoje dane na mocy DPA, jesteś jego podmiotem przetwarzającym, a dostawca AI jest twoim podprocesorem. Zwykle potrzebujesz zgody klienta, zanim skierujesz jego dane przez nowego podprocesora, a wiele umów DPA wymaga wcześniejszego powiadomienia i prawa sprzeciwu. Dodanie narzędzia AI do ścieżki danych osobowych klienta bez tego kroku to problem umowny niezależnie od tego, jak dobre są warunki dostawcy AI.

Konflikty NDA i umów z klientami

NDA i umowy z klientami często ograniczają, gdzie mogą trafić poufne informacje, kto może je zobaczyć i jakie podmioty trzecie mogą być w to zaangażowane. Narzędzie AI jest podmiotem trzecim. Wklejenie poufnych informacji klienta do zewnętrznego modelu może być ujawnieniem, na które NDA nie pozwalało, nawet gdy nikt nie miał zamiaru niczego wyciekać i nawet gdy dostawca AI w ogóle nie trenuje na danych wejściowych.

Typowe konflikty:

• Zakres poufności. NDA może ograniczać ujawnienie do nazwanych odbiorców albo osób z uzasadnioną potrzebą wiedzy. Zewnętrzny dostawca AI nie jest ani jednym, ani drugim, chyba że umowa to przewidziała.
• Listy zatwierdzonych podprocesorów albo dostawców. Niektóre umowy z klientami wymagają, żeby klient zatwierdził każdy podmiot trzeci, który dotyka jego danych. Narzędzie AI dodane po podpisaniu zwykle nie jest na tej liście.
• Klauzule lokalizacji danych i bezpieczeństwa. Umowy mogą określać, gdzie dane mogą być przechowywane i jakie zabezpieczenia obowiązują. Konsumenckie narzędzie AI z niejasną rezydencją danych może naruszyć klauzulę, na której zależy klientowi.

Test przed wysłaniem danych klienta to nie tylko „czy dostawca AI na tym trenuje." To też „czy moja umowa z tym klientem w ogóle pozwala, żeby jego dane trafiły do tego dostawcy." Gdy odpowiedź jest niejasna, bezpieczne pozycje to zredagować dane, aż przestaną być poufnymi albo osobowymi danymi klienta, użyć tylko dostawcy zatwierdzonego przez klienta, albo zapytać.

Czy RODO w ogóle pozwala to wysłać

Dla danych osobowych pod całą resztą leżą dwa pytania z RODO.

Podstawa prawna. Artykuł 6 wymaga podstawy prawnej dla przetwarzania danych osobowych, a wprowadzenie tych danych do narzędzia AI jest przetwarzaniem. Sześć podstaw to zgoda, umowa, obowiązek prawny, żywotne interesy, zadanie publiczne i prawnie uzasadniony interes; w kontekście biznesowym zwykłymi kandydatami są prawnie uzasadniony interes albo wykonanie umowy. Użycie narzędzia AI do pracy, którą i tak już zgodnie z prawem wykonujesz, samo w sobie nie tworzy nowej podstawy, a może wprowadzić nowy cel albo nowego odbiorcę, którego twoja pierwotna podstawa i klauzula informacyjna nie obejmowały. Praktyczny test to pytanie, czy osoby, których dane to dotyczą, rozsądnie spodziewałyby się takiego przetwarzania, i czy twój rejestr czynności przetwarzania odzwierciedla obecność narzędzia AI w tej ścieżce.

Umowa powierzenia. Opisana wyżej: tam, gdzie dostawca przetwarza dane osobowe w twoim imieniu, artykuł 28 czyni DPA obowiązkową. Darmowy plan konsumencki zwykle nie oferuje warunków DPA, które uczyniłyby transfer zgodnym z prawem, co jest jednym z powodów, dla których plany konsumenckie zawodzą przy danych osobowych, nawet jeśli są wygodne.

Ekspozycja na kary jest konkretna. Naruszenia obowiązków podmiotu przetwarzającego i administratora z artykułu 28 podlegają artykułowi 83 ust. 4, z administracyjnymi karami pieniężnymi do 10 milionów EUR albo, w przypadku przedsiębiorstwa, do 2 procent całkowitego rocznego światowego obrotu z poprzedniego roku obrotowego, w zależności od tego, która wartość jest wyższa. Nie chodzi o samą nagłówkową liczbę. Chodzi o to, że brakująca albo wadliwa umowa DPA sama w sobie jest naruszeniem, niezależnie od tego, czy wystąpiła jakakolwiek szkoda.

Redakcja i minimalizacja zmieniają odpowiedź

Najbardziej użytecznym ruchem w tej decyzji jest często zmiana danych, nie narzędzia. Minimalizacja danych, kluczowa zasada RODO, mówi, że powinieneś używać nie więcej danych osobowych, niż wymaga tego zadanie. Zastosowana tutaj oznacza usunięcie tego, co czyni dane wejściowe wrażliwymi, zanim trafią do modelu.

Usuń imiona i nazwiska, dane kontaktowe, numery kont i inne identyfikatory, zastąp je placeholderami, a to, co zostanie, może już nie być danymi osobowymi ani poufnymi informacjami klienta. Klauzula umowy ze zmienionymi stronami i liczbami to inne dane wejściowe niż podpisana umowa. Transkrypcja rozmowy z supportem z usuniętą tożsamością klienta to inne dane wejściowe niż oryginał.

Dwa zastrzeżenia utrzymują to w ryzach. Redakcja musi być prawdziwa: dane spseudonimizowane, które da się ponownie zidentyfikować z kontekstu, albo „zredagowany" dokument, w którym imiona i tak da się wywnioskować, to wciąż dane osobowe. A niektóre dane są wrażliwe przez swoją strukturę, nie tylko identyfikatory, więc upewnij się, że to, co zostaje, naprawdę już nie niesie ryzyka. Tam, gdzie redakcja jest solidna, rutynowo zamienia nie w tak, i zwykle jest szybsza niż cykl zakupowy.

Sposób decydowania dla każdego typu danych

Łącząc trzy zmienne, domyślne podejście do obrony wygląda wiersz po wierszu tak. Dostosuj do własnej tolerancji ryzyka i własnych umów, i traktuj to jako punkt wyjścia, nie sztywną zasadę.

• Publiczne · Osobiste / plan darmowy: Ok · Enterprise / plan no-train z DPA: Ok · Uwagi: Brak ograniczenia wartego śledzenia.
• Wewnętrzne, niewrażliwe · Osobiste / plan darmowy: Zwykle ok · Enterprise / plan no-train z DPA: Ok · Uwagi: Niska stawka, ale warto zachować nawyk korzystania z zatwierdzonego planu.
• Poufne dane biznesowe · Osobiste / plan darmowy: Unikaj · Enterprise / plan no-train z DPA: Zwykle ok · Uwagi: Liczy się tu zobowiązanie no-train i realna umowa.
• Dane osobowe · Osobiste / plan darmowy: Nie · Enterprise / plan no-train z DPA: Warunkowo · Uwagi: Wymaga podstawy prawnej z artykułu 6 i umowy DPA z artykułu 28.
• Dane klienta objęte umową · Osobiste / plan darmowy: Nie · Enterprise / plan no-train z DPA: Warunkowo · Uwagi: Nawet przy dobrym narzędziu sprawdź NDA klienta, listę zatwierdzonych dostawców i zgodę na podprocesora.
• Dane szczególnej kategorii albo regulowane · Osobiste / plan darmowy: Nie · Enterprise / plan no-train z DPA: Zależnie od przypadku · Uwagi: Najwyższa poprzeczka, traktuj jako nie, chyba że konkretne narzędzie, plan i umowa wyraźnie to obejmują.

Komórki „warunkowo" to miejsce, gdzie jest robota. Oznaczają, że plan jest konieczny, ale niewystarczający: nadal potrzebujesz podstawy prawnej, DPA i zgody klienta tam, gdzie w grę wchodzą jego dane. Komórki „nie" odzwierciedlają fakt, że warunki konsumenckie nie dają ochrony umownej wymaganej przez te typy danych, a nie jakąś ocenę firmy stojącej za narzędziem.

Żeby to działało w praktyce, połącz tabelę z krótką klasyfikacją zawierającą przykłady z prawdziwej pracy ludzi i opublikowaną listą tego, które narzędzia i plany są zatwierdzone dla których wierszy. Ludzie, którzy widzą usankcjonowaną opcję, przestają improwizować.

Gdzie w tym wszystkim mieści się AI Act, lekko

Unijny AI Act (Rozporządzenie (UE) 2024/1689) reguluje systemy AI według roli i ryzyka, i funkcjonuje obok RODO, nie zamiast niego. Dla tej decyzji jego znaczenie to głównie ramy. Akt definiuje cztery role w artykule 3: provider, deployer, importer i distributor. Gdy kupujesz i używasz narzędzia AI w swojej firmie, zwykle jesteś deployerem, a dostawca jest providerem. Na mocy artykułu 25 deployer może stać się providerem, na przykład umieszczając własną nazwę na systemie wysokiego ryzyka albo istotnie go modyfikując, co ściąga na niego cięższe obowiązki. Większość codziennych pytań typu „czy możemy to tu wkleić" to najpierw pytania o RODO i umowy; AI Act staje się kluczowy, gdy budujesz na modelu albo istotnie go adaptujesz, zamiast używać narzędzia w dostarczonej formie. Tam, gdzie obowiązują wymogi dotyczące wysokiego ryzyka i przejrzystości, większość z nich wchodzi w życie od 2 sierpnia 2026 roku zgodnie z harmonogramem samego aktu; Digital Omnibus, przyjęty przez Parlament i Radę w czerwcu 2026 i oczekujący na publikację w Dzienniku Urzędowym na lipiec 2026, przesuwa samodzielne obowiązki wysokiego ryzyka z Załącznika III na 2 grudnia 2027, podczas gdy przejrzystość zostaje przy 2 sierpnia 2026.

Źródła

• Art. 28 GDPR, Processor · https://gdpr-info.eu/art-28-gdpr/ (obowiązkowa pisemna umowa z podmiotem przetwarzającym, wystarczające gwarancje, wymagane elementy DPA, uprzednia szczegółowa albo ogólna pisemna zgoda na podprocesorów i przekazanie obowiązków w dół łańcucha)
• What needs to be included in the contract? · ICO · https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/contracts-and-liabilities-between-controllers-and-processors-multi/what-needs-to-be-included-in-the-contract/ (wytyczne regulatora dotyczące obowiązkowych warunków DPA na mocy artykułu 28)
• Art. 6 GDPR, Lawfulness of processing · https://gdpr-info.eu/art-6-gdpr/ (sześć podstaw prawnych przetwarzania danych osobowych)
• Guidance on legal bases for processing personal data · Data Protection Commission · https://www.dataprotection.ie/en/dpc-guidance/guidance-legal-bases-processing-personal-data (wytyczne regulatora dotyczące wyboru podstawy prawnej, w tym prawnie uzasadnionego interesu i umowy)
• Art. 83 GDPR, General conditions for imposing administrative fines · https://gdpr-info.eu/art-83-gdpr/ (próg z artykułu 83 ust. 4: do 10 milionów EUR albo 2 procent światowego rocznego obrotu za naruszenia artykułu 28)
• Art. 5 GDPR, Principles relating to processing of personal data · https://gdpr-info.eu/art-5-gdpr/ (zasada minimalizacji danych leżąca u podstaw redakcji i minimalizacji)
• Regulation (EU) 2024/1689 (EU AI Act), EUR-Lex · https://eur-lex.europa.eu/eli/reg/2024/1689/oj (definicje providera, deployera, importera, dystrybutora w artykule 3; artykuł 25 o tym, kiedy deployer staje się providerem; harmonogram stopniowego wejścia w życie)
• What popular AI tools actually do with your data (unshadow IT, June 2026 review of vendor terms) · wewnętrzne źródło zweryfikowanych domyślnych ustawień trenowania konsumenckiego kontra enterprise, dostępności DPA, retencji i wzorców rezydencji danych na czerwiec 2026; przed poleganiem na tych informacjach zweryfikuj aktualne warunki każdego dostawcy bezpośrednio u źródła.