Om sammenlignbarheten mellom jus og programvare

Hei, jeg er Martin Kurtz, advokat og en av de to grunnleggerne av MaraDocs. Velkommen til MaraDocs-bloggen. Vi skriver om temaer i skjæringspunktet mellom advokatvirksomhet og IT.

Dette er den første artikkelen i serien Anwalt2Dev - A Journey. I artikkelserien vil det handle om min egen profesjonelle historie og motivasjon, men fremfor alt vil jeg i ulik dybde forklare mange konsepter og teknologier som utgjør dagens IT-landskap fra mitt perspektiv. Og ja - det vil sikkert også bli litt kode. :)

// 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!")
  }
}

Så, nå går vi rett på sak!

Jus

Jeg begynte å studere jus ved Universitetet i Bonn i 2005. Jeg kan ikke fortelle så mye om mine første år ved universitetet: Professor Puppe (en legendarisk strafferettsekspert, kjent for sitt mindretal i juridiske spørsmål) forela fortsatt aktivt og i det juridiske seminaret var det fortsatt dedikerte datarom der studenter kunne bruke instituttets datamaskiner.

Jeg husker godt at de første prøvene hadde et skremmende annet nivå enn eksamenene jeg var vant til fra skolen. Jusen, som man fikk lære som student, presenterte seg for meg som et virkelig stort og sammenhengende konsept. Det tok tid før jeg forsto at det finnes underliggende tankemønstre, systemmodeller og metoder som beholder sin gyldighet på alle områder.

Sikkert har de tre store områdene (sivilrett, offentlig rett og strafferett) hver sin helt egen karakter, nesten sin egen smak, som man som ung student blir kjent med bit for bit over mange, mange timer, men likevel ligger det et gjentakende mønster til grunn for det hele: Trinndeling.

Vurderingsskjemaer

Vi lærte fremfor alt vurderingsskjemaer: For eksempel forutsetningene for ulike rettsgrunnlag eller lovligheten av bestemte statlige handlinger. Bak hvert vurderingspunkt skjuler det seg en forgrening, og man er tvunget til å faktisk stoppe ved denne forgreningen og se nøye på om alle underpunktene er oppfylt. Først da er veien til neste vurderingspunkt fri.

Eksempel: Skjema for lovligheten av en forvaltningsavgjørelse, her presentert basert på en fiktiv forvaltningsavgjørelse-klasse i TypeScript.

I. Hjemmelsgrunnlag (EGL)
  1. Nødvendig?
  2. Valg av hjemmelsgrunnlag 
  
II. Formell lovlighet
  1. Kompetanse
  2. Saksbehandling
    a. Forhåndsvarsling
    b. Habilitetskrav
    c. Medvirkning fra andre myndigheter
  3. Form
  
III. Materiell lovlighet
  1. Forutsetninger for hjemmelsgrunnlaget 
  2. Alminnelige lovlighetskrav
    a) Bestemthet, § 37 I VwVfG
    b) Ingen faktisk eller rettslig umulighet
  3. Riktig adressat
  4. Rettsvirkning: Skjønnsmessig avgjørelse eller bundet avgjørelse?
    a) Bundet avgjørelse: Anordning av den forutsatte rettsvirkningen
    b) Skjønnsmessig avgjørelse:
      aa) Skjønnsfeil?
        (1) Manglende skjønnsutøvelse
        (2) Innsnevret skjønn
        (3) Feilaktig skjønnsutøvelse
        (4) Overskridelse av skjønn
      bb) Evt. innsnevring av skjønn til null
      cc) Evt. intendert skjønn

Denne måten å gå trinnvis frem på er veldig lik hvordan dataprogrammer kjører. Forløpet til et klassisk (single threaded) program har til enhver tid nøyaktig ett kontroll- eller arbeidssteg som aldri kan hoppes over. Motsatt kan et program også bare besvare de spørsmålene eller løse de problemene som var forutsatt da programmet ble laget. Dette krever i særlig grad ved utvikling av programvare evnen til å overføre problemet som skal løses til en logisk modell som kan gjennomgås atomært. Alle tenkelige delspørsmål må også bli en del av modellen. Hvis det senere oppstår uventede tilstander (edge cases) som ikke fanges opp (f.eks. ved hjelp av try catch-mønstre), krasjer programmet.

Trinndelingen i juridisk tenkning og problemmodelleringen i programvareutvikling er altså veldig like.

Ingen entydige løsninger

Programvare kan kjøres, testes og feilsøkes eksakt og reproduserbart. En input fører (hvis korrekt implementert) til en definert output. Juridiske vurderinger derimot kjennetegnes som regel av at de riktignok bygger på en strukturert vurderingsoppbygning (subsumpsjon osv.), men alltid også inneholder verdiavhengige elementer og i resultatet er åpen for avveining. Resultatet er altså ikke deterministisk.

Programvare kan testes på grunn av sin deterministiske natur: I en unit test for eksempel blir en funksjon som skal testes programmatisk matet med en definert input og deretter kontrollert om den leverer forventet output. Lover derimot er språklig tvetydige eller i det minste tolkningsbehovende. Dette fører til at man ikke kan teste resultater i klassisk forstand.

Eksempel på en unit test (her i stilen til Jest-rammeverket)

describe('tellReader function', () => {
  test('should return success message when given correct series name', () => {
    // forberede
    const correctSeriesName = "Reise fra advokat til programvareutvikler";
    const expectedMessage = "There will be code, my friend :) ";

    // utføre
    const result = tellReader(correctSeriesName);

    // sammenligne
    expect(result).toBe(expectedMessage);
  });
});

LLM-er og den nye IT-forståelsen: Sannsynligheter i stedet for sannheter?

Mens klassisk programvareutvikling lenge har vært selve inkarnasjonen av deterministisk logikk – input inn, klart definert output ut –, bringer bruken av store språkmodeller (LLM-er) som Claude, LLama eller ChatGPT med seg en ny, kanskje mykere form for IT. Disse systemene opererer ikke på grunnlag av fast kodede beslutningstrær, men på grunnlag av statistiske mønstre som de har ekstrahert fra utenkelig store datamengder. Output-en er dermed ikke forutsigbar i matematisk-streng forstand, men beveger seg innenfor rammen av det sannsynlige, det typiske, det kontekstuelt plausible.

I denne egenskapen ligner resultatene fra LLM-er og resultatene og metodene i juridisk argumentasjon hverandre. Også i jussen blir avgjørelser ikke rent logisk dedusert, men tatt i et spenningsfelt mellom lovtekst, saksforhold, tolkning og avveining. Resultatet av en juridisk vurdering er sjelden "riktig" i betydningen av en objektiv verdi – det er snarere forsvarlig, overbevisende, metodisk solid utledet. Der dette (og her kommer vi tilbake til den manglende verifiserbarheten) igjen bare kan bedømmes i vurderingen til en tredjepart, som på sin side må anvende en vag modell for å evaluere den tidligere funnet. Parallellen til svaret fra en språkmodell er åpenbar: Også her teller plausibiliteten basert på eksisterende statistiske modellstrukturer mer enn den absolutte sannheten.

Slik oppstår en ny bro mellom rett og teknologi. Mens tidligere som beskrevet den strukturelle sammenligningen mellom juridisk subsumpsjon og detaljert programvaredesign sto i forgrunnen, tillater dagens KI-utvikling en dypere analogi: Arbeidet med sannsynligheter, kontekstsensitivitet og diskursiv åpenhet er for lengst ikke lenger kun domenet til humanvitenskapene.

Fordi kodeeksemplene er så fine visuelt, følger det en sammenligning av den nye og den gamle verden i form av to TypeScript-funksjoner.

Klassisk og deterministisk:

function isValidPurchase(userAge: number): boolean {
  if (userAge >= 18) {
    return true // Myndig – kjøp tillatt
  } else {
    return false // Ikke myndig – kjøp nektet
  }
}

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

Moderne LLM-stil (eller: juridisk argumentasjon som funksjon)

function assessPurchaseEligibility(userAge: number, maturityLevel: "høy" | "middels" | "lav"): string {
  if (userAge >= 18) {
    return "Kjøp sannsynligvis tillatt – klassisk myndighetsalder oppnådd."
  }

  if (userAge >= 16 && maturityLevel === "høy") {
    return "Forsvarlig argumentasjon for kjøp – tolkningsrom mulig."
  }

  if (userAge < 16 || maturityLevel === "lav") {
    return "Kjøp heller ikke tillatt – risiko for høy."
  }

  // return ved dårlig prompt uten input-parametere
  return "Jeg er en LLM og jeg hallusinerer tull, og hvis du ikke passer på, merker du det ikke og holder det for sant."
}

Hva skjer videre?

Etter denne lille utflukten i likhetene og forskjellene mellom den juridiske tenkemåten og "tenkemåten" til datamaskiner og programmer blir det i neste artikkel igjen litt mindre teoretisk.

I min egen advokatpraksis (mye trafikrett) har det oppstått en regelrett frustrasjon over ineffektive prosesser, som har plaget meg så sterkt at jeg over flere år har beskjeftiget meg så intenst med programvareutvikling at jeg i dag noen ganger er usikker på om jeg skal presentere meg som jurist eller som programvareutvikler når jeg blir spurt om hva jeg gjør :)

Andre artikkel i serien: Anwalt2Dev - A Journey - Digitalisering av advokatprosesser