Legal Engineering: el perfil que conecta el derecho con la tecnología

Hay una distancia grande entre saber cómo se aplica una norma y poder explicarla con la precisión suficiente para que un sistema la ejecute. Esa distancia es el terreno del Legal Engineering, y explica por qué tantos proyectos de automatización legal se detienen a mitad de camino: no fallan por tecnología, fallan porque la regla nunca estuvo escrita con claridad suficiente.

El ejercicio central es la descomposición. Tomar un criterio que hoy vive en la cabeza de un equipo y convertirlo en condiciones explícitas: qué entradas se necesitan, qué combinaciones producen qué resultado, qué casos quedan fuera y qué se hace con ellos. Suena mecánico y no lo es. La mayor parte del tiempo se va en descubrir que dos personas del mismo equipo aplican criterios distintos y ninguna lo sabía.

Esa es, en la práctica, la mayor aportación de este trabajo, y ocurre antes de escribir una sola línea de configuración. Explicitar una regla obliga a acordarla. Muchos equipos descubren en esa conversación inconsistencias que llevaban años produciendo resultados desiguales sin que nadie los detectara, porque cada caso se veía por separado.

Después viene la parte de estructura. Una regla ejecutable necesita un vocabulario estable: los mismos conceptos con los mismos nombres, tipos de dato definidos, valores posibles acotados. Cuando un campo admite texto libre donde debería admitir una lista cerrada, se rompe la posibilidad de razonar sobre el dato más adelante. Es una decisión pequeña con consecuencias enormes a los dos años.

Un aspecto que suele resolverse mal es el tratamiento de la excepción. Ninguna regla cubre todo, y el error clásico es intentar modelarlo absolutamente todo hasta que el sistema se vuelve inmanejable. La alternativa razonable es cubrir bien el caso frecuente y derivar el resto a revisión humana, de forma explícita y con registro. Un sistema que resuelve el ochenta por ciento y deriva el resto con criterio es mucho más útil que uno que intenta el cien por ciento y falla de manera impredecible.

El mantenimiento también es parte del diseño. Las normas cambian, los criterios internos cambian. Si actualizar una regla requiere que intervenga un desarrollador, el sistema envejecerá mal. Cuando es posible, conviene que la lógica quede en un formato que el propio equipo legal pueda revisar y modificar bajo control de versiones.

Legal Engineering no es programar siendo abogado. Es pensar el conocimiento jurídico como algo estructurable, reutilizable y verificable. Quien hace bien ese trabajo deja algo que sobrevive a las personas que lo escribieron.

Felipe Besnier — Legalmente Ágil