Największym problemem RODO przy AI nie jest sam model, tylko przepływ danych. Gdy zapytanie z danymi osobowymi trafia do API w chmurze, opuszcza Twoją kontrolę: pojawia się powierzenie przetwarzania, pytanie o lokalizację serwerów i o to, co dostawca robi z treścią. Self-hosting wycina ten krok.
Co dokładnie zmienia własny model#
- Brak transferu do podmiotu trzeciego — dane zostają na Twoich serwerach lub w Twojej chmurze prywatnej.
- Mniej umów powierzenia — nie powierzasz przetwarzania zewnętrznemu dostawcy LLM.
- Pełna kontrola retencji — sam decydujesz, co i jak długo jest przechowywane, i realnie realizujesz prawo do usunięcia.
- Lokalizacja przetwarzania — wiesz, gdzie fizycznie są dane, bez domysłów o region API.
Fundamentem jest tu nie tylko sam LLM, ale i serwer embeddingów BGE-M3, dzięki któremu RAG na firmowej wiedzy działa lokalnie — wyszukiwanie semantyczne po Twoich dokumentach bez wysyłania ich na zewnątrz.
Poniższa tabela pokazuje, co konkretnie self-hosting zmienia przy każdym z głównych obowiązków RODO względem API w chmurze. Self-hosting nie usuwa żadnego obowiązku — przesuwa tylko punkt kontroli z dostawcy do Ciebie.
| Obowiązek RODO | API w chmurze | Self-hosted LLM |
|---|---|---|
| Podstawa prawna przetwarzania | Twój obowiązek + podstawa dla powierzenia dostawcy | Twój obowiązek; brak osobnej podstawy dla transferu do LLM |
| Minimalizacja danych | Wymaga filtrowania promptu przed wysłaniem na zewnątrz | Dane nie opuszczają organizacji; minimalizacja wciąż zalecana |
| Retencja i usuwanie | Zależna od polityki i logów dostawcy | W pełni po Twojej stronie — własne TTL i procedury kasowania |
| Prawo do usunięcia (art. 17) | Trzeba objąć logi i indeks po stronie dostawcy | Kasujesz u siebie, łącznie z indeksem RAG |
| Transfer poza EOG | Często wymaga SCC / oceny lokalizacji serwerów | Brak transferu, jeśli infrastruktura stoi w EOG |
| Umowa powierzenia (art. 28) | Konieczna z każdym dostawcą przetwarzającym dane | Zwykle niepotrzebna wobec dostawcy modelu — patrz umowa powierzenia danych a AI |
Compliance-by-design, nie po fakcie#
Zgodność projektujemy od początku, a nie doklejamy na końcu. W praktyce oznacza to: minimalizację danych (model dostaje tylko to, co potrzebne), maskowanie PII zanim cokolwiek trafi do modelu, logowanie dostępu i jasne granice tego, co system może zrobić z danymi.
Warto też wcześnie zaplanować ocenę skutków dla ochrony danych (DPIA) — przy przetwarzaniu danych wrażliwych lub na dużą skalę bywa wymagana niezależnie od tego, gdzie stoi model. Szerzej o terminach i obowiązkach AI Act oraz RODO piszemy w przewodniku obowiązki firm w 2026 wg AI Act i RODO.
Wariant hybrydowy: chmura tam, gdzie wolno#
Nie każda ścieżka wymaga lokalności. Dane nieosobowe albo zanonimizowane można obsłużyć mocniejszym modelem w chmurze. Router kieruje wrażliwe zapytania na model lokalny, a resztę na chmurę — i maskuje PII przed jakimkolwiek wyjściem na zewnątrz. W praktyce taki router LLM działa według prostej reguły: jeśli w zapytaniu wykryto dane osobowe, idzie ono w całości na model lokalny; jeśli nie, prompt zostaje zamaskowany, a dopiero zanonimizowana wersja trafia do chmury. Bezpieczeństwo i RODO są ważniejsze niż pojedynczy feature.
Przykładowa ścieżka dla wejścia z PII wygląda tak: wykryj encje (imię, PESEL, adres) → zamaskuj lub kieruj na model lokalny → przetwórz → przywróć kontekst lokalnie w odpowiedzi. Tylko zapytania bez danych osobowych jadą na mocniejszy model w chmurze. Poniżej możesz sprawdzić, jak model rozpisałby taką politykę routingu dla własnego zestawu zadań.
FAQ#
Czy self-hosted LLM oznacza pełną zgodność z RODO?#
Nie automatycznie — ale usuwa najtrudniejszy element, czyli transfer danych poza organizację. Nadal odpowiadasz za podstawę prawną, minimalizację, retencję i prawa osób. Self-hosting daje Ci nad tym pełną kontrolę.
Czy potrzebuję drogiego klastra GPU, żeby trzymać model u siebie?#
Niekoniecznie. Do wielu zastosowań — klasyfikacja, ekstrakcja, RAG po firmowych dokumentach — wystarczy mniejszy model na pojedynczym GPU. Dopiero złożone wnioskowanie, długi kontekst lub wysoka liczba równoległych zapytań uzasadniają mocniejszą maszynę albo klaster. Sprzęt traktujemy jako stały, amortyzowany koszt rozłożony w czasie, a nie opłatę za każde wywołanie — dlatego dobieramy wariant do realnego obciążenia i budżetu. Liczy się przewidywalny koszt, nie maksymalny sprzęt.
Co z danymi, które i tak idą do chmury?#
Maskujemy PII przed wysłaniem, ograniczamy zakres do niezbędnego minimum i kierujemy wrażliwe ścieżki na model lokalny. To podejście hybrydowe: lokalnie tam, gdzie trzeba, chmura tam, gdzie wolno.
Czy self-hosting eliminuje umowę powierzenia całkowicie?#
Nie zawsze. Znika umowa powierzenia z dostawcą modelu, bo to dostawca przestaje przetwarzać dane. Ale jeśli model stoi w cudzej chmurze prywatnej, a infrastrukturę utrzymuje zewnętrzny podmiot, powierzenie (art. 28 RODO) wciąż może być potrzebne wobec tego dostawcy hostingu. Szczegóły opisujemy w artykule o umowie powierzenia danych a AI.
Co z prawem do usunięcia danych w indeksie RAG?#
Indeks wektorowy też zawiera dane osobowe, więc obejmuje go prawo do usunięcia. Przy self-hostingu masz nad tym pełną kontrolę: usuwasz dokument źródłowy, a następnie kasujesz odpowiadające mu wektory i fragmenty z indeksu (oraz z cache odpowiedzi, jeśli istnieje). Warto z góry powiązać identyfikator dokumentu z jego embeddingami, żeby kasowanie było jednym przewidywalnym krokiem, a nie ręcznym przeszukiwaniem bazy.