Compraste las licencias del copiloto. Hubo un email de lanzamiento, quizá una formación. Y tres meses después, cuando miras el uso real, la mayoría de la gente no lo ha abierto esta semana. No es tu caso solo: Microsoft reportó unos 15 millones de usuarios de pago de Copilot sobre unos 450 millones de licencias comerciales de Office —en torno a un 3% de adopción real— y en 2026 el uso semanal activo típico se mueve en el 20-30% de los asientos con licencia. La conclusión incómoda es esta: el copiloto de IA interno no falla por el modelo. Falla porque nadie lo usa.
La tesis en una frase: un copiloto interno muere por adopción, no por capacidad. El modelo casi siempre es lo bastante bueno; lo que falla es el encaje en el flujo de trabajo real y el acceso a los datos que hacen falta para que la respuesta valga. Sin esas dos cosas, la licencia cara se queda sin abrir —y el problema no se arregla comprando un modelo mejor.
Por qué el copiloto de IA interno se queda sin abrir
El patrón de abandono es tan consistente que ya está documentado: la gente prueba el copiloto una o dos veces, se da cuenta de que revisar y corregir el borrador que genera le lleva más tiempo que escribirlo ella misma, y deja de usarlo. La caída de uso ocurre en la primera semana, no en el primer año. No es pereza ni resistencia al cambio: es una decisión racional. Si la herramienta te cuesta más de lo que te ahorra en tu tarea concreta, dejar de usarla es lo correcto.
Y aquí está el error de diagnóstico que se paga caro: cuando la adopción se estanca, la reacción típica es pensar que el modelo se queda corto y buscar uno mejor. Pero los datos apuntan a lo contrario —la percepción del usuario diverge de la calidad del modelo—, lo que señala a la experiencia de producto y a la ejecución de la integración, no a la capacidad. Cambiar de modelo cuando el problema es de encaje es gastar en la palanca equivocada.
Las tres razones reales por las que la adopción se cae
Debajo del "no lo usan" hay causas concretas, y ninguna se arregla con un modelo más potente.
- No encaja en el flujo de trabajo. El copiloto vive en una pestaña aparte y el trabajo vive en otro sitio. Si usarlo obliga a salir del flujo, copiar contexto y volver, la fricción se come el ahorro. La herramienta tiene que estar donde ya se trabaja, no en una ventana que hay que ir a buscar.
- No tiene los datos a mano. Un copiloto que no conoce tus políticas, tu histórico ni tus sistemas contesta genérico —y lo genérico hay que reescribirlo entero—. El salto de "asistente que redacta cosas plausibles" a "asistente que responde con lo tuyo" es lo que separa un juguete de una herramienta.
- Nadie ha demostrado que funciona para una tarea real. Sin un caso visible en el equipo —alguien que lo use para algo concreto y ahorre de verdad—, no hay prueba social que arrastre al resto. La gente no adopta por un email; adopta cuando ve a un compañero resolver en dos minutos lo que a ellos les lleva veinte.
Hay una cuarta, silenciosa: las dudas sobre seguridad y datos que nadie contestó. Si el equipo no sabe si sus prompts entrenan al modelo o si puede meter datos de cliente, muchos simplemente no lo usan —y no lo dicen—. Esa incertidumbre mata la adopción sin dejar rastro en ninguna encuesta.
Copiloto no es lo mismo que agente: el matiz que cambia el proyecto
Parte del problema es esperar del copiloto algo que, por diseño, no hace. Un copiloto asiste a una persona: espera tu instrucción, redacta, resume, busca. Brilla en lo puntual y muere en lo repetitivo que cruza varias apps —recoger lo que entra por correo y dejarlo estructurado, mantener una ficha coherente en tres sitios, montar un dosier con lo disperso—. Eso no lo hace un copiloto que espera órdenes; lo hace un agente administrativo que trabaja solo. Decidir cuál necesitas es la primera pregunta de qué procesos automatizar con IA: si el trabajo es asistir a personas, copiloto; si es quitar trabajo de teclado repetitivo, agente. Vender un copiloto donde hacía falta un agente es garantía de decepción, y al revés.
Cómo se arregla la adopción (y no es con otro modelo)
Si la adopción es el problema, la adopción es donde se invierte. En la práctica son cuatro movimientos, ninguno sobre el modelo:
- Meter el copiloto en el flujo real. Donde ya se trabaja —el CRM, el helpdesk, el documento— no en una pestaña aparte. Si hay que ir a buscarlo, no se usa.
- Darle los datos a mano. Conectarlo a tus políticas, tu histórico y tus sistemas para que conteste con lo tuyo y no con lo genérico. Aquí es donde un copiloto pasa de plausible a útil.
- Elegir 2-3 tareas concretas y demostrarlas. No "usad la IA": "para este tipo de correo, este prompt te ahorra quince minutos". Un caso visible que funcione arrastra más que diez formaciones.
- Contestar la duda de seguridad antes de que la pregunten. Qué pasa con los datos, qué se puede meter y qué no. La confianza es un prerrequisito de uso, no un extra.
Esto es, en el fondo, el mismo motivo por el que fracasan los proyectos de automatización con IA: se compra tecnología y se salta el encaje con el trabajo real y las personas que lo hacen. La tecnología es la parte fácil; que se use es la difícil, y es la que decide el retorno. Por eso el trabajo que de verdad mueve la aguja no es elegir modelo, es la adopción de la IA en los equipos: encaje en el flujo, datos conectados, casos demostrados y las dudas resueltas.
La pregunta que deberías hacerte antes de renovar licencias
Cuando llegue la renovación y veas el uso plano, la tentación será cambiar de proveedor o de modelo. Antes, hazte la pregunta que ordena el problema: ¿la gente no lo usa porque el modelo es malo, o porque no encaja en su trabajo y no tiene los datos a mano? Casi siempre es lo segundo. Y eso no se arregla comprando —se arregla montando la adopción como un proyecto con dueño, no como un email de lanzamiento—. Un copiloto que nadie usa no es un problema de IA: es una licencia cara esperando a que alguien haga el trabajo de que se use.