Cómo funciona el Redactor IA: secciones, prompts por tipo de documento y estilo de referencia

Cuando un abogado le pide al Redactor IA "armá la demanda", no está pasando lo que uno imagina: el modelo no escribe un documento entero de punta a punta en una sola pasada. Lo arma sección por sección, con reglas distintas para cada una, y solo usa datos reales del caso — si falta algo, se detiene y pregunta. Este artículo abre esa caja: cómo está armado el prompt, cómo cambia según el tipo de escrito, y qué pasa cuando subís un modelo propio para que imite tu estilo.

El documento no es texto libre: es una lista de secciones

Lo primero que hay que entender es que un "escrito" en el Redactor IA no es un cuadro de texto gigante. Es una lista fija de secciones, distinta según el tipo de documento. Hoy existen ocho tipos:

• Demanda Laboral y Demanda Civil
• Contestación de Demanda
• Amparo
• Carta Documento
• Recurso de Apelación
• Medida Cautelar
• Contrato

Por ejemplo, una Demanda Laboral tiene siete secciones: Encabezado, Objeto, Personería, Hechos, Derecho Aplicable, Prueba Ofrecida y Petitorio. Una Carta Documento, en cambio, tiene solo cuatro: Destinatario, Cuerpo, Intimación y Firma. Un Contrato tiene otras siete completamente distintas: Partes, Objeto, Obligaciones, Precio, Plazo, Rescisión y Jurisdicción.

Esta lista no es solo una cuestión visual: es la estructura que el modelo está obligado a respetar. El modelo nunca escribe el documento directamente en el chat. Solo puede tocar el contenido llamando a una única herramienta, update_section, indicando qué sección quiere modificar y el texto completo de esa sección. Si el abogado pide "generá todo", el modelo llama a esa herramienta una vez por cada sección — pero siempre sección por sección, nunca todo junto como un bloque de texto suelto.

Un prompt que se arma en capas, distinto en cada pedido

Antes de mandarle el pedido al modelo, el backend arma un system prompt que combina varias capas:

1. Reglas fijas de estilo jurídico, iguales para cualquier documento: lenguaje formal sin coloquialismos, citar artículos de leyes reales (LCT, CCyC, CPCCN, Ley 24.240...), "V.S." para primera instancia y "V.E." para tribunales superiores, fechas en formato argentino, nombres reales del cliente (nunca "el actor" a secas). Y una regla no negociable: nunca inventar placeholders como [COMPLETAR] o (PENDIENTE: ...). Si falta un dato importante para redactar una sección, el modelo tiene que frenar y preguntarlo en el chat antes de escribir esa parte.

2. La naturaleza del documento. Acá es donde el prompt realmente cambia según el tipo. Un Contrato, por ejemplo, lleva una advertencia explícita: "NO es un escrito judicial: no lo dirijas a un juez, no uses fórmulas como 'V.S.' ni 'Será Justicia', y no menciones tribunales salvo en la cláusula de jurisdicción". Una Carta Documento tiene su propia advertencia parecida. Sin esto, un modelo entrenado mayormente con textos judiciales tiende a "demandizar" cualquier cosa que redacte — meter fórmulas de escrito judicial en un contrato de honorarios, por ejemplo.

3. El estado actual del documento: qué secciones ya tienen contenido y cuáles están vacías, más los primeros ~800 caracteres de cada sección ya redactada. Así, si el abogado pide "mejorá los hechos agregando que hubo un segundo incidente", el modelo puede leer lo que ya está escrito y modificarlo en vez de reescribir desde cero.

4. Los datos concretos del caso: nombre y DNI del cliente, datos del empleador o demandado, fechas de ingreso y despido, salario, CUIJ, juzgado, y — si están disponibles — normativa reciente y jurisprudencia real encontrada en SAIJ. Acá hay una regla estricta extra: el modelo puede citar esos fallos reales textualmente, pero tiene prohibido inventar una carátula, tribunal o fecha que no esté en esa lista. Si no hay jurisprudencia provista, puede hablar en términos genéricos ("la jurisprudencia mayoritaria sostiene...") pero sin inventar una cita puntual.

5. Instrucciones específicas por sección, con overrides según el tipo de documento. La instrucción para "objeto" en una demanda es "qué se pretende y el monto reclamado"; la instrucción para "objeto" en un contrato es completamente distinta: "describí el servicio o prestación, sin mencionar tribunales ni petitorios".

El estilo de referencia: dos caminos, dos estrategias distintas

Cada estudio tiene su forma de escribir. Para que el Redactor IA la respete, existen dos caminos, y — a diferencia de una primera versión de esto — ya no funcionan igual por dentro, porque el caso de uso es distinto en cada uno.

Camino 1: adjuntar un documento suelto en el chat (📎). Es ad-hoc, para un uso puntual dentro de esa conversación. El backend extrae el texto plano (mammoth para .docx, pdf-parse para .pdf), lo recorta a un tamaño razonable, y lo inyecta directo en el prompt como bloque de referencia en cada mensaje de ese chat. Es in-context learning simple: se le muestra el ejemplo al modelo, igual que un abogado junior mostrándole a un colega "mirá cómo redacto yo" antes de empezar.

Camino 2: elegir un modelo cargado por el estudio (Configuración → Plantillas del Estudio) — documentos reales ya redactados, guardados con nombres como "Demanda Laboral - Juan Pérez". Estos se reutilizan una y otra vez, en distintas conversaciones, con distintos clientes, durante meses. Reenviar el documento completo en cada mensaje de cada conversación que lo use es un desperdicio: se vuelve a "leer" el mismo texto una y otra vez.

Por qué no usamos RAG para esto

La respuesta obvia para "no reprocesar el mismo documento siempre" parecería ser RAG (Retrieval Augmented Generation): trocear el documento, indexarlo por significado, y en cada consulta traer solo los fragmentos más relevantes. Es exactamente lo que usa el Radar Legal para buscar entre miles de boletines. Pero acá el objetivo es el opuesto: no queremos "el fragmento más relevante", queremos el documento completo, en el mismo orden, con la misma estructura, cambiando solo los datos puntuales. Aplicar RAG arriesgaría que el sistema decida que ciertas partes "no son relevantes" a la sección que se está redactando y las descarte — perdiendo justo lo que el estudio quiere preservar.

Lo que hacemos en cambio: analizar la plantilla una sola vez

Cuando el abogado carga un modelo en Configuración → Plantillas del Estudio, se dispara automáticamente un único análisis (una llamada aparte al modelo, no streaming, corre una sola vez por plantilla — no en cada mensaje del chat). Ese análisis segmenta el documento en las mismas secciones que ya usa el Redactor IA (encabezado, hechos, derecho, petitorio...) y, para cada una, separa el texto fijo — que se guarda casi literal, con los datos puntuales reemplazados por marcadores como {{nombre_cliente}} o {{fecha_despido}} — de la lista de qué variables hay que completar. El resultado queda guardado en la base, listo para reutilizarse indefinidamente.

A partir de ahí, cada vez que se redacta con esa plantilla como referencia, el prompt ya no manda el documento entero: manda, sección por sección, solo el texto fijo y las variables de esa sección puntual — y solo de las secciones que todavía están vacías. A medida que el documento se va completando, el bloque de referencia que viaja en cada mensaje se va achicando, en vez de mantenerse fijo (o crecer, por el historial de la conversación) durante toda la sesión.

Nada de esto es fine-tuning — no se entrena ningún modelo, no hay ningún proceso que tarde horas. Es análisis + caché: se paga el costo de "entender" la plantilla una sola vez, y se reutiliza gratis en cada redacción posterior. La limitación sigue siendo la misma que antes: hoy se imita texto y estructura, no el formato visual del documento (tipografía, márgenes, membrete) — eso sigue siendo una fase futura, separada.

Cómo se entera el modelo de que le falta un dato

Antes de esta versión, el Redactor IA a veces redactaba secciones completas dejando (PENDIENTE: nombre del testigo) en el medio del texto — un error frecuente y molesto de corregir a mano. La regla actual invierte ese comportamiento: el prompt le exige revisar, antes de llamar a update_section, si tiene todos los datos concretos que esa sección necesita. Si falta alguno, no llama a la herramienta para esa sección — responde en el chat explicando qué dato falta y lo pide. Si el pedido incluye varias secciones y a algunas les falta información, redacta las que sí están completas y avisa, en texto, cuáles quedaron pendientes y por qué.

El recorrido completo de un mensaje

1. El editor arma el estado actual: qué tipo de documento es, qué secciones existen y su contenido, el contexto del caso, y el texto de referencia si hay uno elegido.
2. Ese estado viaja al backend junto con el historial del chat.
3. El backend construye el system prompt combinando las cinco capas de arriba.
4. Se llama a streamText (Gemini 2.5 Flash) con la única herramienta disponible, update_section.
5. El modelo decide qué secciones tocar y en qué orden, llamando la herramienta una vez por cada una — o se detiene a preguntar si falta un dato.
6. Cada llamada de update_section se refleja al instante en el editor: la sección correspondiente se resalta y el cursor se desplaza hasta ella.
7. Al terminar, se descuentan los tokens reales consumidos (prompt + respuesta) del saldo del estudio.
8. El abogado revisa, ajusta a mano lo que quiera desde el editor de texto enriquecido, y exporta a .docx cuando está conforme.

En resumen

El Redactor IA no es un generador de texto libre: es un sistema que fuerza estructura (secciones fijas por tipo de documento), adapta el prompt según la naturaleza legal de lo que se está redactando (un contrato no es una demanda), respeta el estilo real del estudio por in-context learning en vez de inventar una voz genérica, y se niega a inventar datos que no tiene — prefiere preguntar antes que rellenar con placeholders. Esa combinación es lo que separa un buen asistente de redacción de un generador de texto genérico que "suena" a demanda pero no sirve para presentar.