Sulla comparabilità tra diritto e software

Ciao, sono Martin Kurtz, avvocato e uno dei due fondatori di MaraDocs. Benvenuto nel blog di MaraDocs. Scriviamo di temi che si collocano all'intersezione tra professione legale e IT.

Questo è il primo articolo della serie Anwalt2Dev - A Journey. Nella serie di articoli parlerò della mia storia professionale e delle mie motivazioni, ma soprattutto spiegherò con diversi livelli di approfondimento molti concetti e tecnologie che, dal mio punto di vista, caratterizzano l'attuale panorama IT. E sì - ci sarà sicuramente anche un po' di codice. :)

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

Bene, ora entriamo in medias res!

Giurisprudenza

Ho iniziato a studiare giurisprudenza all'Università di Bonn nel 2005. Non posso raccontare molto dei miei primi anni all'università: la professoressa Puppe (una leggendaria penalista, nota per le sue opinioni minoritarie) insegnava ancora attivamente e nel Seminario Giuridico c'erano ancora sale computer dedicate, dove gli studenti potevano utilizzare i computer dell'istituto.

Ricordo bene che i primi esami avevano un livello sorprendentemente diverso rispetto alle prove a cui ero abituato a scuola. La giurisprudenza che si imparava come studente mi si presentava come un concetto davvero ampio e coerente. Mi ci è voluto del tempo per capire che esistono strutture di pensiero o modelli di sistema e metodi sottostanti che mantengono la loro validità in tutti gli ambiti.

Certamente le tre grandi aree (diritto civile, diritto pubblico e diritto penale) hanno ciascuna un carattere proprio, quasi un sapore proprio, che come giovane studente si impara a conoscere pezzo per pezzo in molte, molte ore, ma nonostante ciò all'insieme sottostà un modello ricorrente: la gradualità.

Schemi d'esame

Imparavamo soprattutto schemi d'esame: ad esempio i presupposti di diverse basi giuridiche per le pretese o della legittimità di determinate azioni statali. Dietro ogni punto d'esame si nasconde una diramazione e si è costretti a fermarsi effettivamente a questa diramazione e a guardare attentamente se tutti i sottopunti sono soddisfatti. Solo allora la strada per il prossimo punto d'esame è libera.

Esempio: Schema della legittimità di un atto amministrativo, qui rappresentato sulla base di una classe fittizia di atto amministrativo in TypeScript.

I. Base di abilitazione (EGL)
  1. Necessaria?
  2. Scelta della EGL 
  
II. Legittimità formale
  1. Competenza
  2. Procedura
    a. Audizione
    b. Divieti di partecipazione
    c. Partecipazione di altre autorità
  3. Forma
  
III. Legittimità sostanziale
  1. Presupposti della base di abilitazione 
  2. Presupposti generali di legittimità
    a) Determinatezza, § 37 I VwVfG
    b) Nessuna impossibilità di fatto o di diritto
  3. Destinatario corretto
  4. Conseguenza giuridica: decisione discrezionale o decisione vincolata?
    a) Decisione vincolata: disposizione della conseguenza giuridica prevista
    b) Decisione discrezionale:
      aa) Errore di discrezionalità?
        (1) Mancato esercizio della discrezionalità
        (2) Sottovalutazione della discrezionalità
        (3) Uso improprio della discrezionalità
        (4) Eccesso di discrezionalità
      bb) Eventuale riduzione della discrezionalità a zero
      cc) Eventuale discrezionalità intenzionale

Questo tipo di procedimento graduale è molto simile all'esecuzione dei programmi per computer. Il flusso di un programma classico (single threaded) prevede in ogni momento esattamente un passo di verifica o di lavoro, che non può mai essere saltato. Al contrario, un programma può rispondere solo alle domande o risolvere solo i problemi che erano previsti al momento della creazione del programma. Ciò richiede nella creazione del software in modo particolare la capacità di trasferire il problema da risolvere in un modello logico che può essere attraversato atomicamente. In questo processo, tutte le possibili sotto-domande devono diventare parte del modello. Se in un momento successivo si verificano stati inaspettati (edge cases) che non vengono intercettati (ad esempio tramite pattern try catch), il programma si blocca.

La gradualità del pensiero giuridico e la modellizzazione dei problemi nello sviluppo software sono quindi molto simili.

Nessuna soluzione univoca

Il software può essere eseguito, testato e debuggato in modo esatto e riproducibile. Un input porta (se correttamente implementato) a un output definito. Gli esami giuridici invece si caratterizzano generalmente per il fatto che, sebbene si basino su una struttura d'esame strutturata (sussunzione ecc.), contengono sempre anche elementi dipendenti dalla valutazione e il risultato è aperto alla ponderazione. Il risultato quindi non è deterministico.

Il software può essere testato a causa della sua natura deterministica: in un unit test, ad esempio, una funzione da testare viene alimentata programmaticamente con un input definito e poi si verifica se fornisce l'output atteso. Le leggi invece sono linguisticamente ambigue o almeno necessitano di interpretazione. Ciò fa sì che non si possano testare i risultati nel senso classico.

Esempio di un unit test (qui nello stile del framework Jest)

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

    // eseguire
    const result = tellReader(correctSeriesName);

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

LLM e la nuova comprensione dell'IT: probabilità invece di verità?

Mentre lo sviluppo software classico è stato a lungo considerato l'epitome della logica deterministica – input dentro, output chiaramente definito fuori –, l'uso di grandi modelli linguistici (LLM) come Claude, LLama o ChatGPT porta con sé una forma nuova, forse più morbida, di IT. Questi sistemi non operano sulla base di alberi decisionali codificati rigidamente, ma sulla base di pattern statistici che hanno estratto da quantità di dati inimmaginabilmente grandi. L'output quindi non è prevedibile nel senso matematicamente rigoroso, ma si muove nell'ambito del probabile, del tipico, del contestualmente plausibile.

In questa caratteristica, i risultati degli LLM e i risultati e i metodi dell'argomentazione giuridica si assomigliano. Anche nella giurisprudenza, le decisioni non vengono dedotte puramente in modo logico, ma prese in un campo di tensione tra testo normativo, fattispecie, interpretazione e ponderazione. Il risultato di un esame giuridico è raramente "corretto" nel senso di un valore oggettivo – è piuttosto sostenibile, convincente, metodologicamente ben derivato. Dove questo (e qui torniamo alla mancanza di verificabilità) può essere valutato di nuovo solo nel giudizio di un terzo, che a sua volta deve applicare un modello vago per valutare quello precedentemente trovato. Il parallelo con la risposta di un modello linguistico è evidente: anche qui la plausibilità sulla base di strutture di modelli statistici esistenti conta più della verità assoluta.

Così nasce un nuovo ponte tra diritto e tecnologia. Mentre prima, come descritto, il confronto strutturale tra sussunzione giuridica e design software dettagliato era in primo piano, l'attuale sviluppo dell'IA permette un'analogia più profonda: lavorare con probabilità, sensibilità al contesto e apertura discorsiva non è più da tempo solo dominio delle scienze umane.

Poiché gli esempi di codice sono così belli visivamente, segue ancora un confronto tra il nuovo e il vecchio mondo sotto forma di due funzioni TypeScript.

Classico e deterministico:

function isValidPurchase(userAge: number): boolean {
  if (userAge >= 18) {
    return true // Maggiorenne – acquisto consentito
  } else {
    return false // Non maggiorenne – acquisto rifiutato
  }
}

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

Stile LLM moderno (o: argomentazione giuridica come funzione)

function assessPurchaseEligibility(userAge: number, maturityLevel: "hoch" | "mittel" | "niedrig"): string {
  if (userAge >= 18) {
    return "Acquisto probabilmente consentito – maggiore età classica raggiunta."
  }

  if (userAge >= 16 && maturityLevel === "hoch") {
    return "Argomentazione sostenibile per l'acquisto – margine interpretativo possibile."
  }

  if (userAge < 16 || maturityLevel === "niedrig") {
    return "Acquisto probabilmente non consentito – rischio troppo alto."
  }

  // return con prompt scadente senza parametri di input
  return "Sono un LLM e sto allucinando sciocchezze, e se non stai attento, non te ne accorgi e lo prendi per vero."
}

Come si continua?

Dopo questa piccola escursione nelle somiglianze e differenze tra il modo di pensare giuridico e il "modo di pensare" dei computer e dei programmi, il prossimo articolo sarà di nuovo un po' meno teorico.

Nella mia pratica forense (molto diritto del traffico) è nata una vera e propria frustrazione per i processi inefficaci, che mi ha disturbato così tanto che nel corso di diversi anni mi sono occupato così intensamente di sviluppo software che oggi a volte sono incerto se presentarmi come giurista o come sviluppatore software quando mi viene chiesto cosa faccio :)

Secondo articolo della serie: Anwalt2Dev - A Journey - Digitalisierung von Kanzleiprozessen