Cómo diseñar agentes conversacionales con IA generativa

Por Soledad Ferrer, Senior UX Content & Conversational Designer at Santex

Hay una conversación que se repite. Alguien propone sumar un agente de IA al producto. Se habla del modelo, de la integración, del stack técnico y, en algún momento, casi de pasada, alguien pregunta: "¿Y el system prompt quién lo escribe?"

Esa pregunta tiene una trampa. No porque sea difícil de responder, sino porque asume que el system prompt es el punto de partida. En la práctica, es el final de un proceso que la mayoría de los equipos nunca hace.

Lo que hay que tener resuelto antes de escribir una sola línea de prompt

Un agente conversacional con IA generativa no funciona como un bot tradicional. Un bot hace lo que le programaron; si no lo programaron, no existe. Un agente con IA generativa necesita algo más profundo que reglas: necesita carácter.

Eso significa que antes de abrir cualquier editor y escribir instrucciones, hay que tener definida la identidad completa del agente: su personalidad, sus valores, sus límites, su voz, su sistema de tonos, sus patrones conversacionales y sus arquetipos emocionales. No como un documento de soporte, sino como la arquitectura que sostiene todo lo demás.

En las últimas semanas construí exactamente eso para un agente conversacional con IA generativa en fintech. El trabajo me dejó cinco aprendizajes que vale la pena nombrar.

Cinco capas que definen si un agente conversacional funciona de verdad

1. Un núcleo de identidad que se mantiene constante. 

El agente puede cumplir roles distintos según el momento, por ejemplo, informar, asistir, escalar, contener; no obstante, hay algo que no cambia: quién es. Ese núcleo es lo que le permite responder con coherencia ante situaciones que nadie programó explícitamente.

2. Un sistema de voz y tono con ejemplos concretos. 

A la IA no le sirve un adjetivo. No alcanza con decir "amigable" o "profesional": hay que mostrarle qué decir y qué nunca decir, con ejemplos reales, en el lenguaje del usuario al que va a atender. La diferencia entre un agente que se siente humano y uno que se siente robótico suele estar en este nivel de detalle.

3. Patrones conversacionales documentados en tres capas. 

Qué significa para el negocio, cómo se comporta para el equipo de diseño y cómo se implementa para desarrollo. Un patrón que solo vive en la cabeza de quien lo diseñó no sobrevive a la primera integración.

4. Arquetipos emocionales del usuario. 

No quién es el usuario, sino cómo llega emocionalmente a la conversación. Una persona que consulta su saldo a las once de la noche porque acaba de ver un cargo que no reconoce no está en el mismo estado que alguien que explora productos un sábado a la mañana. El agente tiene que saberlo, y tiene que responder en consecuencia.

5. Antipatrones documentados como parte del diseño. 

Este último punto es el menos visible y, en mi experiencia, el más determinante.

Por qué los antipatrones son parte fundamental del system prompt

Hablamos mucho de qué queremos que haga el agente. Hablamos poco de qué pasa cuando hace algo que no deberíamos querer.

Los antipatrones son exactamente eso: las decisiones documentadas sobre qué no es el agente, qué no hace, y qué ocurre cuando actúa de otra manera. No son documentación de soporte, son parte estructural del system prompt.

¿Cómo se identifican? Se descubren. Aparecen cuando preguntás qué pasa si el agente hace "esto" en "este" contexto, y la respuesta no corresponde o no es la que se necesita.

El proceso que apliqué tiene tres momentos:

1. Estudio y anticipación. Antes de que el agente exista, analicé escenarios reales de otros sistemas. ¿Qué pasa cuando alguien insiste en una respuesta que el agente no puede ni debería dar? ¿Qué pasa cuando el sistema interpreta una intención que no es la del usuario?

2. Documentación y definición. Cada lineamiento surgió de entender qué podría pasar mal, estudiarlo, y definir qué debería hacer el agente antes de que ocurra.

3. Validación con el equipo completo. Diseño, desarrollo y negocio en la misma conversación. Porque un antipatrón que tiene sentido para UX puede ser técnicamente imposible de sostener, o puede tener implicancias legales que UX no ve.

El resultado no es un documento más. Es la base sobre la que cualquier agente, cualquier flujo nuevo, cualquier integración futura, puede apoyarse para sonar coherente, sentirse humano y resolver con criterio.

Cómo entra la IA en mi propio proceso de diseño

Hay una confusión frecuente que conviene aclarar: no uso la IA para diseñar conversaciones. La uso para pensar mejor mientras las diseño. La diferencia importa.

En la etapa de brief y exploración, la IA me ayuda a anticipar intenciones del usuario que quizás no consideré, a identificar casuísticas, a formularme preguntas que no me estaba haciendo.

En el research, procesa volumen. El lenguaje es el dato principal en diseño conversacional: cómo describe alguien su problema, qué palabras elige, qué da por supuesto. Cuando hay cientos de conversaciones para analizar, la IA procesa en horas lo que a mí me llevaría días. Pero la interpretación sigue siendo mía.

En el diseño y prototipado, la uso para generar variaciones. Un mismo mensaje en tres tonos distintos. Una respuesta ante ambigüedad en cinco formas diferentes. No para elegir la mejor automáticamente, sino para tener más opciones sobre la mesa y decidir con criterio.

En la iteración, una vez que la experiencia está en producción y las conversaciones reales muestran lo que no anticipé, la IA me ayuda a detectar patrones de abandono, puntos de quiebre, intenciones no modeladas.

Hay algo que no delego en ninguna de esas etapas: saber por qué algo falla. Entender cuándo un mensaje técnicamente correcto es emocionalmente equivocado, decidir qué cambiar y por qué, eso requiere criterio. Y el criterio no se automatiza.

La IA amplía lo que puedo hacer. No reemplaza lo que sé hacer.

Conversational design como sistema, no como capa de copy

Un error frecuente en las implementaciones de IA conversacional es tratar el diseño conversacional como una capa superficial de la experiencia. Se suma al final, cuando el sistema ya está definido, para "pulir" el lenguaje.

Ese orden está invertido.

Cuando la interacción ocurre a través del lenguaje, el diseño conversacional deja de ser una cuestión de redacción y pasa a formar parte de la arquitectura del sistema. Los sistemas conversacionales operan sobre capas de contenido estructural que definen cómo el agente interpreta, procesa y responde a las intenciones del usuario:

• Diseño de intenciones: cómo se modelan las tareas que los usuarios quieren resolver y cómo el sistema las reconoce dentro de una conversación.

• Arquitectura de conocimiento: la estructura de información que el agente puede consultar, recuperar o inferir, y las reglas que determinan cuándo y cómo utilizarla.

• Comportamiento del sistema: las estrategias que definen cómo el agente responde ante ambigüedad, incertidumbre o información incompleta.

• Estrategia lingüística: los principios que guían el tono, la claridad, la precisión y la consistencia del lenguaje.

• Orquestación de flujos conversacionales: cómo la conversación guía progresivamente al usuario hacia una acción, decisión o resolución de tarea.

Nielsen Norman Group describe este cambio como el paso de interfaces basadas en comandos a modelos basados en intención, donde el usuario expresa el resultado que desea y el sistema determina cómo alcanzarlo. En ese paradigma, el diseño consiste en modelar cómo el sistema interpreta el lenguaje, refina la intención y colabora con el usuario para alcanzar un resultado.

Si las palabras son la interfaz, los agentes conversacionales son el sistema. Y nosotros somos quienes diseñamos cómo ese sistema interpreta, decide y guía una interacción.

La pregunta que cambia el orden del trabajo

¿Podrían algunas experiencias conversacionales tener mayor usabilidad que ciertas páginas web o apps, simplemente porque eliminan la necesidad de navegar?

Cuando el objetivo es rapidez y resolución inmediata, la conversación puede ser el camino más natural, pero no alcanza con poner un bot en un chat. Hay que diseñar cómo el sistema entiende, responde y guía a la persona hacia lo que necesita.

Y ese diseño no ocurre de manera aislada. Para que una experiencia conversacional realmente dé resoluciones efectivas, el equipo de diseño necesita trabajar en conjunto con los especialistas en desarrollo, análisis y negocio. Cada disciplina aporta una parte del contexto: qué necesita el usuario, qué puede sostener técnicamente el sistema, qué reglas debe respetar y qué resultado tiene sentido para el negocio.

Las mejores experiencias aparecen cuando esas decisiones se toman en conjunto desde el inicio, no cuando el diseño conversacional llega al final para ajustar las palabras de un sistema que ya fue definido. Diseñar para IA generativa no es escribir menos reglas, es construir mejores fundamentos, entre todos los que hacen posible la experiencia.