Renzo CavaniProfesor ordinario asociado PUCP
Recientemente, hemos venido publicando sobre CURIA, que es un sistema de inteligencia artificial empleado como asistente jurídico en la Quinta Sala de Derecho Constitucional y Social de la Corte Suprema. En el primer artículo buscamos levantar algunas preguntas sobre el funcionamiento técnico del sistema y sobre los desafíos éticos a alcanzar; en el segundo, procuramos aterrizar un poco más y mostramos los desafíos que este sistema tendría frente al nuevo Reglamento de IA, aprobado en septiembre de 2025.
Ambos artículos se basaron en dos informes situacionales oficiales que indican algunas características del sistema, pero que no permiten comprender del todo el funcionamiento del sistema ni tampoco si se encuentra alineado con estándares éticos de la IA. Así, frente a la falta de información pública, en este texto nos aventuramos a ir un paso adelante y, a partir de algunas intuiciones y conocimiento sobre el funcionamiento técnico de sistemas de IA similares, buscar reconstruir cómo funcionaría CURIA, sus limitaciones y qué necesitaría para ser una plataforma institucionalmente fiable para la justicia.
¿Cuál es la arquitectura de CURIA?
La información que se presenta en los informes oficiales muestra a CURIA como un asistente jurídico basado en técnicas de procesamiento de lenguaje natural, aprendizaje automático y generación de texto. Desde una perspectiva técnica, su funcionamiento requiere una canalización de procesos bien diferenciados: ingestión y normalización de documentos (OCR y parsing), extracción estructurada de metadatos jurídicos, representación semántica de fragmentos textuales, recuperación de evidencia relevante mediante índices de similitud y una capa generativa que redacta o sugiere proyectos de ejecutoria suprema.
En términos concretos, este flujo incluye los siguientes módulos: (1) un pipeline ETL jurídico que transforma expedientes y documentos en texto y en unidades de análisis (hechos, fundamentos, citas); (2) un motor de embeddings que convierte unidades textuales en representaciones vectoriales para la recuperación semántica; (3) un indexador y motor de búsqueda híbrido que ordena precedentes por relevancia contextual; (4) un generador condicional (modelo de lenguaje) que, alimentado por el contexto recuperado, produce una redacción estructurada; y (5) una capa de interacción conversacional que permite consultas en lenguaje natural y presenta salidas formateadas.
La conjunción de recuperación y generación sugiere, con alto grado de plausibilidad técnica, una arquitectura de tipo Retrieval-Augmented Generation (RAG), en la que la fiabilidad del output depende directamente de la calidad del índice y de la precisión del paso de recuperación.
Técnicamente, la eficiencia reportada –un análisis aproximado de 270 folios en alrededor de cuatro minutos y medio por caso en la PoC (prueba de concepto)– es coherente con una implementación que combina indexado por fragmentos (passage-level indexing) y generación condicionada por evidencias concretas.
Ahora bien, un sistema RAG bien diseñado reduce latencia frente a la generación desde cero y permite anclar afirmaciones en fuentes identificables, aunque exige mecanismos claros de trazabilidad. Así, para cada sugerencia CURIA debería registrar los documentos recuperados, los puntajes de similitud, los fragmentos que condicionaron la respuesta, la versión del modelo y los parámetros de inferencia. Sin esa trazabilidad, el valor técnico de la integración disminuye; la comprobación posterior de la razón por la que una sugestión fue ofrecida se complicaría.
La representación semántica en CURIA, si acaso sigue las prácticas estándar en este tipo de modelos, se apoya en encoders basados en transformers o variantes de sentence-embedding (por ejemplo, arquitecturas tipo SBERT adaptadas al dominio jurídico). Estos encoders permiten realizar búsquedas por similitud semántica en vectores densos y, combinados con un motor de búsqueda ANN, habilitan la recuperación de precedentes que pueden no coincidir léxicamente con la consulta, pero que sí lo harían en cuanto al significado jurídico. El modulador de ranking podría ser un re-ranker (algoritmo que refina y reordena resultados) entrenado con señales judiciales (relevancia humana) para priorizar precedentes que contengan cierta ratio decidendi o pasajes doctrinalmente decisivos.
El corpus y los límites que impone
Los informes hacen explícito un hecho crítico: el conjunto de entrenamiento de la prueba de concepto incluyó 1,136 antecedentes y la base SPIJ especializada en revisión de legalidad de ejecución coactiva. Desde la óptica de ingeniería de modelos, ese tamaño y focalización tienen implicaciones técnicas claras: 1,136 documentos pueden ser adecuados para tareas de fine-tuning orientado a subproblemas concretos (clasificación de fragmentos, extracciones de elementos estructurados, re-ranking en dominio muy acotado); pero resultan insuficientes para entrenar un generador de lenguaje generalizable sobre una amplia gama de supuestos jurídicos, aun cuando se trate de revisión de la legalidad de la ejecución coactiva.
En particular, la representatividad estadística es limitada: la cobertura de supuestos fácticos, formulaciones argumentativas y variaciones doctrinales dentro de aquel ámbito jurídico es finita, por lo que extrapolar ese aprendizaje a otro tipo de procesos exigirá estrategias adicionales de transferencia o ampliación del set de datos.
Desde la ingeniería de datos es necesario distinguir tres aspectos que los informes no detallan, pero que condicionan el comportamiento algorítmico: (i) la granularidad de las anotaciones del corpus, esto es, si se entrenó a nivel de documento completo, de secciones etiquetadas (hechos, fundamentos, rationes decidendi) o mediante señales débiles; (ii) la política de curación y selección, o sea, qué criterios guiaron la inclusión de cada uno de los 1,136 antecedentes y si hubo filtrado por calidad, relevancia cronológica o jurisdicción; y (iii) el preprocesamiento aplicado, a saber: normalización de nombres y conceptos, tratamiento de citas y formatos, y anonimización efectiva de datos personales. La ausencia de esa documentación técnica impide evaluar si el comportamiento observado en la PoC responde a una verdadera capacidad inferencial o más bien a ajustes específicos al set de entrenamiento.
La distinción entre tareas también importa: para recuperación de jurisprudencia y ranking, los 1,136 casos pueden permitir construir índices útiles y re-rankers con rendimiento apreciable en el dominio de la revisión de legalidad de ejecución coactiva; pero para la generación de ejecutorias con alto grado de fidelidad y formalización procesal la muestra es muy restrictiva. Por tanto, cualquier afirmación técnica sobre la calidad de la redacción asistida debe ir acompañada de métricas reproducibles, sobre todo en cuanto a medidas de factualidad verificable para generación y, de otro lado, de protocolos de testeo que contrasten la salida del sistema con redacciones de referencia generadas por magistrados.
En efecto, sin runtimes, métricas y datasets públicos, la evaluación técnica queda circunscrita a observaciones empíricas sin mayor reproducibilidad.
Requisitos técnicos para competencia, escalabilidad y auditoría
Para que CURIA deje de ser una PoC y se convierta en una plataforma técnica verificable y competitiva dentro del ecosistema judicial, pensamos que deben instrumentarse cuatro frentes técnicos prioritarios.
Primero: versionado reproducible. Los datasets, scripts de preprocesamiento, checkpoints de modelos y configuraciones de inferencia deben estar versionados. Esto permite reproducir entrenamientos y comparar versiones.
Segundo, trazabilidad por sugerencia. Cada output debe venir acompañado de un registro con las fuentes recuperadas, sus ubicadores, puntajes de similitud, proyección de probabilidades del modelo y parámetros de generación. Esa cadena de evidencias es el insumo técnico para auditorías y para que el usuario verifique la correspondencia entre sugerencia y fuentes.
Tercero, protocolos de evaluación y benchmarks. Es deseable la creación de un corpus de evaluación anotado por expertos que permita medir recuperación y generación (métricas automáticas complementadas con juicios humanos sobre fidelidad y utilidad). Tales benchmarks, si son públicos y estandarizados, fomentan competencia entre implementaciones y aceleran mejoras modulares (mejor encoder, mejor re-ranker, mejores templates de prompt).
Y, cuarto, interfaces y modularidad. CURIA debería ofrecer APIs con contratos claros para R (retrieval) y G (generation), permitir interoperabilidad de índices y desacoplar componentes (OCR ? NER jurídico ? encoder ? indexador ? LLM) para permitir sustituciones tecnológicas y mejoras incrementales sin rehacer todo el sistema.
Adicionalmente, la medición operacional debe incorporar métricas de rendimiento y rutinas de testing que expongan fragilidades en casos limítrofes. La actualización debe formalizarse: triggers de reentrenamiento cuando cambian la jurisprudencia o la práctica doctrinal, y procedimientos para validar que las nuevas versiones no degraden el rendimiento. Por último, la apertura técnica –publicación de especificaciones de pipeline, scripts de evaluación y módulos de código– en aras de facilitar replicabilidad y competencia. Aun cuando partes del sistema se consideren propiedad intelectual, la liberación de componentes de evaluación controlada de parámetros permite someter a pruebas independientes los principales reclamos de eficacia.
Con todo ello, concluimos que la información disponible sobre CURIA permite reconstruir, con cierta cautela, una arquitectura de solución alineada con prácticas modernas de IA. No obstante, la transición de una PoC a una plataforma institucionalmente fiable exige documentación técnica completa sobre el corpus, protocolos de evaluación reproducibles, trazabilidad exhaustiva por sugerencia y prácticas de versionado y testing automatizado.
La muestra de 1,136 antecedentes podría proveer evidencia de viabilidad en un nicho específico, pero su tamaño y focalización requieren estrategias sistemáticas de ampliación, validación y benchmarking para asegurar que la capacidad técnica observada no sea fruto exclusivo de ajuste al set de datos inicial.
Solo con esas herramientas técnicas y procedimientos verificables puede evaluarse objetivamente, y siempre desde una perspectiva estrictamente técnica, la competitividad, escalabilidad y reproducibilidad de CURIA como una buena solución de IA aplicada a la justicia.
