Imagina que un equipo de soporte quiere un resumen generado por IA de cada conversación con un cliente. La primera demostración es sencilla: pegar una conversación en un prompt y leer el resultado. El trabajo se concreta cuando ese resumen forma parte del día a día de alguien.
Usaría ese ejemplo para revisar la función completa, desde la selección de los datos hasta la corrección de un resultado incorrecto.
Definir una tarea concreta
Para un resumen de soporte definiría los datos que necesita el agente: el problema del cliente, lo que ya se ha intentado y lo que queda pendiente. Mantendría enlaces a los mensajes originales para poder comprobar cada afirmación.
Un párrafo bien escrito puede esconder una fecha incorrecta o una promesa que nadie hizo. La persona que lo usa necesita detectar y corregir eso rápidamente. Revisaría la interfaz con ella antes de dedicar demasiado tiempo a elegir el modelo.
Mantener los permisos en el código
La aplicación debe seleccionar las conversaciones a las que el usuario tiene acceso antes de enviar nada al modelo. Una conversación puede contener instrucciones, bromas o texto copiado de otro lugar. Esas palabras no deben cambiar los permisos del usuario.
También separaría guardar un resumen de enviárselo a un cliente. Si la función acaba enviando mensajes, los destinatarios y la confirmación necesitan sus propias comprobaciones en el código. Escribir “ten cuidado” en un prompt no aporta esas comprobaciones.
Guardar unos cuantos ejemplos difíciles
Guardaría un conjunto de pruebas con una conversación normal, una muy larga, un caso sin resolver y una conversación con fechas contradictorias. Los ejemplos sintéticos sirven para esto; los mensajes de producción requieren un tratamiento adecuado antes de usarlos como datos de prueba.
Para cada caso anotaría los hechos que el resumen debe conservar y las preguntas que debe dejar sin respuesta. Repetiría las pruebas al cambiar el prompt, el modelo o la búsqueda de información. Leer unas pocas respuestas convincentes facilita que una regresión pase desapercibida.
Prever que una petición falle
Si el modelo no responde a tiempo, el agente debe conservar la conversación y sus notas. Ofrecería volver a intentarlo sin empezar de cero. Para un resumen que solo lee datos, repetir la petición suele ser sencillo.
Una operación que escribe datos necesita más cuidado. El tiempo de espera puede agotarse después de que el servidor haya guardado el resultado. La aplicación debe comprobar si ocurrió antes de repetir la operación, o podría crear registros duplicados.
Contar el coste de la tarea terminada
Mediría cuánto cuesta producir un resumen útil, incluidas las conversaciones largas y los reintentos. También miraría con qué frecuencia alguien tiene que corregirlo. Una llamada barata al modelo puede generar mucho trabajo si hay que reescribir cada resultado.
La publicación necesita un responsable, una forma de revisar los fallos y una opción para desactivar la función. Empezaría con un grupo pequeño de usuarios y revisaría los problemas antes de ampliar el acceso.