Wdrożenie AI w administracji publicznej: transparentność i zgodność

Urząd Gminy Kraków-Krowodrza uruchamia chatbota do obsługi mieszkańców. Po sześciu tygodniach obsługuje 300-400 zapytań dziennie, skraca czas pierwszego kontaktu z 48 do 4 godzin i odciąża pracowników od rutynowych pytań o procedury meldunkowe, harmonogramy odbioru odpadów i terminy składania wniosków. Żadna decyzja administracyjna nie wyszła z modelu. To realistyczny scenariusz, nie obietnica, bo granica między pomocą informacyjną a decyzją administracyjną jest twarda i nie można jej przekroczyć bez złamania prawa.

Poniżej opisuję, gdzie ta granica przebiega, jakie wymogi nakłada na JST AI Act i RODO, oraz jak zbudować architekturę, która jest zgodna, transparentna i możliwa do utrzymania przez typowy urząd bez dziesiątek specjalistów IT.

Sektor publiczny ma ograniczone pole manewru, ale nie jest bezużyteczne. Trzy kategorie zastosowań są technicznie wykonalne i prawnie bezpieczne przy właściwej architekturze.

Informacja z bazy wiedzy. Agent RAG zaindeksowany na dokumentach urzędowych (regulaminy, BIP, wzory pism, FAQ, harmonogramy) odpowiada na pytania mieszkańców w języku naturalnym z cytowaniem źródeł. Model nie tworzy treści z wyobraźni, tylko wyszukuje i parafrazuje publicznie dostępne dokumenty. Przy odpowiednim guardrails system odmawia odpowiedzi poza zakresem dokumentacji i eskaluje do pracownika. Przykładowe pytania: „Jakie dokumenty potrzebuję do zameldowania?", „Kiedy można składać wnioski o 500+?", „Gdzie reklamować nieodebrane śmieci?"

Routing spraw. Klasyfikator na podstawie treści zgłoszenia określa właściwy wydział i pilność. Mieszkaniec opisuje sprawę w jednym formularzu, system przypisuje ją do wydziału technicznego, finansowego, społecznego lub prawnego bez angażowania pracownika w pierwszym kroku. To structured output z ciasnym schematem: {wydział: enum, pilność: 1-3, kategoria: string, wymaga_weryfikacji: bool}. Decyzję o przekazaniu podejmuje człowiek, AI tylko proponuje.

Wstępne wypełnianie wniosków. Na podstawie danych sesji (np. adres z poprzedniej interakcji) lub informacji podanych przez mieszkańca system prefilluje pola formularza. Mieszkaniec weryfikuje każde pole i zatwierdza przed złożeniem. Model nie składa wniosku za mieszkańca: pomaga go przygotować. To typowy agent tool-use z akcją fill_field, bez akcji submit_form bez potwierdzenia człowieka.

Decyzja administracyjna w rozumieniu art. 104 KPA to jednostronne rozstrzygnięcie organu kształtujące prawa lub obowiązki strony. Zezwolenie, odmowa, nakaz, zakaz, wymierzenie opłaty. Żadna z tych czynności nie może być wynikiem autonomicznej decyzji systemu AI, nawet jeśli technicznie byłoby to możliwe.

Powody są dwa. Prawny: KPA wymaga, by decyzję podpisał upoważniony pracownik lub organ, który ponosi odpowiedzialność prawną. AI nie jest podmiotem prawnym. Etyczny i regulacyjny: AI Act w Załączniku III pkt 1 i 5 klasyfikuje jako wysokiego ryzyka systemy AI używane do decyzji o dostępie do usług publicznych, świadczeń socjalnych i oceny ryzyka prawnego. Dla takich systemów wymogi są surowe: dokumentacja techniczna, logi audytowe, human-oversight jako warunek operacyjny, explainability na żądanie.

Praktyczne przykłady granicy:

• Chatbot może powiedzieć „do ubiegania się o zasiłek potrzebujesz dokumentów X, Y, Z". Nie może powiedzieć „twój wniosek zostaje odrzucony".
• Agent routingowy może zasugerować wydział. Pracownik decyduje, czy zgłoszenie trafia do tego wydziału.
• System prefillujący może wpisać PESEL z danych sesji. Mieszkaniec weryfikuje i zatwierdza przed złożeniem.

AI Act traktuje sektor publiczny z podwyższoną czujnością. Organy administracji publicznej używające systemów AI w obszarach wymienionych w Załączniku III mają status deployer systemów wysokiego ryzyka z pełnym zestawem obowiązków.

Kluczowe obowiązki deployera dla JST:

Rejestr systemów AI. Każdy system wysokiego ryzyka musi być wpisany do rejestru prowadzonego przez organ. Dla systemów używanych wobec mieszkańców dotyczy to m.in. systemów oceny wniosków, scoringu w dostępie do usług i monitoringu przestrzeni publicznej.

Dokumentacja techniczna. Deployer musi posiadać dokumentację techniczną systemu dostarczoną przez dostawcę. W zamówieniach publicznych warto już na etapie SIWZ wymagać od dostawcy dokumentacji zgodnej z AI Act (art. 11 i Załącznik IV).

Nadzór ludzki. Art. 26 ust. 1 AI Act: deployer wdraża „właściwe środki techniczne i organizacyjne" zapewniające, że osoby wyznaczone do nadzoru mają zdolność do interwencji, rozumieją ograniczenia systemu i mogą go zatrzymać.

Przejrzystość wobec osób fizycznych. Art. 50 AI Act: jeśli system AI wchodzi w interakcję z osobami fizycznymi (chatbot obsługi mieszkańców), musi ujawniać, że jest systemem AI. Brak ujawnienia jest naruszeniem niezależnie od tego, czy system podejmuje decyzje czy tylko dostarcza informacji.

Szczegóły klasyfikacji i obowiązków opisujemy w artykule o AI Act i RODO 2026 dla firm oraz o systemach wysokiego ryzyka.

Przetwarzanie danych osobowych przez system AI w urzędzie wymaga kilku kroków, które muszą poprzedzać uruchomienie produkcyjne.

Podstawa prawna przetwarzania. Dla JST podstawą jest najczęściej art. 6 ust. 1 lit. e RODO (zadanie w interesie publicznym lub sprawowanie władzy publicznej). Ważne: podstawa musi odpowiadać konkretnemu celowi. Zbieranie przez chatbota informacji o sprawie mieszkańca, by ją zaklasyfikować, mieści się w tym zakresie. Profilowanie mieszkańca do innych celów już niekoniecznie.

Umowa powierzenia przetwarzania. Jeśli system AI jest dostarczany przez zewnętrznego dostawcę (SaaS lub on-premise z modelem zewnętrznym), urząd jako administrator danych musi podpisać z dostawcą umowę powierzenia przetwarzania zgodną z art. 28 RODO. Uruchomienie systemu bez tej umowy jest naruszeniem RODO.

DPIA. Ocena skutków dla ochrony danych jest obowiązkowa, gdy przetwarzanie może powodować wysokie ryzyko. Dla systemów AI obsługujących mieszkańców UODO rekomenduje DPIA profilaktycznie: koszt kilku dni pracy jest wielokrotnie niższy niż koszt incydentu. DPIA powinna obejmować opis systemu, ocenę konieczności i proporcjonalności oraz środki ograniczające ryzyko.

PII masking. Dane osobowe mieszkańców nie powinny trafiać do zewnętrznego modelu w postaci jawnej. Architektura: moduł PII masking przed wysłaniem zapytania do modelu, odwrócenie maskowania przy wyświetlaniu odpowiedzi użytkownikowi. Przy self-hosting lokalnego modelu (data-residency w infrastrukturze urzędu) problem jest mniejszy, ale nadal wymaga zarządzania logami.

Informacja o przetwarzaniu (art. 13/14 RODO). Mieszkaniec wchodzący w interakcję z chatbotem AI musi zostać poinformowany o przetwarzaniu danych osobowych: administrator, cel, podstawa prawna, prawa. Wymóg ten nakłada się na wymóg transparentności z AI Act (ujawnienie, że to system AI).

JST rzadko mają własne zespoły AI. Wdrożenie przez zewnętrznego integratora z zachowaniem suwerenności danych urzędu jest możliwe, ale wymaga odpowiednich klauzul w umowie.

Pilot w trybie shadow mode. Przez pierwsze 4-8 tygodni system AI działa równolegle z obecnym procesem: odpowiada na zapytania, ale pracownik weryfikuje każdą odpowiedź zanim trafi do mieszkańca. Zbierasz dane o jakości (co model myli, jakie pytania przekracza jego zakres) bez ryzyka operacyjnego.

Zakres bazy wiedzy. RAG na dokumentach publicznych BIP, regulaminów i wzorów pism jest bezpieczny. Indeksowanie danych osobowych mieszkańców (historia spraw, dane z rejestrów) wymaga analizy prawnej i jest opcją wyłącznie dla infrastruktury własnej urzędu z odpowiednią podstawą prawną.

Guardrails publiczne. Chatbot urzędowy powinien mieć wbudowane ograniczenia: odmowa odpowiedzi na pytania spoza zakresu urzędu, odmowa podawania danych osobowych innych osób, blokada pytań próbujących wyciągnąć dane z systemu, obowiązkowe zdanie kończące każdą odpowiedź informujące o możliwości kontaktu z pracownikiem. Wzorzec guardrails opisujemy w artykule o AI governance w firmie.

Monitoring i raportowanie. Rejestruj: liczbę zapytań, stopę eskalacji do pracownika, tematy pytań (bez PII), ocenę jakości przez mieszkańców. Dla systemów wysokiego ryzyka AI Act wymaga logów audytowych przechowywanych przez okres wystarczający do wykazania zgodności. Praktycznie: 24 miesiące dla systemów administracyjnych. Narzędzia do planowania wdrożenia: blueprint agenta i kalkulator ROI.

Opisz swoje wdrożenie lub planowany projekt AI w JST, a model wskaże konkretne wymogi prawne, granice autonomii i rekomendowaną architekturę:

Tak, to obowiązek bezwzględny. Art. 50 AI Act nakłada na deployer systemów AI wchodzących w interakcję z osobami fizycznymi obowiązek ujawnienia, że rozmówca jest systemem AI, chyba że jest to oczywiste z kontekstu. W przypadku chatbota obsługi mieszkańców oczywistość z kontekstu nie wystarczy: urząd powinien wyraźnie oznaczać system jako „asystent AI" lub „chatbot" w interfejsie i przy każdym otwarciu sesji. Brak ujawnienia jest naruszeniem AI Act niezależnie od tego, czy system podejmuje decyzje.

Wspierana tak, podjęta przez AI nie. System AI może przygotować projekt decyzji na podstawie akt sprawy, wskazać brakujące dokumenty, zidentyfikować podobne precedensy w bazie orzecznictwa i zaproponować treść uzasadnienia. Jednak decyzja w rozumieniu art. 104 KPA musi być podpisana przez upoważnionego pracownika lub organ, który ponosi za nią odpowiedzialność prawną i administracyjną. Human-oversight nie jest tu opcją: jest warunkiem legalności.

DPIA jest obowiązkowa przy przetwarzaniu danych osobowych mogącym powodować wysokie ryzyko. W praktyce dla JST: systemy oceniające wnioski o świadczenia, chatboty zbierające dane osobowe mieszkańców (nawet w formie opisowej), systemy monitoringu z analizą obrazu, systemy przetwarzające dane wrażliwe (zdrowie, niepełnosprawność, status społeczny). UODO rekomenduje podejście profilaktyczne: jeśli istnieją wątpliwości, przeprowadź DPIA. Koszt przygotowania DPIA dla prostego systemu to kilka dni pracy; koszt naruszenia RODO to wielokrotność tego.

Minimum prawne: umowa powierzenia przetwarzania danych osobowych zgodna z art. 28 RODO (cel, zakres, czas, obowiązki dostawcy), klauzula o lokalizacji danych (gdzie dane są przechowywane i przetwarzane, obowiązek utrzymania data-residency w EOG lub w infrastrukturze urzędu), zobowiązanie dostawcy do dostarczenia dokumentacji technicznej wymaganej przez AI Act jeśli system jest klasyfikowany jako wysokiego ryzyka, oraz klauzula umożliwiająca audyt przez urząd lub organ nadzorczy. W zamówieniach publicznych warto uwzględnić te wymagania już w SIWZ, by uniknąć konieczności renegocjacji po podpisaniu umowy.

Przez dwa kanały jednocześnie. Pierwszy: klauzula informacyjna RODO (art. 13) widoczna przy pierwszej interakcji z systemem AI, zawierająca administrator danych, cel i podstawa prawna przetwarzania, prawa mieszkańca (dostęp, sprzeciw, usunięcie). Drugi: oznaczenie interfejsu jako systemu AI zgodnie z AI Act art. 50. Oba wymogi można połączyć w jednym komunikacie powitalnym chatbota. Warto też umieścić skrót informacji w widocznym miejscu interfejsu przez całą sesję, nie tylko przy starcie. Zarówno klauzula RODO, jak i oznaczenie AI powinny być dostępne po polsku bez żargonu prawnego.