Anatomía de un prompt sólido
Detectar ambigüedad es sólo la mitad del problema. Una vez que sabemos que una instrucción deja decisiones importantes abiertas, necesitamos una manera práctica de preguntarnos qué información falta.
Para eso utilizaremos una anatomía de diez componentes:
Tarea
Objetivo
Perspectiva
Audiencia
Contexto
Documentos
Evidencia
Criterios
Restricciones
Formato de salidaEsta anatomía no es una ley universal del prompting. Tampoco es un formulario que deba rellenarse siempre. Es una herramienta pedagógica para identificar qué dimensiones de una tarea conviene hacer explícitas.
Un prompt sólido no es el que contiene más secciones.
Es el que contiene las decisiones necesarias para ejecutar la tarea concreta sin dejar abiertos aspectos capaces de cambiar materialmente el resultado.
Una vista general antes de entrar al detalle
| Componente | Pregunta práctica |
|---|---|
| Tarea | ¿Qué operación debe realizar el sistema? |
| Objetivo | ¿Para qué se utilizará el resultado? |
| Perspectiva | ¿Desde qué posición debe analizar? |
| Audiencia | ¿Quién leerá o utilizará la respuesta? |
| Contexto | ¿Qué hechos externos a los documentos importan? |
| Documentos | ¿Qué materiales debe usar y qué rol cumple cada uno? |
| Evidencia | ¿Cómo debe respaldar cada hallazgo? |
| Criterios | ¿Cómo debe comparar, priorizar o evaluar? |
| Restricciones | ¿Qué límites debe respetar? |
| Formato de salida | ¿Cómo debe organizar el resultado? |
La utilidad real aparece cuando aprendemos a distinguir pares que suelen confundirse.
Tarea ≠ objetivo
Perspectiva ≠ audiencia
Contexto ≠ documentos
Evidencia ≠ criterios
Restricciones ≠ formato1. Tarea: qué operación debe realizar
La tarea describe el trabajo principal.
Una instrucción débil sería:
Mira este contrato.Una instrucción más precisa:
Identifica las cláusulas que permiten al proveedor modificar unilateralmente el servicio.O:
Compara la versión enviada por la contraparte con el contrato modelo e identifica cambios jurídicamente relevantes.O:
Extrae todas las obligaciones que subsisten después de la terminación.La elección del verbo importa porque cada operación produce una transformación distinta:
extraer busca elementos;
resumir reduce extensión;
comparar relaciona dos objetos;
clasificar asigna categorías;
evaluar aplica criterios;
redactar produce una nueva formulación;
verificar contrasta una afirmación con una base.
En tareas complejas puede ser útil describir también el alcance:
Revisa el contrato completo, pero reporta únicamente hallazgos sobre datos, confidencialidad, responsabilidad y terminación.La tarea responde a la pregunta: ¿qué debe hacer el sistema ahora?
2. Objetivo: para qué necesitamos la respuesta
La tarea mira hacia el trabajo inmediato. El objetivo mira hacia la decisión o uso posterior.
Comparemos:
Tarea: identifica las cláusulas de confidencialidad.con:
Objetivo: determinar qué obligaciones podrían limitar al trabajador después del término de la relación laboral.La tarea puede ser idéntica en dos casos y, sin embargo, el objetivo cambiar la relevancia de los hallazgos.
Por ejemplo:
Resume esta sentencia.es distinto de:
Resume esta sentencia para decidir si sirve como precedente en una demanda por incumplimiento contractual.El objetivo ayuda al sistema a seleccionar qué información merece mayor atención.
En revisión contractual:
OBJETIVO
Preparar una primera revisión antes de la firma para identificar puntos que deban comprenderse, aclararse, negociarse o escalarse.El objetivo no debería pedir una decisión que el sistema no está autorizado a tomar. Por eso puede ser conveniente redactar:
El resultado servirá como insumo para una decisión humana posterior.cuando corresponda.
3. Perspectiva: desde qué posición analizar
En Derecho, el mismo texto puede evaluarse de manera distinta según la posición que interesa proteger o comprender.
Analiza desde la posición del cliente.Analiza desde la posición del proveedor.Examina los argumentos desde la posición de la parte demandada.Evalúa la política desde la función de compliance y no desde la conveniencia comercial.La perspectiva orienta la selección de riesgos, intereses y preguntas.
No debemos interpretarla como una transformación ontológica del modelo. Escribir “actúa como abogado del cliente” no convierte al sistema en un abogado humano ni le entrega autoridad profesional. Funciona como instrucción para privilegiar cierto punto de vista analítico.
Una formulación más precisa puede ser:
PERSPECTIVA
Analiza desde la posición del cliente comprador de tecnología.
Cuando una cláusula favorezca principalmente al proveedor, explica su efecto práctico sobre el cliente.4. Audiencia: quién utilizará la respuesta
Perspectiva y audiencia pueden coincidir, pero no son lo mismo.
Podemos analizar desde la posición del cliente y escribir para:
- otro abogado;
- un gerente de compras;
- un directorio;
- un equipo técnico;
- un cliente sin formación jurídica.
La audiencia afecta principalmente cómo comunicar el resultado.
Por ejemplo:
AUDIENCIA
El resultado será leído por un gerente de compras sin formación jurídica.
Usa lenguaje profesional, pero explica cualquier término jurídico indispensable.Comparemos dos formulaciones de una misma idea.
Para especialista:
“La indemnidad parece quedar fuera del cap general de responsabilidad.”
Para audiencia no jurídica:
“Aunque el contrato limita normalmente la responsabilidad a un monto máximo, esta obligación podría quedar fuera de ese límite y generar una exposición mayor.”
La segunda no es menos rigurosa. Está adaptada al lector.
5. Contexto: hechos externos que cambian el análisis
Los documentos rara vez contienen todo lo que importa.
Supongamos que un contrato incluye una cláusula de terminación con 30 días de aviso. Su importancia puede ser muy distinta si:
- el servicio es reemplazable en una semana;
- el servicio es crítico y una migración toma seis meses.
Ese dato puede no aparecer en el contrato.
Podemos agregar:
CONTEXTO
El servicio será utilizado en operaciones críticas.
La organización estima que una migración a otro proveedor requiere al menos cuatro meses.El contexto ayuda a interpretar relevancia.
Pero debemos conservar una frontera:
Un hecho entregado por el usuario puede ser necesario para el análisis sin estar contenido en el contrato.
Si la procedencia importa, pide al sistema distinguir:
- texto encontrado en documentos;
- hechos entregados como contexto;
- inferencias.
6. Documentos: qué material utilizar y qué función cumple
Adjuntar archivos no basta cuando varios documentos cumplen funciones distintas.
Una estructura útil puede ser:
DOCUMENTOS
1. contrato_principal.pdf
Documento contractual principal. Debe ser revisado completo.
2. anexo_datos.pdf
Anexo vinculante. Úsalo para revisar tratamiento de datos.
3. propuesta_comercial.pdf
Úsala sólo para detectar diferencias entre lo ofrecido y lo contratado.
4. politica_interna.pdf
Estándar interno de la organización. No la trates como parte del contrato ni como norma jurídica.Esta práctica responde a una pregunta fundamental:
¿Qué autoridad o función tiene cada fuente dentro de la tarea?
También permite manejar contradicciones:
Si dos documentos se contradicen, no elijas silenciosamente uno. Identifica la contradicción y explica qué debe verificarse.En trabajo jurídico, la jerarquía y procedencia de documentos puede ser tan importante como su contenido.
7. Evidencia: cómo respaldar los hallazgos
Un análisis puede sonar convincente y ser difícil de verificar.
Por eso conviene especificar qué cuenta como soporte.
EVIDENCIA
Para cada hallazgo:
- identifica el documento;
- indica cláusula, sección o encabezado;
- copia sólo el fragmento estrictamente necesario;
- señala si el hallazgo deriva de texto literal o de inferencia.Los materiales del curso utilizan una convención semejante:
[Documento]
[Ubicación]
[Tipo de soporte: texto literal / inferencia]La evidencia responde a la pregunta:
¿Cómo podrá otra persona comprobar de dónde salió esta afirmación?
Esto no garantiza que la cita sea correcta. Pero obliga a producir una respuesta diseñada para ser verificada.
8. Criterios: cómo comparar, clasificar o evaluar
La instrucción:
Identifica riesgos importantes.sigue dejando abierta la palabra importante.
Podemos hacerla más operativa:
CRITERIOS
Evalúa cada hallazgo considerando:
- impacto económico potencial;
- impacto operativo;
- amplitud de la obligación;
- posibilidad de incumplimiento involuntario;
- dificultad de mitigación;
- dependencia de una decisión unilateral del proveedor.También podemos definir categorías:
ALTO
Puede impedir la aprobación sin modificación, información adicional o escalamiento.
MEDIO
Requiere aclaración o negociación, pero no necesariamente bloquea la aprobación.
BAJO
Conviene documentarlo, aunque su impacto práctico sea limitado.Los criterios permiten dos mejoras simultáneas:
- orientan la respuesta;
- hacen más visible la base de la clasificación.
Una categoría sin criterio es sólo una etiqueta.
9. Restricciones: qué no debe hacer
Las restricciones delimitan el trabajo.
En tareas jurídicas documentales pueden ser especialmente importantes:
RESTRICCIONES
- No inventes cláusulas ni ubicaciones.
- No uses como evidencia contractual información que sólo aparece en el contexto.
- No presentes inferencias como texto explícito.
- Si falta información, indícalo.
- No redactes una cláusula alternativa si esta etapa es sólo diagnóstica.
- No adoptes la decisión final de aprobación.Las mejores restricciones son observables.
Comparemos:
Sé cuidadoso.con:
Si no puedes localizar una cláusula que respalde el hallazgo, no lo presentes como confirmado.La segunda permite verificar cumplimiento.
10. Formato de salida: cómo organizar el resultado
El formato depende del uso posterior.
Para lectura humana:
Devuelve una tabla con:
- cláusula;
- tema;
- hallazgo;
- evidencia;
- riesgo;
- pregunta para la contraparte.Para comunicación ejecutiva:
Entrega primero una síntesis de cinco prioridades y después desarrolla cada hallazgo.Para procesamiento técnico posterior puede ser útil una salida estructurada como JSON o XML, cuestión que veremos más adelante.
Lo importante es no confundir formato con contenido.
Una tabla excelente puede contener análisis incorrectos. Un JSON válido puede contener una cláusula inventada.
El formato responde a:
¿Cómo necesito recibir el resultado para poder utilizarlo?
Cinco distinciones que conviene dominar
Tarea ≠ objetivo
Tarea: comparar dos contratos.
Objetivo: preparar una negociación.La primera describe la operación. La segunda explica para qué sirve.
Perspectiva ≠ audiencia
Perspectiva: cliente.
Audiencia: gerente de compras.La primera orienta el análisis. La segunda orienta la comunicación.
Contexto ≠ documentos
Contexto: la migración toma seis meses.
Documento: contrato_principal.pdf.El contexto aporta hechos. El documento es una fuente concreta que debe ser utilizada según su rol.
Evidencia ≠ criterios
Evidencia: cláusula 8.2.
Criterio: impacto operativo y dificultad de mitigación.La evidencia dice de dónde proviene el hallazgo. El criterio dice cómo se evalúa.
Restricciones ≠ formato
Restricción: no inventes ubicaciones.
Formato: devuelve una tabla.Una limita conducta. La otra organiza la salida.
Cómo ensamblar un prompt sin convertirlo en burocracia
Veamos una versión integrada.
OBJETIVO
Preparar una revisión previa a la aprobación de un contrato de proveedor de IA.
TAREA
Identifica hallazgos relevantes sobre datos, confidencialidad, continuidad, propiedad intelectual, responsabilidad y terminación.
PERSPECTIVA
Analiza desde la posición del cliente.
AUDIENCIA
El análisis será revisado por un abogado interno y luego resumido para compras.
CONTEXTO
El servicio procesará documentos confidenciales y será utilizado en un proceso operativo crítico.
DOCUMENTOS
- contrato.pdf: documento principal;
- anexo_datos.pdf: anexo vinculante;
- politica_interna.pdf: estándar interno, no parte del contrato.
EVIDENCIA
Para cada hallazgo indica documento, cláusula y fragmento relevante.
CRITERIOS
Prioriza según impacto, dificultad de mitigación y dependencia del proveedor.
RESTRICCIONES
- No inventes información.
- Distingue texto, inferencia e información faltante.
- No adoptes todavía la decisión final.
FORMATO
Devuelve una tabla de hallazgos y una síntesis de las cinco prioridades principales.La utilidad de esta estructura no depende de los títulos en mayúsculas. Podríamos escribir exactamente lo mismo en prosa.
Los encabezados sirven porque hacen visibles las relaciones y ayudan a revisar el prompt antes de usarlo.
Orden y dependencia entre elementos
Berryman y Ziegler destacan que los elementos de un prompt no son simplemente piezas acumuladas. Mantienen relaciones de posición, importancia y dependencia.
Eso puede verse claramente en un caso jurídico.
Si primero definimos:
DOCUMENTOS
Contrato principal y anexo de datos.y después:
EVIDENCIA
Cada hallazgo debe estar respaldado por uno de esos documentos.la dependencia es visible.
Si en cambio dispersamos la regla en un párrafo muy largo, aumenta el riesgo de confusión tanto para el sistema como para la persona que mantiene el prompt.
Una buena estructura editorial ayuda a comprender qué instrucción gobierna qué contenido.
Cuándo omitir componentes
Supongamos:
Traduce al inglés el siguiente párrafo sin modificar las referencias entre paréntesis.Probablemente no necesitamos una sección sobre perspectiva, criterios de riesgo, jerarquía documental o formato JSON.
Agregar componentes irrelevantes no vuelve más profesional la instrucción. Puede volverla más difícil de leer y mantener.
La anatomía funciona como diagnóstico, no como obligación:
¿Qué componente, si falta, dejaría una decisión materialmente importante abierta?
Si ninguno falta, el prompt ya puede ser suficiente.
Una auditoría práctica del prompt
Antes de ejecutar un encargo importante, podemos revisar:
TAREA
¿Dije exactamente qué operación debe realizar?
OBJETO Y ALCANCE
¿Está claro sobre qué debe trabajar y qué debe dejar fuera?
OBJETIVO
¿Expliqué para qué usaré la respuesta?
PERSPECTIVA
¿Está claro desde qué posición se analiza?
AUDIENCIA
¿El nivel de explicación corresponde al lector?
CONTEXTO
¿Incluí hechos relevantes que no están en los documentos?
DOCUMENTOS
¿Asigné un rol claro a cada fuente?
EVIDENCIA
¿Pedí trazabilidad suficiente para comprobar los hallazgos?
CRITERIOS
¿La evaluación tiene una regla reconocible?
RESTRICCIONES
¿Marqué los límites que realmente importan?
FORMATO
¿La salida sirve al uso posterior?Esta auditoría refleja la lógica de la checklist desarrollada en Clases UDD.pdf: antes de enviar un mensaje importante, conviene comprobar que no estamos obligando al sistema a completar por su cuenta decisiones que sí podíamos especificar.
Qué puede salir mal incluso con una anatomía completa
Un prompt puede incluir todos los componentes y seguir siendo malo.
Puede contener:
- un objetivo incompatible con la tarea;
- criterios contradictorios;
- documentos mal jerarquizados;
- restricciones imposibles;
- un formato que no sirve al uso posterior;
- demasiadas instrucciones secundarias;
- una falsa sensación de certeza.
Por eso no debemos confundir completitud formal con calidad de diseño.
La anatomía ayuda a formular preguntas. No reemplaza el juicio sobre cuáles son las preguntas correctas.
Caso conductor: construir la especificación de revisión
Para el contrato del proveedor de IA, la evolución ya no se entiende como “hacer el prompt más largo”, sino como decidir qué dimensiones deben fijarse.
TAREA
Revisar hallazgos contractuales relevantes.
OBJETIVO
Preparar decisión de aprobación.
PERSPECTIVA
Cliente.
AUDIENCIA
Abogado interno + compras.
CONTEXTO
Servicio crítico con tratamiento de información confidencial.
DOCUMENTOS
Contrato + anexos + política interna con roles diferenciados.
EVIDENCIA
Ubicación y fragmento verificable.
CRITERIOS
Impacto, claridad, dependencia, mitigación.
RESTRICCIONES
No inventar, no resolver contradicciones silenciosamente, no adoptar decisión final.
FORMATO
Matriz + prioridades.Ahora tenemos un mapa completo de la tarea.
El siguiente problema es decidir cuánto de este mapa necesitamos en cada caso.
Qué debes recordar
Los diez componentes no son una receta universal. Son una forma de transformar una instrucción vaga en una especificación analizable.
La pregunta no es:
“¿Mi prompt tiene las diez secciones?”
sino:
“¿He hecho explícitas las decisiones que pueden cambiar materialmente el trabajo?”
Cuando un componente no aporta nada, puede omitirse. Cuando una decisión importa, conviene formularla con precisión suficiente para poder revisar después si fue respetada.
El problema que todavía queda abierto
Si conocemos diez componentes, podemos caer en la tentación de utilizarlos todos desde el comienzo.
Eso generaría prompts innecesariamente pesados incluso para tareas simples.
Necesitamos otro principio: crecer por necesidad.
La siguiente página presenta la escalera de complejidad: cómo pasar desde un pedido mínimo hasta un prompt maestro agregando una capa sólo cuando resuelve una limitación concreta del nivel anterior.