«Lo puse en el prompt» no es una respuesta a «¿por qué hizo eso?»
La conversación se repite en todas las empresas que llevan un agente a producción. El agente hace algo raro —promete un plazo que no existe, contesta a algo que no le tocaba, se inventa un procedimiento— y alguien pregunta qué pasó. La respuesta es siempre la misma: «lo tenía puesto en el prompt». Y entonces vienen las tres preguntas incómodas. ¿En qué versión del prompt? ¿Quién escribió esa línea? ¿Alguien probó qué pasaba al quitarla?
Casi nunca hay respuesta, y no es por dejadez: es porque la palabra prompt empuja a tratar el texto como un mensaje. Un mensaje se escribe una vez, se manda y se olvida. Pero lo que gobierna a un agente en producción no es un mensaje: es el documento que define qué hace, qué no toca y a quién llama cuando se atasca. Eso tiene otro nombre en cualquier organización: una descripción de puesto. Y las descripciones de puesto tienen dueño, versión y fecha de revisión.
No es una metáfora cómoda. La propia documentación de Anthropic recomienda pensar en el modelo como «un empleado brillante pero nuevo, que no conoce tus normas ni tus flujos de trabajo», y propone una regla de oro que funciona igual de bien con humanos: enséñale tus instrucciones a un compañero con poco contexto y pídele que las siga; si él se lía, el modelo también. Fuente: Prompting best practices, Claude Platform Docs, consultado el 11 de septiembre de 2026.
Esta guía va de escribir ese documento. No es un curso de prompting ni una plantilla mágica que puedas copiar: es la estructura mínima que aguanta en producción, la parte donde casi todo el mundo se equivoca y el hábito que separa iterar de rezar.
Las seis cosas que tienen que estar escritas
Da igual la plataforma, el modelo y el caso. Si falta alguno de estos seis bloques, el agente lo va a rellenar por su cuenta, y lo que rellene no lo has decidido tú. En la arquitectura que describe OpenAI, un agente son tres piezas —modelo, herramientas e instrucciones—, y las instrucciones son las «directrices y guardarraíles explícitos que definen cómo se comporta». Explícitos es la palabra. Fuente: A practical guide to building agents, OpenAI, consultado el 11 de septiembre de 2026.
| Bloque | Qué contesta | Qué pasa si falta |
|---|---|---|
| Identidad y canal | Quién es, con quién habla y por dónde | Cambia de tono y de tuteo según el día |
| Alcance | De qué se ocupa y de qué no | Contesta a todo, incluido lo que no sabe |
| Qué puede decidir | Dónde acaba proponer y empieza ejecutar | Ejecuta cosas que nadie autorizó |
| Formato de salida | Con qué forma entrega el resultado | El sistema de destino lo rechaza en silencio |
| Qué hace cuando no sabe | La salida honesta por defecto | Rellena el hueco con algo verosímil |
| Cuándo escala | El umbral exacto que llama a una persona | Nadie se entera hasta que hay una queja |
Fíjate en la columna de la derecha: ninguno de esos fallos se manifiesta como un error. Todos se manifiestan como comportamiento, que es mucho más caro de detectar. Un agente que se cae te avisa; un agente al que le falta el bloque de alcance trabaja tan campante durante semanas contestando cosas que no le tocaban.
El error de las reglas en negativo (y qué poner en su lugar)
Aquí está la corrección más útil de toda la guía, y va en contra de lo que hace casi todo el mundo. Cuando un agente se porta mal, el reflejo es añadir una prohibición: «nunca prometas plazos», «no uses emojis», «jamás des precios». La lista de noes crece semana a semana hasta convertirse en un reglamento, y el comportamiento sigue apareciendo.
La documentación de Anthropic es explícita al respecto: dile al modelo lo que tiene que hacer, en vez de lo que no. Su ejemplo para controlar el formato es exactamente este: en lugar de «no uses markdown en tu respuesta», escribe «tu respuesta debe estar compuesta de párrafos de prosa fluida». Y cuando la prohibición es inevitable, la misma guía recomienda acompañarla del motivo: «NUNCA uses puntos suspensivos» rinde peor que «tu respuesta la va a leer en voz alta un motor de texto a voz, así que nunca uses puntos suspensivos, porque no sabrá pronunciarlos». El modelo generaliza a partir de la explicación; de la prohibición seca, no. Fuente: Prompting best practices, Claude Platform Docs, consultado el 11 de septiembre de 2026.
La traducción operativa es sencilla y da trabajo: cada vez que vayas a escribir un «no», párate y contesta dos preguntas. ¿Qué quiero que haga en su lugar? y ¿por qué? Lo que salga de ahí es la regla que hay que escribir.
| Lo que se escribe | Lo que rinde |
|---|---|
| «Nunca prometas plazos de entrega» | «Cuando te pregunten por un plazo, da el que devuelva el sistema de pedidos. Si no lo devuelve, di que lo vas a confirmar y abre una consulta, porque un plazo mal dado genera una reclamación.» |
| «No inventes información» | «Responde solo con lo que encuentres en la documentación. Si no está, dilo con esas palabras y ofrece pasar la pregunta a una persona.» |
| «No des descuentos» | «Los descuentos los aprueba el responsable comercial. Si el cliente pide uno, registra la petición con el importe y avisa a ventas; no confirmes nada tú.» |
Hay una excepción que conviene conocer: las restricciones de seguridad duras —lo que nunca, bajo ninguna circunstancia— sí se escriben en negativo y de forma tajante, y conviene repetirlas al principio y al final del documento. Pero eso son dos o tres líneas, no cuarenta. El resto de tu reglamento de noes es, casi siempre, una especificación positiva que nadie se ha parado a escribir.
Lo que decide, lo que propone y lo que ni toca
El bloque que más dinero ahorra es el más corto. Coge cada acción que el agente puede ejecutar y clasifícala en tres columnas: la ejecuta sola, la deja propuesta para que alguien confirme, o no la toca. Y escríbelo con umbrales numéricos, no con adjetivos: «importes altos» no es un umbral, «por encima de 300 euros» sí.
Para decidir en qué columna va cada acción, la guía de OpenAI propone puntuar el riesgo de cada herramienta —bajo, medio o alto— según cuatro factores: si es de solo lectura o de escritura, si es reversible, qué permisos exige y qué impacto económico tiene. Esa puntuación es la que dispara la pausa o la escalada, y es un criterio mucho más defendible que la intuición de la reunión del martes. Fuente: A practical guide to building agents, OpenAI, consultado el 11 de septiembre de 2026.
Este bloque de las instrucciones y los permisos técnicos del agente son dos cosas distintas que tienen que decir lo mismo. Las instrucciones dicen qué debe hacer; los permisos determinan qué puede hacer. Si el documento dice que no emite reembolsos pero la credencial tiene el alcance para emitirlos, lo único que separa a tu empresa de un reembolso indebido es el buen comportamiento del modelo, que no es un control. Cómo se cierra esa pinza está en qué permisos dar a un agente de IA, y el mapa de cuánta autonomía soltar y en qué orden, en niveles de autonomía de un agente.
Qué hace cuando no sabe, y cuándo llama a una persona
Sin una instrucción explícita, el comportamiento por defecto ante una laguna es rellenarla con algo plausible. No porque el modelo mienta, sino porque nadie le ha dado una salida mejor. La salida mejor se escribe en una línea y cambia el día a día: «si la respuesta no está en la documentación, dilo con esas palabras, no la deduzcas, y ofrece pasar la consulta a una persona».
La escalada es la otra mitad. OpenAI la trata como un mecanismo de seguridad de primera clase y describe dos disparadores que conviene copiar tal cual: superar un umbral de fallos —si el agente no ha entendido la intención después de N intentos, transfiere— y acciones de alto riesgo, entendiendo por tales las sensibles, irreversibles o de mucho impacto; los ejemplos que da son cancelar pedidos, autorizar reembolsos grandes y hacer pagos. Fuente: A practical guide to building agents, OpenAI, consultado el 11 de septiembre de 2026.
Escribe esos dos disparadores con números y con destinatario. No «escala cuando sea necesario», sino «tras dos intentos sin identificar el pedido, pasa la conversación a atención al cliente con el resumen y el histórico». La diferencia entre las dos redacciones es la diferencia entre una escalada que ocurre y una que no.
Una cosa cada vez: el hábito que separa iterar de rezar
Casi todo el mundo ajusta las instrucciones de la misma manera: detecta un comportamiento raro, reescribe cuatro párrafos, prueba dos casos a ojo y lo sube. Si mejora, no sabe cuál de los cuatro cambios lo arregló. Si empeora, tampoco sabe cuál lo rompió. Eso no es iterar, es rezar con pasos intermedios.
El hábito que lo convierte en ingeniería cabe en tres reglas. Una. Cambia una cosa cada vez y déjala escrita: qué cambiaste, por qué y qué esperabas. Dos. Guarda el antes y el después de los mismos casos —los diez o quince que representan tu operación real, incluidos los raros—, porque sin el antes no tienes con qué comparar. Tres. Deja la versión anterior donde puedas recuperarla en un minuto, porque el cambio que estropea algo casi nunca lo estropea en la prueba, lo estropea el martes siguiente.
Estas tres reglas son manuales y funcionan en una hoja de cálculo, que es donde deben empezar. Cuando el agente deja de ser uno y pasa a ser una flota, el registro a mano no aguanta y esto se convierte en una función operativa con fuente única de verdad, batería de pruebas antes de desplegar y vuelta atrás en un minuto: eso es probar y versionar prompts de IA, y es un servicio, no un consejo. Lo que decide el salto no es el tamaño del equipo, es el número de personas que pueden tocar el documento.
Y una advertencia que ahorra semanas: si el agente falla porque no encuentra la información, el problema no está en las instrucciones y reescribirlas no lo va a arreglar. Está en lo que puede consultar —cómo se monta y se evalúa está en entrenar un agente de IA— o en lo que debería recordar entre conversaciones, que es la memoria de un agente de IA. Los tres se arreglan de maneras distintas y confundirlos es la forma más habitual de perder un mes.
La ficha de una página: quién la firma y cuándo se revisó
Cierra el documento con una cabecera de cinco campos. No es burocracia: es lo que convierte un texto suelto en un artefacto que alguien mantiene.
- Dueño. Una persona con nombre, no un departamento. Quien contesta cuando el agente hace algo raro.
- Versión y fecha. Un número que sube y el día en que subió. Sin esto no puedes decir qué estaba corriendo la semana pasada.
- Qué cambió y por qué. Dos líneas por versión. Es el registro que te evita repetir un experimento fallido dentro de seis meses.
- Casos de prueba. Dónde viven los diez o quince casos con los que se comprueba cada cambio, y quién los actualiza.
- Próxima revisión. Una fecha. Las instrucciones caducan cuando cambian la política, el catálogo o el sistema de destino, y nadie avisa.
Si tu agente ya está en producción y este documento no existe, el orden es este: escribe primero el bloque de qué puede decidir y el de cuándo escala, que son los dos que tienen dinero delante. El resto puede esperar una semana. Y el día que alguien vuelva a preguntar «¿por qué hizo eso?», vas a poder abrir un fichero, mirar una versión y contestar.
Nosotros escribimos ese documento con el cliente delante y lo dejamos firmado, versionado y con sus casos de prueba: es parte de montar empleados IA que trabajan de verdad, dentro de la lógica general de crear un agente de IA que aguante producción. No vendemos el prompt. Cobramos por que cualquiera de tu equipo pueda leer qué hace tu agente y por qué, sin preguntarle a nadie.