Własny model AI w polskiej serwerowni ułatwia spełnienie wymogów AI Act i RODO w jednym konkretnym punkcie: dane nie trafiają do zewnętrznego dostawcy API i nie wyjeżdżają poza Europejski Obszar Gospodarczy. Nie zwalnia jednak z żadnego obowiązku: ani z tych dwóch aktów, ani z NIS2 czy DORA. Ten artykuł porządkuje, co hosting w Polsce faktycznie zmienia, czego nie zmienia i jak przygotować dokumentację przed audytem.
Pytanie, jak pogodzić AI z RODO, wraca na każdym spotkaniu, na którym dział biznesu chce podłączyć model językowy do umów, danych klientów albo dokumentacji kadrowej. Do RODO doszły w ostatnich latach trzy kolejne akty: rozporządzenie o sztucznej inteligencji (AI Act), dyrektywa NIS2 wdrażana w Polsce nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa oraz DORA dla sektora finansowego. Opisujemy stan prawny na listopad 2026 r. z perspektywy zespołu, który utrzymuje serwery GPU i prowadzi audyty zgodności. Artykuł ma charakter informacyjny i nie stanowi porady prawnej.
Gdzie trafiają dane, gdy korzystasz z publicznego API AI
Wysłanie zapytania do publicznego modelu to z punktu widzenia RODO powierzenie przetwarzania danych zewnętrznemu podmiotowi. Warto rozpisać, co dokładnie wychodzi z firmy:
- Treść promptów i odpowiedzi. Jeśli pracownik wkleja fragment umowy, CV kandydata albo opis reklamacji, te dane osobowe trafiają do dostawcy razem z kontekstem.
- Logi i retencja. Dostawcy przechowują zapytania przez określony czas, m.in. w celu wykrywania nadużyć. Okres i zakres retencji zależą od planu i umowy, a nie od Ciebie.
- Podprocesorzy. Za API zwykle stoi łańcuch: dostawca modelu, dostawca chmury, firmy od moderacji treści i wsparcia. Każde ogniwo to podmiot, który musisz znać i zaakceptować.
- Transfer poza EOG. Wielu dostawców przetwarza dane w USA. Transfer opiera się wtedy na EU-US Data Privacy Framework albo standardowych klauzulach umownych. To legalne mechanizmy, ale poprzednie podstawy transferów do USA zostały unieważnione przez TSUE, więc ryzyko zmiany otoczenia prawnego nie jest teoretyczne.
- Wykorzystanie do trenowania. W planach konsumenckich dane bywają domyślnie używane do ulepszania modeli. Plany biznesowe zwykle to wyłączają, ale trzeba to sprawdzić w umowie, a nie w materiałach marketingowych.
Do tego dochodzi problem praktyczny: pracownicy korzystają z prywatnych kont w narzędziach AI, bo firma nie dała im alternatywy. Szerzej opisaliśmy to w artykule jak uniknąć wycieku danych do publicznych AI.
Co zmienia własny model w polskiej serwerowni, a czego nie zmienia
Co zmienia
Model open-weight uruchomiony na serwerze GPU w Polsce usuwa z łańcucha przetwarzania dostawcę API i jego podprocesorów. Dane nie opuszczają EOG, więc rozdział V RODO o transferach w ogóle nie ma zastosowania. Logi, retencję i kopie zapasowe konfigurujesz sam. Wiesz, która wersja modelu odpowiada na zapytania, bo nikt nie podmieni jej bez Twojej wiedzy. Ma to znaczenie przy powtarzalności wyników i późniejszych wyjaśnieniach. Pełną ścieżkę wyboru modelu, sprzętu i sposobu utrzymania opisuje nasz przewodnik po własnym LLM w firmie.
Jeśli serwer stoi u dostawcy infrastruktury (wynajem lub kolokacja), ten dostawca nadal jest podmiotem przetwarzającym. Różnica polega na tym, że to jeden, znany podmiot w Polsce, z umową powierzenia i kontrolą dostępu fizycznego, a nie łańcuch firm w kilku jurysdykcjach.
Czego nie zmienia
- Nadal jesteś administratorem danych. Odpowiadasz za podstawę prawną, cel, minimalizację i informowanie osób, których dane dotyczą.
- Ocena skutków (DPIA) nadal bywa obowiązkowa. Art. 35 RODO dotyczy przetwarzania wysokiego ryzyka niezależnie od tego, gdzie stoi serwer. Ocena danych kandydatów, danych medycznych czy profilowanie klientów zwykle jej wymaga.
- Kontrola dostępu. System RAG podłączony do całego dysku sieciowego pokaże handlowcowi dokumenty kadrowe, jeśli nie przeniesiesz uprawnień do warstwy wyszukiwania.
- Logowanie i retencja. Logi z promptami same są zbiorem danych osobowych. Trzeba określić, kto ma do nich dostęp i kiedy są usuwane.
- Prawa osób. Dostęp, sprostowanie i usunięcie danych dotyczą też indeksów wektorowych i zbiorów do dostrajania modelu.
- Bezpieczeństwo aplikacji. Prompt injection, wyciek danych przez odpowiedzi modelu czy nadmierne uprawnienia agentów to ryzyka, które działają tak samo na własnym serwerze jak w chmurze.
AI Act: role, kategorie ryzyka i harmonogram na listopad 2026
AI Act (rozporządzenie (UE) 2024/1689) wszedł w życie 1 sierpnia 2024 r., a jego przepisy stosuje się etapami. W lipcu 2026 r. harmonogram zmieniło rozporządzenie (UE) 2026/1744, tzw. Digital Omnibus on AI. Zostało opublikowane w Dzienniku Urzędowym UE 24 lipca 2026 r. i weszło w życie 27 lipca 2026 r., kilka dni przed pierwotnym terminem dla systemów wysokiego ryzyka.
| Obowiązki | Stosowane od |
|---|---|
| Praktyki zakazane (art. 5) i kompetencje w zakresie AI (art. 4) | 2 lutego 2025 r. |
| Modele AI ogólnego przeznaczenia (GPAI), dla dostawców modeli | 2 sierpnia 2025 r. |
| Obowiązki przejrzystości (art. 50), np. informowanie, że rozmawia się z AI | 2 sierpnia 2026 r., z okresem przejściowym do 2 grudnia 2026 r. na oznaczanie treści z systemów już wprowadzonych do obrotu |
| Nowe zakazy dodane przez Omnibus (m.in. generowanie intymnych treści bez zgody) | 2 grudnia 2026 r. |
| Systemy wysokiego ryzyka z załącznika III (np. rekrutacja, ocena zdolności kredytowej) | 2 grudnia 2027 r. (pierwotnie 2 sierpnia 2026 r.) |
| Systemy wysokiego ryzyka będące elementem produktów z załącznika I (np. wyroby medyczne) | 2 sierpnia 2028 r. (pierwotnie 2 sierpnia 2027 r.) |
W Polsce od 11 sierpnia 2026 r. obowiązuje ustawa o systemach sztucznej inteligencji. Tworzy ona krajowy system nadzoru, a jej przepisy o kontrolach i karach stosuje się od 28 października 2026 r. Przesunięcie terminów nie oznacza, że temat można odłożyć. Wdrożenie systemu wysokiego ryzyka wymaga zmian w procesach i dokumentacji, a RODO obowiązuje w pełni już dziś.
Dostawca czy podmiot stosujący
AI Act rozróżnia przede wszystkim dostawcę (provider), który wytwarza system AI i wprowadza go do obrotu pod własną nazwą, oraz podmiot stosujący (deployer), który używa systemu w swojej działalności. Firma, która uruchamia na własnym serwerze model open-weight i podłącza go do wewnętrznego asystenta, jest zwykle podmiotem stosującym. Dostawcą modelu GPAI pozostaje jego producent. Granica się przesuwa, gdy:
- oferujesz system AI innym pod własną nazwą lub znakiem towarowym,
- istotnie modyfikujesz system wysokiego ryzyka albo zmieniasz przeznaczenie systemu tak, że staje się systemem wysokiego ryzyka (art. 25),
- w znaczącym stopniu dostrajasz model ogólnego przeznaczenia. Wytyczne Komisji wiążą status dostawcy zmodyfikowanego modelu m.in. ze skalą mocy obliczeniowej użytej do modyfikacji. Typowe dostrajanie LoRA na firmowych danych zwykle tego progu nie osiąga, ale warto to udokumentować.
Kategorie ryzyka w praktyce
| Kategoria | Przykłady | Konsekwencja |
|---|---|---|
| Zakazane | Rozpoznawanie emocji pracowników i kandydatów, scoring społeczny, manipulacja wykorzystująca słabości osób | Nie wolno stosować |
| Wysokiego ryzyka (zał. III) | Filtrowanie CV i ocena kandydatów (pkt 4), ocena zdolności kredytowej osób fizycznych (pkt 5), ocenianie uczniów i studentów (pkt 3) | Pełen zestaw wymogów: nadzór człowieka, logi, jakość danych, informowanie osób |
| Ograniczone (przejrzystość) | Chatbot dla klientów, generowane obrazy i nagrania | Informacja, że użytkownik ma do czynienia z AI, oznaczanie treści |
| Minimalne | Streszczenia dokumentów, tłumaczenia, asystent do kodu, wyszukiwanie w procedurach | Brak szczególnych wymogów AI Act. RODO i bezpieczeństwo obowiązują |
Większość firmowych zastosowań LLM mieści się w kategorii minimalnej. Rekrutacja to najczęstszy przykład, w którym firma nieświadomie wchodzi w obszar wysokiego ryzyka. Rozpisaliśmy go osobno w artykule AI w rekrutacji a AI Act.
NIS2 i KSC: system AI jako element łańcucha dostaw
Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca NIS2, obowiązuje od 3 kwietnia 2026 r. (Dz.U. 2026 poz. 252). Podmioty kluczowe i ważne same oceniają, czy spełniają kryteria, i wpisują się do wykazu. Ustawa przewiduje okresy przejściowe na wdrożenie wymagań. Jeśli Twoja organizacja jest objęta przepisami, system AI z dostępem do danych produkcyjnych to kolejny element, który trzeba objąć zarządzaniem ryzykiem:
- Łańcuch dostaw. Dostawca API AI, dostawca modelu i dostawca infrastruktury to dostawcy usług ICT, których ryzyko oceniasz i dokumentujesz. Pobierając wagi modelu, weryfikuj źródło i sumy kontrolne, tak jak przy każdym innym oprogramowaniu.
- Inwentaryzacja i podatności. Serwer inferencyjny, baza wektorowa i integracje to aktywa z aktualizacjami, skanowaniem i kontrolą dostępu.
- Obsługa incydentów. NIS2 przewiduje wczesne ostrzeżenie w ciągu 24 godzin i zgłoszenie incydentu w ciągu 72 godzin. Żeby ustalić, co wyciekło przez odpowiedzi modelu, potrzebujesz logów, które zbierasz centralnie, np. w SIEM.
Przy publicznym API część tych informacji (logi, lokalizacja, zmiany modelu) jest po stronie dostawcy, a Ty dostajesz tylko to, co przewiduje umowa. Przy własnym modelu masz je u siebie. Jeśli nie wiesz, czy i jak obejmują Cię nowe przepisy, zacznij od audytu NIS2.
DORA: dostawca AI to dostawca usług ICT
DORA (rozporządzenie (UE) 2022/2554) stosuje się od 17 stycznia 2025 r. do banków, firm inwestycyjnych, ubezpieczycieli, instytucji płatniczych i innych podmiotów finansowych. Z perspektywy DORA publiczne API AI to po prostu usługa ICT świadczona przez podmiot trzeci. Oznacza to:
- wpis do rejestru informacji o umowach z dostawcami usług ICT,
- wymagane postanowienia umowne, szczególnie jeśli usługa wspiera funkcje krytyczne lub istotne,
- strategię wyjścia: co robisz, gdy dostawca zmieni warunki, wycofa model albo przestanie działać,
- ocenę ryzyka koncentracji, bo kilku dużych dostawców modeli obsługuje znaczną część rynku,
- uwzględnienie systemu AI w testach odporności operacyjnej i klasyfikacji incydentów.
Model open-weight na dedykowanym serwerze w Polsce ułatwia strategię wyjścia: wagi modelu masz u siebie, a serwer można przenieść lub odtworzyć. Zastosowania finansowe (analiza raportów, KYC, AML) opisujemy w artykule AI w finansach przy wymogach DORA. Ocenę zgodności całego środowiska ICT obejmuje audyt DORA.
Lista kontrolna AI Act i RODO: jak udokumentować AI przed audytem
Poniższa lista to minimum, które warto mieć dla każdego systemu AI pracującego na danych firmy, niezależnie od tego, czy model działa w chmurze, czy na własnym GPU.
| Obszar | Co przygotować | Podstawa |
|---|---|---|
| Rejestr systemów AI | Lista zastosowań: cel, model i wersja, dane wejściowe, właściciel biznesowy, kategoria ryzyka AI Act | AI Act, RODO (rejestr czynności) |
| Rola w AI Act | Notatka: dostawca czy podmiot stosujący, z uzasadnieniem (dostrajanie, własna marka, zmiana przeznaczenia) | AI Act art. 3, 25 |
| Podstawa prawna i DPIA | Podstawa przetwarzania, ocena skutków dla zastosowań wysokiego ryzyka, opinia IOD | RODO art. 6, 9, 35 |
| Lokalizacja i podmioty przetwarzające | Gdzie stoją serwery, umowy powierzenia, lista podprocesorów, ewentualne transfery poza EOG | RODO art. 28, rozdz. V |
| Kontrola dostępu | Kto korzysta z modelu, uprawnienia w RAG zgodne z uprawnieniami do źródeł, MFA do paneli | RODO art. 32, NIS2/KSC |
| Logowanie i retencja | Co logujesz (prompty, odpowiedzi, metadane), gdzie, jak długo, kto ma wgląd | RODO, AI Act (logi dla wysokiego ryzyka), NIS2 |
| Łańcuch dostaw | Źródło wag modelu, licencja, sumy kontrolne, ocena dostawców ICT | NIS2/KSC, DORA |
| Incydenty i ciągłość | Procedura zgłaszania, strategia wyjścia, kopie zapasowe konfiguracji i indeksów | NIS2/KSC, DORA |
| Ludzie | Polityka korzystania z AI, szkolenia, wyznaczone osoby do nadzoru nad wynikami | AI Act art. 4 i 26, RODO |
W mniejszych organizacjach tę listę zwykle prowadzi jedna osoba odpowiedzialna za bezpieczeństwo. Jeśli nie masz takiej osoby na etacie, rolę tę może pełnić vCISO, który połączy wymagania RODO, NIS2 i AI Act w jeden zestaw dokumentów zamiast trzech osobnych.
FAQ: najczęściej zadawane pytania
Czy korzystanie z ChatGPT w firmie jest zgodne z RODO?
Może być, jeśli masz umowę powierzenia z dostawcą, znasz podprocesorów i lokalizację przetwarzania, transfer poza EOG ma podstawę prawną, a pracownicy wiedzą, jakich danych nie wolno wprowadzać. Problemem są zwykle prywatne konta, z których firma nie ma żadnej kontroli.
Czy własny model AI na serwerze w Polsce zwalnia z RODO?
Nie. Eliminuje transfer danych do dostawcy API i poza EOG, ale nadal jesteś administratorem: potrzebujesz podstawy prawnej, kontroli dostępu, zasad retencji logów, a dla przetwarzania wysokiego ryzyka także oceny skutków (DPIA).
Od kiedy obowiązują przepisy AI Act dla systemów wysokiego ryzyka?
Po zmianie wprowadzonej rozporządzeniem (UE) 2026/1744 obowiązki dla systemów z załącznika III, np. w rekrutacji, stosuje się od 2 grudnia 2027 r., a dla systemów wbudowanych w produkty z załącznika I od 2 sierpnia 2028 r. Zakazy z art. 5 obowiązują od lutego 2025 r.
Czy firma używająca modelu open source jest dostawcą w rozumieniu AI Act?
Zwykle nie. Jeśli używasz modelu wewnętrznie, jesteś podmiotem stosującym. Stajesz się dostawcą, gdy oferujesz system innym pod własną nazwą, istotnie modyfikujesz system wysokiego ryzyka lub zmieniasz jego przeznaczenie na wysokiego ryzyka.
Czy DORA zabrania korzystania z publicznych modeli AI?
Nie zabrania, ale traktuje je jak każdą usługę ICT od podmiotu trzeciego: wymaga wpisu do rejestru informacji, odpowiednich postanowień umownych, strategii wyjścia i oceny ryzyka koncentracji.
Chcesz uruchomić model AI na infrastrukturze w Polsce i od razu przygotować ją pod audyt? Zobacz serwery GPU w naszej serwerowni Tier III z certyfikatem ISO 27001 i napisz do nas. Pomożemy dobrać sprzęt i przygotować dokumentację pod AI Act i RODO, a także pod NIS2 i DORA.