Bezpieczeństwo danych przy wdrożeniu AI

Bezpieczeństwo danych przy AI rozstrzyga się na etapie architektury, nie po wdrożeniu. Trzeba odpowiedzieć na osiem pytań: jakie dane wchodzą do modelu, gdzie są przetwarzane, kto ma dostęp, co zostaje w logach i jak długo, jakie role wynikają z RODO, co dzieje się przy incydencie oraz czy użytkownik wie, że rozmawia z AI.

Stan prawny tej sekcji: sierpień 2026. To checklista projektowa, nie indywidualna porada prawna.

Odpowiedź „dostawca modelu ma dobrą politykę prywatności” nie jest odpowiedzią na żadne z nich.

1. Jakie dane w ogóle muszą wejść do modelu?

Jednym z podstawowych zabezpieczeń jest minimalizacja: nie wysyłaj tego, co nie jest potrzebne do wykonania zadania.

W praktyce oznacza to trzy techniki:

• Zawężanie kontekstu. Model do klasyfikacji zgłoszenia może nie potrzebować całej historii klienta. Dobrze zbudowany RAG pobiera tylko trafny, możliwie mały zakres źródeł potrzebny do odpowiedzi — co ogranicza ekspozycję danych i koszt przetwarzania.
• Maskowanie identyfikatorów. Numer PESEL, numer umowy lub nazwisko można zastąpić znacznikiem, jeśli zadanie nie wymaga ich znaczenia. Mapowanie umożliwiające przywrócenie danych nadal trzeba chronić i traktować zgodnie z właściwą klasyfikacją; pseudonimizacja nie jest tym samym co anonimowość.
• Podział zadania. Część wymagająca danych wrażliwych może zostać w kodzie, a do modelu trafić wyłącznie fragment wymagający interpretacji tekstu. Możliwość i sens takiego rozdzielenia zależą od procesu oraz kosztu pomyłki.

2. Gdzie dane są przetwarzane?

Trzy opcje z realnymi konsekwencjami:

Opcja	Kontrola	Koszt	Kiedy wybieramy
Model komercyjny przez interfejs dostawcy	umowna	często niski na start	gdy warunki usługi, lokalizacja i poziom wrażliwości danych spełniają wymagania procesu
Model komercyjny z przetwarzaniem w wybranym regionie	umowna plus wymóg lokalizacji	średni	wymóg zgodności co do miejsca przetwarzania
Model otwarty na własnej infrastrukturze	większa, techniczna	wysoki	twarde wymagania dotyczące danych i zespół zdolny zabezpieczyć całość

To decyzja biznesowa, prawna i technologiczna, którą trzeba podjąć przed uruchomieniem danych produkcyjnych. Późniejsza zmiana dostawcy lub modelu może wymagać ponownego testu jakości, integracji i zabezpieczeń. Kryteria doboru rozbieramy w czym jest LLM i jak wybrać model.

3. Czy dane trafią do trenowania modelu?

Nie da się odpowiedzieć zbiorczo dla „AI”. Trzeba sprawdzić warunki konkretnego interfejsu, planu i ustawień: cel użycia danych, retencję, dostęp personelu dostawcy, lokalizację przetwarzania oraz możliwość wyłączenia przechowywania. Te zapisy mogą różnić się między produktem konsumenckim i firmowym tego samego dostawcy.

Praktyczna zasada: zapisz to w umowie z dostawcą i w dokumentacji wdrożenia, a nie w mailu. Jeśli wykonawca nie umie wskazać, gdzie to jest uregulowane, to nie zostało rozstrzygnięte.

4. Kto ma dostęp do czego?

Jednym z ryzyk o dużym skutku we wdrożeniach RAG i asystentów wewnętrznych jest zbyt szeroki dostęp: system pobiera materiały, których pytający nie powinien widzieć. Wtedy model może ujawnić warunki umowy lub inny fragment poza uprawnieniami użytkownika.

Uprawnienia muszą działać na poziomie wyszukiwania, nie na poziomie odpowiedzi. To znaczy: system w ogóle nie pobiera fragmentów, do których pytający nie ma dostępu — nie pobiera ich i „grzecznie pomija”. Filtrowanie po fakcie jest złudzeniem bezpieczeństwa, bo model już miał te dane w kontekście.

Wynika z tego mniej oczywista rzecz: system AI nie może nadawać szerszego dostępu niż źródła, a czasem powinien go dodatkowo zawężać. Jeśli w firmie nikt nie wie, kto ma prawo do jakiego folderu, trzeba rozstrzygnąć te zasady przed udostępnieniem asystenta użytkownikom.

5. Co zostaje w logach?

Logi są konieczne — bez nich nie zdiagnozujesz błędnej odpowiedzi ani nie wykryjesz nadużycia. Jednocześnie logi to kopia danych w kolejnym miejscu.

Rozstrzygnięcia, które podejmujemy jawnie na starcie:

• co logujemy: pełną treść zapytań i odpowiedzi, czy tylko metadane i identyfikatory źródeł,
• jak długo trzymamy logi,
• kto ma do nich dostęp,
• czy logi są objęte tymi samymi zasadami retencji, co dane źródłowe.

Log przechowywany bez terminu jest zobowiązaniem, nie zasobem.

6. RODO w praktyce - co trzeba rozstrzygnąć

Bez wykładu prawnego, praktyczna lista rzeczy, które w naszych wdrożeniach domykamy:

• Cel i podstawa prawna dla każdego rodzaju danych i każdego zastosowania.
• Role stron. Administrator ustala cele i zasadnicze sposoby przetwarzania, a podmiot przetwarzający działa w jego imieniu — nie wolno zakładać ról wyłącznie na podstawie nazwy w umowie. Pomagają w tym wytyczne EROD 07/2020.
• Dokumentacja i ocena ryzyka. Rejestr czynności, ocena skutków dla ochrony danych lub umowa powierzenia są wymagane zależnie od roli, skali i ryzyka konkretnego procesu, nie automatycznie w każdym projekcie.
• Transfery poza EOG — czy występują i na jakim mechanizmie prawnym się opierają.
• Realizacja praw osoby. Trzeba umieć odnaleźć, poprawić lub usunąć odpowiednie rekordy także w indeksie, logach i kopiach zgodnie z właściwymi okresami retencji; pełna przebudowa indeksu nie zawsze jest konieczna.
• Minimalizacja i retencja. System dostaje tylko dane potrzebne do celu i nie trzyma ich bezterminowo.

Nie jesteśmy kancelarią i tego nie udajemy. Odpowiadamy za to, żeby architektura pozwalała spełnić te wymogi; ocenę prawną wykonuje Twój prawnik albo inspektor ochrony danych.

7. Co się dzieje, gdy coś pójdzie źle?

Trzy scenariusze, na które trzeba mieć odpowiedź przed wdrożeniem:

• Model odpowiedział nieprawidłowo i ktoś podjął na tej podstawie decyzję. Kto to zauważy i jak? Dlatego przy sprawach obarczonych ryzykiem zostawiamy tryb „system podpowiada, człowiek zatwierdza”.
• Ktoś próbował wyciągnąć z systemu dane, do których nie ma dostępu. Czy jest log? Czy jest alert?
• Dostawca modelu miał awarię albo zmienił warunki. Czy da się przełączyć na inny model bez przepisywania systemu? To wraca do architektury z możliwością wymiany.

8. Czy użytkownik wie, że rozmawia z AI?

Od 2 sierpnia 2026 roku stosuje się zasadniczą część unijnego AI Act. Jego art. 50 wymaga, aby system przeznaczony do bezpośredniej interakcji informował osobę, że rozmawia z AI, chyba że jest to oczywiste w danych okolicznościach. Informacja ma być jasna i przekazana najpóźniej przy pierwszej interakcji; pełny zakres wyjątków i odpowiedzialności opisuje tekst rozporządzenia (UE) 2024/1689.

Praktycznie: nazwij automat w interfejsie, pokaż łatwe przejście do człowieka i nie projektuj rozmowy tak, by użytkownik brał system za pracownika. Dodatkowe obowiązki mogą wynikać z branży i rodzaju zastosowania, więc przed publikacją rozwiązania ocenę powinien zatwierdzić prawnik lub inspektor ochrony danych.

Czego nie da się załatwić technologią

Uczciwie, bo to bywa przemilczane:

• Nie da się w pełni uszczelnić modelu promptem. Instrukcja „nie ujawniaj poufnych informacji” jest wskazówką, nie zabezpieczeniem. Zabezpieczeniem jest to, że model nie dostał tych informacji.
• Nie da się zagwarantować, że model nigdy się nie pomyli. Można ograniczyć częstość i skutki błędów przez ugruntowanie, testy, kontrolę uprawnień oraz bramki zatwierdzania.
• Nie da się rozstrzygnąć odpowiedzialności jednym zdaniem w regulaminie. Role administratora i podmiotu przetwarzającego wynikają z faktycznego wpływu stron na cele i sposoby przetwarzania; trzeba je ustalić dla konkretnego przepływu.

Najczęstsze pytania

Czy bezpieczniej jest postawić model u siebie?

Pod kątem kontroli nad danymi — tak. Pod kątem realnego bezpieczeństwa — niekoniecznie, bo dochodzi utrzymanie serwerów, aktualizacje i zabezpieczenie infrastruktury, czyli praca, którą trzeba wykonać samemu. Własny model to przesunięcie ryzyka, nie jego zniknięcie.

Czy asystent na stronie może wyciągnąć nasze dane wewnętrzne?

Może, jeśli publiczna ścieżka dostanie dostęp do wewnętrznego źródła albo filtr uprawnień będzie wadliwy. Dlatego asystent publiczny i wewnętrzny powinny mieć rozdzielone źródła, tożsamości techniczne, uprawnienia i testy prób wyłudzenia danych.

Kto po naszej stronie musi być w to zaangażowany?

Potrzebne są osoba znająca proces oraz — zależnie od danych i ryzyka — osoba odpowiedzialna za ochronę danych, bezpieczeństwo lub zgodność. Prowadzimy prace techniczne, natomiast właściciel procesu po stronie klienta zatwierdza cel i zakres wykorzystania danych po uwzględnieniu rekomendacji prawnych i technicznych. Formalne role oraz odpowiedzialność trzeba ustalić według rzeczywistego wpływu stron na cele i sposoby przetwarzania, nie tylko według nazwy w umowie.

---

Bezpieczeństwo rozstrzygamy przed pierwszą linią kodu, w fazie projektowania i planowania, a nie po wdrożeniu. Jeśli masz wymogi zgodności i nie wiesz, jak pogodzić je z AI, napisz do nas albo zobacz integracje LLM.