Qué es un prompt y por qué importa cómo lo escribes

Un prompt es la instrucción que le das a un modelo de inteligencia artificial generativa —ChatGPT, Microsoft 365 Copilot, Gemini o cualquier otro— para decirle qué quieres que haga: qué tarea tiene que resolver, con qué información cuenta, en qué formato tiene que entregar el resultado y qué reglas debe respetar. No es una pregunta suelta ni una fórmula mágica: es el texto de entrada a partir del cual el modelo genera su respuesta, y como el modelo no dispone de más contexto que ese texto —y el resto de la conversación—, la forma en que lo redactas determina de manera directa la calidad de lo que obtienes. A esto se dedica el prompt engineering cuando se aborda de forma sistemática, y la guía oficial de OpenAI sobre prompt engineering lo resume así: «es el proceso de escribir instrucciones efectivas para un modelo, de forma que genere de manera consistente contenido que cumpla tus requisitos». No es programación, es el criterio para pedir las cosas de manera que la respuesta sirva a la primera.

De dónde viene la palabra y qué no es un prompt

«Prompt» viene del inglés «to prompt»: dar pie, incitar a que alguien haga o diga algo. En informática se usaba ya antes de la IA generativa para el símbolo que espera una orden en una línea de comandos —ese cursor parpadeante que «invita» a escribir algo—. Cuando llegaron los modelos de lenguaje, la palabra se trasladó de forma natural: el prompt es lo que le «da pie» al modelo para que responda.

Conviene aclarar también qué no es. Un prompt no es una búsqueda: no recupera un documento que ya existe en algún sitio, sino que genera un texto nuevo a partir de patrones aprendidos durante su entrenamiento, combinados con lo que le has escrito. Tampoco es código ni tiene una sintaxis fija con comandos exactos: se escribe en lenguaje natural, el mismo con el que hablarías con una persona, y admite matices, corrección y precisión progresiva. Esa flexibilidad es su ventaja y también la razón por la que «explícamelo mejor» no funciona como estrategia: cuanto más ambigua es la instrucción, más huecos tiene que rellenar el modelo por su cuenta, y los rellena aunque no tenga con qué.

Los elementos de un buen prompt

Un prompt bien construido no necesita ser largo, pero sí necesita cubrir unos cuantos elementos. Da igual que la herramienta sea una u otra: son los mismos en todas.

• Contexto. Qué situación rodea la tarea: para qué es el texto, quién lo va a leer, qué se sabe ya. Sin esto, el modelo asume un contexto genérico que casi nunca es el tuyo.
• Rol. Desde qué perspectiva quieres que responda: como si redactara para dirección, como si revisara un contrato, como si resumiera para alguien que no ha leído el original. El rol no cambia lo que el modelo «sabe», pero sí cambia el registro, el nivel de detalle y qué da por sobreentendido.
• Tarea exacta. Qué tiene que hacer, dicho sin rodeos: resumir, comparar, reescribir, extraer, ordenar. Una instrucción que mezcla dos tareas en una frase ambigua suele producir un resultado que no hace bien ninguna de las dos.
• Formato de salida. Cómo tiene que entregarse el resultado: una lista, una tabla, un número máximo de líneas, un correo con una estructura concreta. Sin esto, el modelo elige un formato por su cuenta, y rara vez coincide con el que necesitas pegar en otro sitio.
• Qué hacer si falta información. La instrucción más rentable de todas, y la que casi nadie escribe: pedirle explícitamente que diga «esto no aparece» en lugar de inventarlo. Reduce mucho el relleno, aunque no lo elimina del todo.
• Un ejemplo, si lo tienes. Un caso resuelto de la misma tarea —una respuesta anterior que te gustó, un formato ya usado— vale más que dos párrafos de instrucciones sueltas.

Estos seis elementos son el contenido de fondo del prompt engineering: no hace falta memorizar una fórmula fija, sino saber qué preguntarte antes de escribir la instrucción. Es justo lo que se trabaja, con ejercicios sobre tareas de oficina reales, en el curso de prompt engineering.

La estructura que uso cuando la tarea importa

Los seis elementos de arriba bastan para el día a día. Cuando la tarea es importante —un documento que va a dirección, un análisis del que van a salir decisiones, cualquier cosa que luego cueste corregir— utilizo una estructura más larga, y en este orden:

1. Contexto real. No «somos una empresa de servicios», sino la situación concreta: qué ha pasado, qué hay ya escrito, qué se decidió antes.
2. Objetivo. Qué tiene que conseguir el resultado, no solo qué tiene que ser. «Que dirección pueda decidir si seguimos» es un objetivo; «un informe» es un formato.
3. Restricciones. Extensión, tono, qué no se puede afirmar, qué conviene no mencionar.
4. Fuentes que puede usar. Qué material le entrego y si puede salirse de ahí o no. Este punto es el que más reduce el relleno inventado.
5. Entregable exacto. Qué me tiene que devolver, en qué formato y con qué partes.
6. Criterios de aceptación. Cómo sabré yo que está bien. Escribirlos obliga a pensarlo antes, que es la mitad del trabajo.
7. Comprobaciones antes de terminar. Qué debe revisar el propio modelo antes de responder: que los datos salgan de las fuentes que le di, que no falte ninguna parte, que cumpla la extensión.

No hay que usar los siete siempre. Pero cuando un resultado sale mal, casi siempre es porque falta uno de ellos, y saber cuál acorta mucho la segunda vuelta.

El contraejemplo que uso para enseñar lo contrario es «hazme una estrategia de IA para mi empresa». Parece una petición perfectamente válida, y por eso funciona tan bien como ejemplo: obliga al modelo a inventarse el contexto entero —qué empresa, qué tamaño, qué herramientas ya tenéis, qué problema hay que resolver— y lo que devuelve es una respuesta correcta en apariencia que serviría igual para cualquier otra empresa. No es que el modelo falle: es que no se le ha dado nada con lo que trabajar. Poner ese prompt al lado de uno con los siete puntos de arriba explica en treinta segundos algo que en teoría cuesta media hora.

Prompt flojo frente a prompt mejorado: tres tareas de oficina

La teoría se entiende mejor con ejemplos comparados. Los tres que siguen son tareas habituales en cualquier despacho; en ninguno se muestra la respuesta de una herramienta concreta, porque lo que importa no es lo que contestó tal modelo un día dado, sino el patrón de instrucción que cambia el resultado.

Redactar un correo

Prompt flojo:

«Escríbeme un correo para el cliente sobre el retraso del pedido.»

Prompt mejorado:

«Redacta un correo para un cliente que lleva dos semanas esperando un pedido. Tono profesional pero cercano, sin fórmulas rebuscadas, máximo diez líneas. Explica el motivo del retraso [descríbelo aquí] y la nueva fecha prevista [indícala aquí]. No prometas ninguna compensación ni fecha que no te haya dado yo.»

Qué cambia: la versión mejorada fija a quién va dirigido, el tono, la extensión máxima y, sobre todo, qué datos concretos puede usar y cuáles no puede inventarse. La versión floja deja todo eso a criterio del modelo, que tiene que decidir por su cuenta el tono, la longitud y —el riesgo real— qué motivo y qué fecha poner si no se los has dado.

Resumir un documento

Prompt flojo:

«Resume este documento.»

Prompt mejorado:

«Resume este documento para alguien que tiene que decidir si aprobarlo, sin haberlo leído antes. Máximo doce líneas, centradas en plazos, coste y riesgos. Si algún dato no aparece en el texto, dilo en lugar de deducirlo.»

Qué cambia: un resumen sin más instrucciones puede ser fiel al documento y aun así inútil, porque el modelo decide qué es relevante sin saber para qué lo necesitas. Fijar el destinatario —alguien que decide, no alguien que ya conoce el tema— y los tres focos concretos —plazos, coste, riesgos— hace que el resumen sirva para tomar la decisión, no solo para ahorrar lectura.

Comparar dos propuestas

Prompt flojo:

«Compárame estas dos propuestas.»

Prompt mejorado:

«Te paso dos propuestas para el mismo servicio. Compáralas solo en lo que afecta a la decisión: precio, plazo de entrega y condiciones de cancelación. Ignora las diferencias de redacción o de formato que no cambien el fondo. Entrégamelo en una tabla.»

Qué cambia: sin acotar el criterio de comparación, el modelo puede señalar diferencias de redacción, de orden o de estilo que no aportan nada a quien tiene que decidir. Decirle qué cuenta como diferencia relevante —y pedir el resultado en tabla, no en párrafos— convierte una lista genérica en un documento que se puede usar directamente en una reunión.

Los tres ejemplos comparten la misma lección: la mejora no está en usar palabras más sofisticadas, está en decidir de antemano qué información necesita el modelo para no tener que suponerla.

Tres errores frecuentes al escribir un prompt

Los tres ejemplos anteriores muestran el patrón que funciona; estos son los fallos que más veces arruinan un prompt que, a primera vista, parecía razonable.

Antes de los tres, el error de partida: tratar a ChatGPT o a Claude como si fueran Google. Una frase corta, sin contexto, sin explicar para quién es la respuesta, qué restricciones hay ni cómo sabremos si el resultado es bueno. Es el error más común que veo al empezar una formación, y no es cuestión de nivel técnico: es que la costumbre de doce años escribiendo en un buscador pesa mucho. El momento en que la cosa cambia —el «clic»— llega cuando la persona deja de buscar la frase mágica y empieza a dar contexto, criterios de aceptación, ejemplos y un formato de salida. Ahí ve que el mismo modelo, con la misma suscripción, pasa de dar algo genérico a producir algo que realmente puede usar.

• Pedir varias cosas a la vez sin separarlas. «Resume esto, tradúcelo y hazme también una lista de tareas» en una sola frase suele producir un resultado que cumple las tres cosas a medias. Separar en pasos, o repetir la instrucción una vez completada la anterior, da mejor resultado que meterlo todo junto.
• No decir para quién es el texto ni para qué sirve. El mismo resumen cambia por completo según sea para informar a dirección o para que un compañero retome una tarea donde la dejó. Sin ese dato, el modelo elige un destinatario genérico que rara vez coincide con el real.
• Dar por hecho que el modelo recuerda algo que no está escrito en esa conversación. Cada chat parte de lo que hay escrito en él: si abres uno nuevo, o si el dato se mencionó hace muchos mensajes, el modelo no lo «recuerda» salvo que vuelva a aparecer en el texto que tiene delante. Repetir el dato importante sale más barato que descubrir a mitad de respuesta que se ha perdido por el camino.

Esto no es solo teoría de curso: lo compruebo cada semana usando agentes de código (Claude Code, Codex) para tareas reales de desarrollo y automatización, no solo para redactar texto. Un prompt corto del tipo «arregla esto» les hace interpretar mal en qué fase está el proyecto, o tocar archivos que no tocan; uno que fija el estado actual, el objetivo, qué no hay que romper y qué cuenta como terminado, cambia por completo el resultado. Es el mismo patrón de aquí arriba —contexto, tarea, límites—, aplicado a código en lugar de a un correo o un informe.

No es una habilidad de una sola herramienta

Todo lo anterior vale igual si trabajas en ChatGPT, en Microsoft 365 Copilot, en Gemini o en la herramienta con IA generativa que tu sector incorpore mañana. Lo que cambia entre una y otra es dónde vive la herramienta y a qué información tiene acceso —Copilot, por ejemplo, puede apoyarse en documentos de tu propio Microsoft 365 sin que se los pegues—, pero el criterio para escribir la instrucción es el mismo en todas: contexto, rol, tarea, formato y qué hacer si falta un dato.

Por eso el prompt engineering, entendido como habilidad, no caduca cuando cambia la interfaz de una aplicación ni cuando sale una versión nueva de un modelo. Es la parte del trabajo con IA que no depende de la herramienta, y es también la razón por la que aprenderlo de forma genérica —no atado a un botón concreto de una pantalla concreta— rinde más a largo plazo. Si tu equipo trabaja sobre todo con ChatGPT, el curso de ChatGPT para empresas pone estos mismos patrones en práctica sobre esa herramienta en concreto, con vuestros propios documentos.

Aprenderlo no es memorizar una fórmula

Ningún prompt sale perfecto a la primera, ni falta que hace. Lo habitual es escribir una instrucción razonable, mirar el resultado y ajustar lo que falló: falta un dato, sobra un párrafo, el tono no es el que tocaba. Esa segunda vuelta —afinar en lugar de descartar y volver a empezar de cero— es donde más se nota la diferencia entre quien lleva un tiempo trabajando así y quien empieza.

Y hay un paso que no es opcional, escriba quien escriba el prompt y use la herramienta que use: revisar el resultado antes de darlo por bueno. Cifras, fechas, nombres y compromisos concretos son justo lo que un modelo de lenguaje puede presentar con total seguridad estando equivocado, porque su trabajo es generar el texto más plausible, no comprobar hechos. Un buen prompt reduce ese riesgo —pedir explícitamente que no invente ayuda mucho— pero no lo elimina, así que la revisión sigue siendo tuya.

Dónde se practica esto en serio

Leer sobre los elementos de un prompt sirve para entender el concepto; escribirlos de verdad, sobre documentos reales de tu empresa, es otra cosa. Eso es lo que se trabaja en el curso de prompt engineering: un taller centrado en el patrón de instrucción, aplicable a cualquier herramienta de IA generativa, pensado para equipos administrativos, comerciales y de gestión. Si el punto de partida de tu equipo es aprender una herramienta concreta desde cero, el curso de ChatGPT para empresas es la puerta de entrada más directa, y ambos forman parte del itinerario de formación en IA para empresas.

Si no tienes claro por dónde empezar, reserva media hora y lo vemos con el trabajo real de tu equipo, no con ejemplos genéricos.