El año pasado tuve que analizar cerca de 200 expedientes judiciales para identificar patrones de distribución de carga entre despachos. Hacerlo manualmente tomaba semanas. Con la combinación correcta de código y los prompts adecuados, lo resolví en dos días.
No fue magia. Fue saber exactamente cómo pedirle al modelo lo que necesitaba.
Llevo tiempo usando modelos de lenguaje como herramienta de trabajo diario en proyectos como Marduk y Sherlock-docs. En ese proceso fui descubriendo que la diferencia entre un resultado útil y uno genérico casi siempre está en cómo formulas la instrucción. Este post es ese aprendizaje en crudo: los tipos de prompts que uso, los patrones que me funcionan, y lo que aprendí rompiéndolos.
Por qué el contexto lo es todo
El error más común que veo cuando alguien empieza a usar IA en trabajo profesional es preguntar como si el modelo supiera quién eres, dónde trabajas y para qué necesitas la respuesta.
No lo sabe.
Antes de cualquier tarea compleja, siempre establezco el contexto:
Eres un asistente especializado en el sistema judicial colombiano.
Estoy desarrollando una herramienta de automatización para analizar
expedientes electrónicos bajo el Código General del Proceso (CGP).
El sistema genera documentos en formato Word que siguen la estructura
definida por el Consejo Superior de la Judicatura.
Este bloque de contexto va al inicio de cualquier sesión donde voy a hacer trabajo técnico relacionado con lo judicial. Cambia completamente la calidad de las respuestas porque el modelo ahora sabe el marco de referencia en el que opera.
El patrón: rol + dominio específico + herramienta o sistema concreto.
Análisis de documentos legales
Una parte importante de mi trabajo es procesar texto extraído de expedientes, autos, sentencias y demandas. Los documentos judiciales tienen una estructura particular — están llenos de referencias normativas, citas jurisprudenciales y fórmulas procesales que para un modelo genérico son ruido.
El prompt que más uso en esta categoría:
Analiza el siguiente texto extraído de un auto judicial colombiano.
Identifica y extrae en formato JSON:
1. Tipo de actuación (auto, sentencia, decreto, etc.)
2. Fecha de emisión
3. Despacho que lo emite
4. Partes procesales mencionadas (demandante, demandado, terceros)
5. Normas procesales citadas (artículo y código)
6. Decisión principal adoptada
7. Términos procesales que otorga (si aplica)
Si algún campo no está presente, indícalo como null.
Responde únicamente con el JSON, sin explicaciones adicionales.
TEXTO:
[pegar el texto del documento aquí]
La clave de este prompt es el formato de salida (JSON estructurado) y la instrucción final de no agregar texto extra. Cuando el output va a alimentar código Python, necesito que sea predecible.
Generación de código para automatización
Aquí es donde más tiempo ahorro. En lugar de escribir código desde cero, uso el modelo como par de programación que entiende el contexto del problema.
El patrón que me funciona tiene tres partes:
CONTEXTO:
Estoy construyendo un módulo en Python para procesar expedientes judiciales.
Ya tengo implementada la clase `ExpedienteProcessor` que lee archivos .docx
y extrae texto plano. El sistema usa Python 3.11, la librería python-docx
y sigue una arquitectura de repositorio.
TAREA:
Necesito un método que reciba el texto extraído de un expediente y detecte
automáticamente si contiene una medida cautelar. Las medidas cautelares en
Colombia típicamente incluyen frases como "decreto medida cautelar",
"embargo y secuestro", "inscripción de demanda".
RESTRICCIONES:
- No uses expresiones regulares complejas, prefiere lógica de búsqueda simple
- El método debe retornar True/False más el fragmento de texto donde encontró la coincidencia
- Agrega docstring con ejemplo de uso
Lo que diferencia este prompt de uno genérico: el contexto técnico exacto (versión de Python, librería específica, arquitectura), la descripción del problema en términos del dominio (medidas cautelares, terminología colombiana), y las restricciones de implementación.
Síntesis y resúmenes para toma de decisiones
Este es el tipo de prompt que creo que más valor tiene para abogados, aunque también es el que más cuidado requiere.
Cuando tengo que revisar múltiples documentos y necesito un resumen que me ayude a decidir qué hacer después:
Lee los siguientes fragmentos de tres autos del mismo proceso judicial.
Tu objetivo es ayudarme a entender el estado actual del proceso, no resumir
cada documento por separado.
Dime:
1. ¿Qué etapa procesal se está tramitando?
2. ¿Hay términos vencidos o próximos a vencer?
3. ¿Qué actuación debería ocurrir a continuación según el CGP?
4. ¿Hay alguna irregularidad procesal evidente?
Responde en máximo 200 palabras. Señala con [VERIFICAR] cualquier
conclusión donde no tengas certeza absoluta por falta de información.
DOCUMENTOS:
[fragmentos aquí]
La instrucción [VERIFICAR] es crítica. Le pido explícitamente al modelo que sea honesto sobre su incertidumbre. En contexto legal, un dato presentado con falsa confianza puede ser peor que ningún dato.
Revisión de código que escribí hace seis meses
Este uso es menos obvio pero igual de valioso. Los proyectos en los que trabajo tienen código que yo mismo escribí hace meses y que ya no recuerdo bien. En lugar de leer todo el archivo, uso esto:
Analiza el siguiente código Python que forma parte de un sistema de
automatización judicial. Explícame:
1. Qué hace exactamente, sin asumir que conozco el contexto
2. Qué dependencias externas necesita para funcionar
3. Qué edge cases no está manejando
4. Qué cambiaría si quisiera hacerlo más testeable
No sugieras refactorizaciones completas. Solo responde las cuatro preguntas.
[código aquí]
La restricción “no sugieras refactorizaciones completas” es importante. Sin ella, el modelo tiende a reescribir todo. A veces eso es lo que quiero, pero cuando solo necesito entender algo rápido, es ruido.
Lo que aprendí sobre escribir buenos prompts
Después de meses haciendo esto de manera sistemática, el patrón que emerge es siempre el mismo:
Contexto específico > instrucción vaga. Cuanto más le digo al modelo dónde está parado, mejor me entiende.
Formato de salida explícito. Si necesito JSON, pido JSON. Si necesito máximo 200 palabras, lo digo. Los modelos respetan las restricciones formales mejor que las cualitativas.
Honestidad sobre la incertidumbre. En cualquier prompt que vaya a informar una decisión sobre un proceso real, siempre agrego alguna variante de “señala lo que no sabes con certeza”. El modelo no es omnisciente — y en contexto legal, ese reconocimiento importa.
Iterar, no perfeccionar. El primer prompt casi nunca es el mejor. Lo que funciona es tener una base, ver qué falla y ajustar.
Estos no son los únicos prompts que uso, ni son fórmulas mágicas. Son los que me han funcionado en el contexto específico en el que trabajo. Si tu contexto es diferente, las variables cambian.
Si usas IA en tu trabajo legal o judicial y tienes una forma particular de pedirle las cosas que te funciona, me interesa saberlo.
Este post es parte de la serie [Construyendo] — donde comparto en abierto las herramientas, patrones y decisiones detrás de los proyectos en los que trabajo.