Ya explicamos en qué es el prompt engineering en qué consiste diseñar bien las instrucciones que recibe un modelo de IA, y por qué esa disciplina es una de las formas más rápidas y baratas de mejorar los resultados de un proyecto de IA. Lo que no cubrimos allí, y es igual de importante, es el momento en que ese trabajo, por muy bien hecho que esté, deja de ser suficiente. Muchas empresas gastan semanas reescribiendo el mismo prompt una y otra vez, convencidas de que la solución está en encontrar la formulación perfecta, cuando el problema real ya no tiene que ver con cómo está redactada la instrucción.
Este artículo trata precisamente de eso: cómo distinguir un problema de prompt (se arregla mejorando el texto de la instrucción) de un problema estructural (necesita algo distinto al prompt, por bien escrito que esté).
La señal más clara: el prompt "perfecto" sigue fallando en lo mismo
Si llevas semanas ajustando un prompt y sigue fallando de forma consistente en el mismo tipo de caso, no es un problema de redacción. Un prompt mal diseñado suele mejorar de forma visible cuando lo perfeccionas: las respuestas se vuelven más precisas, más consistentes, más alineadas con lo que pedías. Si en cambio llevas varias iteraciones sin que la mejora se note, o mejora una cosa y empeora otra sin que consigas estabilizarlo, es una señal de que el techo no está en el texto de la instrucción, sino en algo que el prompt, por definición, no puede resolver.
Primera causa estructural: falta de información, no falta de instrucciones
El error más frecuente es pedirle al modelo que responda con precisión sobre datos que, sencillamente, no tiene. Ningún prompt, por muy detallado que sea, puede hacer que un modelo conozca el estado real de un pedido en tu sistema de gestión, el histórico de un cliente concreto o el precio actualizado de un producto que cambió ayer. Si tu caso de uso necesita respuestas basadas en información que vive fuera del modelo y que cambia con el tiempo, el camino no es seguir puliendo el prompt: es conectar el modelo a esa fuente de datos mediante recuperación de información, la técnica que se conoce como RAG y que explicamos con más detalle en qué es RAG en inteligencia artificial.
Segunda causa estructural: tareas que requieren acción, no solo texto
Un prompt, por definición, hace que el modelo genere una respuesta en forma de texto. Si lo que tu negocio necesita es que el sistema haga algo (reservar una cita en un calendario, actualizar un registro en el CRM, enviar un correo real, consultar el estado de un envío en tiempo real), ninguna instrucción de texto por sí sola puede ejecutar esas acciones. Esto requiere dotar al modelo de herramientas que pueda invocar (lo que se conoce como function calling o uso de herramientas), convirtiéndolo en parte de un agente de IA con capacidad de actuar, no solo de responder. Si notas que estás pidiéndole al modelo, con distintas formulaciones, que "haga" algo en lugar de "diga" algo, ese es el síntoma.
Tercera causa estructural: un patrón de comportamiento muy específico y estable
Hay casos en los que el modelo entiende perfectamente la instrucción, pero su comportamiento por defecto tira hacia un estilo, un formato o un criterio distinto al que necesitas, y ese sesgo es tan persistente que ni las instrucciones más detalladas ni los ejemplos dentro del propio prompt consiguen corregirlo del todo. Esto suele ocurrir con jerga muy específica de un sector técnico, o con un tono de marca muy particular que hay que replicar de forma exacta en miles de interacciones. Aquí es donde entra en juego el fine-tuning, un proceso distinto al prompt engineering que ajusta el propio modelo en lugar de las instrucciones que recibe. En fine-tuning vs prompt engineering explicamos cuándo tiene sentido dar ese paso adicional, que conviene reservar para cuando de verdad se han agotado las otras vías, porque su coste y su complejidad son mayores.
Cuarta causa estructural: el modelo necesita recordar entre conversaciones
Un prompt vive dentro de una conversación concreta; cuando esa conversación termina, lo que el modelo "aprendió" en ella desaparece. Si tu caso de uso necesita que el sistema recuerde preferencias, historial o decisiones de un cliente entre sesiones distintas (no dentro de la misma conversación, sino de una semana a la siguiente), eso no se resuelve alargando el prompt cada vez con todo el historial: se resuelve con un sistema de memoria externa que guarda y recupera esa información cuando hace falta, sin depender de que el usuario o el propio prompt la repitan cada vez.
Cómo diagnosticar cuál de estas causas es la tuya
Antes de asumir que necesitas RAG, herramientas, fine-tuning o memoria externa, conviene hacerse una pregunta simple para cada fallo que detectes: ¿el modelo falla porque no sabe algo (falta de datos), porque no puede hacer algo (falta de acción), porque tiende a comportarse de una forma que no quiero de manera persistente (falta de ajuste de comportamiento), o porque no se acuerda de algo de una sesión a otra (falta de memoria)? Cada una de estas cuatro preguntas apunta a una solución distinta, y ninguna de ellas se resuelve solo con un prompt mejor escrito, por mucho tiempo que le dediques.
El error de saltar directamente a la solución más cara
Un patrón que vemos con frecuencia es el contrario al de insistir demasiado con el prompt: empresas que, en cuanto detectan una limitación, asumen que necesitan fine-tuning porque suena a la solución "más avanzada", sin haber agotado antes las alternativas más rápidas y baratas como el RAG o el uso de herramientas. El orden razonable casi siempre es: primero un buen prompt, después conectar datos reales si el problema es de información, después añadir herramientas si el problema es de acción, y solo al final considerar el fine-tuning si el problema persiste siendo de comportamiento estable y específico. Saltarse este orden suele significar pagar mucho más de lo necesario por un problema que se podía resolver de forma más sencilla.
Conclusión
Cuando un cliente nos dice que "el prompt no funciona" por mucho que lo cambian, lo primero que hacemos es clasificar el fallo según las cuatro causas anteriores, en lugar de seguir iterando sobre el texto de la instrucción. En la mayoría de los casos, el problema no está en cómo está escrito el prompt, sino en que le falta al modelo acceso a datos, capacidad de acción o memoria entre sesiones, y una vez identificado el origen real, la solución suele ser más rápida y más barata de lo que parecía al principio.
Si llevas tiempo ajustando un prompt sin conseguir que funcione de forma consistente, es muy probable que el problema no esté ahí. Reserva una primera reunión y te ayudamos a identificar la causa real antes de seguir invirtiendo tiempo en la dirección equivocada.