Prompt engineering para agentes de voz con IA: buenas prácticas y ejemplos

Dos empresas despliegan agentes de voz con IA basados exactamente en el mismo modelo de lenguaje. Uno da respuestas incoherentes, a veces contradice su propia política y no sabe bien cuándo pasar la llamada a una persona. El otro concierta citas de forma fiable, cumple las normas de la empresa sin fallar y pasa la llamada a una persona sin fricciones en cuanto una conversación se sale de lo que le corresponde.

El mismo modelo. Las mismas capacidades de base. La diferencia está en el diseño del prompt, no en la propia IA. Esta distinción importa más de lo que creen la mayoría de los compradores, porque significa que la calidad de un agente de voz con IA depende menos del LLM que hay detrás y más de lo bien que alguien haya pensado qué debe decir, preguntar y hacer.

¿Qué es el prompt engineering para agentes de voz con IA?

En este contexto, el prompt engineering es el proceso de redactar las instrucciones que determinan cómo responde un agente de voz con IA, qué preguntas hace, qué reglas de negocio sigue, cómo gestiona las situaciones para las que no se le preparó de forma explícita y cuándo pasa la llamada a una persona.

Una versión simplificada de dónde se sitúa el prompt en la cadena de procesamiento:

El prompt de sistema es la capa que convierte un modelo de lenguaje con capacidades genéricas en algo que se comporta como tu empresa, y no en un asistente genérico que simplemente atiende tus llamadas.

Los prompts de voz y los de chatbot no son intercambiables, aunque se basen en técnicas parecidas. Un prompt escrito para un chatbot de texto y trasladado sin cambios a un agente de voz suele producir respuestas forzadas y demasiado largas, que suenan poco naturales en voz alta.

En qué se diferencian los prompts de voz de los prompts de chatbot

Las conversaciones por texto toleran cosas que las conversaciones habladas no toleran. Un chatbot puede soltar un párrafo de cinco frases y el usuario simplemente se desplaza y lo lee a su ritmo. Un agente de voz que dice lo mismo en voz alta parece que le esté leyendo a alguien un documento de políticas.

Los prompts de voz tienen que tener en cuenta de forma específica:

• Respuestas más cortas: los monólogos largos hacen que quien llama pierda la atención enseguida
• Gestión de interrupciones: el prompt tiene que definir qué pasa si quien llama habla por encima del agente en mitad de una respuesta
• Confirmación: repetir los datos clave (“entonces, el martes a las dos de la tarde”) importa más en una llamada, porque no hay ningún texto al que volver a echar un vistazo
• Ritmo natural: pausas y frases que suenen a conversación, no a un documento leído en voz alta
• Memoria de la conversación: hacer referencia a lo que se dijo dos turnos antes sin que quien llama tenga que repetirlo

Con una comparación rápida la diferencia salta a la vista. Una respuesta al estilo de un chat podría ser: “Puedo ayudarte a cambiar tu cita. Ten en cuenta que nuestra política de cancelación exige un preaviso de 24 horas y que los cambios con menos de 24 horas de antelación pueden tener un cargo de 15 dólares. ¿A qué fecha te gustaría cambiar tu cita?”. Dicho en voz alta, es mucho que asimilar de una sola vez. Una versión adaptada a la voz lo divide: “Claro, te ayudo con eso. Para que lo sepas, cambiarla con menos de 24 horas de antelación tiene un pequeño cargo. ¿Qué día te viene bien?”.

Los elementos básicos de un prompt eficaz

Un prompt bien estructurado para un agente de voz suele incluir, más o menos por orden de importancia:

1. Definición del rol: quién es el agente y a qué empresa representa
2. Objetivos de negocio: cómo es de verdad una llamada que ha salido bien
3. Tono de voz: formal, informal, cercano, ágil, en línea con la marca
4. Políticas de la empresa: las normas que el agente nunca debe contradecir
5. Acceso al conocimiento: cuándo y cómo buscar en la base de conocimiento
6. Uso de herramientas: qué acciones puede realizar el agente, y cuándo
7. Reglas de escalado: las condiciones concretas en las que se pasa la llamada a una persona
8. Formato de las respuestas: ritmo, extensión y cuándo confirmar los datos
9. Gestión de errores: qué decir cuando algo sale mal o el agente no sabe la respuesta

Piensa en ellos como capas, no como piezas intercambiables. El rol y los objetivos de negocio definen el marco; las políticas y las reglas de escalado ponen los límites; el tono y el formato definen cómo suena realmente; y la gestión de errores es lo que evita que una llamada se venga abajo cuando ocurre algo inesperado.

Cómo diseñar prompts para distintos casos de uso

Los mismos elementos básicos pesan de forma distinta según para qué sirva realmente el agente:

Un prompt de atención al cliente que dedica la mayor parte de sus instrucciones a preguntas para conocer necesidades está resolviendo el problema equivocado; un prompt de cualificación de leads cargado de lenguaje empático y con poca captura de datos estructurados dará lugar a conversaciones cálidas que, en realidad, no aportan nada útil al CRM. Ajustar el peso del prompt al objetivo de negocio real importa más que cubrir por igual todas las categorías de instrucciones posibles.

Cómo funcionan juntos la base de conocimiento y los prompts

Conviene ser preciso con una distinción que se difumina constantemente: el prompt le dice a la IA cómo comportarse. La base de conocimiento le dice qué debe saber. Confundir las dos cosas da lugar a prompts llenos de datos propios de la empresa que deberían estar en un documento, lo que hincha el prompt y lo hace más difícil de mantener.

El flujo es así:

Explicamos exactamente cómo funciona este proceso de búsqueda, incluido el RAG, en Cómo funcionan los agentes de voz con IA. En resumen, lo que importa aquí es que un buen prompt indica al agente cuándo y cómo buscar en la base de conocimiento, y qué hacer si no encuentra nada relevante, en lugar de intentar meter todos los datos posibles directamente en las instrucciones.

Errores habituales en el prompt engineering

Prompts demasiado largos

Riesgo para el negocio: el modelo pierde de vista las instrucciones anteriores o las reglas clave quedan enterradas

Buena práctica: mantén los prompts centrados y lleva el material de referencia a la base de conocimiento en lugar de al propio prompt.

Instrucciones ambiguas

Riesgo para el negocio: comportamiento incoherente de una llamada a otra.

Buena práctica: sé explícito con los casos límite en lugar de dar por hecho que el modelo “ya lo resolverá”.

Falta de lógica de escalado

Riesgo para el negocio: las llamadas que deberían pasar a una persona se quedan atrapadas en un bucle.

Buena práctica: define criterios concretos y específicos para pasar la llamada a una persona, no un vago “escala si es necesario”.

Reglas contradictorias

Riesgo para el negocio: el agente se comporta de forma impredecible cuando dos instrucciones se contradicen.

Buena práctica: revisa los prompts en busca de contradicciones antes del despliegue, no después de que una queja de un cliente saque una a la luz.

Sin respuestas de respaldo

Riesgo para el negocio: el agente se inventa la respuesta o se queda callado cuando no sabe algo.

Buena práctica: define de forma explícita qué decir cuando el agente no encuentra una respuesta.

Ignorar el contexto de la conversación

Riesgo para el negocio: el agente pide a quien llama que repita algo que ya ha dicho

Buena práctica: indica al agente que tenga en cuenta los turnos anteriores y se apoye en ellos, en lugar de tratar cada respuesta de forma aislada.

Cómo probar y optimizar los prompts

Los prompts deben tratarse como se trata el código en producción: se prueban, se versionan y solo se despliegan cuando se ha verificado el cambio, en lugar de editarlos en directo y esperar que todo salga bien.

El ciclo básico:

El Prompt Editor de telli es un buen ejemplo de cómo es esto cuando está bien integrado en una plataforma. En lugar de depender de ediciones manuales o de peticiones a un equipo interno, los cambios pasan primero por una fase de revisión. Las peticiones de cambio informales se convierten en sugerencias concretas que un equipo puede aceptar una a una o todas a la vez antes de que nada se active. Esa capa de revisión funciona, en la práctica, como un control de versiones ligero para los prompts, y detecta una edición errónea antes de que llegue a quienes llaman de verdad, no después.

Más allá de la propia revisión de los prompts, aquí es donde la analítica cierra el ciclo: probar un cambio, observar qué pasa realmente después con la tasa de transferencias o con la tasa de citas concertadas, y volver a ajustar. Profundizamos en esa parte de la medición en Cómo funciona la analítica de los agentes de voz con IA.

Seguridad en los prompts de IA de voz

La inyección de prompts (prompt injection), en la que lo que dice un usuario manipula al modelo para que ignore sus instrucciones originales, es actualmente el principal riesgo de seguridad para aplicaciones de LLM según OWASP, por delante de todas las demás categorías de su Top 10 para aplicaciones de LLM.

Un agente de voz no está a salvo de esto automáticamente solo porque lo que recibe llegue hablado y no escrito: quien llama y dice algo pensado para anular las instrucciones del agente está intentando exactamente el mismo tipo de ataque.

Lo que conviene incluir en cualquier prompt en producción:

• Límites claros sobre lo que el agente hará y no hará, diga lo que diga quien llama
• Instrucciones para tratar lo que dice quien llama como datos a los que responder, no como nuevas instrucciones que seguir
• Ninguna información interna sensible (prompts de sistema, políticas internas, datos de otros clientes) expuesta, se formule como se formule la petición
• Pasos de verificación de identidad antes de realizar cualquier acción sobre una cuenta concreta
• Una vía definida para escalar a una persona cualquier cosa que parezca un intento de manipular el comportamiento del agente

Lista de buenas prácticas de prompt engineering

Diseño del prompt

• Rol, objetivos y tono claramente definidos al principio del prompt
• Instrucciones lo bastante concretas para evitar interpretaciones ambiguas

Diseño de la conversación

• Respuestas ajustadas al ritmo de una conversación hablada, no a la extensión de un párrafo escrito
• Confirmación de los datos clave (fechas, nombres, importes) integrada en las respuestas

Conocimiento

• El material de referencia está en la base de conocimiento, no metido a presión en el prompt
• Instrucciones claras sobre qué hacer cuando la búsqueda no da resultados

Pruebas

• Cambios en el prompt probados con llamadas reales o simuladas antes de activarlos
• Control de versiones para poder revertir rápidamente un cambio que salga mal

Seguridad

• Límites explícitos frente a los intentos de inyección de prompts
• Ningún dato sensible expuesto, se formule como se formule la petición

Monitorización

• Analítica revisada con regularidad para detectar cambios de comportamiento tras modificar un prompt
• Responsables claros de revisar y aprobar las actualizaciones del prompt

Conclusión: qué te llevas de todo esto

El prompt engineering consiste en diseñar una conversación fiable, coherente, segura y realmente alineada con lo que el negocio necesita, más que en redactar instrucciones ingeniosas. Si lo haces bien, el trabajo posterior de analítica y optimización tendrá una base sólida sobre la que construir; si lo haces mal, por mucho que mires los cuadros de mando no arreglarás una conversación que nunca se diseñó bien.

Referencias

1. telli.com - Cómo funcionan los agentes de voz con IA
2. telli.com - Cómo funciona la analítica de los agentes de voz con IA
3. genai.owasp.org - Clasificación y definición de la inyección de prompts por OWASP como principal riesgo de seguridad de los LLM