Un piloto de agente de IA tarda unas semanas en impresionar. El chat responde, recupera información del catálogo y parece entender al usuario. Entonces llega el momento de conectarlo con pedidos reales, permisos internos y casos que nadie definió en el briefing. Ahí se atasca.
No es un problema del modelo. Los modelos de hoy cubren el tipo de tareas que una empresa media necesita automatizar. El problema aparece en los bordes: el cliente que pide algo fuera de catálogo, el pedido que está en estado intermedio, la devolución que requiere aprobación de dos personas. Un piloto no se diseñó para eso. Un sistema en producción, sí.
Qué rompe cuando el piloto toca datos reales
La primera grieta suele ser la misma: los datos están repartidos. El ERP tiene la información financiera, el CRM los contactos, la plataforma de pedidos el historial, y el sistema de tickets las incidencias abiertas. El piloto funcionaba con una API limpia y cuatro endpoints. La realidad tiene doce sistemas, tres formatos de fecha distintos y dos equipos que no se ponen de acuerdo sobre quién es el responsable de cada campo.
La segunda grieta son los permisos. Un agente que responde a cualquier empleado lo que pregunta no sirve para una empresa con departamentos separados por confidencialidad. Hay que definir qué ve cada rol, qué acciones puede ejecutar y dónde necesita aprobación humana. Esto no es un detalle técnico. Es una decisión de negocio que nadie tomó durante el piloto.
La tercera grieta son los casos límite. El cliente que quiere devolver un producto personalizado. El pedido que lleva tres días en estado "en revisión". La factura que no cuadra con el albarán. Estos casos no aparecen en el demo porque el demo se construyó con el camino feliz. En producción representan el 30% del volumen real.
Qué hacen distinto los pilotos que llegan a producción
Los equipos que logran llevar un agente a producción comparten un patrón: empiezan pequeño y conectan datos reales desde el primer día. No eligen "un asistente para todo". Eligen un caso concreto con límites claros: un copiloto para el equipo de soporte que consulta pedidos y estado de envíos, o un asistente de catálogo para el equipo comercial que busca fichas técnicas y stock.
Conectan el agente a datos reales, no a mocks. Si el piloto depende de datos simulados, no estás validando la solución. Estás validando una interfaz. Los permisos se definen antes, no después. Qué puede ver cada usuario, qué puede hacer el agente sin aprobación y qué escala a una persona. Esto se escribe en un documento de una página antes de tocar una línea de código.
Miden lo que importa. No solo la velocidad de respuesta. Miden cuántas consultas resuelve el agente sin escalar, cuántas veces el usuario corrige la respuesta, cuánto tiempo ahorra al equipo humano. Si no mides eso, no sabes si el agente funciona o solo parece que funciona.
Y diseñan para el fallo. Cuando el agente no sabe la respuesta, transfiere a una persona con el contexto completo. Cuando un sistema externo no responde, lo registra y notifica. No intenta disimular el error. Un agente que dice "no lo sé, te transfiero" genera más confianza que uno que inventa una respuesta.
En Luxion ayudamos a empresas a dar este paso sin humo: elegimos juntas el caso con mejor relación entre esfuerzo y resultado, montamos un prototipo conectado a datos reales y enseñamos cómo funciona antes de comprometer un proyecto completo.