Construimos el primer Claude for Legal de Paraguay (y por qué no es un fork)

Cuando un abogado escucha "inteligencia artificial jurídica", piensa en el caso famoso del colega que presentó un escrito con fallos inventados. Es un miedo razonable. Pero después de meses construyendo un asistente jurídico para la práctica paraguaya, podemos decir que ese no es el error que más nos costó controlar.

El error que más nos costó controlar es este: la cita que existe, es real, está bien transcripta... y es incorrecta para lo que se la usa.

Hoy anunciamos Claude for Legal Paraguay: un conjunto open source de skills y plugins que convierte a Claude en un asistente jurídico paraguayo que no cita sin fuente verificada. El repositorio es público en github.com/dikaia-io/claude-for-legal-paraguay, la licencia es Apache-2.0, y este artículo cuenta el método con el que se construyó. Una aclaración antes de seguir: es un proyecto comunitario de Dikaia sobre el patrón abierto que publicó Anthropic, sin afiliación con Anthropic.

Un ejemplo que nos pasó de verdad#

En derecho laboral paraguayo hay una pregunta que aparece todas las semanas: ¿cuánto tiempo tiene el empleador para despedir con causa desde que conoce la falta?

La respuesta correcta es 30 días, y está en el artículo 401 del Código del Trabajo (la condonación de la falta). Pero durante la construcción de nuestro asistente detectamos que esa regla se estaba atribuyendo al artículo 82, que existe, que es laboral, que habla de despido... pero que regula otra cosa (la improcedencia de preaviso e indemnizaciones). El error no era una invención: una cita real usada para la regla equivocada. Y lo más instructivo vino al corregirlo: el error ya se había propagado en cascada por una docena de archivos, porque todo el mundo, humanos e IA por igual, copia las citas de donde ya están escritas.

Ese es el riesgo nº 1: la autoridad incorrecta que sobrevive revisiones porque suena bien. La alucinación grosera cualquier abogado la caza en dos minutos; esta otra viaja de escrito en escrito sin que nadie la frene.

Las cuatro caras de la autoridad incorrecta#

Trabajando en esto las vimos todas:

1. La cita del país equivocado. Los modelos de IA leyeron mucho más derecho argentino y español que paraguayo. Si no se los disciplina, un asistente te habla de la LCT, de la CNAT o del art. 245. Todo perfectamente real... en Argentina. En Paraguay es ruido con toga.
2. El artículo desactualizado. La norma existió, pero fue modificada o derogada. De esto ya escribimos un artículo entero: encontramos cosas sorprendentes hasta en el Código Procesal Civil.
3. La regla real con el artículo equivocado. El caso del art. 82/401 de arriba.
4. El criterio de tribunal sin fuente. "La jurisprudencia dice que..." ¿Cuál, de qué sala, de qué año, verificada dónde?

Por qué no es un fork#

Cuando arrancamos ya existían dos proyectos excelentes: el repositorio open source de Anthropic para práctica legal (pensado para el mercado estadounidense) y el fork argentino construido sobre él por Cristian Aboitiz, un trabajo pionero en español. La tentación obvia era clonar y adaptar.

Hicimos otra cosa: estudiamos los dos hasta entenderlos, tomamos sus patrones de diseño y no copiamos una sola afirmación jurídica de ninguno. El patrón se porta con crédito; el contenido jurídico se reconstruye desde cero contra fuentes paraguayas. Adaptar un documento extranjero habría sido fabricar en serie el riesgo nº 1: autoridad del país equivocado, escrita con total corrección técnica. Un artículo próximo de esta serie va a contar esa decisión en detalle, incluido el descubrimiento incómodo de que los "modelos" que circulan en cualquier estudio pueden traer copyright ajeno adentro.

Cómo lo controlamos: tres decisiones de diseño#

Primera: las fuentes mandan, no el modelo. El asistente no cita derecho "de memoria". Toda norma que puede citar vive en un mapa de autoridad: un registro estructurado y versionado donde cada ley tiene su estado de verificación (borrador → verificada → derogada), la fecha en que se cotejó contra la fuente oficial y contra qué se cotejó. Un validador automático rompe el build si una skill estable cita una norma no verificada. Si una norma no está verificada, el asistente lo dice. Cada verificación deja además su fila en una bitácora auditable: qué se cotejó, contra qué fuente, qué se encontró, con fecha. Cualquiera puede abrir el repo y reconstruir por qué el sistema cree lo que cree.

Segunda: la incertidumbre se declara, no se rellena. Definimos un catálogo cerrado de marcadores que el asistente está obligado a usar: [VERIFICAR VIGENCIA] cuando la norma no fue cotejada en sesión, [VACÍO PROBATORIO] cuando una afirmación no tiene respaldo documental, [INSERTAR JURISPRUDENCIA VERIFICADA] cuando el argumento necesita un fallo que todavía no se verificó. Un asistente que confiesa lo que no sabe vale más que uno que completa los huecos.

Tercera: toda cita lleva su gramática de autoridad. Fuente oficial usada, fecha de verificación, tipo de autoridad y nivel de certeza. Igual que un buen dictamen distingue "el artículo dice" de "la doctrina sostiene" de "algunos tribunales entienden", el asistente distingue el texto legal verificado del criterio jurisprudencial relevado y de la práctica del estudio.

El contenido se testea, no se asume#

Cada materia del proyecto tiene casos de prueba con rúbrica: qué debe contener la respuesta, qué la distingue de una excelente, y la sección que más errores caza: qué no debe decir. El módulo laboral pasó 10 de 10 casos contra fuente primaria, y el de litigación 7 de 7 corridos contra el sistema real, con los plugins cargados de verdad. Ese "contra fuente primaria" importa: la batería destapó un decreto derogado citado como vigente y la cascada del art. 82/401 que abrió este artículo. Si una skill falla un caso importante, no se publica ni se marca como estable. La anatomía completa de esos evals también va a tener su propio artículo.

Dónde entra la jurisprudencia (y por qué es el problema más difícil)#

De las cuatro caras del problema, la jurisprudencia es la peor: no hay un "texto consolidado" de los criterios de los tribunales. Para eso conectamos el asistente a GNOSIS, nuestra base de jurisprudencia paraguaya con búsqueda semántica sobre el texto completo de los fallos: en lugar de que la IA "recuerde" lo que dicen los tribunales, consulta sentencias reales, con su número, sala y fecha, y construye criterios a partir de ellas, con reglas estrictas sobre qué puede afirmar y qué no (eso también merece su propio post).

Lo que viene#

Este artículo abre una serie donde documentamos, con los hallazgos reales de la construcción, cómo se hace un asistente jurídico que no inventa. El primer capítulo ya está publicado: la vez que descubrimos que dos copias de la misma ley tenían el mismo error de transcripción. Siguen cómo convertimos miles de fallos en criterios operativos, por qué nuestro asistente a veces se niega a redactar, y qué aprendimos de los proyectos open source de Anthropic y de la comunidad argentina.

La tesis completa, en una línea: la confianza en la IA jurídica se construye con método, fuente por fuente, y se audita. Todo lo que contamos acá se puede verificar en el repositorio.

Construimos herramientas de IA jurídica en Dikaia: GNOSIS, la investigación de jurisprudencia paraguaya con IA, y Kai, su asistente jurídico. El repositorio de Claude for Legal Paraguay es público y con licencia Apache-2.0. Si lo instalás y encontrás un error, abrí un issue: los errores documentados son la materia prima de esta serie.