El software de tecnología jurídica necesita algo más que generar documentos

La tecnología jurídica es uno de los cinco ámbitos en los que desarrollamos software. El error que más vemos en este ámbito es buscar el valor del producto en el documento que genera. El valor real está en que la regla funcione dentro del sistema siempre de la misma forma.

Cuando se observa la presentación de un producto de tecnología jurídica, lo más probable es que se vea lo siguiente. Genera borradores de contratos, propone cláusulas, da formato al documento. Son tareas útiles. El problema es que la verdadera cuestión del ámbito no es esta, y el problema que creemos que resuelven estas herramientas es, en realidad, la parte más fácil del problema.

La verdadera cuestión está aquí. Una organización está sujeta a una obligación jurídica. Se hace una interpretación sobre lo que significa esa obligación. La interpretación se escribe en un documento. Después ese documento se archiva, y el funcionamiento diario de la organización continúa sin conocer ese documento. Esta desconexión entre el documento y el sistema es el error más costoso que veo en la práctica, y ninguna herramienta de plantillas de contratos lo resuelve.

Interpretar es cosa de personas, aplicar es cosa del sistema

Convertir una regla en software no es escribir la regla en código. Entre ambas cosas hay un paso que no puede automatizarse.

El artículo 7 de la Ley 6698 establece que, cuando desaparezcan las razones que exigían su tratamiento, el dato personal se borrará, destruirá o anonimizará. Esta disposición es clara. Pero ¿qué significa exactamente "que desaparezca la razón" respecto a los datos de facturación de una organización? ¿El fin de la relación con el cliente, el vencimiento del plazo de conservación previsto en la normativa fiscal, o lo que ocurra más tarde de las dos cosas? A esta pregunta responde un jurista. Su respuesta es una interpretación, y mientras esa interpretación no quede registrada, dentro de seis meses nadie recordará por qué se eligió ese plazo.

Ahí empieza el trabajo del software. Una vez dada la interpretación, asegurar que se aplique siempre de la misma manera y que pueda demostrarse que se ha aplicado. Si dispone de un sistema que hace esto, está usando tecnología jurídica. Si solo genera plantillas, está usando un procesador de texto.

Qué ocurre cuando el documento y el sistema se separan

Veámoslo con un ejemplo concreto. En la política de conservación de una organización consta que los registros de comunicación con clientes se conservarán durante dos años. Cuando llega una auditoría, se presenta esa política.

El auditor hace una única pregunta. ¿Qué componente aplica este plazo?

La respuesta, la mayoría de las veces, no existe. En la base de datos hay un campo created_at, pero no hay expires_at. No existe ningún proceso que elimine el registro cuando el plazo vence. Aunque exista una eliminación, no genera ningún registro de lo actuado. Al final, la organización no puede demostrar que hace lo que su política dice. La política en sí misma no es una prueba, es a lo sumo una declaración de intenciones.

La forma de corregir este panorama no es redactar un mejor texto de política. Es añadir al modelo de datos un campo que transporte el plazo de conservación, escribir un componente que aplique ese plazo, y hacer que ese componente genere un registro cuando se ejecute. Cuando las tres cosas están presentes, el texto de la política deja de ser una afirmación y pasa a ser la descripción de lo que el sistema realmente hace.

Los cinco eslabones de la cadena

Convertir un texto jurídico en un control que funciona dentro del sistema ocurre en cinco pasos. El orden de estos pasos importa, y omitir cualquiera de ellos hace que el resultado deje de ser fiable.

Primero se identifica la norma. Se determina la regla aplicable y, si existe, su excepción. Después se hace la interpretación, es decir, se decide qué significa la regla en el proceso de negocio concreto. Este paso corresponde a una persona y debe quedar registrado. En el tercer paso, la interpretación se vincula a la arquitectura, determinando qué campo transportará qué regla. En el cuarto paso se escribe el componente que aplica la regla en el momento de la operación. En el quinto paso se registra que ese componente se ha ejecutado.

Un control escrito sin haber hecho la interpretación aplica la regla equivocada. Un control que no produce evidencia no sirve en una auditoría. El error que veo con frecuencia es que se salten el tercer y el cuarto paso y se pase directamente al quinto. La organización lleva un registro, anota algo allí, pero no queda claro qué regla demuestra que se ha aplicado.

La cuestión del monopolio de la abogacía

Existe un límite que toda persona que desarrolle productos en este ámbito debe conocer. El artículo 35 de la Ley de la Abogacía n.º 1136 reserva a los abogados la tramitación de asuntos jurídicos y la emisión de dictámenes jurídicos.

En la práctica, esto determina qué puede y qué no puede decir su producto. Decir "en su contrato falta esta cláusula" es informar. Decir "no firme este contrato, tendrá consecuencias en su contra" es emitir una opinión. La línea entre ambas es fina y debe protegerse de forma consciente en el diseño del producto. El método más sólido para mantener esa línea es que el sistema no tome la decisión por sí mismo y que detrás de cada resultado siga siendo visible una decisión humana.

Este límite parece un obstáculo, pero en realidad es una buena restricción de diseño. Un sistema que no asume la decisión tampoco asume la responsabilidad cuando comete un error, y esto impide que el usuario confíe ciegamente en el sistema.

Qué ha cambiado la inteligencia artificial y qué no

El procesamiento del lenguaje natural aporta una ganancia real de eficiencia en el análisis de documentos. Encontrar un tipo determinado de cláusula entre cientos de contratos era antes una tarea de semanas. Ahora se hace en horas.

Lo que no cambia es la responsabilidad. Si no se puede rastrear de qué documento y de qué párrafo procede el resultado producido por el modelo, ese resultado no es una constatación, es una conjetura. Del mismo modo, si el sistema no muestra de forma distinguible un resultado del que no está seguro frente a uno del que sí lo está, el usuario confía igual en todos ellos, y el error pasa desapercibido.

Cuando estas dos condiciones no se cumplen, la ganancia de eficiencia obtenida se compensa después con el riesgo que surge. Y lo peor es que no se sabe cuándo se materializará ese riesgo.

Por dónde empezar

Al iniciar un proyecto corporativo de tecnología jurídica, recomiendo elegir una única obligación. Abordarlas todas a la vez suena bien, pero en la práctica ninguna llega a completarse.

Para la obligación elegida se construyen los cinco eslabones completos. Se redacta la norma, la interpretación queda registrada, se vincula al modelo de datos, el control funciona, se produce la evidencia. Este trabajo se completa en seis semanas, y al final no tendrá un informe, sino un control que funciona y un registro que puede mostrarse en una auditoría.

La segunda obligación avanza mucho más rápido. Porque lo difícil no es la regla, es construir la cadena por primera vez.