Praktyczny przewodnik dla prawników, Inspektorów Ochrony Danych i compliance officerów. GDPR Art. 5/6/9/22/32/35, Schrems II, EU-US Data Privacy Framework, AI Act 2024/1689, DPIA dla AI on-prem, CNIL approach, UODO trend 2024-2026 - w jednym miejscu, z dosłownymi cytatami z aktów prawnych i linkami do oficjalnych źródeł.
Ogólne rozporządzenie o ochronie danych (RODO, GDPR, rozporządzenie (UE) 2016/679) weszło w życie 25 maja 2018 r. i pozostaje aktem fundamentalnym dla każdego wdrożenia AI w Unii Europejskiej. AI Act z 2024 r. nie zastępuje RODO - działa obok niego, a w obszarze danych osobowych pierwszeństwo ma RODO. Dla compliance officera oznacza to, że AI on-prem nie jest „RODO‑safe by design” tylko z hasła „serwer w Polsce", lecz dlatego, że eliminuje cały łańcuch ryzyk transferowych, telemetrycznych i audit-trailowych. Poniżej sześć artykułów RODO, które warto znać dosłownie i po imieniu.
Art. 5 RODO definiuje siedem zasad przetwarzania: legalność, rzetelność i przejrzystość, ograniczenie celu, minimalizacja danych, prawidłowość, ograniczenie przechowywania, integralność i poufność, oraz rozliczalność. To są zasady, na które powołuje się prawie każda decyzja UODO. Architektura on-prem ułatwia minimalizację (dane nie wychodzą poza organizację), ogranicza retencję (administrator ma fizyczną kontrolę nad cyklem życia logów) i wzmacnia rozliczalność (cały audit trail jest lokalny, eksportowalny, podpisany hashem).
Art. 6 RODO wymienia sześć podstaw przetwarzania danych zwykłych: zgoda (lit. a), umowa (lit. b), obowiązek prawny (lit. c), ochrona żywotnych interesów (lit. d), zadanie realizowane w interesie publicznym (lit. e), prawnie uzasadniony interes (lit. f). Dla AI w sektorze prywatnym najczęstszą podstawą jest umowa (np. obsługa klienta biura rachunkowego) lub prawnie uzasadniony interes (np. wewnętrzny asystent compliance) - pod warunkiem przeprowadzenia testu wyważenia (LIA, Legitimate Interest Assessment) i udokumentowania go.
Art. 9 RODO zakazuje przetwarzania danych ujawniających pochodzenie rasowe lub etniczne, poglądy polityczne, przekonania religijne lub światopoglądowe, przynależność do związków zawodowych, danych genetycznych, biometrycznych, dotyczących zdrowia, seksualności i orientacji seksualnej, o ile nie zachodzi jeden z dziesięciu wyjątków z ust. 2 (m.in. wyraźna zgoda, prawo pracy, ochrona żywotnych interesów, działalność polityczna lub religijna, dane upublicznione przez osobę, dochodzenie roszczeń, ważny interes publiczny, profilaktyka zdrowotna, archiwizacja, badania naukowe). Dla kancelarii prawnych obsługujących sprawy medical malpractice albo dla biur rachunkowych prowadzących kadry sektora medycznego oznacza to, że każdy prompt do zewnętrznego LLM-a może zawierać dane szczególnych kategorii, a samo przetwarzanie wymaga podstawy z art. 6 oraz wyjątku z art. 9 ust. 2. To bardzo wysoka poprzeczka dla SaaS AI, znacznie niższa dla on-prem.
Art. 22 RODO jest sercem każdej dyskusji o AI i automatycznym podejmowaniu decyzji. Reguluje on prawo osoby, której dane dotyczą, do tego, by nie podlegała decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu - w tym profilowaniu - wywołującej skutki prawne lub w podobny sposób istotnie na nią wpływającej. Pełny tekst (cytat dosłowny z research GAPS rozdz. 4.4):
„1. The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.
2. Paragraph 1 shall not apply if the decision: (a) is necessary for entering into, or performance of, a contract between the data subject and a data controller; (b) is authorised by Union or Member State law to which the controller is subject and which also lays down suitable measures to safeguard the data subject's rights and freedoms and legitimate interests; or (c) is based on the data subject's explicit consent.
3. In the cases referred to in points (a) and (c) of paragraph 2, the data controller shall implement suitable measures to safeguard the data subject's rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision.
4. Decisions referred to in paragraph 2 shall not be based on special categories of personal data referred to in Article 9(1), unless point (a) or (g) of Article 9(2) applies and suitable measures to safeguard the data subject's rights and freedoms and legitimate interests are in place."
Praktyczne implikacje art. 22 dla AI on-prem są bardzo konkretne. Po pierwsze, jeśli system AI rekomenduje decyzję (np. „zaakceptuj fakturę, bo zgadza się z białą listą") i człowiek tylko klika „OK" bez realnej oceny, organ nadzorczy może uznać to za decyzję zautomatyzowaną w rozumieniu art. 22. Po drugie, ust. 4 wprost zakazuje opierania decyzji zautomatyzowanej na danych szczególnych kategorii (art. 9), chyba że spełnione są wyjątkowo wąskie warunki. Po trzecie, on-prem ułatwia spełnienie obowiązku „prawa do interwencji człowieka", bo cały model, kontekst i ścieżka rozumowania pozostają lokalne i interpretowalne - w odróżnieniu od „czarnej skrzynki" w cudzej chmurze.
Art. 32 RODO nakazuje administratorowi i podmiotowi przetwarzającemu wdrożenie „odpowiednich środków technicznych i organizacyjnych" proporcjonalnych do ryzyka. Praktyka UODO 2024-2026 jasno pokazuje, że organ patrzy na analizę ryzyka jako fundament - kara 40 000 zł dla SPZOZ Pajęczno (decyzja UODO, 2024) zapadła wprost za brak takiej analizy przed atakiem ransomware. AI on-prem domyślnie zmniejsza powierzchnię ataku: mniej transferów poza środowisko klienta, brak domyślnego call-home produktu i mniejsza zależność od zewnętrznych subprocessora w łańcuchu.
Art. 35 RODO wymaga DPIA, gdy przetwarzanie - w szczególności z użyciem nowych technologii - z dużym prawdopodobieństwem może powodować „wysokie ryzyko" naruszenia praw lub wolności osób fizycznych. Ust. 3 lit. b wprost wskazuje przetwarzanie szczególnych kategorii danych z art. 9 lub danych z art. 10 (wyroki) na dużą skalę jako case wymagający DPIA. Wdrożenie AI w kancelarii medycznej, kancelarii prawa pracy z danymi biometrycznymi pracowników czy biurze rachunkowym obsługującym klientów medycznych prawie zawsze wymaga DPIA. Detal w sekcji 5 niżej.
Mapping AI on-prem na sześć artykułów RODO: art. 5 (minimalizacja - dane fizycznie nie wychodzą), art. 6/9 (audit trail wewnętrzny, łatwiejsze udokumentowanie podstawy), art. 22 (interpretowalność z citations zamiast czarnej skrzynki), art. 32 (kontrola nad środkami bezpieczeństwa), art. 35 (DPIA krótszy, bo nie trzeba pokrywać transferu do USA, Schrems II, Cloud Act, FISA 702, podprocesorów). Więcej kontekstu o samym pojęciu „prywatne AI" i jak różni się ono od „lokalnego" lub „on-prem", znajdziesz w dokumencie /docs/ki-prywatne.
16 lipca 2020 r. Trybunał Sprawiedliwości Unii Europejskiej (TSUE) wydał w sprawie C‑311/18 (Data Protection Commissioner przeciwko Facebook Ireland Ltd, Maximillian Schrems) wyrok, który zmienił architekturę globalnego compliance. TSUE unieważnił decyzję adekwatności Privacy Shield (poprzednia rama transferu danych UE-USA), pozostawiając ważność standardowych klauzul umownych (SCC, Standard Contractual Clauses) jako podstawy art. 46 RODO, ale z fundamentalnym zastrzeżeniem: SCC są ważne tylko wtedy, gdy w państwie docelowym istnieje ochrona „zasadniczo równoważna" tej w UE i gdy administrator przeprowadził Transfer Impact Assessment (TIA) oraz wdrożył dodatkowe środki zabezpieczające („additional measures"), jeżeli ocena wskazuje luki.
Najmocniejszy redakcyjnie fragment wyroku to paragraf 184. TSUE pisze tam, że ochrona zapewniana przez mechanizm transferu musi być „actionable in practice" - nie tylko formalna deklaracja w umowie, ale rzeczywista, możliwa do wyegzekwowania ścieżka odwoławcza, gdy organy państwa trzeciego sięgają po dane osób z UE. Cytat dosłowny:
„The protection afforded by that mechanism must, in practice, be actionable."
Tłumaczenie robocze: „Ochrona zapewniana przez ten mechanizm musi być w praktyce możliwa do wyegzekwowania."
Zdanie krótkie, ale skutki dalekosiężne. Każdy administrator danych w UE - w tym polska kancelaria, biuro rachunkowe, szpital, gmina - musi realnie sprawdzić, czy dostawca SaaS w USA jest w stanie zapewnić, że organy amerykańskie nie sięgną po dane klientów. Sam papier kontraktowy nie wystarcza. Polski enterprise użytkownik, który wkleja umowę klienta do ChatGPT, w sensie prawnym dokonuje transferu do państwa trzeciego, a brak adekwatnego „additional measure" eksponuje administratora na karę z art. 83 RODO.
Z punktu widzenia DPIA praktyka jest następująca: jeśli polska kancelaria medyczna używa Microsoft Copilot w Microsoft 365 z data residency Frankfurt, to ocena Schrems II musi zaadresować dwa pytania: (1) czy Microsoft Corporation jako podmiot amerykański może być adresatem nakazu CLOUD Act dla danych przechowywanych w Niemczech? (2) czy istnieją „additional measures" - w tym szyfrowanie po stronie klienta z kluczem, którego Microsoft nie ma - które praktycznie wykluczają dostęp organów USA? Bez pozytywnej odpowiedzi na obu poziomach, transfer pozostaje ryzykowny. Wiele kancelarii w 2024-2026 wybrało prostszą drogę: blokadę cloud AI dla danych klientów medycznych i prawnych, a zamiast tego wdrożenie modelu on-prem (np. BezChmury 11B v3 lub PLLuM) z lokalnym RAG.
Tę logikę kontynuujemy w sekcji 3 - DPF z 2023 r. częściowo obniżył ryzyko transferu, ale tylko dla podmiotów certyfikowanych i tylko w obszarze wprost objętym ramą. Cloud Act i FISA 702 pozostają w tle.
10 lipca 2023 r. Komisja Europejska wydała decyzję wykonawczą (UE) 2023/1795 stwierdzającą, że Stany Zjednoczone zapewniają adekwatny poziom ochrony danych przekazywanych do organizacji amerykańskich uczestniczących w EU‑US Data Privacy Framework (DPF). Decyzja ta jest następczynią Privacy Shield i - w ocenie Komisji - uwzględnia zastrzeżenia z wyroku Schrems II. Dla compliance officera oznacza to, że transfer danych do certyfikowanego uczestnika DPF jest, prima facie, dopuszczalny na podstawie art. 45 RODO bez konieczności oddzielnego TIA. Ale - i to jest kluczowe „ale" - tylko dla podmiotów wprost obecnych na oficjalnej liście DPF i tylko w zakresie ich certyfikacji.
Oficjalna lista uczestników DPF jest publikowana i aktualizowana przez Departament Handlu
USA pod adresem https://www.dataprivacyframework.gov/list.
Dla najczęściej używanych dostawców AI status na dzień 01.05.2026 wygląda następująco
(źródło: research FULL + bezpośrednia weryfikacja URL DPF participant pages):
Compliance officer kontraktujący usługę AI z dostawcą amerykańskim powinien zawsze sprawdzić aktualny status na liście DPF - w umowie wpisać konkretną jednostkę (np. „Microsoft Corporation, certyfikat #6474, zakres: Cloud Service Provider") i zakres usług objętych certyfikacją. Sama marka („Microsoft", „Google", „AWS") nie wystarcza, bo grupa kapitałowa może mieć kilka spółek o różnych statusach.
Clarifying Lawful Overseas Use of Data Act (CLOUD Act) z 2018 r. uprawnia amerykańskie organy ścigania do żądania dostępu do danych przechowywanych przez dostawców podlegających jurysdykcji USA - nawet jeśli serwer fizycznie znajduje się w UE. Mechanizm jest narodowy, oparty na nakazach (warrants) wydawanych przez sądy federalne USA. Spółka amerykańska, niezależnie od regionu data center, jest adresatem takiego nakazu.
Foreign Intelligence Surveillance Act, sekcja 702 (FISA 702) idzie dalej: uprawnia amerykańskie służby wywiadowcze do programowego (programmatic) nadzoru komunikacji osób spoza USA znajdujących się poza USA, gdy komunikacja ta przechodzi przez infrastrukturę amerykańskich „electronic communication service providers". To właśnie FISA 702 była centralnym argumentem TSUE w Schrems II - sąd uznał, że nadzór ten nie spełnia testu „proporcjonalności" wymaganego przez Kartę Praw Podstawowych UE.
Konsekwencja praktyczna dla AI workloads jest następująca:
Diagram poniżej ilustruje zmianę ryzyka transferowego po wprowadzeniu DPF (2023) i po wdrożeniu on-prem (po stronie klienta).
Praktyczna konkluzja sekcji 3: DPF + EU data residency obniża ryzyko, ale nie eliminuje go. On-premise daje twardą pozycję compliance bez konieczności aktywnej obsługi „additional measures" i bez stałego monitoringu listy DPF (która może ewoluować - np. jeśli NOYB skutecznie zaskarży DPF przed TSUE w sprawie „Schrems III", o czym piszemy ostrożnie, bo timeline'u nie da się przewidzieć rzetelnie).
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 z 13 czerwca 2024 r. („AI Act") zostało opublikowane w Dzienniku Urzędowym UE serii L w dniu 12 lipca 2024 r. i weszło w życie 1 sierpnia 2024 r. AI Act jest pierwszym na świecie horyzontalnym aktem prawnym regulującym sztuczną inteligencję - w tym sensie ma znaczenie globalne. Cel rozporządzenia jest zdefiniowany w motywie 1 (Recital 1):
„The purpose of this Regulation is to improve the functioning of the internal market by laying down a uniform legal framework in particular for the development, the placing on the market, the putting into service and the use of artificial intelligence systems (AI systems) in the Union… while ensuring a high level of protection of health, safety, fundamental rights… and to support innovation."
Tłumaczenie robocze: „Celem niniejszego rozporządzenia jest poprawa funkcjonowania rynku wewnętrznego poprzez ustanowienie jednolitych ram prawnych, w szczególności dla rozwoju, wprowadzania do obrotu, oddawania do użytku i stosowania systemów sztucznej inteligencji w Unii… przy jednoczesnym zapewnieniu wysokiego poziomu ochrony zdrowia, bezpieczeństwa i praw podstawowych… oraz wspieraniu innowacji."
Recital 1 jest dla compliance officera czytelnym sygnałem: AI Act nie jest aktem o zakazie AI. Jest aktem o uporządkowaniu rynku, ochronie praw podstawowych i równoczesnym wspieraniu innowacji. Ten sam motyw może być cytowany przez wdrożeniowca jako uzasadnienie projektu („AI Act dopuszcza nasz model, jeśli spełnimy wymogi"), jak i przez prawnika klienta („AI Act wymaga, byś wdrożył to w sposób bezpieczny").
„'AI system' means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments."
Tłumaczenie robocze: „«system AI» oznacza system oparty na maszynie, zaprojektowany do działania z różnymi poziomami autonomii i mogący wykazywać adaptacyjność po wdrożeniu, który - dla celów wyraźnych lub dorozumianych - wnioskuje na podstawie otrzymanego wejścia, jak generować wyniki, takie jak przewidywania, treści, rekomendacje lub decyzje, które mogą wpływać na środowiska fizyczne lub wirtualne."
Definicja jest celowo szeroka. Obejmuje zarówno klasyczne ML (klasyfikator z drzewem decyzyjnym), jak i LLM (Bielik, GPT, Claude). Kluczowe są trzy elementy: (1) machine-based, (2) różne poziomy autonomii, (3) wnioskowanie z input - generowanie output. Asystent KSeF, który czyta pytanie księgowej i zwraca rekomendację z cytatem ustawy, jest „systemem AI" w rozumieniu AI Act.
AI Act został zaprojektowany jako akt etapowo wchodzący w życie. Harmonogram:
Dla compliance officera w polskiej kancelarii lub biurze rachunkowym najważniejszy jest rok 2026: 02.08.2026 to data, od której większość systemów high-risk z Annex III musi być w pełni zgodna. Dobra wiadomość: typowy asystent KSeF on-prem albo asystent compliance dla biura rachunkowego nie jest high-risk. Komisja Europejska w oficjalnym FAQ AI Act Service Desk wyraźnie podkreśla, że klasyfikacja wynika z konkretnego use case'u z Annex III, a nie z samego faktu użycia AI w danym sektorze. „Wewnętrzny asystent dokumentowy" lub „narzędzie Q&A" obsługujące księgową lub prawnika nie staje się automatycznie high-risk, jeśli nie wpisuje się w żadną z kategorii Annex III.
Co wymaga BezChmury jako system AI? Po pierwsze, technical documentation - opis architektury (BezChmury 11B v3, RAG, lokalna baza SSoT 630 faktów), opis danych treningowych modelu bazowego, intended purpose („asystent compliance dla polskich biur rachunkowych i kancelarii"), ograniczenia (zdefiniowany zakres KSeF/RODO/ZUS, brak dziedzin out-of-scope). Po drugie, transparency wobec użytkownika końcowego - informacja, że odpowiedź pochodzi z AI, że może zawierać błędy, że każdy fakt ma cytat źródłowy. Po trzecie, GPAI obligations dla samego modelu BezChmury 11B v3 (po stronie SpeakLeash jako developera). Pomoc dla compliance officera zapewnia AI Act Service Desk Komisji Europejskiej (ai-act-service-desk.ec.europa.eu), gdzie znajdziesz oficjalne FAQ, AI Act Explorer i pomoc kontekstową dla konkretnych use case'ów.
Szczegółowe wskazówki dla wdrożenia BezChmury w infrastrukturze klienta - w tym technical documentation gotowa do audytu - w dokumencie /docs/ksef-bezchmury.
Ocena skutków dla ochrony danych (DPIA, Data Protection Impact Assessment) jest wymagana z art. 35 RODO przy każdym przetwarzaniu wysokiego ryzyka. Europejska Rada Ochrony Danych (EROD/EDPB) w opinii 28/2024 z grudnia 2024 r. wprost wskazuje, że przy AI należy uwzględnić m.in. przetwarzanie szczególnych kategorii danych, zautomatyzowane decyzje lub profilowanie, ochronę danych w fazie projektowania (privacy by design) oraz DPIA. Poniżej dziewięcioskładnikowy template DPIA dla wdrożenia on-prem AI, oparty na strukturze art. 35 ust. 7 RODO i wskazówkach UODO/EDPB.
DPIA dla cloud AI musi pokryć dodatkowe rozdziały: ocena adekwatności transferu (Schrems II, DPF, SCC, TIA), inwentaryzacja podprocesorów (każdy w odrębnej tabeli z lokalizacją i statusem DPF), Cloud Act / FISA 702 risk, mechanizmy odwoławcze dla osób, których dane dotyczą, „additional measures" (w tym szyfrowanie po stronie klienta z kluczem klienta - Customer Key, BYOK). DPIA dla on-prem AI jest krótszy - fokus na lokalne security, retention, model risk, ale bez konieczności spinania łańcucha dziewiętnastu podprocesorów w trzech jurysdykcjach.
Sample DPIA dla BezChmury KSeF Private - przykładowy fragment dla biura rachunkowego obsługującego 80 klientów - zawiera wpisy: cel = „lokalny asystent KSeF i compliance", podstawa = art. 6 ust. 1 lit. b (umowa) + ust. 1 lit. f (prawnie uzasadniony interes wewnętrzny), kategorie danych = księgowe (NIP, REGON, adres, dane kontaktowe, kwoty faktur), retencja logów AI = 24 miesiące, środki = AES-256 disk encryption, RBAC, audit log z hashem każdego zapytania, brak transferu do USA, brak telemetrii zewnętrznej. Ryzyko po środkach: niskie. Konsultacje z UODO: niewymagane. Ten szkic jest punktem wyjścia, nie gotowym dokumentem - każda organizacja ma własną specyfikę i własny IOD.
Komisja Narodowa ds. Informatyki i Wolności (CNIL, Commission Nationale de l'Informatique et des Libertés) jest francuskim regulatorem ochrony danych - odpowiednikiem polskiego UODO. Od 2024 r. CNIL prowadzi action plan dla generative AI, który stał się dla europejskiego compliance jednym z najważniejszych miękkich źródeł interpretacyjnych. CNIL nie zakazuje AI, lecz wymaga „responsible deployment" - odpowiedzialnego wdrożenia z udokumentowaną oceną ryzyka.
Pięć priorytetów CNIL w obszarze AI (na podstawie oficjalnego planu działań i guidance):
„This guide will therefore be relevant for some of the data processing necessary for the design of AI systems, including generative AIs."
Tłumaczenie robocze: „Ten przewodnik będzie więc istotny dla części operacji przetwarzania danych niezbędnych przy projektowaniu systemów AI, w tym generatywnej AI."
CNIL opublikowała też pięć Q&A o generative AI, które są najbardziej praktyczną kompilacją kierunku interpretacyjnego w UE. Najważniejsze odpowiedzi: (1) tak, GAI może przetwarzać dane osobowe, ale wymaga DPIA i przejrzystości; (2) zgoda nie zawsze jest wymagana - prawnie uzasadniony interes (art. 6 ust. 1 lit. f) jest często wystarczający, jeśli przeszedł test wyważenia; (3) dane treningowe mogą być danymi osobowymi i wymagają oceny - w szczególności scraping publicznych danych nie zwalnia z RODO; (4) dane wyjściowe (output) mogą zawierać dane osobowe i muszą być traktowane analogicznie do danych wejściowych; (5) on-premise i lokalne modele zmniejszają powierzchnię ryzyka, ale nie zwalniają z DPIA.
Praktyczna lekcja dla polskiego compliance: UODO prawdopodobnie pójdzie podobną ścieżką. Polskie decyzje 2024-2026 (sekcja 7) pokazują, że organ koncentruje się na analizie ryzyka, środkach zaradczych i dokumentacji, a nie na zakazie konkretnych technologii. Compliance officer, który orientuje się w aktualnym piśmiennictwie CNIL, ma dobrą podstawę do projektowania DPIA - także dla wdrożeń on-prem.
Urząd Ochrony Danych Osobowych (UODO) w latach 2024-2026 wyraźnie przesunął akcent decyzji z formalnych braków obowiązków informacyjnych na analizę ryzyka, adekwatne środki techniczne i organizacyjne (art. 32) oraz terminy zgłaszania naruszeń (art. 33-34). Cztery konkretne case'y, które warto znać:
Komunikat UODO z 13.08.2024. Atak hakerski objął szeroki zakres danych pacjentów i pracowników: dane o zdrowiu, PESEL, rachunki bankowe, dokumenty tożsamości, hasła. UODO zarzucił niewystarczające środki bezpieczeństwa (art. 32) i nieprawidłową analizę ryzyka. To największa kara UODO 2024 dla podmiotu prywatnego.
Atak ransomware. UODO uznał, że administrator nie przeprowadził analizy ryzyka wymaganej przed wdrożeniem środków bezpieczeństwa (art. 24, 32, 34). Decyzja jest ważnym precedensem dla sektora publicznego - pokazuje, że UODO patrzy na proces, nie tylko skutek incydentu.
Zbyt późne zgłoszenie naruszenia (art. 33: 72 godziny od stwierdzenia) oraz opóźnione zawiadomienie osób, których dane dotyczą (art. 34). Case pokazuje, że terminy są twarde - formalne 72 godziny mają znaczenie operacyjne.
Utrata pendrive z danymi osobowymi (w tym danymi zdrowotnymi). UODO zarzucił brak właściwych zabezpieczeń przy nośnikach przenośnych i brak analizy ryzyka (art. 5 ust. 1 lit. f, art. 5 ust. 2, art. 32). Zdarzenie banalne, ale konsekwencje finansowe realne.
W decyzji o sygnaturze DKN.5131.3.2025 UODO domagał się od administratora wskazania, czy przeprowadził analizę ryzyka niezbędną do oceny, czy incydent skutkował naruszeniem wymagającym zgłoszenia organowi i osobom, których dane dotyczą. To jest sygnał kierunkowy: organ nie pyta o modne hasła AI, tylko o udokumentowaną procedurę. Compliance officer wdrażający AI on-prem ma w tym kontekście realną przewagę - architektura lokalna upraszcza dokumentację (mniej podprocesorów, brak transferu, lokalna retencja logów), co bezpośrednio przekłada się na lepszą jakość DPIA.
Na poziomie kar maksymalnych warto pamiętać polską specyfikę: art. 102 ust. 1 ustawy o ochronie danych osobowych ogranicza maksymalną karę administracyjną dla jednostek sektora finansów publicznych z art. 9 pkt 1-12 i 14 ustawy o finansach publicznych do 100 000 zł, a dla jednostek z art. 9 pkt 13 - do 10 000 zł. Dla podmiotów prywatnych obowiązuje próg z art. 83 RODO - do 20 mln euro lub 4% rocznego obrotu, w zależności od tego, która kwota jest wyższa.
Praktyczne wnioski dla wdrożenia AI: każda implementacja w sektorze medycznym lub na danych szczególnych kategorii wymaga DPIA + analizy ryzyka + udokumentowanych środków. On-prem domyślnie zmniejsza powierzchnię ryzyka, ale nie zwalnia z dokumentacji. Case study dla kancelarii medycznej, która wdrożyła BezChmury jako odpowiedź na audit po incydencie UODO, opisaliśmy w /case-studies/kancelaria-marek.
FAQ
Jeśli ten artykuł wskazał luki w Twoim wdrożeniu AI lub potrzebujesz konkretnego DPIA dla on-prem, najszybsza ścieżka to 15-minutowe demo BezChmury KSeF Private. Pokażemy: (1) lokalne działanie modelu BezChmury 11B v3 bez połączenia z internetem, (2) sample DPIA dla biura rachunkowego i kancelarii, (3) RODO compliance flow z audit logiem i eksportem dla audytora, (4) integrację z istniejącym ERP / KSeF / białą listą.
Dominik Witanowski - buduje BezChmury od 2024 r. 10 lat w IT, fokus na source-backed scoring, prywatne RAG dla compliance polskiego sektora księgowego, prawnego i medycznego. Od 2026 r. odpowiedzialny za rodzinę produktów BezChmury (KSeF Private, Księgowy Private, RODO Private, Enterprise On-Prem), opartą o lokalny model BezChmury 11B v3 (SpeakLeash + ACK Cyfronet AGH) z bazą SSoT 630 zweryfikowanych faktów. Wszystkie wdrożenia w architekturze on-premise, RODO-aware, z minimalizacją transferu danych klientów poza środowisko wdrożenia.
Disclaimer. Niniejszy artykuł jest materiałem informacyjnym i nie stanowi porady prawnej. Decyzje compliance dotyczące AI on-prem, DPIA, transferów do państw trzecich i klasyfikacji systemów AI w rozumieniu AI Act powinny być podejmowane w konsultacji z IOD, radcą prawnym lub doradcą podatkowym właściwym dla danej organizacji. Wszystkie cytaty z aktów prawnych pochodzą z oficjalnych źródeł EUR-Lex / CURIA / UODO / CNIL - w razie wątpliwości redakcyjnych prosimy o weryfikację z bezpośrednim tekstem dokumentu.
LISTA BETA · ZNIŻKA 30% PRZED LAUNCH
Dołącz do listy beta – ekskluzywny krąg wczesnych testerów BezChmury. Co 2 tygodnie wysyłam dziennik dewelopera: co buduję, co łamie, co decyduję.
SŁOWNIK POJĘĆ
ŹRÓDŁA
Wszystkie cytaty dosłowne w artykule pochodzą z powyższych oficjalnych źródeł.
Inline odniesienia oznaczone [N] linkują do tej listy.
Krótkie demo KSeF Private (15 min). Pokażemy lokalne działanie, pytania kontrolne, bazę źródeł i sposób, w jaki BezChmury ogranicza ryzyko halucynacji.