Związek Powiatów Polskich przedstawił uwagi do projektu rozporządzenia w sprawie repozytorium interoperacyjności, opracowanego przez Ministerstwo Cyfryzacji. Projekt datowany jest na 22 lipca 2026 roku. Uwagi zostały przekazane w ramach uzgodnień z Komisją Wspólną Rządu i Samorządu Terytorialnego.

Uwagi dotyczące dostępu do repozytorium i standardów technicznych

Brak doprecyzowania standardu API (§ 2 ust. 1 pkt 2)

ZPP wskazuje, że projekt nie precyzuje takich kwestii jak format API (np. OpenAPI), zasady wersjonowania czy mechanizmy autoryzacji, co utrudnia planowanie integracji po stronie urzędu.

Brak informacji o dostępie przez ePUAP (§ 2 ust. 1)

ZPP wskazuje na brak określenia, czy repozytorium będzie dostępne za pośrednictwem ePUAP, jak ma to miejsce dotychczas. Organizacja zwraca uwagę, że w uzasadnieniu projektu rozporządzenia wskazano na dokonanie oceny stanu funkcjonowania repozytorium na ePUAP oraz dalszego rozwoju i rozbudowy repozytorium interoperacyjności. Jednak wnioski z tej oceny nie wskazują na konieczność dalszego utrzymania repozytorium na tej platformie, a przewidziane metody dostępu do informacji zawartych w repozytorium interoperacyjności nie wskazują na możliwość  dostępu do tych danych przez ePUAP.

Rygor niemodyfikowalności danych (§ 2 ust. 2–3)

ZPP wskazuje, że rygor, zgodnie z którym dane „nie mogą być modyfikowane lub usunięte", przy jednoczesnym wersjonowaniu może być problematyczny przy korektach oczywistych błędów. Organizacja postuluje doprecyzowanie trybu sprostowań/korekty metadanych/API, aby nie było wątpliwości jak poprawić błędne informacje..

Brak minimalnych wymagań ergonomii wyszukiwania (§ 3)

ZPP wskazuje, że pomimo wymienienia kryteriów wyszukiwania brakuje minimalnych wymagań ergonomii – filtrowania po urzędzie, rejestrze i typie informacji, a także wsparcia masowych pobrań danych. Utrudni to bieżące zarządzanie własnymi metadanymi/API.

Brak określenia kanałów subskrypcji (§ 4)

ZPP wskazuje na brak określenia kanałów subskrypcji (e-mail, webhooki, RSS) oraz formatu powiadomień, co utrudni automatyczną integrację z systemami urzędowymi.

Uwagi dotyczące procedur i terminów

Brak terminów rozpatrywania zgłoszeń (§ 5 w związku z § 9 ust. 1 pkt 2–3)

ZPP wskazuje na brak określenia terminów i trybu rozpatrywania zgłoszeń oraz propozycji urzędów, w tym czasu reakcji administratora repozytorium, co może prowadzić do niejasności organizacyjnych.

Brak standardów opisu metadanych rejestrów (§ 6 ust. 1–2)

ZPP wskazuje na brak jednoznacznego określenia standardów opisu metadanych rejestrów – słowników, relacji między rejestrami, nazewnictwa pól – co grozi rozbieżnościami między urzędami.

Niejasne statusy rejestrów (§ 6 ust. 3)

ZPP wskazuje, że statusy „planowany", „istniejący" i „wycofany" nie są powiązane z konkretnymi etapami procesu legislacyjnego i wdrożeniowego. Nie jest jasne, kiedy dokładnie rejestr jest „planowany", a kiedy musi już mieć opublikowane metadane.

Brak trybu awaryjnego dla systemów urzędowych (§ 7 ust. 1–2)

ZPP ocenia pozytywnie przewidzenie przerw serwisowych repozytorium, wskazuje jednak na brak analogicznych regulacji dla awarii po stronie systemów urzędu, które muszą publikować dane w wyznaczonych terminach. Organizacja wskazuje na potrzebę jasnego trybu awaryjnego w odniesieniu do obowiązków z § 11–12.

Uwagi dotyczące ról i uprawnień użytkowników

Brak wymogów kompetencyjnych dla poszczególnych ról (§ 8)

ZPP wskazuje, że projekt przewiduje złożoną listę ról – zwykły użytkownik, reprezentant, akceptujący, administrator podmiotu, administrator repozytorium – bez określenia minimalnych wymogów kompetencyjnych każdej z nich, np. czy akceptujący ma posiadać upoważnienie kierownika jednostki. Może to utrudnić projektowanie procedur i zakresów odpowiedzialności.

Brak określenia zarządzania uprawnieniami (§ 10 ust. 1)

ZPP postuluje uzupełnienie treści zapisu o informację, kto zarządza użytkownikami, jaka jest rola zwykłego użytkownika, jakie warunki należy spełnić, by uzyskać tę rolę, oraz jakie uprawnienia ona daje w kontekście form dostępu opisanych w § 2 ust. 1 pkt 1 oraz pkt 2 Projektu rozporządzenia.

Organizacja wskazuje, że projekt nie przewiduje powszechnego dostępu do repozytorium, lecz wyłącznie dostęp po uwierzytelnieniu, jednocześnie nie określając, kto odpowiada za zarządzanie uprawnieniami (nadawanie, odbieranie i autoryzację) zwykłego użytkownika oraz w jakim trybie można uzyskać tę rolę.. ZPP zwraca uwagę na kontekst prawny: przywołanie w uzasadnieniu art. 220 ustawy z 14 czerwca 1960 r. - Kodeksu postępowania administracyjnego wskazuje, że dostęp jest potrzebny dla wszystkich podmiotów publicznych, natomiast art. 13 ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne – wchodzący w życie 23 lutego 2027 roku – nakłada obowiązek przygotowania m.in. „dokumentację API, zawierającą w szczególności opis struktur dokumentów elektronicznych, formatów danych oraz protokołów komunikacyjnych i szyfrujących,” która z kolei jest dokumentacją operacyjną SZBI ,  zgodnie z art. 10 ust. 3 pkt 4 Ustawy o krajowym systemie cyberbezpieczeństwa i podlega ograniczeniu dostępu na podstawie art. 10 ust. 6 pkt 1 tej ustawy. Wobec tego niezbędne jest określenie odpowiedzialności za zarządzanie uprawnieniami użytkowników mających dostęp do takiej dokumentacji.

Brak terminów i trybu odwoławczego przy nadawaniu ról (§ 10 ust. 2–3)

ZPP wskazuje, że sposób nadawania ról wymaga aktywności administratora podmiotu i administratora repozytorium, brakuje jednak zapisów o terminach rozpatrywania wniosków urzędów oraz o trybie odwoławczym.

Uwagi dotyczące obowiązków publikacyjnych urzędów

Zbyt restrykcyjny termin publikacji (§ 11 ust. 1)

ZPP ocenia wymóg publikacji metadanych rejestru „niezwłocznie, najpóźniej w terminie 7 dni" od powstania lub zmiany ich treści jako bardzo restrykcyjny. Organizacja wskazuje, że przyjęty termin nie uwzględnia złożoności procesu legislacyjnego i wdrożeniowego w urzędach – analizy, testów i uzyskiwania zgód.

Brak szczegółowych standardów (§ 11 ust. 3)

ZPP wskazuje, że rozporządzenie nie precyzuje szczegółowych standardów, takich jak OpenAPI dla API, zasady wersjonowania, nazwy pól czy słowniki, co utrudni standaryzację między urzędami.

Brak definicji braku dostępności API (§ 12 ust. 3)

ZPP wskazuje na brak precyzyjnej definicji „braku dostępności API" oraz minimalnego zakresu informacji, które urząd ma w takiej sytuacji opublikować – np. przewidywanego czasu usunięcia awarii, przyczyny czy zakresu dotkniętych usług.

Brak określenia metryk (§ 12 ust. 4)

ZPP wskazuje, że przepis nie określa minimalnego zakresu metryk (liczba wywołań, błędy, czas odpowiedzi, dostępność) ani nie uwzględnia różnej skali urzędów (małe jednostki mogą mieć trudności z ich zapewnieniem.

Narzędzia do tworzenia oprogramowania (§ 12 ust. 5)

ZPP postuluje rozważenie zobowiązania ministra do zapewnienia referencyjnych narzędzi. Organizacja wskazuje, że przesunięcie ciężaru możliwości tworzenia „zestawów narzędzi do tworzenia oprogramowania" na podmioty realizujące zadania publiczne może okazać się dla wielu urzędów niewykonalne.

Uwagi dotyczące integracji i monitoringu

Nieokreślony model integracji (§ 13 ust. 1)

ZPP wskazuje, że sformułowanie „umożliwia pobieranie do repozytorium interoperacyjności" metadanych i informacji o API nie precyzuje modelu integracji – czy chodzi o model push czy pull, jaka jest częstotliwość, standardy i wymogi bezpieczeństwa. Nie jest jasne, czy urzędy mają samodzielnie budować integracje, czy zostaną im dostarczone gotowe mechanizmy i narzędzia.

Brak powiązania monitoringu z obowiązkami urzędów (§ 13 ust. 2)

ZPP wskazuje na brak powiązania mechanizmu monitoringu z obowiązkami urzędów z § 12 – np. co się dzieje, gdy monitoring stwierdzi niedostępność, a urząd nie opublikował informacji.

Brak terminów i trybu odwoławczego przy ocenie jakości (§ 13 ust. 3)

ZPP wskazuje na brak określenia terminów na dostosowanie, konsekwencji jego braku oraz trybu odwoławczego, w tym możliwości zakwestionowania oceny jakości przez urząd. Organizacja ocenia, że powstaje ryzyko dodatkowego, nie do końca uregulowanego „quasi-nadzoru".

Uwagi dotyczące wejścia w życie i bezpieczeństwa

Brak okresu przejściowego (§ 14)

ZPP wskazuje na brak przewidzianego okresu przejściowego na dostosowanie systemów urzędowych, procedur i zasobów kadrowych do nowych obowiązków. Organizacja ocenia, że przy tak szerokich obowiązkach – ciągłej publikacji metadanych/API, statystykach, informacjach o niedostępności oraz integracjach – potrzebny jest co najmniej kilkunastomiesięczny okres wdrożeniowy.

Uwaga ogólna – brak regulacji bezpieczeństwa informacji

ZPP wskazuje na brak szczegółowych regulacji dotyczących bezpieczeństwa informacji o API i strukturach danych, w tym zakresu ujawniania endpointów oraz powiązania tych kwestii z ustawą o ochronie informacji niejawnych i przepisami o ochronie danych osobowych.