Cómo escribir peticiones que funcionen a la primera, y qué cambia cuando ese uso deja de ser ocasional y se vuelve parte de cómo opera un equipo todos los días.
Esta guía es para cualquier persona que usa una herramienta de inteligencia artificial generativa en su trabajo (ChatGPT, Claude, Gemini o cualquier otra) y quiere dos cosas: primero, escribir peticiones que funcionen a la primera con más frecuencia; segundo, entender qué cambia cuando ese uso deja de ser ocasional y se vuelve parte de cómo opera un equipo o un negocio todos los días.
Se divide en dos partes:
No hace falta saber programar para ninguna de las dos partes. Cada concepto viene con un ejemplo de un caso de negocio común, del tipo que cualquier empresa reconoce sin importar su industria.
Un prompt flojo casi siempre tiene la misma causa: le falta uno de cinco elementos. No hace falta usar los cinco en cada petición, pero cuando algo no funciona, casi siempre es porque falta alguno de estos.
Quién es el modelo para esta tarea. Sin rol, el modelo responde como generalista: correcto en general, útil para nadie en particular.
Para quién trabaja, en qué situación, bajo qué restricciones. El contexto es lo que convierte una respuesta genérica en una respuesta útil para tu caso.
El verbo y el objeto: qué quieres que haga, exactamente. No la intención detrás ("ayúdame con esto"), sino la acción concreta ("clasifica", "redacta", "compara").
La estructura exacta de lo que quieres recibir. Sin esto, se recibe prosa, y la prosa no se puede copiar directo a una hoja de cálculo ni procesar de forma consistente.
Cómo sabrá el modelo, y cómo sabrás tú, que la salida sirve. Es el elemento que casi nadie escribe, y el que más separa una herramienta confiable de una que hay que revisar dos veces.
Petición sin ningún elemento: "Ayúdame a responder este correo de un cliente molesto."
Resultado típico: una respuesta genérica, con un tono que puede o no ajustarse a cómo tu empresa realmente se comunica, y que probablemente vas a tener que reescribir de todos modos.
Agregando rol y contexto: "Eres el responsable de atención a clientes de una tienda en línea. Un cliente escribió molesto porque su pedido llegó con tres días de retraso."
Ya sabe desde qué posición responder y qué pasó, pero todavía no sabe qué quieres que haga con eso.
Agregando instrucción: "Redacta una respuesta que reconozca el retraso, ofrezca una compensación razonable, y pida disculpas sin sonar robotizado."
Ahora tiene una tarea concreta, no solo una situación.
Agregando formato: "Devuélvelo como un correo de no más de ciento veinte palabras, en un tono cordial pero profesional."
Ahora el resultado es algo que puedes copiar y enviar casi sin editar.
Agregando el criterio de calidad: "Si el pedido tardó más de cinco días, la compensación debe incluir el envío gratis del siguiente pedido; si fue menos de cinco días, basta con un descuento del diez por ciento. Si no tienes ese dato, pregúntamelo antes de redactar."
Ahora el modelo tiene una regla de negocio real que seguir, y sabe qué hacer cuando le falta un dato en vez de inventarlo.
Un prompt de una línea, revisado dos veces, casi siempre gana a uno de un párrafo escrito de un jalón. Escribe la versión más corta que se te ocurra, mira qué le falta, y agrégalo.
En vez de escribir de entrada un prompt de ocho líneas para resumir una reunión, empieza con "resume esta reunión" y mira qué falta: ¿falta decir para quién es el resumen? ¿Falta el largo? ¿Falta qué hacer con los pendientes? Cada vuelta agrega solo lo que realmente hizo falta.
Pedir que algo sea "corto" o "profesional" deja la interpretación al modelo. Pedir el largo exacto y la audiencia exacta no.
En vez de "hazme un resumen corto para mi jefe", escribe "tres oraciones, para alguien que no estuvo en la reunión y solo necesita saber qué se decidió y qué sigue."
Si mezclas instrucción y contexto en un solo párrafo largo, el modelo tiene que adivinar qué es la tarea y qué es solo información de fondo. Sepáralos, aunque sea con un salto de línea.
"Clasifica los siguientes cinco comentarios de clientes por nivel de urgencia (alta, media, baja)." seguido, en un párrafo aparte, de los cinco comentarios. No al revés.
Decir qué debe hacer el modelo funciona mejor que enumerar qué no debe hacer. Una lista de prohibiciones dice qué evitar, pero no dice qué hacer en su lugar, y el modelo termina llenando ese vacío como puede.
"Responde usando solo la información de este documento, y si algo no está ahí, dilo explícitamente" funciona mejor que "no inventes información que no esté en el documento."
Mostrar uno o dos ejemplos del resultado exacto que quieres reduce la ambigüedad del formato mucho más que describirlo con palabras. Es la diferencia entre decir "quiero que se vea así" y de verdad enseñarle cómo se ve.
"Clasifica por tipo de problema los tickets de soporte que la empresa recibe cada día."
Sin ejemplos: "Clasifica este ticket de soporte por tipo de problema." El modelo va a inventar sus propias categorías, y cada ticket puede terminar clasificado con una etiqueta distinta a la del anterior.
Con ejemplos, cada uno como par ticket → categoría:
Con dos o tres ejemplos, el modelo entiende no solo qué categorías existen, sino el nivel de detalle y el tono con el que se nombran.
Pedir que muestre los pasos antes de dar la respuesta final reduce errores en cualquier tarea que tenga más de una regla que aplicar, y además te deja ver cómo llegó a esa conclusión, en vez de recibir solo un veredicto que hay que confiar a ciegas.
"Revisa si este gasto de viaje cumple con la política de la empresa."
Sin pedir razonamiento: "¿Este gasto de trescientos pesos en una comida cumple con la política?" Responde sí o no, y si se equivoca, no tienes forma de saber en qué regla falló.
Pidiendo razonamiento: "Antes de responder, enumera qué reglas de la política de viáticos aplican a este gasto y si cada una se cumple o no. Solo después, da tu conclusión final." Ahora, si el modelo dice que el gasto no cumple, puedes ver exactamente cuál regla incumplió y verificarlo tú mismo en diez segundos, en vez de tener que revisar la política completa otra vez.
Cuando el costo de un error es alto, una sola respuesta no es suficiente evidencia. Pedir el mismo trabajo tres veces, de forma independiente, y comparar en qué coinciden, es una manera simple de detectar cuándo el modelo está seguro y cuándo está adivinando.
"Estima cuánto va a crecer la venta de este producto el próximo trimestre, a partir de los datos históricos."
Una sola versión: le pides el pronóstico una vez y lo tomas como dado, sin saber si esa cifra es una estimación sólida o una entre varias igualmente plausibles.
Tres versiones: le pides el mismo pronóstico tres veces, en conversaciones separadas, y comparas los tres resultados. Si las tres cifras están cerca entre sí, tienes una estimación razonablemente estable. Si varían mucho, es una señal de que el modelo no tiene suficiente base para ese pronóstico, y que conviene tratarlo con más cautela o pedir más datos antes de decidir con base en él.
En vez de una sola petición gigante que intenta hacer todo de un jalón, una cadena de peticiones más chicas, donde la salida de una alimenta a la siguiente, es más fácil de revisar y de corregir cuando algo sale mal en un solo eslabón.
"Prepara el reporte ejecutivo de ventas del mes."
Todo en una sola petición: "Aquí están los datos de ventas del mes, dame el reporte ejecutivo completo con análisis y recomendaciones." Si el reporte final tiene un error, no sabes si el problema fue en el análisis de los datos, en la interpretación, o en la redacción, porque todo pasó en un solo paso.
Como cadena:
"extrae de estos datos los cinco productos con mayor y menor crecimiento respecto al mes anterior.""para cada uno, identifica una posible causa del cambio usando estos otros datos de contexto (campañas activas, cambios de precio, disponibilidad de inventario).""redacta el resumen ejecutivo en tres párrafos, para alguien que solo va a leer esto y no los datos originales."Si el resumen final no convence, revisas primero si el análisis del paso dos fue correcto, sin tener que rehacer todo desde cero.
Antes de pedir el resultado, pedir las preguntas que hacen falta contestar para hacerlo bien. Es contraintuitivo (se siente como un paso extra), pero suele ahorrar más tiempo del que toma, porque evita que el modelo llene con suposiciones los huecos que tú podrías haber contestado.
"Redacta el copy de la campaña de correo para el lanzamiento de este producto."
Sin dos tiempos: pides el copy directo, y el modelo asume el tono, la audiencia, la duración de la promoción y el llamado a la acción, porque nadie se los dio. Es probable que tengas que reescribir varias partes.
Con dos tiempos: "Voy a pedirte que redactes el copy de una campaña de lanzamiento. Antes de escribir nada, hazme las preguntas que necesitas contestadas para hacerlo bien. No redactes todavía." El modelo pregunta, por ejemplo, cuál es la audiencia, cuánto dura la promoción, qué tono usa la marca, y cuál es el llamado a la acción exacto. Contestas esas preguntas, y solo entonces pides el copy. La segunda versión, con esas respuestas ya incorporadas, casi siempre necesita muchos menos ajustes.
Están detrás de la gran mayoría de los prompts que no funcionan.
"Ayúdame con esto" no tiene verbo ni objeto: el modelo tiene que adivinar qué significa ayudar, y adivina mal. Corrección: nombra la acción exacta, como "resume", "clasifica" o "compara".
Sin eso, el modelo responde para un lector genérico, y tú no eres un lector genérico: tienes un sector, restricciones y una audiencia concreta. Corrección: una sola oración de contexto suele bastar.
Si no lo pides, recibes prosa, y la prosa no se puede pegar en una hoja de cálculo ni revisar campo por campo. Corrección: pide la estructura exacta, aunque sea tan simple como "en una tabla de tres columnas".
El modelo resuelve bien la primera y mal las demás, y no hay forma de saber cuál falló. Corrección: una petición, una tarea; si son varias, encadénalas en pasos separados (Capítulo 6).
La primera respuesta casi nunca es la mejor versión posible; es solo la primera. Corrección: trata cada respuesta como un borrador, no como un veredicto, y pide el ajuste específico que le falta.
Uno de los mayores obstáculos para usar bien estas herramientas no es técnico: es que la mayoría de la gente no tiene un vocabulario preciso para describir qué trabajo quiere que la IA haga. Decir "necesito un agente de IA" o "hay que automatizar esto" describe una solución imaginada, no un trabajo real. Estos siete verbos cubren, en la práctica, casi cualquier tarea de apoyo que la IA generativa puede hacer hoy.
Produce una respuesta fundamentada a partir de un cuerpo de información existente.
Ejemplo: "Encuentra la cláusula exacta de este contrato de cientos de páginas, en vez de leerlo completo."
Convierte una entrada libre en campos, hechos o una tabla.
Ejemplo: "Lee esta factura en PDF y convierte el proveedor, el monto y la fecha en columnas de una hoja de cálculo."
Propone una etiqueta, una cola o un orden.
Ejemplo: "Decide qué correos de clientes se atienden primero según su urgencia."
Produce un borrador, un resumen o un cambio de formato.
Ejemplo: "Convierte estas notas sueltas de una llamada de ventas en un correo de seguimiento."
Compara algo contra un criterio y dice qué falta o qué no cumple. No decide ni aprueba por sí solo.
Ejemplo: "Revisa este expediente de cliente nuevo contra el checklist de documentos requeridos."
Sugiere una opción o formula las preguntas críticas para decidir.
Ejemplo: "Sugiere a qué cliente contactar primero según su historial de compras."
A diferencia de los otros seis, que terminan con una salida que una persona revisa, este actúa sobre un flujo completo: da seguimiento a estatus, manda alertas, y avisa cuando algo se detiene.
Ejemplo: "Avisa automáticamente cuando falte un documento, antes de que el proceso de contratación se atrase."
Nombrar el verbo correcto, antes de escribir el prompt, ya resuelve buena parte del trabajo: el verbo del trabajo es, casi siempre, el primer verbo del prompt.
Todo lo anterior resuelve una petición puntual, hecha una vez, por una persona. Pero un buen prompt tiene un límite: funciona para una petición a la vez, y depende de que alguien lo escriba bien cada vez que hace falta.
El problema aparece cuando el mismo trabajo deja de ser ocasional. Si todos los lunes alguien tiene que revisar veinte reportes de gastos contra la política de viáticos, un prompt perfecto ayuda, pero sigue exigiendo que una persona copie y pegue el reporte, adjunte la política, y repita la petición veinte veces. El modelo, además, no recuerda nada de la revisión de la semana pasada: cada vez empieza de cero, aunque el mismo empleado haya cometido el mismo error de forma repetida.
Cuando el trabajo se repite, involucra información propia del negocio, o necesita conectarse con otras herramientas para completarse, ya no basta con escribir mejor la petición: hace falta diseñar qué información rodea a esa petición, de dónde sale, y qué se hace con el resultado. A esa disciplina se le empezó a llamar, apenas hace poco, "context engineering": la ingeniería de decidir qué entra al espacio de trabajo del modelo, en vez de solo qué se le pide.
Un sistema de IA, a diferencia de un prompt suelto, se construye con cuatro piezas.
El rol y las reglas que no cambian entre un uso y el siguiente: quién es, qué política sigue, qué tono usa.
Ejemplo: "Si no puedes evaluar un gasto con certeza, márcalo siempre como 'requiere revisión humana', sin excepción."
La información real del negocio que el modelo consulta para responder, en vez de depender de lo que "cree" saber.
Ejemplo: la política de viáticos vigente de la empresa, consultada directamente, en vez de escrita de nuevo cada vez dentro del prompt.
Lo que el sistema recuerda de interacciones anteriores, sin que alguien se lo tenga que repetir.
Ejemplo: recordar que un empleado en particular ya presentó gastos fuera de política dos veces este trimestre, sin que nadie tenga que buscar ese historial a mano.
Lo que el modelo puede hacer, además de generar texto: consultar una base de datos, actualizar un registro, mandar una notificación.
Ejemplo: "Marca automáticamente este gasto como aprobado en el sistema contable, en vez de solo decir que está aprobado."
El espacio de trabajo de un modelo de IA es limitado, igual que la memoria de trabajo de una persona: no puede tener presente todo a la vez, así que lo que decides meter ahí, y lo que decides dejar afuera, determina si el sistema funciona bien o se confunde.
Que el sistema guarde información fuera de la conversación actual, para usarla después, en vez de perderla en cuanto termina el intercambio.
Ejemplo: "Guarda el resultado de cada reporte de gastos revisado, para detectar más adelante si un mismo empleado repite el mismo tipo de gasto fuera de política."
Traer solo lo relevante al momento, no todo el historial disponible.
Ejemplo: "Al revisar el reporte de gastos de un empleado de ventas, trae solo la sección de la política que aplica a viáticos de campo, no el manual completo de cien páginas."
Resumir o descartar lo que ya no aporta, antes de que el espacio disponible se sature.
Ejemplo: "Si un empleado ha tenido diez intercambios de correo con soporte sobre el mismo problema, resume esos diez correos en tres líneas antes de escalar el caso a una persona."
Separar tareas distintas en espacios de trabajo distintos, para que no se mezclen entre sí.
Ejemplo: "Mantén la revisión de un reporte de gastos y la redacción de un correo al mismo empleado como dos procesos separados, para que una tarea no contamine el resultado de la otra."
Para ver los cuatro movimientos juntos, conviene seguir un solo caso de principio a fin: la revisión de reportes de gastos de viaje contra la política de viáticos de una empresa.
Cada vez que alguien necesita revisar un reporte, escribe: "Eres analista de control interno. Revisa este reporte de gastos contra la política de viáticos adjunta y determina el estatus de cada gasto. Devuélvelo como tabla: concepto de gasto, estatus, observación." Funciona bien, una vez, con un reporte a la vez. Pero cada persona que lo usa tiene que acordarse de adjuntar la política completa, escribir la instrucción de nuevo, y no queda ningún registro de lo que se revisó ayer ni la semana pasada.
La política de viáticos vive en un solo lugar que el sistema consulta directamente, así que nadie tiene que adjuntarla ni copiarla (dato propio, seleccionado solo en la parte relevante para el tipo de gasto).
Cada reporte revisado, y su resultado, se guarda automáticamente (memoria, escrita para uso futuro), de modo que si el mismo empleado presenta un gasto fuera de política por tercera vez en el trimestre, el sistema lo señala como patrón, no solo como un caso aislado.
Si un empleado tiene un historial largo de reportes ya revisados, el sistema resume ese historial en una línea de contexto en vez de cargarlo completo cada vez (compresión). Y la revisión de gastos corre como un proceso separado de, por ejemplo, la aprobación de vacaciones del mismo empleado, aunque ambos vivan en el mismo sistema de recursos humanos (aislamiento), para que una instrucción de un proceso no se filtre al otro.
El resultado no es solo "una respuesta mejor": es un proceso que corre solo, que mejora con el tiempo porque acumula memoria, y que ya no depende de que una persona escriba bien el prompt cada vez.
No todo trabajo necesita las cuatro piezas de context engineering. La mayoría de las tareas ocasionales se resuelven bien con un buen prompt. La señal para saber en qué punto está un caso concreto son estas tres preguntas.
Si es una tarea que se hace una sola vez, o de forma esporádica, un buen prompt basta. Si es algo que un equipo hace todos los días, empieza a justificar un sistema.
Si el modelo puede responder solo con lo que ya sabe de forma general, un prompt basta. Si necesita consultar una política interna, un historial de clientes, o datos que cambian todos los días, ya hace falta conectar información propia, no solo escribir mejor la petición.
Si basta con que alguien lea la respuesta y decida, un prompt basta. Si el resultado tiene que actualizar un registro, mandar una notificación, o encadenarse con otro paso automático, ya hace falta un sistema con herramientas, no solo una buena respuesta de texto.
Un caso con una respuesta "no" a las tres preguntas está listo para resolverse esta misma semana con un buen prompt: el Kit de Prompt Ejecutivo tiene la hoja para armarlo y probarlo. Un caso con una o más respuestas "sí" es candidato a diseñarse como sistema, y ahí es donde vale la pena invertir el tiempo de diseñarlo bien, en vez de forzarlo a vivir como un prompt cada vez más largo y frágil.
La diferencia entre estas dos partes no es de nivel de dificultad: es de naturaleza del problema. Escribir un buen prompt es una habilidad que se aprende en una tarde y se afina con la práctica. Diseñar un sistema es una decisión de negocio: vale la pena cuando el trabajo se repite lo suficiente, o pesa lo suficiente, como para justificar construirlo una vez y dejar que corra solo después.
La mayoría de las oportunidades reales de una empresa con la IA de hoy no están en encontrar el prompt perfecto. Están en identificar con precisión cuáles de sus procesos repetitivos ya cruzaron la línea de "esto ya no debería depender de que alguien escriba bien una petición cada vez", y empezar a diseñarlos como lo que realmente necesitan ser: no una herramienta que alguien usa de vez en cuando, sino un sistema que trabaja todos los días.
Es la práctica de escribir peticiones a un modelo de IA generativa que incluyan los cinco elementos que determinan el resultado: rol, contexto, instrucción, formato y criterio de calidad.
Es la disciplina de decidir qué información rodea a una petición de IA, de dónde sale y qué se hace con el resultado, en vez de depender solo de escribir mejor cada petición. Se construye con cuatro piezas: instrucciones fijas, datos propios, memoria y herramientas.
Cuando el trabajo se repite todos los días, necesita información propia del negocio para responder bien, o el resultado tiene que activar algo más allá de una respuesta de texto. Si las tres respuestas son "no", un buen prompt basta.
No. Ninguna de las dos partes de la guía requiere programar; cada concepto viene con un ejemplo de negocio que no depende de herramientas técnicas.
Un prompt suelto resuelve una petición puntual y depende de que alguien lo escriba bien cada vez. Un sistema conecta datos propios, memoria y herramientas para que el mismo trabajo corra de forma consistente sin que una persona lo repita manualmente.
Conversemos sobre el caso concreto y qué pieza de contexto le falta para dejar de depender de que alguien escriba bien el prompt cada vez.
CONVERSEMOS SOBRE TU CASO