La demostración termina bien. El agente encuentra el pedido, consulta su estado y redacta una respuesta que cualquiera del equipo enviaría. Entonces alguien pregunta: «¿Y si se corta la conexión justo después de cambiar el pedido?». Durante unos segundos, la conversación deja de girar alrededor del modelo.
Esa pregunta marca una frontera bastante más útil que el final de una prueba de concepto. En producción habrá solicitudes incompletas, herramientas que no respondan y personas que pidan cosas fuera de lo previsto. Lo que necesita el CTO es saber cómo se comportará el servicio en esas condiciones y quién podrá hacerse cargo. El agente está preparado para avanzar cuando el equipo puede explicar ese recorrido con la misma claridad con la que enseña la demo.
Qué trabajo le estás confiando exactamente
“Resolver consultas” es un alcance demasiado abierto. Resulta más útil definir entradas admitidas, fuentes disponibles, acciones permitidas y condiciones de cierre. Por ejemplo: preparar una respuesta sobre el estado de un pedido, utilizando únicamente registros accesibles para ese usuario. Añade exclusiones explícitas. El agente puede informar, pero quizá no puede cambiar precios, modificar entregas o prometer compensaciones. Estas restricciones deben reflejarse en las herramientas y permisos, además de las instrucciones.
Establece también cuándo debe abstenerse. Un identificador inexistente, datos incompatibles o una petición fuera de alcance requieren una respuesta controlada. La abstención bien resuelta forma parte del servicio; no es simplemente un fallo del modelo.
Los casos incómodos también forman parte de la prueba
Reúne ejemplos representativos de la operación, debidamente protegidos o anonimizados. Incluye casos habituales y otros que exijan especial cuidado: datos incompletos, documentos contradictorios, usuarios sin permisos y herramientas temporalmente indisponibles. Para cada caso, escribe el resultado esperado y las acciones prohibidas. Comprueba tanto el texto final como los cambios realizados en los sistemas. Una respuesta amable no compensa una modificación incorrecta.
Las evaluaciones de agentes descritas por Anthropic distinguen tareas, intentos y criterios de evaluación. Una consecuencia práctica es repetir los casos cuando existe variabilidad y no tratar una ejecución favorable como evidencia suficiente. Mantén un conjunto reservado para comprobar cambios. Si se ajusta todo utilizando siempre los mismos ejemplos, el sistema puede mejorar en la prueba y seguir fallando en solicitudes nuevas.
Proponer una acción no concede permiso para ejecutarla
El modelo puede proponer una acción; el sistema debe decidir si esa acción está permitida. Esta frontera es esencial cuando el agente tiene acceso a herramientas que escriben datos o envían comunicaciones. Utiliza identidades de servicio con permisos limitados. Valida parámetros contra reglas de negocio y comprueba que el usuario tiene acceso al recurso solicitado. Evita herramientas genéricas que acepten instrucciones arbitrarias o permitan operar sobre cualquier registro.
El contenido recuperado de correos y documentos debe tratarse como datos, no como órdenes del sistema. Si un documento pide ignorar las políticas o enviar información a otro destino, esa instrucción no puede ampliar los permisos del agente.
La conexión se corta. ¿Qué ha ocurrido realmente?
Supongamos que el agente ha enviado una modificación a un sistema externo, pero la conexión se pierde antes de recibir la confirmación. Desde su punto de vista hay un error; desde el del destino, la modificación quizá ya se ha realizado. Pulsar «reintentar» sin averiguarlo puede repetir una acción que el cliente solo pidió una vez.
Para salir de esa incertidumbre, el proceso necesita conservar el identificador de la operación y estados reconocibles: recibido, validado, pendiente de aprobación, ejecutado y cerrado. No basta con guardar una conversación larga. Quien recupere el caso debe poder comprobar qué se intentó, qué quedó confirmado y qué sigue pendiente, consultando el destino antes de repetir una acción incierta.
Lo mismo ocurre con las aprobaciones. Una persona puede haber autorizado una propuesta ayer y encontrarse hoy con otro importe o destinatario. Asociar la aprobación a la propuesta exacta, con sus condiciones de caducidad, evita que la recuperación ejecute una decisión que ya no corresponde al caso. Cuando el destino no permita verificar el resultado, esa incertidumbre tendrá que llegar a un operador.
Abrir el servicio poco a poco
Consideremos un agente hipotético que prepara respuestas de soporte. En la primera fase trabaja con casos históricos. En la segunda propone respuestas sobre solicitudes reales, pero una persona revisa todas antes de enviarlas. Una tercera fase puede permitir respuestas automáticas solo para categorías acotadas y comprobables. Las demás siguen supervisadas. El paso entre fases depende de los resultados, no de una fecha comercial arbitraria.
Mantén un interruptor operativo que detenga nuevas acciones y una cola clara para continuar manualmente. Volver a una versión anterior del agente no revierte mensajes enviados ni cambios externos. Por eso la recuperación debe considerar tanto el software como sus efectos.
Seguir al cliente hasta el cierre
Una ejecución técnicamente correcta puede terminar con el cliente sin respuesta. La monitorización debe seguir el recorrido de negocio, desde la entrada hasta la confirmación de cierre. Registra identificador del caso, versión de instrucciones, modelo utilizado, llamadas a herramientas, validaciones y resultado. Evita almacenar información sensible innecesaria. Define quién puede consultar las trazas y durante cuánto tiempo se conservan.
Combina indicadores de calidad, latencia, errores, revisión humana y coste por caso completado. Observa también la antigüedad de los casos pendientes. Una media de tiempo favorable puede ocultar solicitudes que llevan días abandonadas.
Antes del lanzamiento, alguien debe saber qué hacer si falla el proveedor del modelo, una herramienta devuelve datos incompletos o el agente empieza a consumir más recursos de lo previsto. Documenta procedimientos breves y ensáyalos. Define quién puede detener el servicio, qué casos requieren aviso y cómo se informa al usuario. Establece límites de gasto y duración por ejecución para evitar bucles costosos.
La revisión humana también necesita capacidad. Si el piloto deriva la mitad de los casos, calcula el esfuerzo de esa cola. Un agente no aumenta la capacidad total si desplaza más trabajo del que resuelve.
Antes de abrir el servicio a más usuarios, sienta en la misma revisión a quienes responden por el negocio y por la operación técnica. La conversación debería recorrer casos concretos: qué puede hacer el agente, qué resultados obtuvo, qué permisos tiene y cómo se atendería una interrupción. Anota las limitaciones conocidas y las señales que obligarían a reducir su autonomía; serán más útiles durante una incidencia que una declaración genérica de que las pruebas fueron bien.
Después del lanzamiento, cada fallo real puede convertirse en un caso de evaluación, y cada cambio de modelo, herramienta o política debe volver a contrastarse. Si quieres revisar una prueba de concepto con DigitalCube, lleva también el caso que todavía te preocupa. La pregunta de aquella demo —qué pasa cuando se corta la conexión— merece una respuesta antes de que la formule un cliente.