Alfabetización en IA - Prompt engineering aplicado: 7 patrones para el equipo
En el capítulo anterior vimos que el AI Act obliga a documentar qué formación ha recibido tu equipo sobre IA. Aquí llegamos a la pregunta práctica: ¿qué le enseño exactamente?
No se trata de que todos aprendan a ajustar temperaturas de modelo o entiendan backpropagation. Se trata de que quienes usan IA en su trabajo diario sepan cómo hablar con ella para sacar resultados decentes sin que parezca que se comunican con un chatbot emborrachado.
Eso es prompt engineering operativo. No es una especialidad. Es un oficio que cualquiera en tu equipo puede aprender en un par de sesiones si te enfocas en lo que importa.
Los siete patrones que sigue son exactamente lo que enseño en las sesiones de formación que hago con equipos. Cada uno tiene un antes y un después usando casos de verdad. Verás que no es difícil. Es cuestión de hábito.
Los tres pilares que están detrás de todo
Antes de entrar en patrones, hay que entender qué hace que un prompt funcione o fracase. Tres cosas.
Contexto. El modelo es un sistema sin memoria a largo plazo. Si quieres que entienda lo que le pides, tienes que decirle quién es en esta conversación, qué información relevante existe y en qué situación estamos. Un prompt sin contexto es como pedirle a alguien que resuelva un problema sin darle los datos.
Expectativa clara. El modelo es literal. Si le pides "mejora este texto", puede mejorar la gramática, el tono, la estructura o la extensión. No sabe cuál de esas cosas es importante para ti. Si le pides "mejora este texto para que sea más breve manteniendo los datos concretos", ya sabe qué busca.
Verificación. El modelo alucinaciona. Genera texto coherente sobre cosas que no sabe. Si le pides que genere una cifra, puede sonar cierta cuando es inventada. Si le pides que resuma un documento, puede resumir párrafos que no están en el documento. Quien usa IA tiene que validar la salida.
Ahora, los patrones.
Patrón 1: Rol
Decirle al modelo qué rol asumir cambia drásticamente cómo estructura sus respuestas.
Antes:
Redacta un email a un cliente que duda entre nuestro software y el de nuestro principal competidor.
Respuesta esperada: sí, pero genérica. Sonará corporativa, larga, con todas las características listadas.
Después:
Eres el comercial senior de esta empresa. Acabas de tener una videollamada con este cliente y te ha dicho que está dudando entre nuestro producto y el de [competidor]. Tiene especial preocupación por el tiempo de implementación. Redacta un email de seguimiento informal pero profesional que:
1. Reconoce su preocupación.
2. Aclara cuánto tiempo real toma nuestra implementación.
3. Invita a una demo de 20 minutos con nuestro equipo técnico.
Máximo 150 palabras. Tono de persona que entiende el negocio, no de vendedor genérico.
Resultado: el email sale más natural, menos "según nuestros estudios", más "te entiendo, aquí está la realidad".
Por qué funciona: cuando asignas un rol, el modelo usa patrones de lenguaje que ha visto de ese tipo de persona. Un comercial habla diferente a un especialista técnico. El rol te da consistencia sin que tengas que describir cada detalle.
Caso real: un equipo de marketing en Madrid que usa este patrón para generar sugerencias de CTAs obtiene respuestas más directas que antes de especificar "eres un copywriter que sabe de conversiones".
Patrón 2: Formato de salida
Decir explícitamente cómo quieres que te devuelva la respuesta evita reformatear después.
Antes:
Analiza este email de un cliente insatisfecho y dame los puntos clave.
Respuesta esperada: párrafos, quizá numerados, tal vez largos. Tienes que leerlo todo para extraer lo que importa.
Después:
Analiza este email de un cliente insatisfecho.
Devuelve tu análisis en este formato exactamente:
Problema principal (una frase):
Impacto reportado (qué dice que se rompió o no funciona):
Tono del cliente (enojado, decepcionado, neutral):
Urgencia (alta/media/baja, y por qué):
Sé muy conciso. Máximo una línea por sección.
Resultado: una estructura que puedes copiar directamente a tu CRM, sin pasos intermedios.
Por qué funciona: el modelo entiende formatos explícitos mejor que instrucciones vagas. Si dices "dame un resumen", cada modelo y cada ocasión da algo diferente. Si dices "dame tres puntos separados por guion, cada uno bajo una línea", el resultado es predecible.
Caso real: un equipo de soporte en Valencia que clasifica tickets con IA usa este patrón. Pasaron de revisar cada respuesta para extraer la información a copiar directamente.
Patrón 3: Few-shot, ejemplos concretos
Mostrar ejemplos de qué es "bien" hace que el modelo entienda mucho mejor qué esperas.
Antes:
Redacta un mensaje corto de LinkedIn para promocionar nuestro webinar del próximo martes. Hazlo atractivo.
Respuesta esperada: algo que probablemente funcione, pero no es lo que querías. "Atractivo" es subjetivo.
Después:
Redacta un mensaje corto de LinkedIn para promocionar nuestro webinar del próximo martes.
Aquí hay dos ejemplos de tono y estructura que queremos:
EJEMPLO 1 (funciona bien):
"Dentro de 3 días: alucinaciones de ChatGPT. Cómo ocurren, cómo detectarlas, qué hacer al respecto. Martes 10:30, 25 minutos sin relleno. Reserva plaza: [link]"
EJEMPLO 2 (también funciona):
"Si alguien en tu equipo ha visto que ChatGPT genera datos inventados y no sabía cómo evitarlo: martes te lo explicamos. Webinar 25 min, live, sin grabación posterior. 10:30. [link]"
Ahora redacta uno similar para NUESTRO webinar sobre [tema], pero con tu voz. Máximo dos líneas.
Resultado: el modelo entiende que quieres frases cortas, acciones concretas, números reales, no adjetivos flotantes.
Por qué funciona: los ejemplos concretos funcionan mejor que instrucciones abstractas. El modelo ve el patrón de lo que hiciste bien y lo replica.
Caso real: un equipo de marketing en Madrid que genera títulos de blog usa este patrón. Pasaron de 15 títulos generados de los que salvaban 2 o 3 a que 13 de 15 sean publicables.
Patrón 4: Delimitadores para separar contexto de tarea
Usar marcadores visuales (comillas, líneas, etiquetas XML, bloques de código) para que el modelo entienda qué es "contexto" y qué es "lo que me importa hacer".
Antes:
Quiero que revises este párrafo de una propuesta comercial que escribimos para un cliente de logística. El párrafo habla de nuestras capacidades técnicas. Mejóralo para que suene menos como ingenieros y más como gente que entiende el negocio de logística.
Párrafo:
"Nuestro sistema utiliza algoritmos de optimización de rutas basados en machine learning para garantizar la máxima eficiencia en la asignación de carga a vehículos, minimizando el costo de combustible y maximizando la utilización del espacio."
Resultado: funciona, pero el modelo podría perder de vista qué parte es "el contexto" y qué es "lo que tiene que mejorar".
Después:
CONTEXTO:
Estás revisando una propuesta comercial para una empresa de logística. El cliente cuida mucho que sus proveedores entiendan la industria, no solo la tecnología.
PÁRRAFO A MEJORAR:
---
Nuestro sistema utiliza algoritmos de optimización de rutas basados en machine learning para garantizar la máxima eficiencia en la asignación de carga a vehículos, minimizando el costo de combustible y maximizando la utilización del espacio.
---
INSTRUCCIÓN:
Reescribe este párrafo para que suene como si quien lo escribe entiende la presión de costos y plazos en logística, no solo tecnología. Mantén los beneficios reales (reducción de combustible, mejor carga), pero explícalos sin jerga.
Resultado: el modelo entiende claramente qué información es background y qué es lo que tiene que transformar.
Por qué funciona: el modelo es literal en cómo procesa texto. Si usas delimitadores (o sea, líneas visuales, etiquetas, bloques), entiende mejor las fronteras. Es como subrayar lo importante en un examen.
Caso real: un equipo de propuestas comerciales en Barcelona que usa este patrón reduce el número de rondas de revisión a una.
Patrón 5: Cadena de razonamiento paso a paso
Pedir al modelo que "piense en voz alta" antes de responder genera resultados más confiables.
Antes:
¿Cuál es la mejor estrategia para que nuestro equipo de ventas aumente el pipeline en Q4?
Respuesta esperada: algo que suena bien, pero es genérico. Puede estar inventado. No ves cómo lo pensó.
Después:
¿Cuál es la mejor estrategia para que nuestro equipo de ventas aumente el pipeline en Q4?
Importante: antes de responder, piensa paso a paso.
1. ¿Cuáles son los tres factores que limitan el pipeline en Q4 en empresas de [tu sector]?
2. ¿Cuál de esos tres nuestro equipo puede controlar directamente?
3. De ese factor, ¿cuál es el apalancamiento (el cambio pequeño que genera impacto grande)?
4. Ahora: ¿cuál es la estrategia concreta en tres pasos?
Responde pensando en voz alta. Luego da la estrategia final en una frase.
Resultado: no solo ves la respuesta, ves cómo llegó a ella. Puedes validar cada paso. Si uno es falso, lo ves.
Por qué funciona: el modelo tiende a "correr" hacia la respuesta sin validar pasos intermedios. Cuando le pides que piense en voz alta, puede detectar sus propios errores (o al menos, tú ves dónde están).
Caso real: un director general de una agencia de marketing que usa este patrón para decisiones estratégicas dice que obtiene mejores respuestas que cuando pide "qué deberíamos hacer".
Patrón 6: Verificación cruzada
Pedir al modelo que revise su propia respuesta antes de entregártela.
Antes:
Extrae las palabras clave SEO principales de este artículo de blog sobre IA en pymes.
[artículo de 2.500 palabras]
Respuesta esperada: una lista de palabras clave. Algunas correctas, algunas que no están en el texto.
Después:
Extrae las palabras clave SEO principales de este artículo de blog sobre IA en pymes.
[artículo de 2.500 palabras]
IMPORTANTE: Una vez que hayas extraído las palabras clave, verifica cada una. Para cada palabra clave, contesta:
- ¿Esta palabra o frase aparece explícitamente en el artículo? (sí/no)
- ¿Es tema central o menciona de pasada? (central/pasada)
- Descarta las palabras que no sean centrales.
Devuelve solo las palabras clave que pasaron esta verificación. Junto a cada una, entre paréntesis, indica cuántas veces aparece.
Resultado: la lista de palabras clave es más confiable porque el modelo las validó contra el texto real.
Por qué funciona: el modelo tiende a alucinar. Si le pides que verifique su propia respuesta, reduce alucinaciones porque tiene que "buscar prueba" en el contenido original.
Caso real: un equipo de SEO en Madrid que usa este patrón detectó que sus listas de palabras clave bajaron un 30% en cantidad pero subieron un 90% en precisión.
Patrón 7: Iteración estructurada
No pidas una respuesta perfecta a la primera. Pide una versión, y luego mejoras concretas.
Antes:
Redacta un comunicado de prensa sobre la nueva integración con Salesforce.
Respuesta esperada: un comunicado. Probablemente genérico. Si no te gusta, pides "hazlo más conciso" o "suena corporativo", y eso es vago.
Después:
Redacta un primer borrador de un comunicado de prensa sobre nuestra nueva integración con Salesforce. No busco perfección en este primer paso, busco que captures los tres puntos clave:
1. Quién se beneficia (equipos de ventas y CRM que querían automatización).
2. Qué cambia (ahora pueden sincronizar datos sin exportar manualmente).
3. Cuándo está disponible (el 15 de octubre).
Máximo 200 palabras. Tono profesional pero directo, no "nos complace anunciar".
Resultado: primer borrador que captura la esencia.
Luego:
Este borrador es bueno. Ahora hazme una segunda versión donde:
- Reemplazas "nos complace anunciar" por algo más real.
- Añades un número: ¿cuánto tiempo ahorran los usuarios por semana?
- Quita la frase que empieza con "En el contexto de una transformación digital".
Resultado: el modelo sabe exactamente qué cambiar porque le diste instrucciones concretas, no retroalimentación vaga.
Por qué funciona: la iteración estructurada es más eficiente que pedir perfección de entrada. El modelo entiende feedback específico. Si dices "mejóralo", no sabe qué mejorar. Si dices "cambia X por Y y quita Z", lo hace bien.
Caso real: un equipo de redacción en Barcelona que antes pasaba tres rondas de revisión con el modelo ahora lo hace en dos, y la calidad es mejor.
Errores típicos al enseñar esto al equipo
Cuando introduces estos patrones en tu empresa, hay trampas comunes.
Error 1: Asumir que todos lo cogen a la primera.
Algunos miembros del equipo van a decir "esto es demasiado, ¿para qué escribir un rol si puedo escribir directamente?". Déjales un ejemplo de antes y después con su trabajo. Eso suele cerrar la discusión.
Error 2: Copiar exactamente tus prompts.
Un comercial copia exactamente el prompt que escribiste para generador de emails. Pero luego lo usa para un contexto diferente (un email a un lead que aún no es cliente, no uno de seguimiento después de una demo). El resultado suena fuera de lugar.
Solución: enséñale la estructura, no la receta exacta. El patrón es "rol + contexto específico". Él debe adaptar el contexto a su situación.
Error 3: No validar nunca.
Le pides al equipo que use patrones de cadena de razonamiento. Lo hacen. Y luego copian la respuesta sin verificar si el modelo alucina algún número o dato.
Solución: incluir en el entrenamiento un checklist: "Antes de copiar una respuesta donde el modelo da un número, un nombre o una cifra, verifica que sea cierto."
Error 4: Confundir "mejorado" con "correcto".
Alguien usa el patrón de verificación cruzada. El modelo dice "aquí están las palabras clave, validadas". El empleado cree que es verdad porque dice "validadas".
Solución: validación del modelo no es lo mismo que validación humana. El patrón de verificación cruzada reduce errores, no los elimina.
Error 5: Usar estos patrones para cosas que no necesitan IA.
"Voy a pedir un prompt engineering estructurado para que me haga un email a un cliente que ya conozco bien y escribo correos similares cada semana."
Si lo puedes escribir en dos minutos sin pensar, probablemente no necesites IA. Los patrones son para situaciones donde el modelo realmente te ahorra tiempo o te saca de un bloqueo.
Siguientes pasos
Este capítulo cubre prompt engineering aplicado. Los patrones aquí no requieren que nadie sea técnico. Funcionan en ChatGPT, Gemini, Claude o cualquier LLM.
El próximo capítulo trata sobre shadow AI y auditoría. Eso es: qué herramientas están usando en tu empresa sin que oficialmente las hayas autorizado, cómo detectarlas y cómo hacer que una política interna de IA sea operativa sin ahogar la innovación.
Si necesitas que alguien de tu equipo reciba formación sobre estos patrones y cómo aplicarlos a su rol específico, puedes reservar una sesión de una hora donde vemos cómo trabajan realmente, dónde está el bloqueo y cómo los patrones resuelven ese bloqueo.