O porównywalności prawa i oprogramowania

Cześć, jestem Martin Kurtz, radca prawny i jeden z dwóch założycieli MaraDocs. Witamy na blogu MaraDocs. Piszemy o tematach z pogranicza praktyki prawniczej i IT.

To jest pierwszy artykuł z serii Anwalt2Dev - A Journey. W serii artykułów opowiem o mojej własnej historii zawodowej i motywacji, ale przede wszystkim wyjaśnię z różną głębią wiele koncepcji i technologii, które z mojego punktu widzenia tworzą dzisiejszy krajobraz IT. I tak - z pewnością będzie też trochę kodu. :)

// anwalt2dev - a journey
const SERIES_NAME = "Anwalt2Dev - A Journey"

export const tellReader = (whatDoesHeRead: string) => {
  if (whatDoesHeRead === SERIES_NAME) {
    return "There will be code, my friend :) "
  } else {
    throw new Error("you are reading the wrong stuff, buddy!")
  }
}

Więc teraz w medias res!

Prawo

W 2005 roku rozpocząłem studia prawnicze na Uniwersytecie w Bonn. Nie mogę zbytnio opowiadać o moich pierwszych latach na uniwersytecie: prof. Puppe (legendarna specjalistka od prawa karnego, znana z reprezentowania poglądów mniejszościowych) nadal aktywnie wykładała, a w Seminarium Prawniczym były jeszcze dedykowane sale komputerowe, w których studenci mogli korzystać z komputerów instytutu.

Dobrze pamiętam, że pierwsze egzaminy miały szokująco inny poziom niż sprawdziany, do których byłem przyzwyczajony ze szkoły. Prawo, którego można się było uczyć jako student, prezentowało się mi jako naprawdę wielka i spójna koncepcja. Potrzebowałem trochę czasu, aby zrozumieć, że istnieją podstawowe struktury myślenia, modele systemowe i metody, które zachowują swoją ważność we wszystkich dziedzinach.

Z pewnością trzy wielkie dziedziny (prawo cywilne, prawo publiczne i prawo karne) mają swój własny charakter, niemal własny smak, który młody student poznaje kawałek po kawałku przez wiele, wiele godzin, ale mimo to całości leży u podstaw powtarzający się wzorzec: małe kroki.

Schematy egzaminacyjne

Uczyliśmy się przede wszystkim schematów egzaminacyjnych: na przykład przesłanek różnych podstaw roszczeń lub zgodności z prawem określonych działań państwowych. Za każdym punktem kontrolnym kryje się rozwidlenie i jest się zmuszonym naprawdę zatrzymać się przy tym rozwidleniu i dokładnie sprawdzić, czy wszystkie podpunkty są spełnione. Tylko wtedy droga do następnego punktu kontrolnego jest wolna.

Przykład: schemat zgodności z prawem aktu administracyjnego, przedstawiony tutaj na podstawie fikcyjnej klasy TypeScript dla aktu administracyjnego.

I. Podstawa prawna (EGL)
  1. Wymagana?
  2. Wybór podstawy prawnej
  
II. Zgodność formalna
  1. Właściwość
  2. Postępowanie
    a. Przesłuchanie
    b. Zakazy uczestnictwa
    c. Udział innych organów
  3. Forma
  
III. Zgodność materialna
  1. Przesłanki podstawy prawnej
  2. Ogólne przesłanki zgodności z prawem
    a) Określoność, § 37 I VwVfG
    b) Brak niemożliwości faktycznej lub prawnej
  3. Właściwy adresat
  4. Skutek prawny: Decyzja uznaniowa czy decyzja związana?
    a) Decyzja związana: Zarządzenie przewidzianego skutku prawnego
    b) Decyzja uznaniowa:
      aa) Błąd uznania?
        (1) Niewykorzystanie uznania
        (2) Niedostateczne wykorzystanie uznania
        (3) Niewłaściwe wykorzystanie uznania
        (4) Przekroczenie uznania
      bb) Ewent. redukcja uznania do zera
      cc) Ewent. intendowane uznanie

Ten sposób postępowania małymi krokami jest bardzo podobny do przebiegu programów komputerowych. Przebieg klasycznego (jednowątkowego) programu przewiduje w każdym momencie dokładnie jeden krok sprawdzający lub roboczy, którego nigdy nie można pominąć. Z drugiej strony program może odpowiedzieć tylko na pytania lub rozwiązać problemy, które zostały przewidziane w momencie tworzenia programu. Wymaga to przy tworzeniu oprogramowania w szczególny sposób umiejętności przekształcenia problemu do rozwiązania w model logiczny, który można przejść atomowo. Przy tym wszystkie możliwe pytania częściowe muszą również stać się częścią modelu. Jeśli w późniejszym czasie wystąpią nieoczekiwane stany (edge cases), które nie są przechwytywane (np. za pomocą wzorców try catch), program się zawiesza.

Podejście małych kroków w myśleniu prawniczym i modelowanie problemów w rozwoju oprogramowania są więc bardzo podobne.

Brak jednoznacznych rozwiązań

Oprogramowanie można wykonywać, testować i debugować dokładnie i odtwarzalnie. Dane wejściowe prowadzą (jeśli są poprawnie zaimplementowane) do zdefiniowanych danych wyjściowych. Kontrole prawne natomiast charakteryzują się z reguły tym, że chociaż opierają się na ustrukturyzowanej strukturze egzaminacyjnej (subsumpcja itp.), zawsze zawierają również elementy zależne od oceny i są otwarte na wyważenie w wyniku. Wynik nie jest więc deterministyczny.

Oprogramowanie można testować ze względu na jego deterministyczną naturę: na przykład w unit test testowana funkcja jest programowo zasilana zdefiniowanymi danymi wejściowymi, a następnie sprawdzana, czy dostarcza oczekiwane dane wyjściowe. Przepisy prawne natomiast są językowo niejednoznaczne lub przynajmniej wymagają interpretacji. Prowadzi to do tego, że nie można testować wyników w klasycznym sensie.

Przykład unit testu (tutaj w stylu frameworka Jest)

describe('tellReader function', () => {
  test('should return success message when given correct series name', () => {
    // przygotowanie
    const correctSeriesName = "Reise vom Rechtsanwalt zum Softwareentwickler";
    const expectedMessage = "There will be code, my friend :) ";

    // wykonanie
    const result = tellReader(correctSeriesName);

    // porównanie
    expect(result).toBe(expectedMessage);
  });
});

LLM-y i nowe rozumienie IT: Prawdopodobieństwa zamiast prawd?

Podczas gdy klasyczny rozwój oprogramowania długo uchodził za uosobienie deterministycznej logiki – dane wejściowe wchodzą, wyraźnie zdefiniowane dane wyjściowe wychodzą – zastosowanie dużych modeli językowych (LLM) takich jak Claude, LLama czy ChatGPT przynosi nową, być może łagodniejszą formę IT. Systemy te nie działają na podstawie sztywno zakodowanych drzew decyzyjnych, ale na podstawie wzorców statystycznych, które wyekstrahowały z niewyobrażalnie dużych zbiorów danych. Dane wyjściowe nie są więc przewidywalne w ściśle matematycznym sensie, ale poruszają się w ramach prawdopodobnego, typowego, kontekstowo-wiarygodnego.

W tej właściwości wyniki LLM-ów i wyniki oraz metody argumentacji prawnej są do siebie podobne. Również w prawie decyzje nie są dedukowane czysto logicznie, ale podejmowane w polu napięcia między tekstem normy, stanem faktycznym, interpretacją i wyważeniem. Wynik kontroli prawnej rzadko jest „poprawny" w sensie obiektywnej wartości – jest raczej możliwy do obrony, przekonujący, metodycznie czysto wyprowadzony. Przy czym to (i tutaj wracamy do braku możliwości weryfikacji) można ponownie ocenić tylko w ocenie osoby trzeciej, która z kolei musi zastosować niejasny model, aby ocenić wcześniej znaleziony. Paralela do odpowiedzi modelu językowego jest oczywista: Tutaj również wiarygodność oparta na istniejących strukturach modeli statystycznych liczy się bardziej niż absolutna prawda.

Tak powstaje nowy pomost między prawem a technologią. Podczas gdy wcześniej, jak opisano powyżej, na pierwszym planie było strukturalne porównanie między subsumpcją prawną a szczegółowym projektowaniem oprogramowania, dzisiejszy rozwój AI pozwala na głębszą analogię: Praca z prawdopodobieństwami, wrażliwością kontekstową i otwartością dyskursywną nie jest już tylko domeną nauk humanistycznych.

Ponieważ przykłady kodu wyglądają tak ładnie wizualnie, następuje jeszcze porównanie nowego i starego świata w formie dwóch funkcji TypeScript.

Klasycznie i deterministycznie:

function isValidPurchase(userAge: number): boolean {
  if (userAge >= 18) {
    return true // Pełnoletni – zakup dozwolony
  } else {
    return false // Niepełnoletni – zakup odmówiony
  }
}

console.log(isValidPurchase(17)) // false
console.log(isValidPurchase(18)) // true

Nowoczesny styl LLM (lub: argumentacja prawna jako funkcja)

function assessPurchaseEligibility(userAge: number, maturityLevel: "hoch" | "mittel" | "niedrig"): string {
  if (userAge >= 18) {
    return "Zakup prawdopodobnie dozwolony – osiągnięta klasyczna pełnoletność."
  }

  if (userAge >= 16 && maturityLevel === "hoch") {
    return "Możliwa do obrony argumentacja za zakupem – możliwy margines interpretacji."
  }

  if (userAge < 16 || maturityLevel === "niedrig") {
    return "Zakup raczej niedopuszczalny – ryzyko zbyt wysokie."
  }

  // return przy słabym promptcie bez parametrów wejściowych
  return "Jestem LLM i halucinuję bzdury, a jeśli nie uważasz, nie zauważysz tego i uwierzysz, że to prawda."
}

Jak dalej?

Po tej małej wycieczce w podobieństwa i różnice między sposobem myślenia prawniczego a "sposobem myślenia" komputerów i programów, w następnym artykule będzie znowu nieco mniej teoretycznie.

W mojej własnej praktyce adwokackiej (dużo prawa o ruchu drogowym) powstała wręcz frustracja z powodu nieskutecznych procesów, która tak bardzo mi przeszkadzała, że przez kilka lat zajmowałem się rozwojem oprogramowania tak intensywnie, że dzisiaj czasami nie jestem pewien, czy powinienem przedstawić się jako prawnik czy jako programista, gdy pytają mnie, co robię :)

Drugi artykuł z serii: Anwalt2Dev - A Journey - Digitalisierung von Kanzleiprozessen