Kupujesz AI do firmy? 10 pytań do dostawcy przed pierwszym promptem

Demo trwa 30 minut. Narzędzie podsumowuje spotkania, czyta dokumenty, odpowiada klientom i obiecuje oszczędzić zespołowi kilka godzin tygodniowo.

Licencję można kupić kartą. Trudniej ustalić, co stanie się z danymi klientów, plikami pracowników, historią rozmów i wynikami wygenerowanymi przez system.

6 sierpnia 2026 r. UODO opublikował listy pytań inicjalnych dotyczących RODO i AI, w tym osobną wersję dla MŚP korzystających z gotowych narzędzi. Kolejność pytań jest trafna: firma powinna najpierw zrozumieć cel, dane i wpływ systemu, a dopiero później oceniać dostawcę oraz dokumenty.

DPA, certyfikat bezpieczeństwa i deklaracja o europejskim regionie danych są ważne. Żaden z tych elementów osobno nie odpowie jednak, czy narzędzie pasuje do konkretnego procesu.

Czego dowiesz się z tego tekstu?

W skrócie

• Zacznij od konkretnego sposobu użycia AI, nie od katalogu funkcji dostawcy.
• Zmapuj prompty, pliki, integracje, wyniki, historię, telemetrię i logi bezpieczeństwa.
• Sprawdź osobno role dostawcy przy świadczeniu usługi, analityce, bezpieczeństwie i rozwoju produktu.
• Ustal, czy dane służą do trenowania, dostrajania lub oceny modeli.
• DPA powinno odpowiadać realnemu przepływowi danych, a nie wyłącznie nazwie produktu.
• Umowa powinna regulować zmiany usługi, incydenty, transfery, usuwanie danych i zakończenie współpracy.

Checklista UODO: od celu do umowy

UODO przygotował kilka list dla organizacji na różnych etapach pracy z AI: wersję ogólną, wersję dla sektora publicznego, praktyczną checklistę dla MŚP oraz wariant rozszerzony, który sygnalizuje również zagadnienia wynikające z AI Act.

Materiał ma charakter pomocniczy. Nie jest wiążącą wykładnią i nie zastępuje analizy ryzyka, oceny skutków dla ochrony danych ani oceny wpływu na prawa podstawowe. Jest jednak dobrym punktem startowym, bo oddziela pytania o sam projekt od pytań o jego zgodność.

To ważne rozróżnienie. Brak odpowiedzi nie zawsze oznacza automatycznie naruszenie RODO. Czasem pokazuje, że organizacja nie zna jeszcze własnego procesu i nie ma materiału potrzebnego do jego oceny.

1. Jaki dokładnie problem rozwiązuje narzędzie?

Ocena powinna dotyczyć konkretnego sposobu użycia, a nie ogólnej kategorii produktu. To samo narzędzie może poprawiać tekst marketingowy, analizować reklamacje albo wspierać ocenę kandydatów. Każdy z tych procesów wykorzystuje inne dane, inaczej wpływa na ludzi i wymaga innych zabezpieczeń.

Opis zastosowania powinien wskazywać:

• kto korzysta z systemu;
• w jakim procesie;
• jakie dane przekazuje;
• jaki wynik otrzymuje;
• kto podejmuje ostateczną decyzję;
• co dzieje się po błędzie systemu.

Hasło „asystent AI dla działu obsługi” jest zbyt ogólne. Trzeba ustalić, czy asystent jedynie redaguje odpowiedzi, sugeruje rozstrzygnięcie, sam wysyła wiadomości, czy może przyznać rabat albo odmówić reklamacji.

2. Jakie dane rzeczywiście trafiają do systemu?

Mapa danych musi obejmować więcej niż sam prompt. Znaczenie mają załączniki, informacje pobierane z integracji, wyniki, wnioski wygenerowane przez model, historia rozmów, logi techniczne i pamięć kontekstowa. Dane osobowe mogą pojawić się również w metadanych albo wyniku, nawet jeśli użytkownik nie wpisał nazwiska wprost.

Warstwa	Przykłady danych
Dane wejściowe	Prompt, e-mail, nagranie, dokument, zdjęcie
Kontekst	Dane z CRM, RAG, baza wiedzy, kalendarz
Wynik	Odpowiedź, podsumowanie, profil, rekomendacja
Telemetria	Identyfikator użytkownika, adres IP, czas użycia
Historia	Zapis rozmów, wersje dokumentów, pamięć agenta
Bezpieczeństwo	Logi dostępu, alerty, zapis sesji administracyjnych

Trzeba też oddzielić dane produkcyjne od danych używanych w testach. Wrzucenie pełnej bazy klientów do pilotażu „żeby sprawdzić jakość” nadal jest przetwarzaniem danych osobowych.

3. Czy dostawca jest procesorem czy administratorem?

Rola wynika z faktycznego wpływu na cele i sposoby przetwarzania. Etykieta w regulaminie nie rozstrzyga sprawy. Dostawca może działać jako podmiot przetwarzający, nazywany też procesorem, gdy wykonuje usługę na polecenie klienta. Przy innych operacjach może samodzielnie ustalać cele i działać jako administrator.

Każdą operację trzeba ocenić osobno. Podział ról powinien obejmować przynajmniej:

• świadczenie głównej usługi;
• utrzymanie i bezpieczeństwo;
• analitykę użycia;
• rozwój produktu;
• trenowanie lub dostrajanie modeli;
• obsługę zgłoszeń i incydentów.

Jeżeli dostawca przetwarza dane wyłącznie na udokumentowane polecenie klienta, potrzebna będzie umowa powierzenia zgodna z art. 28 RODO, zwykle nazywana DPA. Jeżeli wykorzystuje dane do własnych celów, samo nazwanie go procesorem nie wystarczy. Trzeba ustalić cel, podstawę prawną, obowiązki informacyjne i odpowiedzialność.

4. Czy dane służą do trenowania lub ulepszania modelu?

Dostawca powinien jasno określić, czy wykorzystuje prompty, pliki, wyniki, oceny użytkowników albo logi do trenowania, dostrajania lub oceniania modeli. Trzeba sprawdzić ustawienia konta, warunki usługi, DPA i dokumentację produktu. Wyłączenie treningu nie zawsze oznacza wyłączenie każdego ponownego użycia danych.

W dokumentach mogą występować różne cele:

• trenowanie modelu bazowego;
• dostrajanie modelu dla konkretnego klienta;
• ocena jakości odpowiedzi;
• moderacja i zapobieganie nadużyciom;
• rozwój funkcji produktu;
• ręczny przegląd próbek przez personel lub podwykonawców.

Każdy cel wymaga osobnej oceny. Firma powinna też wiedzieć, czy ustawienie wyłączające trening działa domyślnie, czy trzeba je aktywować dla każdego workspace’u albo integracji.

Opinia EROD 28/2024 pokazuje, że ocena modeli AI może wymagać zbadania danych użytych do ich rozwoju, podstawy prawnej i tego, czy model rzeczywiście można uznać za anonimowy. Sama deklaracja dostawcy o anonimowości nie zamyka analizy.

5. Jak długo przechowywane są dane i jak je usunąć?

Retencja powinna obejmować więcej niż historię widoczną dla użytkownika. Trzeba ustalić okres przechowywania promptów, plików, wyników, logów, kopii bezpieczeństwa, pamięci agenta i danych zachowanych przez podprocesorów. Usunięcie rozmowy z interfejsu nie musi oznaczać natychmiastowego usunięcia wszystkich kopii.

Umowa lub dokumentacja powinna odpowiadać:

• jakie są domyślne okresy retencji;
• czy klient może je skrócić;
• kto może usunąć dane;
• jak długo dane pozostają w backupach;
• co dzieje się po zamknięciu konta;
• czy i w jakim zakresie można wycofać dane użyte wcześniej do rozwoju modelu;
• jak dostawca potwierdza wykonanie usunięcia.

Jeżeli dostawca nie pozwala ograniczyć retencji, firma powinna ocenić, czy dany rodzaj informacji w ogóle może trafiać do narzędzia. Czasem właściwą decyzją będzie ograniczenie zastosowania, a nie kolejny akapit w polityce prywatności.

6. Gdzie dane są przetwarzane i kto jest podprocesorem?

Lista lokalizacji centrów danych nie wystarcza. Trzeba sprawdzić podprocesorów, dostęp administracyjny, wsparcie techniczne i transfery w całym łańcuchu usługi. Przetwarzanie w regionie UE może nadal wiązać się z dostępem z państwa trzeciego albo korzystaniem z globalnych usług pomocniczych.

Do przeglądu potrzebne są:

• aktualna lista podprocesorów;
• ich funkcje i lokalizacje;
• sposób informowania o zmianach;
• możliwość zgłoszenia uzasadnionego sprzeciwu;
• podstawa transferu poza EOG;
• zastosowane środki uzupełniające;
• zasady zdalnego dostępu i wsparcia.

Dobrze, jeżeli umowa określa skutek sprzeciwu. Sama możliwość wysłania wiadomości „nie zgadzamy się” niewiele daje, gdy dostawca może odpowiedzieć: „przyjęliśmy do wiadomości”.

7. Jak dostawca zabezpiecza usługę i zgłasza incydenty?

Certyfikat może być ważnym dowodem, ale nie opisuje całego wdrożenia klienta. Ocena powinna uwzględnić kontrolę dostępu, szyfrowanie, izolację klientów, logowanie, zarządzanie podatnościami, ciągłość działania i procedurę incydentową.

Warto ustalić:

• dostępność MFA i SSO;
• podział ról administracyjnych;
• szyfrowanie podczas przesyłania i przechowywania;
• sposób zarządzania kluczami;
• izolację danych klientów;
• zakres logów dostępnych dla klienta;
• testy bezpieczeństwa i obsługę podatności;
• termin pierwszej informacji o incydencie;
• zakres kolejnych aktualizacji i raportu końcowego;
• wsparcie przy realizacji obowiązków z art. 33 i 34 RODO.

Termin dostawcy powinien pozwolić administratorowi wykonać jego własne obowiązki. Klauzula „poinformujemy bez zbędnej zwłoki” bez kanału kontaktu i minimalnego zakresu informacji bywa mało użyteczna w sobotę o 3:00.

8. Czy człowiek naprawdę kontroluje wynik AI?

Nadzór człowieka jest realny, gdy pracownik ma wiedzę, czas, informacje i uprawnienie do zakwestionowania wyniku. Automatyczne zatwierdzanie rekomendacji pod presją kolejki nie daje skutecznej kontroli. Trzeba sprawdzić projekt procesu, a nie tylko obecność przycisku „zaakceptuj”.

Ocena powinna obejmować:

• czy pracownik widzi dane, na których oparto wynik;
• czy zna typowe ograniczenia systemu;
• czy może zmienić decyzję bez dodatkowej zgody;
• czy ma wystarczająco dużo czasu na ocenę;
• czy organizacja analizuje odsetek zmian i automatycznych akceptacji;
• czy osoba, której dotyczy wynik, może uzyskać interwencję człowieka.

Jeżeli wynik AI prowadzi do decyzji wywołującej skutki prawne lub w podobny sposób istotnie wpływającej na osobę, trzeba dodatkowo przeanalizować art. 22 RODO. Obecność pracownika w procesie nie wystarczy, jeśli jedynie bezrefleksyjnie zatwierdza rekomendację systemu.

9. Co stanie się po aktualizacji modelu lub regulaminu?

Usługa AI może zmienić się bez klasycznego wdrożenia nowej wersji po stronie klienta. Dostawca może zastąpić model, dodać podprocesora, zmienić okres retencji albo uruchomić nową funkcję. Umowa powinna określać, które zmiany wymagają informacji, ponownej oceny lub zgody klienta.

Procedura zmian może obejmować:

• zmianę modelu lub jego dostawcy;
• dodanie nowego celu wykorzystania danych;
• zmianę lokalizacji przetwarzania;
• nowego podprocesora;
• zmianę skuteczności albo ograniczeń systemu;
• funkcję zwiększającą autonomię agenta;
• zmianę zasad bezpieczeństwa i retencji.

Przy istotnej zmianie firma powinna mieć czas na test, aktualizację DPIA lub instrukcji i, w razie potrzeby, rezygnację z usługi. DPIA to ocena skutków dla ochrony danych, wymagana wtedy, gdy planowane przetwarzanie może powodować wysokie ryzyko dla praw lub wolności osób.

10. Jak firma odzyska dane i zakończy usługę?

Plan wyjścia powinien określać eksport danych, usunięcie kopii, wyłączenie integracji, odebranie tokenów oraz zachowanie potrzebnych logów i dokumentacji. Bez tych zasad organizacja może zakończyć subskrypcję, ale nadal nie wiedzieć, gdzie znajdują się dane i jak wykazać ich usunięcie.

W umowie warto ustalić:

• format eksportu;
• okres dostępu po wypowiedzeniu;
• pomoc przy migracji;
• termin usunięcia danych;
• sposób potwierdzenia usunięcia;
• zasady dotyczące backupów;
• wyłączenie integracji, kluczy API i kont technicznych;
• usunięcie danych z pamięci kontekstowej i baz RAG.

RAG to mechanizm, w którym system wyszukuje informacje w podłączonych źródłach, na przykład bazie wiedzy klienta, i wykorzystuje je przy tworzeniu odpowiedzi. Exit plan musi więc obejmować nie tylko konto użytkownika, ale też źródła, indeksy i integracje podłączone do usługi.

Kazus modelowy: AI ocenia reklamacje, człowiek naciska Enter

Sklep internetowy wdraża usługę AI do obsługi reklamacji. System czyta wiadomości klientów, pobiera historię zamówień z CRM, klasyfikuje sprawę, przygotowuje rekomendację i tworzy gotową odpowiedź dla pracownika.

Podczas pilotażu firma korzysta z prawdziwych zgłoszeń. Dokumentacja dostawcy mówi, że dane klientów biznesowych nie są używane do trenowania głównego modelu. Inny punkt pozwala jednak używać telemetrii i wybranych fragmentów interakcji do oceny jakości oraz bezpieczeństwa.

Historia rozmów znika z panelu po 30 dniach, ale logi techniczne pozostają przez rok. Jeden z podprocesorów zapewnia moderację treści spoza EOG.

Pracownik formalnie zatwierdza każdą odpowiedź. Ma jednak kilkadziesiąt spraw dziennie, a interfejs pokazuje gotową decyzję bez jasnego wskazania danych, które wpłynęły na rekomendację. W 96% przypadków pracownicy wybierają domyślne „zaakceptuj”.

Firma podpisała DPA, ale nadal nie ustaliła:

• dokładnych celów ponownego użycia danych;
• retencji poszczególnych warstw;
• zasad transferu do podprocesora;
• sposobu realizacji praw klienta;
• kryteriów rzeczywistego nadzoru pracownika;
• procedury po błędnej odmowie reklamacji;
• sposobu wycofania danych po zakończeniu pilotażu.

Rozsądniejszy proces zacząłby się od mapy przepływu danych i ograniczonego zbioru testowego. Następnie należałoby ustalić role, wyłączyć zbędne użycie danych, skrócić retencję, sprawdzić transfery i zaprojektować ekran tak, aby pracownik widział podstawę rekomendacji. Dopiero później przychodzi czas na pełne wdrożenie.

Jak wykorzystać listę UODO przy zakupie AI?

Lista UODO może stać się punktem wyjścia do wspólnej pracy productu, zakupów, security, IOD i właściciela biznesowego.

Praktyczna kolejność wygląda tak:

• opisz zastosowanie i oczekiwany wynik;
• narysuj przepływ danych;
• sklasyfikuj dane i osoby, których dotyczą;
• oceń wpływ wyniku na człowieka;
• ustal role dostawcy oraz klienta;
• przejrzyj regulamin, politykę prywatności, DPA i listę podprocesorów;
• sprawdź ustawienia produktu i faktyczny zakres usługi;
• oceń bezpieczeństwo i transfery;
• uzgodnij warunki umowy, nadzoru oraz wyjścia;
• przypisz właściciela procesu i termin ponownego przeglądu.

Jeżeli organizacja nie wie, z jakich narzędzi korzystają pracownicy, powinna zacząć od uporządkowania Shadow AI i zasad AI governance. Przy kwalifikacji obowiązków AI Act pomocny będzie tekst o rolach providera i deployera. Jeżeli system kontaktuje się z klientem albo generuje treści syntetyczne, trzeba również sprawdzić obowiązki przejrzystości z art. 50 AI Act.

Dobra umowa zaczyna się przed dokumentami

Umowa z dostawcą AI będzie użyteczna dopiero wtedy, gdy firma wie, co kupuje, jakie dane przetwarza i jak wynik wpływa na ludzi.

DPA, certyfikat i deklaracja o europejskim regionie danych są elementami oceny. Żaden z nich osobno nie odpowie, czy narzędzie pasuje do konkretnego procesu. Najpierw trzeba zrozumieć wdrożenie. Dopiero później można dobrze opisać role, bezpieczeństwo, odpowiedzialność i wyjście z usługi.

Kupujesz lub wdrażasz narzędzie AI?

Pomagam firmom przejść od opisu zastosowania i mapy danych do umowy z dostawcą, DPA, DPIA oraz zasad używania AI. W ramach wsparcia prawnego dla SaaS i platform łączę perspektywę RODO, AI governance, bezpieczeństwa i realnego działania produktu.

Umów 30-minutową konsultację