SISTEM PRAVNE ANALIZE (e. Legal Expert System-LES).

Uvod
Uspešno pretvaranje pravne proze u kod zahteva stalnu, holističku i efikasnu saradnju
između pravnika i programera. Integracija ugovorne odredbe u programski kod zahteva
interpretaciju pravnih pravila: tumači pravnih pravila su pravnici. Cilj tumačenja je da kod bude
definisan na način koji je u skladu sa pravnim pravilima.Okvir te saradnje je ustanovljavanje tzv.
„Sistema pravne ekspertize“. (e. „Legal Expert System“). U osnovi, ovaj sistem generiše snagu
“pravnog inžinjeringa”: dve ekspertize koje imaju za cilj da obezbede uspešnu
dvodimenzionalnu analizu angažovanih pitanja (pravnu i programersku). Sintagma LES
označava program koji su koncipirali pravnici i koji imitira rešavanje problema od strane
pravnika. Cilj LES jeste: sticanje znanja programera o ugovoru kao pravnom institutu;
integracija tog znanja u LES; kontrola i testiranje programskog koda kroz saradnju programera i
pravnika. Eksperti koji učestvuju u opisanim aktivnostima nazivaju se “inženjerima pravnog
procesa”. Oni mogu da budu pravnici i/ili programeri; verovatnije je da pojam obuhvata
najmanje dva lica sa različitom ekspertizom: primarnom (pravo ili programiranje) i sekundarnom
(osnovna znanja iz prava ili programiranja).
Automatsko donošenje pravnih odluka oslanja se na kompjuterske programe nastale u
okviru sistema pravne ekspertize. Ove programe izvršavaju mašine (u ovom trenutku nedovoljno
razvijene da bi imale pravno rasuđivanje).
Programer, međutim, treba da obezbedi da računarski program verno odražava slovo i
snagu pravne norme. Sadržina pravne norme je specifikacija problema koje rešava algoritam
računarskog programa/softvera. Način na koji se programi pišu i funkcionišu zahteva od
programera da izrazi svoju nameru u određenom obliku logike ili statističkog modela koji
nameće programski jezik ili okvir. Sa druge strane, nameravano funkcionisanje programa
(specifikacije), u kontekstu prava se definiše korišćenjem prirodnog jezika i pojmova koji su
specifični za pravni domen (po tome se pravo ne razlikuje od ostalih oblasti-ekonomije, medicine
i slično koji su zavisni od sopstvenih, specifičnih pravila i pojmova).
Svaki programer svoj rad započinje analizom zahteva sa ciljem izdvajanja specifikacija
zahteva naručioca programa: ove specifikacije moraju da budu konvertovane i izražene u formi
računarskog programa.
U slučaju automatizovanog pravnog odlučivanja i pravnih ekspertskih sistema, elementi
specifikacije su delovi norme, kao i njene moguće interpretacije: oba elementa moraju da se nađu
u računarskom programu. Kao osnovna pitanja za ispravnost i bezbednost pravnih ekspertskih
sistema postavljaju se sledeća:
-prvo, kako da se pravna argumentacija prevede u skup zahteva (specifikacija) kreatorima
softvera?
-kako verifikovati/proveriti da su ovi zahtevi ispravno prevedeni u kompjuterski kod?
-kako sprečiti da se u kod ne unese „specifikacija“ koja rezultira nezakonitim
ponašanjem?
Specifikacije
Pre nego što napiše kompjuterski program, programer mora prvo da zna šta ovaj program
treba da radi. Ova jednostavna izjava leži u osnovi jednog od najtežih izazova u kompjuterskoj
nauci, koji ne proizilazi iz algoritamske složenosti, već zbog nepreciznosti i nejasnoće zahteva
usmerenih kreatoru računarskog programa.

1
 U tom smislu, pravni ekspertski sistemi spadaju u širu kategoriju logički orijentisanih
sistema. Norma (ugovor, zakon, sudska odluka) nema za cilj neki poseban „proizvod“: ona je
rezultat napora za rešavanjem određenog društvenog političkog ili poslovnog (kod ugovora)
pitanja na kompromisan način. Da bi ovaj cilj ostvarili, pravni izvori (tekstovi) imaju jezičku
formu koja se razlikuje od formalnih kompjuterskih programa. Iz vizure kompjuterskog softvera,
pravna proza je neformalna kategorija.
Računar koristi sveden i precizan programski jezik. Program i njegova semantika ne
mogu da trpe dvosmislenost: time bi bili onemogućeni da izvrše svoje operacije..
Iza programa obično postoje tekstualni dokumenti koji služe kao referenca i vodič za
njihovo kreiranje. Ovi dokumenti, koji mogu biti pravni tekstovi ili poslovni ugovori, nazivaju se
specifikacijama
Kako pomiriti neformalnost specifikacija (koje u slučaju pravnog teksta mogu da budu
dvosmislene ili nedovoljno jasne) sa principom rigidnosti kompjuterskih programa (rigidnosti
koja ne trpi dvosmislenosti i nejasnoće)?
Teorija i praksa tragaju za rešenjima. Ona, u ovom trenutku, nisu zasnovana na pravnim
konceptima već pre na prevodu namere i cilja pravne norme na računarima razumljiv jezik.
Prvo, specifikaciju pravne norme moguće je definisati kroz opisivanje predmeta
regulisanja. Elementi specifikacije (ulazne vrednosti za računarski program) dobijaju se
analizom: potom se definiše niz koraka sličnih matematičkom proračunu koji analizira ove
ulazne veličine. Iz tog proračuna se dobija rezultat koji je osnov za odluku o primeni norme na
određeno lice ili situaciju. Arhetipski primer ovog pristupa je iznos poreza koji se dobija nakon
popunjavanja prijave prihoda. Ova specifikacija se naziva “procesno definisanim”: (e. “process-
constrained”): predmet kodiranja/programiranja računarskog programa je proces koji
pretpostavlja dobijanje određenog rezultata. “Procesno definisane” specifikacije se jednostavnije
prevode u kompjuterske programe: i programi i procesi imaju sopstvenu strukturu i korake
(sekvenca algoritma funkcionalno je slična sekvenci procesa-postupka).
Drugo, postoje pravne specifikacije koje definišu konačne karakteristike rezultata
programa kome su specifikacije u pitanju upućene (e. “result constrained”). Ove specifikacije
samo definišu cilj, a kreatoru procesa (odnosno kreatoru algoritma) ostaje da osmisli sekvence i
korake. Primer ovog pristupa je kada kompanija prima zaposlenog: zakon definiše samo potrebu
da proces ne bude diskriminatoran (zbog pola, rase i slično). Na kompaniji je da sama kreira
pravila procesa.
Navedene kategorije pravnih specifikacija imaju (posmatrano kroz vizuru računarskog
programa) nedostatke jer su „neformalne“. Ovi su nedostaci različiti.
Prvo oni su sintaksički (struktura rečenice): sintaksa može da bude nepodobna za
raščlanjivanje/sekvenciranje (e. „parsing“). Ovaj nedostatak moguće je rešiti primenom pravila
simboličke logike (konjukcija, disjunkcija, negacija i slično).
Druga teškoća je nekonzistentnost: različiti članovi mogu da definišu različite posledice
za iste okolnosti (recimo kod poreskog zakonodavstva različite stope za istu imovinu), odnosno
da se različita pravila za istu imovinu primenjuju pod različitim uslovima (oba slučaja mogu da
upućuju na odredbe drugih zakona-e. cross refference). U drugom slučaju, postavlja se pitanje
koje pravilo ima hijerarhijsku prednost u primeni? Opisani nedostatak prevazilazi se
preciziranjem namere zakonodavca i definisanjem veze sa drugim zakonima.
Treće su tzv. konceptualne nejasnioće. Zakonske norme su često dvosmislene ili otvorene
za interpretaciju: to je posledica potrebe da se ostavi prostor za „vibriranje“ norme u prostoru i
fleksibilnost u primeni (rigidna norma donela bi više štete nego koristi).

2
 Tumačenje norme u ekspertskom sistemu je restriktivno po definiciji. Korisnik programa
koji je nastao u ekspertskom sistemu biće vezan samo za tumačenja i principe koji su uneti u kod
prethodno u vidu specifikacija. Tumačenja pravne norme su postavljena u okviru neizmenljivog
izvornog koda sistema (e. source code).1 U ovom kontekstu pravni ekspertski sistem je projekcija
tumačenja određenog zakona u formi programskog jezika. Nasuprot LES-u, strana u sporu koji
se vodi u klasičnom smislu može da menja svoje stavove ili da ih dodatno objašnjava u duskom
sporu, u skladu sa svojim interesom. Sa druge strane, program nastao kao rezultat LES-a ima za
rezultat samo stavove i interese koje je autor specifikacija uneo kao uslove koje programer mora
da definiše programskim jezikom.
Opisana projekcija tumačenja određenog zakona može da bude više ili manje fleksibilna
za tumačenje: pravni ekspertski sitem može da ostavi mogućnost da koristnik bira između više
razuličitih tumačenja određene zakonske tačke. Sa druge strane, ovakvo širenje okvira tumačenja
je suštinski neograničeno: koliko pravnika, toliko i mišljenja. To dovodi do problema održivosti
programiranja s obzirom na potrebno vreme i finansijska sredstva za izradu takvog programa.

Jednakost programa/koda i specifikacije

Koja su informatička rešenja problema transkribovanja/konvertovanja/prevoda
neformalnih specifikacija ovih sistema u programski kod? Specifikaciju pravnog ekspertskog
sistema čine različiti pravni tekstovi koji mogu proizaći iz zakona, propisa ili zbirke sudskih i
arbitražnih presuda. službenih propisa ili internih biltena. Pravno-ekspertski sistem dobija i
određeni broj inputa koje daje korisnik i automatski ispisuje svoju odluku. Odluka treba da bude
verna onome što bi se desilo da je pravnik klasično, “analogno”, primenio pravnu normu na
pravnu situaciju koja predstavlja ulaznu vrednost (input) za pravni ekspertski sistem.
Metode vrednovanja ekspertskog sistema u pogledu jednakosti sa normom koja je
predmet programiranja (“specifikacijom”) razlikuju se u zavisnosti od toga da li se radi o
specifikaciji koja je određena procesom ili rezultatom.

Specifikacije definisane rezultatom

Kada pravna specifikacija karakteriše samo svojstva koja treba da ima rezultat pravnog
ekspertskog sistema, stvarna implementacija toga kako sistem zapravo dolazi do svojih odgovora
je irelevantna. Ovo je tzv. scenario „crne kutije“ (e. black box): vidi se rezultat, ali se ne vidi
postupak kojim se došlo do pravnog rezultata. Metodi provere procesa su nejasni i teško
sprovodljivi: jedina provera je da li rezultat primene pravne norme odgovara specifikaciji (samoj
normi koja je predmet kompjuterskog programa).
Šta ukoliko rezultat računarskog programa čija je specifikacija definisana nameravanim
rezultatom primene norme ne odgovara cilju same norme (npr. nalog da se kupi najjeftinije na
tržištu ne rezultira takvom kupovinom robe)? Tada (osim ukoliko nema karakteristika mašinskog
učenja i upodobljavanja novog postupanja prikupljenom iskustvu), može da se očekuje kontrola
od strane drugog kompjuterizovanog sistema ili samog operatera LES; time se umanjuje korist
od algoritmiranja norme (efikasnost, brzina, pouzdanost). Veći broj odbijanja utiče na
pouzdanost sistema što bi moglo da rezultira zahtevom za preradu programa: to je zahtevno
vremenski i tehnički skupo.
1
Otvoreni izvorni kod je slobodno dostupan korisnicima: bilo ko može da preuzme izvorni kod, da ga modifikuje i
da distribuira njegovu modifikovanu verziju u neograničenom broju kopija. Ne postoje novčane nadoknade za
licencu ili bilo koja druga ograničenja. Detaljnija i tehnolški razrađena definicija data je na web stranici Open
Source Initiative; https://opensource.org/osd.

3
 Jedan od načina da se ovo pitanje reši da se validacija vrši prethodno (ex post) a ne
naknadno kada je program već izvršen (kada je programski kod aktiviran i obavio je svoj zadatak
tumačenja norme u okviru LES). Primer ovakvog pristupa je sistem koji programskim kodom
izvršava obavezu da svaki univerzitet u Francuskoj mora da primi određeni broj studenata koje
stipendira država. Radi se o programu zasnovanom na rezultatu. Umesto da se provera vrši
naknadno, izrađen je relativno složen algoritam koji ovu proveru vrši prethodno (prilikom
prijavljivanja). Ovaj algoritam je javan: njegov rezultat je, dakle, podložan kontroli. Tako da
„crna kutija“, na ovaj način, može da postane „bela“ (transparentna). Problem je što su troškovi
ovog sistema visoki, a izrada sistema je sama po sebi kompleksna.

Specifikacija zasnovana na procesu

Zbog svoje konstruktivne prirode, specifikacije zasnovane na procesu moraju precizno da
opisuju kako da se postigne željeni rezultat. U izvesnom smislu, ove specifikacije definišu
pravila (jezički definisane formule) koje izvršava program nakon unosa određenih vrednosti od
strane korisnika. Provera da li je pravni ekspertski sistem dao tumačenje ili primenio pravo u
skladu sa specifikacijom uključuje više aktera: programere LES-a, kao i pravnike
korisnika/implementatora pravnog ekspertskog sistema.
U interdisciplinarnom procesu programiranja, to jest prevođenju pravnih, procesno
definisanih specifikacija u kod, pravnici poseduju znanja specifična za utvrđivanje da li je
specifikacija ispravno priimenjena. S druge strane, samo programer zna tačno kako program/kod
funkcioniše. Potrebne su i pravnička i programerska validacija rezultata primene programa na
osnovu date specifikacije.
Čest metod validacije u pravnim ekspertskim sistemima (kao i kod drugih softvera) je
pravljenje test slučajeva. Test slučaj je imaginarna ili stvarna lista ulaznih podataka. Slučaj koji
se terstira ima strukturu pravnog akta: opisuje ulazne činjenice zajedno sa odlukom o tome šta je
nameravani rezultat funkcionisanja softvera (“odluka”). U stvarnom svetu, sudske odluke, na
primer, donose se tek nakon što se zakon usvoji. Test slučaj pomaže da se mapiraju različiti
scenariji koji mogu nastati kada se ulazni elementi unesu u program na algoritamsku obradu.
Nedostatak ovog sistema je što testirani programi mogu da pronađu “prisustvo grešaka”, ali ne i
njihovo odsustvo: to jest, činjenica da je program dao rezultat koji je u skladu sa specifikacijama,
ne znači da ne postoje okolnosti u kojima taj rezultat ne bi odgovarao specifikaciji (odnosno
normi koja je funkcionalno specifikacija programa). Pravnik i programer traže “zajednički
osnov”, temelj (e. common ground) za validaciju rezulteta programa i njegovu saglasnost sa
specifikacijom. Problem je sledeći: potencijalno pogrešni rezultati LES-a (i nesaglasnost
rezultata sa normom/specifikacijom) su mnogobrojni. Nemoguće je da se program testira za
svako moguće ponašanje.
U određenim zemljama postoje LES sistemi koji izračunavaju iznos poreza koje
domaćinstvo duguje u zavisnosti od njegovog prihoda. U Francuskoj, verzija ovog programa ima
više hiljada ulaznih varijabila. Testiranje bi zahtevalo ne samo da se testira svaka varijabila (ulaz,
input), već i da se ta varijabila testira u kombinaciji sa drugim ulaznim varijabilama na kojima
počiva LES. Uloga pravnika u definisanju test slučajeva uključuje znanje iintuiciju: kako nije
moguće da se izradi test za svaki slučaj, moraju da anticipiraju koji su to slučajevi koji mogu da
budu problem za algoritam. Oni se suštinski bave obrnutim inženjeringom, što nije znanje koje
se uči na pravnom fakultetu.2 Kako god bilo, validacija test slučajevima je metod koji nije

2
Obrnuti inženjering (engl. reverse engineering) je postupak otkrivanja tehnoloških principa uređaja,
predmeta ili sistema putem temeljnih analiza njegove konstrukcije, funkcije i načina rada. [1] Često podrazumeva

4
potpuno pouzdan. Stoga se dopunjava drugim metodom validacije: pregledom programskog
koda.

Pregled koda kao metod provere saglasnosti računarskog programa sa pravnom

normom (specifikacijom)

Pregledanje dela koda se sastoji u čitanju i razumevanju kompjuterskog programa.

Pregled koda je uobičajena tehnika u softverskom inženjeringu: popularne platforme za
upravljanje izvornim kodom kao što je GitHub.3 Centralni koncept ove platforme u kontekstu
pregleda koda je zahtev za povlačenje. Zahtev za povlačenje je predlog autora softvera za
modifikaciju koda koji jasno prikazuje mesta gde predlog menja izvorni kod. Zahtevi za
povlačenje mogu da sadrže tekstualnu specifikaciju šta promene koda impliciraju u smislu
promena ponašanja programa: neretko ih, preko platforme, pregledaju drugi autori softvera pre
nego što budu prihvaćeni. Zahtev za povlačenje je rezultat pregleda koda učinjenog u cilju
osiguranja da promena izvornog koda tačno odgovara specifikaciji promena u ponašanju
programa: pri tome je jasno da su promene u ponašanju programa kao rezultat promene izvornog
koda poželjne (zato se izvorni kod i menja).
Pažljiv pregled koda, poput izrade test/probnog slučaja, podrazumeva zamišljanje svih
mogućih situacija sa kojima bi se softver mogao suočiti i diskutovanje o tome šta bi trebalo da
bude željeno ponašanje programa u tim situacijama. Zapravo, pregled koda često dovodi do
dodavanja novih test slučajeva sa problematičnim ulazima utvrđenim inspekcijom izvornog

razlaganje nečega: na primer, mehaničkog uređaja, elektronske komponente, softverskog programa, ili biološke,

hemijske ili organske materije, i analiziranja pricipa rada, u cilju popravke, tekućeg održavanja ili stvaranja novog
uređaja ili programa, koji vrši istu funkciju, ali ne i prosto kopiranje bez razumevanja originala. Koreni obrnutog
inženjeringa potiču iz analize opreme za komercijalnu ili vojnu primenu. [2] Cilj je da se dođe do zaključaka o
konstruktivnim odlukama koje su dovele do nastanka gotovog proizvoda uz malo ili nimalo predznanja o
postupcima koji su upotrebljeni u originalnom procesu konstruisanja i proizvodnje.
3
GitHub (https://github.com) je veb-baziran hosting servis za kontrolu verzije, Git. Pruža Git
funkcionalnosti: distribuiranu kontrolu revizija i menadžment izvornog koda (eng. Source Control Management —
SCM), dodajući dodatne funkcije. Za razliku od Git-a, koji je striktno alat koji se koristi iz komandne linije, GitHub
pruža veb grafički interfejs, radnu površinu i mobilnu integraciju. Takođe pruža kontrolu pristupa i nekoliko
funkcija za saradnju, kao što su praćenje grešaka (eng. bug tracking), zahteve za dodavanje novih
karakteristika (eng. feature request), upravljanje zadacima (eng. task management) i mogućnost
pravljenja viki dokumentacije za svaki projekat.
GitHub pruža planove za privatna skladišta kao i besplatne naloge, koji se obično koriste kao hostovi za
softverske projekte otvorenog koda. GitHub izveštaji iz aprila 2016. godine tvrde postojanje više od 14 miliona
korisnika i 35 miliona skladišta, što GitHub čini najvećim hostom izvornog koda na svetu.
Razvoj GitHub platforme je počeo 1. oktobra 2007. Sajt je pokrenut u aprilu 2008. od strane  Tom Preston-
Vernera, Krisa Vanstrata i P.J. Hajeta, par meseci pošto je bio dostupan u beta izdanju.
Projektima na GitHub-u se pristupa i manipuliše koristeći standardni Git interfejs iz komandne linije preko
kojeg su dostupne i sve standardne Git komande. GitHub dopušta registrovanim i neregistrovanim korisnicima da
pregledaju javna skladišta na sajtu. Nekoliko desktop klijenata i Git priključaka su kreirani pomoću GitHub-a koji se
integrišu sa platformom.
GitHub sajt pruža funkcije slične društvenim mrežama kao što su: dovodi (engl. feeds), pratioci (engl.
followers), viki (koristeći softver Gollum) i grafikone saradnje koji ukazuju kako programeri rade na svojim
verzijama ("račvama") skladišta i koja račva (i grana te račve) je najnovija.
Korisnik mora da napravi nalog kako bi doprineo stranici, ali javna skladišta mogu biti pregledana i
preuzeta od strane bilo koga. Sa registrovanim korisničkim nalogom, korisnici mogu da diskutuju, upravljaju
skladištima, prave nova skladišta, postavljaju doprinose drugim skladištima i pregledaju izmene u kodu.

5
koda. U slučaju pravnih ekspertskih sistema, problem je što se pravo može tumačiti na više
načina, a pravne dileme rešavaju nadležni organi u pravnom procesu. Programer pravnog
ekspertskog sistema, prilikom pisanja koda, mora unapred da odredi ponašanje softvera za sve
moguće ulazne vrednosti; kada se radi o pravu, to nije moguće. Programer nema unapred pristup
svim budućim sudskim odlukama koje će uticati na ponašanje sistema. Ovo je velika i
fundamentalna nekompatibilnost između pravnog sistema i računarskog programa. Pravni sistem
reaguje naknadno na situacije i ponašanja. Računarski program sve rešava unapred, pre nego što
postane fukcionalan i počne da proizvodi pravne posledice. Da bi LES bio funkcionalan,
potrebno je pravničko znanje i pravnička intuicija: mera njihove uspešne implementacije u kod i
kroz process dizajna koda biće i mera uspeha programa koji je LES generisao.
Navedena teškoća prevazilazi se tako što pravnici koji učestvuju u kreiranju i validaciji
rezultata LES sistema u skladu sa datim specifikacijama (normama) definišu, prema najboljem
znanju i umenju, moguće situacije. Te situacije su parametri za formiranje ulaznih vrednosti i
uslova pre nego što se program operacionalizuje. Analogna situacija nije načelno česta kod
odluka koje su rezultat pravnih procesa (sudovi i arbitraže ne daju mišeljenja niti donose odluke
o hipotetičkim slučajevima, delimično uz izuzetak instituta obiter dictum-a).
Primer ovakvog pristupa je funkcionisanje poreskih službi: nacionalna zakonodavstva
uvode nove odredbe poreskog prava. Ove odredbe mogu da se tumače različito. Pravni
ekspertski sistem, međutim, mora da ima rešenje koje unapred, pre nego što bilo koji organ
(najčešće sud) donese odluku o načinu interpretacije novih poreskih odredbi, omogućava
obračun poreza. Sve dok se i sami sudovi ne zainteresuju za rad ovih sistema, ove unapred
definisane odluke LES –a biće predmet ispitivanja od strane advokata i sudija (reč je o procesno
orijentisanom sistemu).
Pregled koda omogućava validaciju-ispitivanje saglasnosti specifikacije/norme i
računarskog programa. Kvalitet te validacije zavisi od kompetencije onih koji povezuju
apstraktnju pravnu normu sa računarskim kodom koji normu interpretira. Ova kompetencija
zahteva znanje i prava i koda. Navedeno binarno znanje obezbeđuje se na više načina: prvi je
pretvaranje pravnika u programere tako što se pravnicima obezbeđuju alati (recimo u formi
pseudokoda ili grafičkih interfejsova) koji omogućavaju pravniku da napiše kompjuterski
program. Ovim alatima, međutim, često nedostaju napredne funkcije, što je cena koja se plaća za
jednostavnost. Alternativa ovom pristupu je da se dizajnira programski jezik koji izgleda kao
katalog ili rečnik pravnih formulacija. Ovaj jezik je najpre tražen u kontekstu logičkog
programiranja (primene pravila simboličke logike), a u novije vreme kroz tzv „kontrolisani
priodan jezik“ (e. „Controlled Natural Language“).4

4
Kontrolisani prirodni jezici su vrsta prirodnih jezika koji se dobijaju ograničavanjem gramatike i rečnika
radi smanjivanja ili uklanjanja dvosmislenosti i složenosti. Kontrolisani jezici tradicionalno spadaju u dve glavne
vrste: one koji omogućavaju ljudima da bolje razumeju napisani tekst (npr. osobama koje nisu izvorni govornici) i
one koje omogućavaju pouzdanu automatsku semantičku analizu jezika. Prva vrsta jezika (često se nazivaju
"pojednostavljeni" ili "tehnički" jezici), na primer ASD pojednostavljeni tehnički engleski, tehnički engleski
Katerpilara, IBM-ov jednostavni engleski, koriste se u industriji radi povećanja kvaliteta tehničke dokumentacije i
eventualno radi pojednostavljenja (polu)automatskog prevoda dokumentacije. Ovi jezici ograničavaju pisca opštim
pravilima kao što su „Neka rečenice budu kratke“, „Izbegavajte upotrebu zamenica“, „Koristite samo reči koje se
nalaze u rečniku“ i „Koristite samo aktiv“. Druga vrsta jezika ima formalnu sintaksu i semantiku i može se preslikati
na postojeći formalni jezik, kao što je logika prvog reda (Logika prvog reda ili predikativni račun prvog reda je
formalni sistem koji se koristi u matematici, filozofiji, lingvistici i računarstvu.). Stoga se ti jezici mogu koristiti
kao jezici za predstavljanje znanja, [1] a pisanje tih jezika potpuno je podržano automatskim
proveravanjem doslednosti.

6
 Treći pristup je zasnovan na interdisciplinarnoj saradnji zasnovanoj na tzv. „Agilnom
pristupu razvoju softvera“.5
Ova metodologija podrazumeva zajednički kontinuirani rad pravnika i programera, uz
pismenu transformaciju specifikacija/pravne norme u pravila programskog jezika specifičnog za
domen tzv. Catala jezika. Preplitanjem fragmenata zakonske specifikacije i fragmenata koda
(pismeno programiranje), pravnik i programer (programiranje u paru) mogu pronaći zajedničku
osnovu za definisanje kriterijuma utvrđvanja ispravnosti rezultata softvera i saglasnosti sa
specifikacijom/pravnom normom čijoj implementaciji služi.
Takav proces saradnje omogućava neku vrstu defanzivnog programiranja prilikom
prevođenja pravne norme u kod.
Odbrambeno programiranje je metod kreiranja programa s ciljem obezbeđenja
kontinuiranog funkcionisanja programa u nepredviđenim okolnostima. Defanzivno
programiranje koristi se u situacijama kada je potrebna pouzdanost , bezbednost i sigurnost
funkcionisanja programa: u pravnom kontekstu to je svakako slučaj, s obzirom na posledice
neadekvatne primene pravne norme.
Na primer, u kontekstu agilnog programiranjau LES-u, prvi korak je da programer da
okvirni (grubi) prevod dela pravnog propisa. Ovaj prvi prevod će ispitati pravnik koji će pokušati
da smisli situaciju koja razbija implicitne pretpostavke na kojima je programer zasnovao svoj
prevod norme u kod. Na primer, da bi izračunao socijalne beneficije, programer može
pretpostaviti da je svako dete vezano za jedno domaćinstvo. Ali u ovoj situaciji, advokat može
podsetiti programera na podeljeno starateljstvo: kako ovaj slučaj uneti u programski kod? Da li
postoji neki drugi zakon koji ovo pitanje reguliše? Ponavljanjima ovog procesa se jača
pouzdanost i preciznost koda u odnosu na specifikaciju/pravnu normu čijoj implementaciji služi.
Neretko, opisani proces kooperacije pravnika i programera može da definiše i
kontradiktornost u postupku konverzije proze u kod.
Programiranje kao podsticaj za jasne formulacije pravnih odredbi
Kada bi se metodologija primene pravnih ekspertskih sistema proširila i na proceduru
definisanja zaknskih propisa, to bi svakako pomoglo kasnijem razumevanju namera koje su
zakonodavci imali. Izgradnjom čvršćih zakonskih specifikacija koje jasno obuhvataju nameru
zakonodavca, olakšala bi se javna debata oko sadržine zakonskih rešenja. Postoje alati koji
zakonodavcima omogućavaju da procene uticaj primene pravnih praavila. Ovi su alati zasnovani
na LES konceptima. Kako je cilj pravnih ekspertskih sistema da automatizuju sprovođenje
zakona, oni su suočeni sa istom raznolikošću stvarnih situacija kao i sudovi, osim što ne mogu da
izvrše odluku suda već su dužni su da slede ono što je u linijama koda/računarskog programa.
Pravo pojedinaca da se žale na takve automatizovane odluke da se žale na ljudski sud, kao što je
predviđeno odgovarajućim odredbama zakonodavstva EU, adekvatno je sredstvo za otklanjanje
nedogovarajućih posledica ovih sistema. Navedena mogućnost trebalo bi da bude praćena
metodologijom pregleda i testiranja koda od strane pravnih stručnjaka,. U praksi je zamislivo da
tim za razvoj softvera iz poreske uprave definiše niz hipotetičkih problematičnih situacija u vezi
primene poreskog zakonodavstva. Takve situacije, u sledećem koraku, “podnosi” “sudu” koji bi
mogao da donosi “hipotetičke” sudske presude. Ove presude se koriste prilikom definisanja
5
Agilni razvoj softvera podrazumeva razvoj softvera kroz iteracije-ponavljanja gde se projeakt realizuje
kroz ponavljanja i koperaciju aktera. gde se glavni životni ciklus projekta sastoji od nekoliko iteracija u nizu.
Agilne metode imaju značajne razlike u odnosu na ranije planskocentrične inženjerske metode. Najuočljivija razlika
je insistiranje na manje obimnoj dokumentaciji za dati problem. Umesto dokumentaciono-orijentisane, agilne
metode su pre orijentisane ka izvornom kodu kao ključnom delu dokumentacije. Agilne metode su pre adaptivne
nego predvidljive.

7
odredbi softvera. Stvaraju se “virtuelni” sudski presedani. Takve “presude” bi unapredile rad
LES sistema i eliminisale greške čije posledice bi osetio veliki broj pojedinaca (upravo su te
greške razlog zbog kojeg se LES ograničeno primenjuje).