El lanzamiento del agente de IA para clasificar solicitudes internas tenía fecha en el calendario, una capacitación grupal de una hora y un comunicado interno con una captura de pantalla. La primera semana, catorce personas del equipo de operaciones lo probaron con curiosidad genuina. A los dos meses quedaban cuatro. A los seis meses quedaba una sola persona, la misma que había armado la capacitación original. El resto había vuelto a mandar las solicitudes por correo directo a un compañero, como siempre lo habían hecho. El agente seguía activo y respondía bien cuando alguien lo usaba. La empresa seguía pagando una licencia que casi nadie tocaba.
En el reporte, sin embargo, la implementación estaba terminada. La capacitación se había hecho, el agente estaba funcionando y nadie había reportado problemas. Después cambió un proveedor clave y el flujo quedó desactualizado. Más tarde llegaron tres analistas nuevos que nunca recibieron la capacitación y que, por lo mismo, nunca incorporaron la herramienta a su forma de trabajar. Nadie volvió a revisar el uso del agente ni a preguntarse por qué cada vez entraba menos gente. No hubo una decisión de dejar de usarlo. Simplemente fue quedando atrás, mientras en los reportes seguía apareciendo como una herramienta implementada.
La confusión entre activar un agente y que la empresa lo adopte de verdad
BCG publicó en 2025 un análisis titulado AI Adoption Puzzle, Why Usage Is Up But Impact Is Not, que revisa por qué el uso reportado de inteligencia artificial generativa sube en las encuestas de las empresas mientras el impacto financiero real se mantiene plano. La conclusión central es que la adopción no es un interruptor que se enciende una sola vez, es un cambio de comportamiento que hay que sostener semana tras semana, y que medir solo la cantidad de inicios de sesión esconde el verdadero problema, que es si la forma de trabajar de las personas realmente cambió o si el agente terminó siendo un experimento que se probó una vez y se abandonó.
Esa distinción, entre adopción como número de cuenta activada y adopción como comportamiento que se mantiene, es la que casi nunca se mide en las empresas chilenas que compran una herramienta de IA. Se mide si se contrató, se mide si se instaló, a veces se mide cuántas personas asistieron al lanzamiento. Casi nunca se mide si esas mismas personas la siguen usando pasado el primer trimestre, y esa omisión es exactamente donde se pierde la inversión.
El dato que explica por qué una capacitación de una sola vez no alcanza
En otro informe publicado en noviembre de 2025, To Unlock the Full Value of AI, Invest in Your People, BCG documenta el caso de una compañía global de biofarmacéutica que segmentó a más de cien mil empleados en cuatro arquetipos según su relación con la inteligencia artificial, y diseñó una ruta de aprendizaje distinta para cada uno, en vez de una charla única para toda la organización. Los líderes recibieron acompañamiento para modelar el uso frente a sus equipos y dar contexto estratégico, mientras que las personas más cercanas a la operación diaria participaron en simulaciones prácticas ligadas a casos reales de su propio trabajo. El resultado fue que la adopción de herramientas de IA subió de aproximadamente 20% a casi 90% dentro de esa compañía.
El mismo informe agrega un matiz que rara vez se menciona cuando se habla de capacitación en IA, que la ruta de aprendizaje tiene que avanzar por etapas, desde lo básico hasta lo aplicado y luego hasta convertirse en hábito incorporado en el flujo diario, y que ese último tramo, el que convierte una herramienta nueva en una costumbre de trabajo, es justamente el que se salta cuando la capacitación se agota en la semana del lanzamiento.
Qué significa esto para un agente que clasifica tickets, responde clientes o controla inventario
El mecanismo no cambia según qué tarea automatice el agente. Si clasifica solicitudes de soporte interno, si responde consultas de clientes por WhatsApp, o si consolida ventas por canal para un reporte semanal, la mecánica de abandono es la misma, si la persona que lo usa no entiende cómo ajustarlo a un caso particular que no calzó con lo aprendido en el lanzamiento, y si nadie resuelve esa duda dentro de los primeros días, esa persona vuelve al método que ya conocía. No porque el agente falló, sino porque nadie estuvo disponible para resolver la fricción a tiempo.
Esa fricción suele ser pequeña y específica, un formato de archivo que el agente no reconoció, un caso límite que no estaba en la capacitación, una duda sobre si la respuesta generada se puede editar antes de enviarla. Ninguna de esas dudas justifica cancelar el proyecto, pero todas juntas, sin nadie que las resuelva, explican por qué la curva de uso cae después del primer mes y ya no se recupera.
Un ejemplo de lo que pasa cuando nadie mantiene lo que el agente sabe
Atlas, uno de los agentes del marketplace de AgentLayer, concentra el conocimiento interno de una empresa, desde el organigrama y los contratos hasta el catálogo de productos, y responde preguntas de cada equipo las 24 horas, sin que un colaborador tenga que esperar a que alguien de otra área le conteste un correo. Ese tipo de agente ilustra bien el problema de fondo, porque su utilidad depende directamente de que la información detrás siga actualizada. Si la política de vacaciones cambia, si se firma un contrato nuevo con un proveedor, si el catálogo se actualiza, y nadie carga esos cambios, Atlas sigue respondiendo con seguridad, pero con datos que ya no son ciertos. El agente no se rompe de forma visible, simplemente empieza a dar respuestas cada vez más desactualizadas hasta que alguien nota el error frente a un cliente o un colaborador nuevo.
Este ejemplo muestra por qué separar la capacitación inicial del mantenimiento posterior es un error de diseño del proyecto, no un detalle operativo menor. Un agente de conocimiento interno necesita a alguien que actualice su información con la misma regularidad con la que cambia el negocio, y un agente que clasifica o responde necesita a alguien que revise casos nuevos y ajuste el criterio cuando el proceso de la empresa se mueve.
El soporte después del primer mes decide más que el lanzamiento
La mayoría de los proyectos de IA en empresas chilenas concentra todo el esfuerzo de acompañamiento en la semana de lanzamiento y muy poco en los meses siguientes, que son justamente los que definen si el agente sobrevive al primer cambio de prioridades del equipo. Cuando llega un cierre de mes complicado, una campaña comercial urgente o una reestructuración de procesos, lo primero que se abandona es lo que todavía no se volvió costumbre, y una herramienta capacitada una sola vez, sin nadie disponible para resolver dudas después, cae exactamente en esa categoría.
Por eso la pregunta correcta para un gerente de operaciones no es solo si el equipo sabe usar el agente el día uno, sino quién va a estar disponible en el mes tres cuando aparezca un caso que la capacitación original no cubrió, y qué pasa si esa persona cambia de rol o deja la empresa antes de que el uso se vuelva hábito para el resto del equipo.
Cómo la metodología de piloto a producción responde a este problema
AgentLayer estructura la implementación de cada agente en cuatro etapas dentro de un plazo de treinta días, pensadas justamente para que la adopción no dependa de un solo lanzamiento con fecha de vencimiento. La primera etapa es un diagnóstico y validación del caso de uso real con el equipo que lo va a operar, no una demostración genérica. La segunda es la implementación técnica del agente sobre los sistemas y procesos existentes de la empresa. La tercera es una prueba real de una a dos semanas donde el equipo del cliente co-crea ajustes junto con AgentLayer, corrigiendo justo esas fricciones pequeñas y específicas que en otros proyectos nadie llega a resolver a tiempo. La cuarta etapa es la entrega, que incluye un manual de uso concreto y soporte continuo después del lanzamiento, no solo una capacitación de una hora y un comunicado interno.
Esa cuarta etapa es la respuesta directa al problema que describe el estudio de BCG. La diferencia entre una adopción que se sostiene y una que se apaga a los pocos meses no está en la calidad del agente el día del lanzamiento, está en si alguien sigue disponible para resolver dudas, ajustar el comportamiento y actualizar el contexto cuando el negocio cambia. Diseñar esa etapa de soporte como parte del contrato, y no como un favor posterior, es lo que separa un piloto exitoso de un piloto que termina como una licencia que nadie usa.
Tres preguntas antes de dar un proyecto de IA por cerrado
Antes de firmar el acta de cierre de un proyecto de IA, un gerente de operaciones debería tener respuesta clara a tres preguntas que rara vez se formalizan por escrito.
Quién revisa en el mes tres si el equipo sigue usando el agente en el trabajo diario y no solo en la demostración inicial. Quién actualiza la información o el criterio del agente cuando un proceso de la empresa cambia, y con qué frecuencia lo hace. Y qué pasa con la capacitación de las personas nuevas que se suman al equipo después del lanzamiento, que nunca vivieron la charla original y que, sin una respuesta a esta pregunta, terminan trabajando como si el agente no existiera.
Ninguna de esas tres preguntas tiene una respuesta técnica. Las tres se responden con un dueño claro del soporte y una capacitación que se piensa como proceso continuo, no como un evento de un día. Las empresas que responden esas preguntas antes de lanzar son las que, seis meses después, siguen usando lo que compraron.
