De la comparabilidad del Derecho y el Software

Hola, soy Martin Kurtz, abogado y uno de los dos fundadores de MaraDocs. Bienvenido al blog de MaraDocs. Escribimos sobre temas en la intersección entre el ejercicio de la abogacía y las TI.

Este es el primer artículo de la serie Anwalt2Dev - A Journey. En la serie de artículos hablaré de mi propia historia profesional y motivación, pero sobre todo explicaré con diferente profundidad muchos conceptos y tecnologías que, desde mi punto de vista, conforman el panorama actual de las TI. Y sí, seguramente habrá también un poco de código. :)

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

Así que, ¡ahora sí, in medias res!

Derecho

En el año 2005 comencé a estudiar Derecho en la Universidad de Bonn. No puedo contar demasiado sobre mis primeros años en la universidad: la profesora Puppe (una legendaria penalista conocida por su supremacía de opiniones minoritarias) todavía impartía clases activamente y en el Seminario Jurídico aún había salas de informática dedicadas donde los estudiantes podían utilizar ordenadores del instituto.

Recuerdo bien que los primeros exámenes tenían un nivel sorprendentemente diferente de las pruebas a las que estaba acostumbrado en el colegio. El Derecho que uno tenía el privilegio de aprender como estudiante se me presentaba como un concepto realmente amplio y coherente. Me llevó tiempo comprender que existen estructuras de pensamiento subyacentes o modelos sistémicos y métodos que mantienen su validez en todas las áreas.

Ciertamente, las tres grandes áreas (Derecho Civil, Derecho Público y Derecho Penal) tienen cada una su propio carácter, casi su propio sabor, que uno como joven estudiante va conociendo paso a paso en muchas, muchas horas, pero aun así subyace en todo ello un patrón recurrente: la gradualidad.

Esquemas de examen

Aprendimos sobre todo esquemas de examen: por ejemplo, los requisitos de diferentes fundamentos de pretensión o de la legalidad de determinadas actuaciones estatales. Detrás de cada punto de examen se esconde una bifurcación y uno se ve obligado a detenerse realmente en esa bifurcación y mirar con atención si se cumplen todos los subpuntos. Solo entonces queda libre el camino hacia el siguiente punto de examen.

Ejemplo: Esquema de legalidad de un acto administrativo, aquí representado sobre la base de una clase ficticia de acto administrativo en TypeScript.

I. Base de habilitación (EGL)
  1. ¿Requerida?
  2. Selección de la EGL 
  
II. Legalidad formal
  1. Competencia
  2. Procedimiento
    a. Audiencia
    b. Prohibiciones de participación
    c. Participación de otras autoridades
  3. Forma
  
III. Legalidad material
  1. Requisitos de la base de habilitación 
  2. Requisitos generales de legalidad
    a) Determinación, § 37 I VwVfG
    b) No imposibilidad fáctica o jurídica
  3. Destinatario correcto
  4. Consecuencia jurídica: ¿decisión discrecional o decisión vinculada?
    a) Decisión vinculada: ordenación de la consecuencia jurídica prevista
    b) Decisión discrecional:
      aa) ¿Error de discrecionalidad?
        (1) No ejercicio de la discrecionalidad
        (2) Ejercicio insuficiente de la discrecionalidad
        (3) Abuso de la discrecionalidad
        (4) Exceso de discrecionalidad
      bb) En su caso, reducción de la discrecionalidad a cero
      cc) En su caso, discrecionalidad intencionada

Este tipo de procedimiento gradual es muy similar al funcionamiento de los programas informáticos. El desarrollo de un programa clásico (single threaded) prevé en cada momento exactamente un paso de verificación o trabajo que nunca puede ser omitido. A la inversa, un programa también solo puede responder las preguntas o resolver los problemas que estaban previstos en el momento de la creación del programa. Esto requiere, de manera muy especial en la creación de software, la capacidad de transformar el problema a resolver en un modelo lógico que pueda ser recorrido de forma atómica. Todas las cuestiones parciales posibles deben formar también parte del modelo. Si posteriormente surgen estados inesperados (edge cases) que no se capturan (por ejemplo, mediante patrones try catch), el programa se bloquea.

La gradualidad del pensamiento jurídico y la modelización de problemas en el desarrollo de software son, por tanto, muy similares.

Sin soluciones unívocas

El software se puede ejecutar, probar y depurar de manera exacta y reproducible. Un input conduce (si está correctamente implementado) a un output definido. Los exámenes jurídicos, por el contrario, se caracterizan por lo general por el hecho de que, aunque se basan en una estructura de examen estructurada (subsunción, etc.), siempre contienen también elementos dependientes de valoración y están abiertos a la ponderación en cuanto al resultado. El resultado no es, por tanto, determinista.

El software puede ser probado debido a su naturaleza determinista: en un unit test, por ejemplo, se alimenta programáticamente una función a probar con un input definido y luego se verifica si proporciona el output esperado. Las leyes, sin embargo, son lingüísticamente ambiguas o al menos requieren interpretación. Esto conduce a que los resultados no puedan ser probados en el sentido clásico.

Ejemplo de un unit test (aquí al estilo del framework Jest)

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

    // ejecutar
    const result = tellReader(correctSeriesName);

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

LLMs y la nueva comprensión de las TI: ¿Probabilidades en lugar de verdades?

Mientras que el desarrollo de software clásico ha sido considerado durante mucho tiempo como el epítome de la lógica determinista –input adentro, output claramente definido afuera–, el uso de grandes modelos de lenguaje (LLMs) como Claude, LLama o ChatGPT trae consigo una forma nueva, quizás más flexible, de las TI. Estos sistemas no operan sobre la base de árboles de decisión firmemente codificados, sino sobre la base de patrones estadísticos que han extraído de cantidades de datos inimaginablemente grandes. El output no es, por tanto, predecible en el sentido matemático-estricto, sino que se mueve en el marco de lo probable, de lo típico, de lo contextualmente plausible.

En esta característica se asemejan los resultados de los LLMs y los resultados y métodos de la argumentación jurídica. También en la Jurisprudencia las decisiones no se deducen de forma puramente lógica, sino que se toman en un campo de tensión entre texto normativo, hechos, interpretación y ponderación. El resultado de un examen jurídico rara vez es "correcto" en el sentido de un valor objetivo –es más bien defendible, convincente, derivado metodológicamente de forma limpia. Aunque esto (y aquí volvemos a la falta de verificabilidad) solo puede ser juzgado nuevamente en la valoración de un tercero, que a su vez debe aplicar un modelo vago para evaluar el previamente encontrado. El paralelismo con la respuesta de un modelo de lenguaje es evidente: aquí también cuenta más la plausibilidad basada en estructuras de modelo estadísticas existentes que la verdad absoluta.

Así surge un nuevo puente entre el Derecho y la tecnología. Mientras que antes, como se describió anteriormente, la comparación estructural entre subsunción jurídica y diseño de software minucioso estaba en primer plano, el actual desarrollo de IA permite una analogía más profunda: el trabajo con probabilidades, sensibilidad al contexto y apertura discursiva ya no es solo dominio de las ciencias humanas.

Porque los ejemplos de código son visualmente tan bonitos, sigue todavía una comparación del mundo nuevo y del antiguo en forma de dos funciones de TypeScript.

Clásico y determinista:

function isValidPurchase(userAge: number): boolean {
  if (userAge >= 18) {
    return true // Mayor de edad – compra permitida
  } else {
    return false // No mayor de edad – compra denegada
  }
}

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

Estilo LLM moderno (o: argumentación jurídica como función)

function assessPurchaseEligibility(userAge: number, maturityLevel: "hoch" | "mittel" | "niedrig"): string {
  if (userAge >= 18) {
    return "Compra probablemente permitida – mayoría de edad clásica alcanzada."
  }

  if (userAge >= 16 && maturityLevel === "hoch") {
    return "Argumentación defendible para la compra – margen de interpretación posible."
  }

  if (userAge < 16 || maturityLevel === "niedrig") {
    return "Compra más bien no permitida – riesgo demasiado alto."
  }

  // return con mal prompt sin parámetros de input
  return "Soy un LLM y estoy alucinando cualquier basura, y si no prestas atención, no te darás cuenta y lo tendrás por cierto."
}

¿Cómo continúa esto?

Después de esta pequeña excursión a las similitudes y diferencias del modo de pensar jurídico y el "modo de pensar" de las computadoras y programas, el próximo artículo será algo menos teórico de nuevo.

En mi propia práctica como abogado (mucho derecho de tráfico) ha surgido una auténtica frustración por procesos ineficaces que me han molestado tanto que durante varios años me he dedicado tan intensamente al desarrollo de software que hoy a veces no estoy seguro de si debo presentarme como jurista o como desarrollador de software cuando me preguntan qué hago :)

Segundo artículo de la serie: Anwalt2Dev - A Journey - Digitalisierung von Kanzleiprozessen