Postępująca informatyzacja wymiaru sprawiedliwości i administracji publicznej jest faktem, nawet jeżeli złośliwi preferują określenie „pełzająca”. Problem w tym, że kod owych systemów jest efektem interpretacji istniejących przepisów, zamiast być bezpośrednim odwzorowaniem istniejącego prawa. Mówiąc inaczej: aby stworzyć system ułatwiający realizację praw lub obowiązków, należy „przełożyć” obowiązujące prawo na kod przyjmując punkt widzenia podmiotu uprawnionego/zobowiązanego. Rodzi to szereg problemów takich jak „luki w tłumaczeniu” prawa na kod, niekompatybilność i „silosowatość” rozwiązań czy wreszcie wysokie koszty utrzymania będące efektem dwóch poprzednich. Przede wszystkim jednak wskazuje na negatywną cechę powstającego prawa: jest ono przeznaczone dla organów władzy publicznej, a nie dla obywateli.

Patryk Ciurak 

Zatem jeżeli informatyzacja szeroko rozumianych: wymiaru sprawiedliwości i administracji publicznej nie ma zabrnąć w ślepą uliczkę astronomicznych kosztów utrzymania, zmianie powinna ulec optyka tworzenia prawa. Mowa tu o konieczności koncentracji na tzw. użytkowniku końcowym (user-centered design), koncepcji tworzenia (przede wszystkim) oprogramowania komputerowego powstałej, która narodziła się w na przełomie lat 70-tych i 80-tych XX w. W trakcie prac legislacyjnych należy jednoznacznie określić m.in. kto będzie adresatem norm, czy przyznane zostanie uprawnienie czy nałożony obowiązek, co będzie chciał osiągnąć, w jakich sytuacjach będzie stosował prawo, z jakimi podmiotami wchodził w interakcje w całym procesie. Pytania te mogą się wydawać oczywiste, a lektura uzasadnień do projektów aktów normatywnych pozwala przypuszczać, że odpowiedzi na nie oczywiście znajdują się w przepisach obecnie powstających. Jednak już pierwsze próby przełożenia nawet niewielkiego fragmentu obowiązującego prawa na kod komputerowy prowadzą do odmiennych wniosków. Pomimo tego, że adresatami norm deklarowani są np. przedsiębiorcy, istniejące prawo ma służyć przede wszystkim prowadzeniu postępowania przez szeroko rozumiane organy administracji publicznej. Prawodawca określa, który organ, kiedy i wobec kogo może podjąć działania, aby wyegzekwować obowiązek lub umożliwić realizację uprawnienia. Regulacje są bardziej skoncentrowane na sposobie osiągnięcia celu, niż na celu samym w sobie. Istnieje tendencja do wskazywania jakimi środkami technicznymi należy się posłużyć i jaką formę czynności zachować; wymaga się osobistego stawiennictwa adresata norm i składania oświadczeń co do faktów, które mogą być uzyskane np. z publicznych rejestrów [1]. W rezultacie prawo w wielu przypadkach nie jest dostosowane do obsługi za pomocą systemów komputerowych. Dobitny tego przykład stanowią rezultaty eksperymentu przeprowadzonego w Nowej Zelandii. Jego celem było zbadanie możliwości zapisu obowiązującego prawa w postaci kodu komputerowego, który byłby tożsamy z przepisami w formie języka naturalnego. Uczestnicy eksperymentu w pewnym momencie jednak zrezygnowali z prób „translacji” i zdecydowali o napisaniu badanej regulacji na nowo, w sposób dostosowany do użytkownika końcowego. Rezultaty eksperymentu były na tyle satysfakcjonujące, że wskazano na możliwość „przepisania” w ten sposób całej ustawy, co jednak wiązałoby się ze znacznym nakładem pracy [3].
Można więc przyjąć, że rezygnacja z dotychczasowego podejścia i koncentracja na adresacie norm i na celu, który chce osiągnąć, umożliwi zaprojektowanie daleko zautomatyzowanego procesu stosowania prawa. Rolą organów administracji publicznej oraz sądów będzie sprawowanie nadzoru nad jego przebiegiem, a nie inicjowanie i wykonywanie większości etapów, jak ma to miejsce obecnie [4]. Może również szybciej uwypuklić sytuacje, w których intencje prawodawcy nie wynikają jasno z treści przepisów, a ich ustalenie należy do organów stosującym prawo. W efekcie nowelizacje mogą zostać nastąpić sprawniej, jeżeli prawodawca uzna to za konieczne.

Tworzenie prawa zorientowanego na użytkownika końcowego jest również warunkiem upowszechnienia stosowania przepisów w postaci kodu komputerowego. Machine-consumable legislation czy też Rules-as-Code – bo tak nazywana jest ta forma – ma gwarantować takie samo znaczenie kodu oraz tekstu w języku naturalnym (co określane jest niekiedy mianem izomorfizmu) oraz pozwolić na traktowanie obu wersji jako tekstów autentycznych [5]. Aby było to możliwe, musi istnieć wspólny punkt wyjścia bowiem każde działanie związane z tłumaczeniem tekstu na kod (lub odwrotnie) będzie prowadziło do powstania wspomnianych już „luk w tłumaczeniu” [6]. Możliwym rozwiązaniem jest spisanie założeń projektowanej regulacji w postaci pseudokodu, czyli uproszczonego zapisu algorytmu postępowania. Zdania zapisane przy jego pomocy zachowują składnię właściwą dla kodu komputerowego, pozbawione są jednak szczegółów implementacyjnych potrzebnych do wykonania kodu [7]. Część z poleceń zapisana jest również językiem naturalnym, aby zwiększyć czytelność. Procesy mające podlegać regulacjom mogą (a nawet powinny) być zilustrowane przy użyciu diagramów stworzonych zgodnie z notacją Business Process Model and Notation (BPMN) albo Unified Modeling Language (UML) – w zależności od potrzebnego poziomu szczegółowości. Spisane w ten sposób założenia wspomagają jednakowe zrozumienie celów postawionych przed zespołem pracującym nad aktem normatywnym i są stosunkowo proste w odbiorze [8]. Mogą być również łatwiej zweryfikowane przez ekspertów w danej dziedzinie [9].
Opisane wyżej podejście przyjął zespół biorący udział eksperymencie w Nowej Zelandii [2]. Działania pierwotnie obejmowały wyjście od wysokopoziomowych modeli koncepcyjnych, w wyniku czego powstawały modele podejmowania decyzji. Następnie spisywano treść przepisów i przekazywano je programistom pracującym w zasadzie poza zespołem. W trakcie pracy kod oraz tekst przepisu były na bieżąco uzgadniane między nimi i pozostałymi uczestnikami, aby zapewnić maksymalną spójność obu wersji. Wkrótce jednak okazało się, że stanowi to istotną niedogodność spowalniającą prace. Zdecydowano wobec tego o włączeniu programistów do pracy całego zespołu już na bardzo wczesnym etapie, aby zminimalizować ryzyko nieporozumień i rozbieżności między kodem a tekstem aktu prawnego. Dodatkową korzyścią był bardzo cenny wkład programistów w postaci propozycji rozwiązania napotkanych problemów i wskazywania nieścisłości na wczesnych etapach projektowania [10]. Sumarycznie ilość czasu i pracy poświęconych na wytworzenie modeli i w dalszej kolejności równocześnie kodu i przepisów w języku naturalnym była mniejsza niż w przypadku, gdy tworzono najpierw przepisy, a następnie tłumaczono je na kod [11].

Materiały (nazywane niekiedy artefaktami) powstałe w trakcie prac niosą istotną wartość jako źródła wykładni autentycznej. Mogą zostać wykorzystane przez inne zespoły pracujące w przyszłości nad nowelizacjami przepisów oraz być pomocne dla adresatów norm, a więc często zwykłych obywateli nieposiadających specjalistycznej wiedzy prawniczej. Obecnie stosowane uzasadnienia do projektów aktów normatywnych powstają najczęściej w formie „ściany tekstu”. Utrudnia to przyswojenie potrzebnych informacji nawet czynnym zawodowo prawnikom, a dodatkowo może być bardziej czasochłonne niż praca z profesjonalnie przygotowanym schematem. Na podstawie artefaktów można również przygotować materiały informacyjne dla adresatów norm, zgodnie z zasadami wypracowanymi w ramach badań nad legal design [12]. W rezultacie będą on nie tylko informowani o celu regulacji, ale mogą zostać przekonani o jego słuszności.

Projektując prawo warto również zastanowić się, kogo uznaje się za użytkownika końcowego projektowanych przepisów. Wskazanie na osobę fizyczną czy osobę prawną wydaje się naturalne, jednak działania obu tych kategorii podmiotów obsługiwane są w dużej mierze przez komputery. Dlatego bardziej trafnym jest wskazanie jako użytkownika końcowego zarówno człowieka jak i komputer. Prawo pod postacią kodu będzie wykonywane właśnie na komputerze i będzie musiało być dla komputera zrozumiałe oraz użyteczne. Zrozumiałość prawa zależy od działań legislacyjnych, jednak użyteczność w duże mierze zależeć będzie od tego, skąd i jak sprawnie pozyskana zostanie informacja wejściowa. Mówiąc inaczej, niezbędne jest zapewnienie połączenia systemu, w którym wykonywane będą przepisy w postaci kodu, z systemami i rejestrami administracji publicznej [13]. Bez zapewnienia takiego połączenia większość danych dotyczących choćby stanu faktycznego będzie musiała być pozyskiwana przez organ stosujący prawo (tak jak ma to miejsce obecnie), który najczęściej zażąda ich od podmiotu dążącego do uzyskania rozstrzygnięcia. W praktyce oznacza konieczność wypełnienia kolejnego formularza. Tworząc prawo w postaci kodu zorientowane na użytkownika końcowego należy dążyć, by dane były pobierane automatycznie w tak szerokim zakresie, jak tylko jest to możliwe oraz potrzebne do wydania rozstrzygnięcia.
Podsumowując, jeżeli prawo ma być dostosowane do obsługi przez systemy informatyczne, zmienić się musi optyka tworzenia aktów normatywnych. Powinno nastąpić skupienie przede wszystkim na adresacie normy. Dotyczyć to będzie nie tylko treści przepisów istniejących w postaci kodu czy ich spójności (eliminacja „luk w tłumaczeniu”), ale i uzasadniania stanowionych regulacji w sposób zrozumiały i użyteczny. Wreszcie, aby adresat norm w pełni odczuł korzyść z wprowadzonego rozwiązania konieczne będzie zadbanie o automatyczne pozyskiwanie niezbędnych danych pozostających w posiadaniu administracji publicznej.

Tekst dostępny w wersji angielskiej:  https://apolitical.co/solution-articles/en/why-user-centred-law-is-a-prerequisite-for-effective-digital-transformation

[1] Jeżeli nawet przewidziano możliwość składania wniosków on-line, często należy je wypełniać ręcznie zamiast pobrać dane np. z rejestrów PESEL czy REGON. Jaskrawym tego przykładem było przyznawanie pożyczek mikroprzedsiębiorcom na podstawie art. 15zzd ustawy z dnia 2 marca 2020 r. o szczególnych rozwiązaniach związanych z zapobieganiem, przeciwdziałaniem i zwalczaniem COVID-19, innych chorób zakaźnych oraz wywołanych nimi sytuacji kryzysowych (t.j. Dz. U. poz. 1842 z późn. zm.).

[2] (Accident Compensation Better Rules Discovery Team, 2019).

[3] (Accident Compensation Better Rules Discovery Team, 2019, str. 32).

[4] Automatyzacja w większym stopniu nie może być jednak mylona z sytuacją, w której wyłączona jest interpretacja obowiązującego prawa. Autor chciałby bardzo mocno zaznaczyć, że jego zdaniem przy obecnym stanie wiedzy i techniki nie jest możliwe ani też korzystne wyeliminowanie wykładni z procesu stosowania prawa.

[5] Por. (Wong, 2020).

[6] Istnienie takich luk stwierdzono w trakcie innego eksperymentu przeprowadzonego w Nowej Zelandii: (The Service Innovation Lab (LabPlus), 2018, strony 10-11). Należy jednak zaznaczyć, że niekiedy postulowane jest sporządzanie formy tekstowej aktów normatywnych na podstawie pierwotnej wersji zapisanej w postaci kodu komputerowego (Wong, 2020).

[7] Por. https://pl.wikipedia.org/wiki/Pseudokod, (dostęp: 5 lutego 2021 r.).

[8] Doświadczenie pokazuje, że pominięcie na początkowym etapie stworzenia modeli koncepcyjnych prowadzi szybko do rozbieżności między rozumieniem pojęć (Accident Compensation Better Rules Discovery Team, 2019, str. 30).

[9] (Accident Compensation Better Rules Discovery Team, 2019, strony 19, 27) Umożliwia to zidentyfikowanie błędów przeoczonych przez zespół. Dodatkową korzyścią jest identyfikacja błędów i luk w samym prawie, których istnienia można nie być w ogóle świadomym. Dobrym przykładem są nieścisłości w definicjach (Accident Compensation Better Rules Discovery Team, 2019, strony 29, 31).

[10] (Accident Compensation Better Rules Discovery Team, 2019, str. 15). Na podstawie własnych doświadczeń autor może z całą mocą potwierdzić, że zaangażowanie programistów w projektowanie rozwiązań nawet bardzo dalekich od sfery IT może skutkować bardzo trafnymi spostrzeżeniami.

[11] (Accident Compensation Better Rules Discovery Team, 2019, str. 27).

[12] Przez legal design należy rozumieć projektowanie prawa i procesów jego stosowania w sposób bardziej zorientowany na użytkownika, użyteczny i zrozumiały. Więcej o legal design można dowiedzieć się z publikacji Law by Design autorstwa M. Hagan dostępnej na stronie https://www.lawbydesign.co/, (dostęp: 5 lutego 2021 r.).

[13] W polskim systemie prawa podstawą dla tego typu działań jest ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (t.j. Dz. U. z 2019 r. poz. 700 z późn. zm.) oraz wydane na jej podstawie rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (t.j. Dz. U. z 2017 r. poz. 2247).

Bibliografia
Accident Compensation Better Rules Discovery Team. (2019, 1 lipca). Exploring Machine Consumable Accident Compensation Legislation. Lessons for a structural rewrite of the AC Act and opportunities to make it machine consumable. Pobrano 30.01.2021 r. z lokalizacji The Service Innovation Lab: https://serviceinnovationlab.github.io/assets/Exploring_Machine_Consumable_Code_With_ACC.pdf
The Service Innovation Lab (LabPlus). (2018, marzec). Better Rules for Goverment Discovery Report. Pobrano 31.01.2021 r. z lokalizacji NZ Digital Goverment: https://www.digital.govt.nz/dmsdocument/95-better-rules-for-government-discovery-report/html#summary,
Wong, M. (2020). Rules as code – Seven levels of digitisation. Pobrano: 17.04.2021 r. z lokalizacji Research Collection School Of Law: https://ink.library.smu.edu.sg/sol_research/3093/