Jak AI może pomóc przy obiegu dokumentów w EZD PUW i SIDAS Madkom?

AI podłączone do EZD PUW lub SIDAS Madkom może realnie wspomóc pracę kancelarii, sekretariatu i referentów w czterech konkretnych miejscach: wyszukuje sprawę po opisie zamiast sygnatury, sygnalizuje sprawy stojące bez ruchu, pilnuje kolejki pism czekających na podpis i dostarcza gotowe zestawienia obciążenia wydziałów. Nie przejmuje decyzji administracyjnych ani nie podpisuje dokumentów za urzędnika. Robi to, co dotąd zajmowało referentowi kilkanaście minut dziennie: przeglądanie rejestrów i sprawdzanie, gdzie sprawa ugrzęzła w obiegu.

Z jakich danych w EZD PUW i SIDAS korzysta AI?

Oba systemy gromadzą ustrukturyzowane dane, które AI może czytać bez ingerencji w samą aplikację i bez zmiany czegokolwiek w bazie. To punkt wyjścia, który warto mieć w głowie: AI pracuje w trybie odczytu.

W EZD PUW najważniejsze źródła to:

• Rejestr Korespondencji Przychodzącej (RKP): numer pisma, data wpływu, nadawca, opis, status dekretacji, powiązana sprawa
• Rejestr Korespondencji Wychodzącej (RKW): data wysyłki, adresat, powiązana sprawa, metoda doręczenia
• Metryka sprawy: sygnatura, symbol JRWA, data wszczęcia, termin załatwienia, prowadzący, wydział, status, historia operacji
• Kolejka dekretacji: pisma oczekujące na przypisanie do sprawy lub referenta przez kierownika wydziału
• Lista podpisów: dokumenty w statusie "oczekuje na podpis" z datą wpłynięcia do kolejki podpisującego

SIDAS Madkom przechowuje te same kategorie, tyle że podzielone na moduły: Kancelaria (rejestracja korespondencji przychodzącej i wychodzącej), Sprawy (teczki i dokumenty), Dekretacja i ePodpis. Nazwy pól mogą się różnić między konfiguracjami poszczególnych urzędów, bo wdrożenia SIDAS bywają mocno dostosowywane do struktury danej jednostki. Przed każdym wdrożeniem sprawdzamy, które pola w konkretnej instalacji są faktycznie i regularnie wypełniane przez pracowników. Jeśli "termin załatwienia" w metryce sprawy uzupełnia tylko co trzeci referent, AI nie ma co monitorować.

Jak AI wyszukuje sprawę, gdy mieszkaniec nie zna numeru?

Każde biuro obsługi interesanta zna ten scenariusz. Dzwoni mieszkaniec i mówi: "chciałem zapytać o ten mój wniosek o warunki zabudowy, składałem gdzieś w maju". Pracownik przy stanowisku musi znać nazwisko, datę albo numer sprawy, żeby cokolwiek znaleźć w systemie. Bez przynajmniej jednej z tych informacji wyszukiwanie w standardowym widoku EZD staje się ręcznym przewijaniem rejestru strona po stronie.

AI podchodzi do tego inaczej. Indeksuje treści pól tekstowych z metryk spraw: imię i nazwisko strony postępowania, opis sprawy, adres nieruchomości, numer działki ewidencyjnej, symbol JRWA, wydział prowadzący. Pracownik wpisuje w okno czatu: "Nowak, warunki zabudowy, działka przy Lipowej". AI przeszukuje indeks i zwraca listę pasujących spraw z sygnaturą, statusem, terminem załatwienia i prowadzącym referentem. Pracownik klika w sygnaturę i otwiera sprawę bezpośrednio w EZD.

Typowo AI zwraca dwie albo trzy sprawy spełniające kryteria, a pracownik wybiera właściwą. Rzadko kiedy opisy są na tyle unikalne, żeby pierwsze zapytanie dawało jedno trafienie. Ale i tak jest szybciej niż ręczny przegląd rejestru. I to jest właśnie granica, której AI nie przekracza: pokazuje wynik, nie otwiera sprawy, nie modyfikuje żadnych pól, nie wysyła nic do mieszkańca.

Kiedy sprawa stoi za długo: jak AI to wykrywa?

W każdym urzędzie zdarzają się sprawy, które grzęzną. Pismo wpłynęło, dostało sygnaturę w RKP, referent dostał dekretację, a potem cisza. Nikt nie wysłał ponaglenia, nikt nie sprawdził. Mieszkaniec pojawi się po sześciu tygodniach i okaże się, że sprawa nie ruszyła od pierwszego dnia.

AI monitoruje datę ostatniej aktywności w sprawie: wpisanie dokumentu, zmiana statusu, wysyłka pisma, dodanie adnotacji przez referenta. W EZD PUW historia operacji daje dokładny obraz każdej czynności w sprawie. W SIDAS pole "data ostatniej czynności" pełni tę samą funkcję. Jeśli sprawa nie miała żadnej aktywności przez ustalony czas, a jej termin załatwienia zbliża się lub już minął, AI generuje alert.

Próg "bez ruchu" ustalamy razem z urzędem i zależy on od charakteru spraw. Dla postępowań z terminem 30-dniowym może to być 7 dni roboczych bez aktywności. Dla decyzji o warunkach zabudowy albo pozwoleń środowiskowych, gdzie termin sięga 60 lub 90 dni, próg może być wyższy.

Alert nie trafia jako powiadomienie push do każdego referenta w wydziale. Raz lub dwa razy w tygodniu naczelnik wydziału dostaje zwięzłe zestawienie: sygnatura, prowadzący, liczba dni bez ruchu, termin załatwienia. Decyzja o tym, co z tym zrobić, należy do naczelnika. AI nie pisze ponagleń do referentów, nie zmienia przypisania sprawy, nie kontaktuje się ze stroną.

Kolejka ePodpisu: co się dzieje, gdy decyzja czeka tydzień?

Zarówno EZD PUW, jak i SIDAS obsługują podpis elektroniczny. Dokument trafia do kolejki i czeka, aż uprawniona osoba: wójt, burmistrz, naczelnik lub pełnomocnik, podpisze go kwalifikowanym podpisem elektronicznym albo przez profil zaufany. Problem pojawia się, gdy w kolejce stoją dziesiątki dokumentów i nikt nie monitoruje, które czekają za długo.

AI sprawdza kolejkę podpisów i wyciąga pisma, które przekroczyły ustalony próg oczekiwania. Na przykład: każde pismo czekające na podpis dłużej niż 48 godzin roboczych ląduje na zestawieniu dla sekretariatu. W zestawieniu widać: tytuł pisma, powiązana sprawa z sygnaturą, data wpłynięcia do kolejki i kto jest osobą podpisującą.

Sekretariat może działać: przypomnieć podpisującemu, sprawdzić, czy nie przebywa na urlopie i czy wyznaczono zastępcę w module uprawnień, przenieść dokument do właściwej kolejki. U jednego z urzędów, z którymi współpracujemy, decyzja o warunkach zabudowy czekała na podpis przez ponad tydzień, bo naczelnik wyjechał na szkolenie i nikt nie aktywował zastępcy w module ePodpisu SIDAS. AI wykryło brak aktywności po dwóch dniach roboczych i zgłosiło do sekretariatu. Decyzja trafiła do podpisu tego samego popołudnia.

Metryki wydziałów: co wyciągamy z rejestrów i po co?

EZD PUW i SIDAS gromadzą dane, które normalnie leżą w bazie nieużywane albo wymagają ręcznego zestawiania w arkuszu kalkulacyjnym przed radą gminy lub kontrolą z urzędu wojewódzkiego. AI może przygotowywać z nich gotowe zestawienia dla kierownictwa.

Co konkretnie wyciągamy:

• Liczba spraw wszczętych i zamkniętych w danym miesiącu według wydziałów i symboli JRWA
• Sprawy po terminie załatwienia według referentów, z liczbą dni przekroczenia
• Średni czas od wpływu pisma do dekretacji w poszczególnych wydziałach
• Pisma zarejestrowane w RKP, które nie zostały przypisane do żadnej sprawy przez więcej niż 5 dni roboczych
• Obciążenie bieżące: ile aktywnych spraw prowadzi każdy referent w danej chwili
• Porównanie liczby spraw w przekroju miesięcznym między wydziałami

Te dane nie służą do oceniania pracowników. Służą temu, żeby naczelnik albo sekretarz gminy zobaczył, gdzie jest wąskie gardło w procesie. Czy Wydział Architektury obsługuje sprawy z JRWA 6220 trzykrotnie dłużej niż rok temu? AI pokaże ten trend. Czy jedno pismo na pięć w kancelarii czeka ponad tydzień na dekretację? AI to wyliczy. Dlaczego tak jest, to pytanie do ludzi. AI dostarcza obraz, nie wyrok.

Od czego zacząć i co trzeba sprawdzić przed wdrożeniem?

Integracja AI z EZD PUW lub SIDAS nie wymaga wymiany systemu ani przebudowy bazy danych. Zaczynamy od audytu, który odpowiada na trzy pytania: do których danych mamy dostęp technicznie (API systemu, bezpośrednie połączenie z bazą, eksport plików), które pola są faktycznie i regularnie wypełniane przez pracowników, i jakie procesy chcemy wspomóc jako pierwsze.

Zwykle zaczynamy od wyszukiwania spraw po opisie i monitorowania kolejki ePodpisu. Efekt widać natychmiast i nie trzeba zmieniać nawyków pracowników. Dopiero potem wchodzą raporty obciążenia wydziałów i alert na sprawy bez ruchu, bo te wymagają ustalenia progów razem z kierownictwem urzędu.

Jedna kwestia, której nie wolno pominąć: dane osobowe stron postępowania. W sprawach administracyjnych mamy imiona, nazwiska, adresy, numery ewidencyjne nieruchomości, czasem dane wrażliwe z pomocy społecznej albo stanu cywilnego. Przetwarzanie tych danych przez AI wymaga podstawy prawnej i, jeśli korzystamy z zewnętrznej chmury, umowy powierzenia przetwarzania z dostawcą. W wariancie lokalnym, gdzie AI działa na serwerach urzędu, dane nie opuszczają sieci wewnętrznej. Oba podejścia są możliwe i dobieramy je po wstępnym audycie konkretnej instalacji.

Chcesz sprawdzić, co realnie da się zrobić z Twoim EZD PUW lub SIDAS? Zacznij od bezpłatnego audytu. Jeśli wolisz najpierw zobaczyć, jak podobna integracja wygląda w praktyce, sprawdź realne wdrożenia w innych urzędach.