El authority map: separar el derecho del prompt

Si le pedís a cualquiera que "configure un GPT jurídico", va a hacer lo mismo: escribir un prompt largo con las leyes importantes adentro. "El plazo para contestar la demanda es de 18 días (art. 234 CPC). La indemnización por despido es de 15 salarios diarios por año (art. 91 CT)..."

Funciona una semana. Después empiezan los problemas: ¿quién verificó ese artículo? ¿Contra qué fuente? ¿Sigue vigente? ¿En cuántos prompts distintos está repetida esa cita? Cuando una norma cambia (y en Paraguay solo en 2025 hubo reformas al CPC por la Ley 7424/2025, una nueva ley de feriados, la 7544/2025, y una nueva ley de protección de datos, la 7593/2025) hay que encontrar y corregir cada copia. El prompt se convierte en un compendio desactualizado más, con el agravante de que nadie lo audita.

La decisión de diseño: los datos jurídicos no viven en el prompt#

En Claude for Legal Paraguay, nuestro marketplace open source de plugins jurídicos, tomamos la decisión inversa: el prompt define el método; el derecho vive en datos estructurados. Lo llamamos el authority map: un conjunto de archivos YAML versionados en git donde cada norma es una entrada con campos obligatorios.

Una entrada real (simplificada):

codigo_procesal_civil:
  official_title: "Ley N° 1337/1988 - Código Procesal Civil"
  short_cite: "Ley N° 1337, art. {art}"
  modified_by:
    - "Ley 7424/2025 (arts. 480, 657, 665, 666 modif.; art. 701 derog.)"
    # ... y todas las demás, en orden
  verification:
    status: "verified"
    verified_at: "2026-07-05"
    verified_against: "texto consolidado local + manifiesto de modificatorias"
    official_source_checked: true

Tres cosas hacen que esto sea un sistema#

Primero, el ciclo de vida: draft → verified → deprecated. Toda norma entra como draft. No importa qué tan segura parezca la cita: hasta que alguien la coteja contra la fuente oficial y registra la verificación, es borrador. Cuando se verifica, pasa a verified con fecha y fuente. Cuando una reforma la reemplaza, pasa a deprecated. No se borra, porque los casos viejos pueden seguir necesitándola (el decreto laboral derogado en 2024 sigue siendo relevante para hechos anteriores). Y la regla dura del sistema: una skill estable no puede citar una norma en draft o deprecated. Si lo necesita, tiene que emitir el marcador [VERIFICAR VIGENCIA]. La incertidumbre viaja hasta el abogado, visible.

Segundo, la bitácora: toda verificación deja fila. Cada vez que una entrada cambia de estado, se registra una fila en verification-log.md: fecha, qué se verificó, contra qué fuente, resultado y notas. La bitácora es donde viven las historias del post anterior: el epígrafe erróneo del art. 470, la laguna del 114 inc. b, las modificatorias faltantes. Son asientos auditables: cualquiera puede abrir el repo y reconstruir por qué el sistema cree lo que cree.

Esto tiene un efecto secundario que no anticipamos: la bitácora se volvió el lugar donde se acumula el conocimiento de método. "No confundir la multa por mora con el plazo de comunicación." "El PDF oficial es escaneado; el texto útil está en el HTML." "Dos copias del mismo linaje no son verificación cruzada." Cada error cometido una vez queda documentado para no repetirse.

Tercero, el validador: la disciplina no depende de la buena voluntad. Un script (validate_authorities.py) rompe la validación si: una entrada no cumple el esquema; una skill estable cita una norma draft o deprecated; una skill cita una ley que no existe en el mapa; o una entrada dice verified pero no tiene fecha de verificación o cotejo con fuente oficial. Es el equivalente jurídico de los tests en CI: el sistema no puede mentirse a sí mismo sin que suene una alarma.

Esta es la salida real del validador al cierre de este post (22/08/2026):

Authority map: 39 normas (35 verified, 2 draft, 2 deprecated);
jurisprudencia: 10 criterios, 0 fallos.

OK: mapa, procedencia y referencias pasan la validación.

Treinta y cinco normas verificadas contra fuente oficial, dos que todavía no pueden citarse y dos deprecadas que se conservan para casos viejos. El número exacto importa menos que el hecho de que cualquiera puede correr el script y obtener el mismo resultado.

El nivel que faltaba: la jurisprudencia#

Las leyes tienen texto oficial contra el cual verificar. Los criterios de los tribunales, no. Para eso el mapa tiene un archivo aparte (jurisprudencia.yaml) con dos niveles de autoridad distintos: criteria (tendencias verificadas contra fallos reales, que el asistente puede afirmar como práctica jurisprudencial) y rulings (fallos individuales citables, que exigen cotejo contra el portal del Poder Judicial). De dónde salen esos criterios (de nuestra base GNOSIS, consultando el texto completo de sentencias reales) lo contamos en GNOSIS por dentro.

Todo esto está publicado bajo Apache-2.0 en github.com/dikaia-io/claude-for-legal-paraguay. La razón es simple: un sistema cuyo argumento central es "podés auditar por qué cito lo que cito" tiene que poder ser auditado de verdad. El authority map, la bitácora y el validador son la parte del producto que queremos que nos revisen.

Fuentes consultadas#

• Mapa de autoridad de Claude for Legal Paraguay, conteo verificado el 22/08/2026 corriendo validate_authorities.py.
• Ley N.º 1337/1988, Código Procesal Civil, art. 234 citado en el ejemplo, texto consolidado con sus modificatorias.
• Código del Trabajo, Ley N.º 213/1993, art. 91 citado en el ejemplo.

Auditá el método#

Este método alimenta a Kai, el asistente jurídico de GNOSIS, el producto de investigación jurídica de Dikaia. Si estás construyendo IA para un dominio regulado, el patrón es transferible: datos de autoridad fuera del prompt, ciclo de vida explícito, bitácora y validación automática. Y si sos abogado y solo querés usarlo: eso también se puede. El repositorio completo está abierto para que lo revises.