Metodologia

redtapeai jest projektem badawczym — nie autorytetem prawnym. Ta strona wyjaśnia, jak powstają rekordy widoczne w bazie, jaki jest scope projektu i gdzie są jego ograniczenia.

Czym jest obciążenie administracyjne (a czym nie)

W naszym znaczeniu obciążenie administracyjne (administrative burden, red tape) to sytuacja stanowiąca ograniczenie wolności gospodarczej — w rozumieniu art. 20-22 Konstytucji RP. To są powinności biurokratyczne nakładane na podmioty regulowane (przedsiębiorców, obywateli, pracodawców, podatników) i tworzące koszty compliance.

NIE są obciążeniem administracyjnym w sensie tego projektu:

Procedury wewnątrz administracji — obowiązki ministerstw, organów kontroli, sądów, wójtów wobec siebie nawzajem. To są procesy państwowe, nie burden na biznes. Klasyfikujemy je jakosubject_category=publici ukrywamy w domyślnym widoku.
Daniny publiczne (art. 217 Konstytucji RP) — podatki, opłaty publiczne, składki ZUS/NFZ, cła, akcyzy oraz określanie podmiotów/przedmiotów opodatkowania, stawek, ulg i zwolnień. To są obowiązki konstytucyjne (art. 84), nie compliance bureaucracy. Klasyfikujemy je jakois_danina_publiczna=true.

Ważny niuans: compliance wokół danin (deklaracje VAT, JPK, ewidencja podatkowa, rejestracja jako podatnik VAT, wnioski o interpretacje indywidualne) JEST obciążeniem administracyjnym, bo to są koszty biurokratyczne ograniczające wolność gospodarczą, nie sama danina.

Pipeline ekstrakcji

Ingestion — pobranie aktu z ELI API (api.sejm.gov.pl/eli).
Parsing — strukturyzacja HTML do hierarchii art./ust./pkt/lit.
Pattern scanner — deterministyczne wykrywanie kandydatów na obowiązek (markery typu „obowiązany", „w terminie", „pod rygorem").
LLM extraction — kandydaci analizowani przez model (claude-opus-4-7), który zwraca obowiązki z dosłownym cytatem i klasyfikacją subject_category + is_danina_publiczna.
Walidator cytatu — twardy gate: cytat MUSI dosłownie występować w źródle, inaczej rekord jest odrzucany.
Klasyfikator regułowy — cross-check stem-prefix matchingu polskiej morfologii, jako fallback i retrofit.
Confidence scoring — wielosygnałowy wynik (siła wzorca, kompletność, specyficzność cytatu i podmiotu).

Pipeline monitoringu legislacyjnego (Sejm + RCL)

Równolegle do pipeline'u ekstrakcji obowiązków działa pipeline monitoringu legislacji — codzienna automatyzacja śledząca stan procesów ustawodawczych od konsultacji ministerialnych do publikacji w Dz.U.:

RCL (pre-sejm) — projekty rządowe na etapie konsultacji ministerialnych. Scraper pobiera listę wszystkich projektów + dla każdego pełen timeline 14 etapów (Uzgodnienia → Konsultacje publiczne → Opiniowanie → Komitety → Komisja Prawnicza → Rada Ministrów → Notyfikacja → Skierowanie do Sejmu) z dokumentami per etap (Projekt.docm, Uzasadnienie.docx, OSR.doc, Pisma kierujące, Stanowiska zgłoszone w konsultacjach).
Sejm — procesy z API api.sejm.gov.pl/sejm/term{N}/processes z pełnym timeline etapów (1. czytanie → komisja → 2. czytanie → 3. czytanie → Senat → poprawki → podpis), głosowaniami imiennymi, drukami sejmowymi (PDF). Pokrywamy kadencje 10, 9, 8.
Cross-reference — heurystyka „o zmianie ustawy o X" + fuzzy match tytułów: na karcie każdej ustawy z naszej bazy widać które projekty Sejm próbują ją zmienić (w toku / uchwalone / odrzucone).
Klasyfikacja wnioskodawcy — z prefixu tytułu Sejm: rządowy / poselski / senacki / komisyjny / obywatelski / prezydencki. Plus statystyki skuteczności: rządowe ~95% pass, poselskie ~36%, obywatelskie ~12%.
Daily automation — GitHub Actions, cron 6:30 UTC. Inkrementalny ingest (nowe etapy + ~80 nowych RCL details / dzień), commit + push do main → CF Pages auto-deploy.

Co domyślnie widzisz na dashboardzie

Domyślny widok („obciążenia regulacyjne") pokazuje obowiązki spełniające:

subject_category ∈ {private, mixed}
is_danina_publiczna = false

Przełącznik „wszystkie obowiązki" odsłania procedury wewnątrz administracji + daniny publiczne — dla pełnej transparency datasetu, ale to nie jest core scope projektu.

„Przepis" vs „norma prawna" — świadome uproszczenie

Po konsultacji eksperckiej (maj 2026) potwierdzamy znane ograniczenie metody: redtapeai mapuje jeden przepis na jeden obowiązek, ale w teorii prawa norma prawna często wynika z kilku przepisów czytanych łącznie, a jeden przepis może zawierać kilka odrębnych norm.

Konsekwencje praktyczne:

Niektóre cytaty są fragmentaryczne względem pełnej normy — np. termin jest w jednym przepisie, sankcja w innym.
Niektóre normy nie pojawiają się w bazie, bo wymagają syntezy 2-3 przepisów (np. obowiązek X = art. A + definicja z art. B + delegacja z rozporządzenia).
Pole related_units dokumentuje powiązane przepisy gdy są znane — eksperci czytający rekord dostają pełniejszy kontekst.

To jest pragmatyczne uproszczenie, nie błąd. Pełne modelowanie norm wymagałoby ręcznego networkingu przepisów — koszt nieadekwatny do MVP. Zostawiamy hooki (related_units) na ścieżce dojścia tam później.

Goldplating: porównanie PL ↔ UE

Art. 67 ustawy o Prawie Przedsiębiorców postuluje przeciwdziałanie pozłacaniu (goldplating) regulacji unijnych — polskie prawo nie powinno nakładać więcej obowiązków niż wynika z dyrektywy UE, chyba że jest to wyraźnie uzasadnione.

Pole implements_eu_act przy każdym obowiązku, jeśli wypełnione, mówi:

który akt UE (dyrektywa/rozporządzenie) jest źródłem,
jaki artykuł UE konkretnie,
czy PL „pozłaca" — czyli dokłada wymagań ponad minimum UE — i dlaczego (uzasadnienie).

Mapowanie jest ręczne, w trakcie budowy: zaczynamy od AML (dyrektywy 2015/849 i 2018/843) jako proof-of-concept. Rozwija się stopniowo.

Confidence score — co oznaczają liczby przy obowiązkach

Każdy obowiązek ma conf między 0 a 1. Wynik to średnia ważona czterech sygnałów:

pattern_strength — jak mocne markery językowe („obowiązany", „w terminie") znalazł pattern scanner;
schema_completeness — ile pól rekordu udało się wypełnić (deadline, sankcja, adresat, częstość);
citation_specificity — czy cytat jest konkretny, czy ogólny;
subject_specificity — czy podmiot zobowiązany jest precyzyjnie określony.

Jak czytać: ≥ 0.80 — wysoka pewność, kompletny rekord; 0.60–0.79 — średnia, warto rzucić okiem na cytat; < 0.60 — niska, traktować jako kandydata do weryfikacji eksperckiej.

Niska confidence NIE znaczy, że obowiązek nie istnieje — znaczy, że ekstrakcja była niejednoznaczna i rekord może wymagać dopracowania.

„do przeglądu" / flagged_for_review

Etykieta do przeglądu oznacza, że rekord przeszedł walidator cytatu (cytat jest dosłowny w źródle), ale jeden z heurystyk oznaczył go jako wymagający eksperckiej weryfikacji — np. niska confidence + brak deadline + ogólny podmiot. Lista takich rekordów to roadmapa do iteracji datasetu, nie sygnał błędu.

Identyfikatory `DU/yyyy/nnnn`

Skrót DU/2018/646 to address ELI (European Legislation Identifier) — Dziennik Ustaw z roku 2018, pozycja 646. Każdy akt w bazie jest pobrany z api.sejm.gov.pl/eli po tym właśnie identyfikatorze. Klikając w identyfikator albo tytuł aktu wchodzisz na stronę aktu w naszej bazie z listą obowiązków.

Ograniczenia metody

System wykrywa jednoznaczne obowiązki — domyślne / pośrednio wynikające z interpretacji nie są w bazie.
Obecnie 54 ustawy w bazie z 377 obowiązkami; pełna walidacja metody na różnych typach aktów (kodeksowe, podatkowe, sektorowe) wciąż w toku — kierunek: 100 ustaw / 800 obowiązków w v2.
Confidence to wskaźnik jakości ekstrakcji, nie wagi prawnej obowiązku.
Każdy rekord należy traktować jako kandydata do eksperckiej weryfikacji, nie jako interpretację prawną.
Klasyfikacja subject_category opiera się o stem-prefix matching polskiej morfologii + LLM — błędy klasyfikacji są możliwe (np. „organ lub jednostka organizacyjna" jest niejednoznaczne kontekstowo).

Wersjonowanie

Dataset jest powiązany z wersją tekstu jednolitego pobraną z ELI w danym momencie. Plik extraction_run.json zawiera metadane runa (model, prompt_version, timestamps, błędy). Plikclassify_log.json dokumentuje rule-based klasyfikacje subject_category dla każdego obowiązku.

Dane i kontakt

Dataset JSON: /data/obligations.json
Źródło aktów: api.sejm.gov.pl/eli
Kontakt z autorem: LinkedIn / arvind@oumm.pl