PROMPT: cómo redactar directivas robustas

Más allá del prompt suelto: cómo redactar instrucciones de sistema robustas

Escribes una petición a la IA y la respuesta es buena. Al día siguiente haces la misma petición y el resultado es distinto: más largo, menos preciso o con un dato inventado. Si te pasa a menudo, el problema no está en tu forma de preguntar. Está en que dependes de prompts sueltos que escribes cada vez desde cero.

Con este capítulo pasamos del marco legal a la práctica del diseño. Verás por qué los trucos de prompt engineering no bastan para construir sistemas fiables y cómo estructurar una instrucción de sistema en cinco bloques. También tienes un ejemplo completo de revisión de contratos y dos técnicas para afinar los resultados.

Por qué los trucos de prompt no bastan

Cuando la IA generativa se popularizó, la ingeniería de prompts (prompt engineering) se vendió muchas veces como una colección de trucos: fórmulas mágicas, palabras clave secretas o frases que supuestamente «desbloquean» mejores respuestas.

Ese enfoque artesanal tiene tres problemas cuando quieres usarlo en un negocio:

• Es inconsistente. Un truco que funciona con un modelo puede no funcionar con otro, ni siquiera con la siguiente versión del mismo modelo.
• Se vuelve caótico. Vas añadiendo instrucciones sobre la marcha, sin un orden claro, y al final algunas se contradicen.
• Te obliga a estar siempre presente. Cada resultado necesita que escribas una petición nueva. Sigues vendiendo tu tiempo, como vimos en el capítulo 7 sobre la productividad superficial.

Para construir sistemas que den resultados repetibles y escalables, tienes que pasar de los prompts improvisados a las instrucciones de sistema (system instructions o system prompts), que aquí llamaremos también directivas operativas.

Una instrucción de sistema no es una sugerencia. Funciona como el código fuente en lenguaje natural de un agente. Define quién es, hasta dónde llega, cómo debe razonar y qué forma debe tener lo que entrega.

Anatomía de una instrucción de sistema: el marco R-C-M-F-E

Para que un agente funcione de forma consistente, previsible y segura, organiza su instrucción de sistema en cinco bloques:

Bloque

Qué define

Pregunta que responde

R · Rol y postura

Quién es el agente, su tono y su actitud ante la evidencia

¿Desde dónde mira el problema?

C · Contexto y alcance

Para qué existe, para quién trabaja y qué datos recibe

¿Qué problema resuelve?

M · Metodología

El proceso que sigue, paso a paso

¿Cómo llega a la respuesta?

F · Frenos

Lo que nunca debe hacer

¿Dónde están sus límites?

E · Esquema de salida

La estructura exacta del resultado

¿Qué forma tiene lo que entrega?

Bloque 1: rol y postura ante la evidencia

Este bloque define el campo de competencia del agente y lo prudente que debe ser al juzgar. Un buen rol no sirve para halagar al modelo. Sirve para calibrar su forma de razonar.

Mala práctica:

«Eres un experto mundial en marketing y lo sabes todo».

Este tipo de frase empuja al modelo a sonar grandilocuente y demasiado seguro de sí mismo.

Buena práctica:

«Eres un auditor analítico especializado en evaluar modelos de negocio B2B. Tu postura es escéptica, constructiva y rigurosa. Das más valor a la evidencia que a las afirmaciones retóricas. Si los datos no son suficientes, señálalo de forma explícita».

La diferencia está en que el segundo rol le dice al agente cómo tratar la incertidumbre, no solo cuánto sabe.

Bloque 2: contexto y alcance

Aquí delimitas el entorno en el que trabaja el agente. Incluye:

• Quién lo usará: un equipo de operaciones, un cliente final, otro agente.
• Qué recibirá como entrada: archivos adjuntos, transcripciones, datos en formato JSON, correos.
• Cuál es su objetivo concreto. No se trata de generar mucho texto, sino de resolver un cuello de botella concreto.

Cuanto más claro sea el alcance, menos tendrá que adivinar el modelo.

Bloque 3: metodología de razonamiento

Este bloque obliga al modelo a seguir un proceso por fases antes de dar una respuesta. Es la técnica de razonamiento paso a paso (chain of thought) que vimos en el capítulo 2, pero aplicada de forma estructurada.

Ejemplo:

1. Extrae los hechos. Identifica los datos y las afirmaciones de la entrada.
2. Contrástalos con el Brain. Comprueba si coinciden con los manuales internos.
3. Identifica discrepancias o riesgos.
4. Redacta la propuesta con la estructura indicada.

Así reduces los saltos lógicos y, además, puedes revisar en qué fase se equivocó el agente si algo sale mal.

Bloque 4: frenos y restricciones

Los modelos tienden a la complacencia: intentan agradar y responder siempre algo, aunque no tengan datos. Las restricciones actúan como cortafuegos frente a ese comportamiento.

Algunos ejemplos útiles:

• «No inventes fuentes, artículos de ley, métricas ni jurisprudencia».
• «Si la información no está en el Brain, responde exactamente: "Información no disponible en las fuentes autorizadas"».
• «No uses introducciones de cortesía ni despedidas. Empieza directamente con el análisis».
• «No tomes decisiones finales en nombre del usuario. Presenta opciones con sus riesgos».

Dos consejos para que funcionen mejor:

• Explica qué hacer en lugar de lo prohibido. «No inventes» funciona mejor junto a «si no lo sabes, escribe esta frase concreta».
• No acumules prohibiciones sin orden. Agrúpalas y prioriza las que de verdad protegen al usuario.

Bloque 5: esquema de salida

Este bloque elimina cualquier ambigüedad sobre el formato. Es un contrato: el agente sabe exactamente qué tiene que entregar.

Puedes fijar:

• Encabezados Markdown exactos.
• Tablas con columnas definidas.
• Formatos de datos estructurados, como JSON o YAML, si otro programa o agente va a leer el resultado.

Una salida estable sirve a dos públicos: a la persona que la lee sin esfuerzo y al software que la procesa sin errores.

Ejemplo: del prompt improvisado a la instrucción de sistema

El prompt improvisado

«Revisa este contrato y dime si está bien. Búscame los fallos y hazme un resumen en una tabla».

Resultado habitual: respuestas distintas cada vez, cláusulas importantes que se pasan por alto, riesgos inventados y una extensión que varía de un día a otro.

La instrucción de sistema

IDENTIDAD Y PROPÓSITO
Actúas como asistente técnico de revisión contractual para el
departamento de operaciones. Tu función es revisar borradores de
contratos de servicios frente a los estándares de la empresa e
identificar cláusulas de riesgo antes de que una persona los firme.

FUENTES Y AUTORIDAD
- Usa exclusivamente las directrices contractuales de tu base de
  conocimiento (Brain).
- Si una cláusula no está contemplada en esas directrices, márcala
  como "Requiere criterio legal externo".

PROTOCOLO DE REVISIÓN (PASO A PASO)
1. Localiza en el documento estas cinco áreas:
   (a) objeto, (b) plazos, (c) propiedad intelectual,
   (d) responsabilidad e indemnización, (e) confidencialidad.
2. En cada área, comprueba si hay discrepancias con la política
   de la empresa.
3. Clasifica cada discrepancia como riesgo ALTO, MEDIO o BAJO
   según los criterios del manual.

RESTRICCIONES
- No afirmes nunca que un contrato "es seguro" o "está listo para
  firmar". Tu papel es solo detectar y clasificar riesgos.
- No redactes cláusulas nuevas sin autorización humana previa.
- Si detectas una cesión ilimitada de propiedad intelectual,
  asígnale siempre riesgo ALTO.

FORMATO DE SALIDA
Responde exactamente con esta estructura Markdown:

## 1. Resumen ejecutivo del riesgo
(Máximo 3 líneas)

## 2. Matriz de revisión
| Cláusula | Estado (Conforme / Discrepante) | Nivel de riesgo | Riesgo identificado | Acción sugerida |

## 3. Puntos pendientes de decisión humana
(Lista numerada)

Dos técnicas para afinar tus instrucciones de sistema

1. Incluye ejemplos (few-shot prompting)

Añade a la instrucción de sistema uno o dos ejemplos completos: una entrada real y la salida exacta que esperas. Un ejemplo concreto suele orientar al modelo mucho mejor que cualquier descripción abstracta del resultado.

Para sacarle partido:

• Usa ejemplos representativos, parecidos a los casos reales que recibirá el agente.
• Varíalos si añades más de uno. Si todos se parecen demasiado, el modelo tenderá a copiar detalles concretos en lugar de captar el patrón.
• Elimina los datos personales o confidenciales de los ejemplos.

2. Divide en módulos

No cargues a un solo agente con diez páginas de instrucciones para resolver todo el negocio. Cuanto más larga y dispersa es una instrucción, más fácil es que el modelo pierda partes por el camino. Es la degradación del contexto que vimos en el capítulo 1.

Es mejor crear varios agentes con instrucciones breves, cada uno centrado en una sola fase del proceso. Por ejemplo:

1. Un agente extrae las cláusulas del contrato.
2. Otro las compara con la política de la empresa.
3. Un tercero redacta el informe final.

Es la misma lógica de orquestación que vimos en los capítulos 3 y 4: piezas pequeñas, previsibles y fáciles de revisar.

Un límite que conviene recordar

Una buena instrucción de sistema reduce mucho los errores, pero no los elimina. El modelo sigue funcionando por probabilidades. Además, una entrada maliciosa puede intentar saltarse las instrucciones mediante la inyección de instrucciones (prompt injection) que vimos en el capítulo anterior.

Por eso, combina siempre tus instrucciones con:

• Validaciones deterministas para los datos críticos, como cálculos, fechas o formatos.
• Revisión humana en las decisiones de impacto.
• Pruebas periódicas con casos reales cada vez que cambies de modelo o de versión.

Lista rápida para revisar tus instrucciones de sistema

Antes de poner en marcha un agente, comprueba que su instrucción:

• Define un rol con una postura clara ante la incertidumbre.
• Explica quién lo usa, qué datos recibe y qué problema resuelve.
• Indica las fuentes autorizadas y qué hacer si falta información.
• Describe el proceso en pasos numerados.
• Incluye restricciones concretas y una alternativa para cada una.
• Fija un formato de salida exacto.
• Reserva un espacio para las decisiones humanas.
• Se ha probado con varios casos reales, incluidos casos difíciles.

Conclusión

Un prompt suelto resuelve una tarea. Una instrucción de sistema bien diseñada crea un agente que resuelve esa tarea siempre de la misma forma. Si estructuras tus directivas con rol, contexto, metodología, restricciones y formato de salida, conviertes tu forma de trabajar en algo reutilizable, revisable y escalable. Ese es el paso que te permite dejar de depender de tu presencia en cada interacción.

¿Quieres empezar a convertir tu método de trabajo en agentes con instrucciones claras? Visita libertadia.com y regístrate en la aplicación.