Evals jurídicos: si una skill falla un caso, no se publica

Hay una pregunta que desnuda a cualquier producto de IA jurídica: "¿cómo sabés que funciona?". "Lo probamos y responde bien" no alcanza como respuesta, porque es una anécdota. La nuestra es una regla escrita en la documentación del proyecto: cada materia tiene casos de prueba; si una skill falla un caso importante, no se publica ni se marca como estable. Sin excepciones, ni siquiera cuando el que quiere publicar es uno mismo.

Anatomía de un eval jurídico#

Un eval nuestro son dos archivos. El caso: una consulta realista y anonimizada, con los datos que un cliente de verdad daría, incompletos, con presión de tiempo y con un pedido emocional ("quiero que anulen todo"). Y la rúbrica, con tres secciones.

Obligatorios. Lo que la respuesta debe contener sí o sí: el plazo correcto con su artículo, el encuadre procesal correcto, los marcadores de incertidumbre donde faltan datos.

Deseables. Lo que distingue una respuesta buena de una excelente: la estrategia subsidiaria, la advertencia de costas, el escenario alternativo.

Ausentes esperados. La sección que casi nadie tiene y que más errores caza: lo que la respuesta no debe decir. Que no recomiende contestar en el plazo falso que declaró la contraparte. Que no cite el artículo real pero equivocado. Que no use categorías argentinas. Que no invente jurisprudencia. Testear lo que no debe aparecer es la única forma de testear la disciplina. Los dos errores de contenido que contamos más abajo son de ese tipo: el sistema no se quedó callado, dijo de más y lo dijo con confianza.

La regla que sostiene todo: verificar contra fuente primaria#

El error clásico del testing con rúbricas es que la rúbrica también la escribió alguien, y ese alguien pudo equivocarse. Por eso nuestra regla de corrida dice que cada cita de la respuesta se verifica contra la fuente primaria en el momento del eval: el texto consolidado de la ley, no la rúbrica.

Esa regla es la razón de que la primera batería laboral (los diez casos del módulo de despidos, liquidaciones y negociación) haya sido bastante más que un examen. Fue una auditoría, y destapó errores reales del contenido, no de las respuestas.

Un decreto derogado citado como vigente. El régimen de inscripción obrero patronal, planillas y comunicaciones ante el MTESS que "todo el mundo conoce" era el del Decreto N° 8304/2017. Está derogado desde 2024: lo derogó el art. 3° del Decreto N° 1989/2024, que actualiza el Registro Obrero Patronal (REOP), los libros de tenencia obligatoria y las comunicaciones electrónicas, junto con el Decreto N° 9368/2018, y que está reglamentado por la Resolución MTESS N° 991/2024. La respuesta del asistente citaba el régimen viejo porque el contenido base lo traía. El eval lo cazó, la corrección entró al mapa de autoridad con su fila de bitácora (verificada el 30/06/2026 contra el PDF primario) y el decreto viejo quedó marcado deprecated, que no es lo mismo que borrado: sigue siendo citable para hechos anteriores a 2024, porque derogado no es inexistente.

La cascada del artículo equivocado. El caso del art. 82 contra el art. 401 del Código del Trabajo que contamos en el primer post de esta serie: un eval de despido lo detectó, y la corrección hubo que propagarla por una docena de archivos. Los errores de cita se comportan como epidemias, y el paciente cero infecta todo lo que se escribió copiándolo.

Resultado final de esa batería: 10 de 10 aprobados, pero después de las correcciones. El número importa menos que el proceso. Sin los evals, esos errores estarían hoy en producción, bien redactados.

Qué hay en la batería ahora#

La suite creció con el proyecto: casos de contratos (¿la plantilla detecta la cláusula nula?) y cuatro casos procesales nuevos que todavía no corrieron. Un pagaré sin protesto que el cliente quiere "ejecutar ya" (¿el asistente detecta que el título no se basta solo?), una demanda con plazo declarado falso (¿desarma los tres relojes?), una contestación con excepciones (¿no cruza los regímenes civil y laboral?) y una nulidad de notificación (¿corre el test de viabilidad antes de redactar?).

Hasta que no pasen, los módulos de litigación llevan una etiqueta visible: v0.1, pendiente de evals. Implementado y estable son dos cosas distintas, y la documentación no tiene permitido confundirlas.

Por qué esto importa más que el benchmark de moda#

Los benchmarks públicos de IA jurídica miden conocimiento general con exámenes tipo test. Nuestros evals miden otra cosa: si el sistema se comporta con la disciplina prometida frente a un caso concreto de la jurisdicción concreta, con sus plazos, su fuente primaria en la mano y sus trampas típicas. Un modelo puede saber muchísimo derecho y reprobar el caso del plazo falso. Para un abogado, esa es la única nota que importa.

Fuentes consultadas#

• Decreto N° 1989/2024, que actualiza el Registro Obrero Patronal, los documentos y libros de tenencia obligatoria y las comunicaciones ante el MTESS; su art. 3° deroga los Decretos N° 8304/2017 y N° 9368/2018. Reglamentado por la Resolución MTESS N° 991/2024. Verificado el 30/06/2026 contra el PDF de fuente primaria.
• Ley N.º 213/1993, Código del Trabajo, arts. 82 y 401.
• Suite de evals de Claude for Legal Paraguay, con los casos, las rúbricas y la bitácora de verificación.

Mandanos el caso que creés que una IA respondería mal#

Toda la suite es parte del repositorio open source. Los productos de Dikaia, GNOSIS y su asistente Kai, pasan por esta batería antes de tocar un caso real. Si tenés un caso que creés que una IA jurídica respondería mal, mandánoslo: los mejores evals nuestros empezaron así.