Qué es la adopción de IA en una empresa

Instalado no es lo mismo que usado

Una aseguradora regional en Colombia, con un centro de atención de unas 300 personas, instaló un asistente de IA para responder consultas de pólizas y siniestros. El proveedor mostró el caso como éxito en una conferencia del sector. Seis meses después, el equipo de atención seguía transfiriendo la mayoría de las consultas complejas a un supervisor humano, no porque el sistema no tuviera la respuesta, sino porque nadie confiaba en pasarla tal cual al cliente sin que alguien la revisara primero.

Esto se repite en sectores distintos. Una firma de servicios profesionales en Chile, de unas 80 personas, compró licencias de un asistente para redactar informes y apoyar investigación. El área de finanzas ve el gasto mensual en la línea de software y asume que el proyecto avanza. Nadie mide cuántos informes reales se escribieron con ayuda del sistema frente a cuántos se siguieron haciendo desde cero, como antes de firmar el contrato.

El patrón es el mismo en los tres casos. La empresa paga la herramienta, paga la capacitación, y paga, sin saberlo, el costo de mantener vivo el proceso viejo en paralelo. Dos sistemas conviven, uno visible en el contrato y otro invisible en el hábito real del equipo, y el segundo casi siempre gana cuando hay presión de tiempo.

Qué es la adopción de IA, en criterio de negocio

Aquí conviene separar dos cosas que en la conversación de negocio se mezclan todo el tiempo: tener el sistema y usarlo. Una empresa puede tener el contrato firmado, las cuentas creadas y el logo del proveedor en la intranet interna, y aun así no haber adoptado nada. La adopción no vive en el contrato ni en el tablero de licencias activas. Vive en lo que la gente hace cuando nadie está mirando, cuando tiene la opción de resolver rápido por el camino conocido o por el sistema nuevo.

Dicho así suena obvio, pero en la práctica casi ninguna empresa mide esto. Miden accesos, miden licencias activadas, miden asistencia a la capacitación. Nada de eso responde la pregunta real: de las tareas que ese sistema debía absorber, ¿cuántas efectivamente pasan por ahí hoy? Si quieres el detalle de cómo construir esa medición paso a paso, ya existe la guía sobre cómo medir la adopción real de un sistema de IA. Acá el objetivo es otro: entender qué es la adopción y por qué se frena, antes de intentar medirla.

Adopción no es lo mismo que uso

La métrica que más engaña en estos proyectos es usuarios activos. Alguien puede entrar al sistema, hacer clic en dos pantallas y salir, y ese ingreso cuenta igual que el de la persona que resolvió ahí su tarea completa del día. El dashboard de uso sube, la adopción real no se mueve.

• Cuenta el ingreso, no la tarea resuelta: alguien puede entrar solo a mirar algo y salir sin haber usado la función que reemplaza el proceso viejo.
• Un pequeño grupo de usuarios intensivos infla el promedio general y esconde que el resto del equipo casi no entra.
• El uso sube fuerte las primeras semanas por curiosidad y baja después, y el acumulado esconde esa caída si nadie mira la tendencia.
• Se mide a nivel de cuenta activa, no de proceso: alguien puede tener sesión abierta todos los días y seguir resolviendo la mayor parte de su trabajo por fuera del sistema.
• El proveedor suele reportar asientos asignados o activados como si fuera adopción, cuando es una métrica de venta y aprovisionamiento, no de comportamiento real.

La pregunta que reemplaza a usuarios activos es más incómoda y más útil: de las tareas que este sistema debía absorber, ¿cuántas efectivamente pasan por ahí esta semana, y cuántas siguen resolviéndose por el camino de siempre?

Adopción tampoco es lo mismo que licencias compradas

El segundo error de lectura es asumir que comprar licencias es haber adoptado. Comprar licencias mide la decisión de compra, no el cambio de comportamiento. Una empresa de logística en Argentina, con flota propia y cerca de 200 empleados administrativos, compró licencias de un sistema de IA para planificación de rutas para todo el equipo de operaciones. Un año después, la renovación del contrato se aprobó de manera casi automática, sin que nadie revisara cuántas de esas licencias se usaban en serio.

• Las licencias se asignan por cargo o por área, no porque la persona haya pedido usar el sistema, y muchas quedan sin abrirse nunca.
• El ciclo de renovación del contrato es anual, y la decisión de renovar pasa por compras o finanzas, que ven el gasto, no el comportamiento del equipo.
• El costo por licencia se vuelve una línea fija del presupuesto, y una vez presupuestada, nadie la cuestiona salvo que alguien pida explícitamente cancelarla.
• El proveedor factura por licencia activada, así que su propio incentivo comercial es que la empresa compre más asientos, no que audite cuántos se usan de verdad.
• Una licencia sin uso no aparece como alerta en ningún tablero financiero: aparece igual que una licencia usada a diario, como una fila más en la factura.

Licencias compradas es una métrica de procurement. Adopción es una métrica de comportamiento. Confundirlas es la razón por la que tantos proyectos de IA se reportan como implementados en el directorio y siguen sin mover una sola cifra operativa real.

Por qué se frena la adopción

Cuando la adopción no arranca, casi siempre es por una de cuatro razones, y ninguna de las cuatro se arregla con un curso adicional de capacitación.

• El proceso viejo sigue existiendo en paralelo: nadie apagó la planilla, el correo o el chat interno que resolvía esto antes, así que el atajo conocido sigue disponible y siempre gana cuando hay presión de tiempo.
• El sistema nuevo es más lento que el atajo: si escribir la cotización en Excel toma minutos y hacerlo por el sistema toma más tiempo porque hay que completar campos que antes se improvisaban, el equipo vuelve a lo rápido, sin que nadie lo decida de forma explícita.
• Nadie es dueño del resultado: el sistema se instaló, pero ningún puesto tiene como responsabilidad formal que la adopción suba, y sin un dueño, el tema desaparece de la agenda apenas termina el proyecto de implementación.
• El equipo no confía en la salida: si la primera vez que alguien usó la respuesta del sistema tal cual le salió mal, esa persona no vuelve a confiar, revisa todo de nuevo por su cuenta, y terminar revisando todo dos veces es más lento que no haber cambiado nada.

Estas cuatro razones casi nunca aparecen solas. En la aseguradora de Colombia del ejemplo anterior convivían la segunda y la cuarta: el sistema pedía más pasos de verificación que el criterio del supervisor de siempre, y encima nadie confiaba todavía en dejarlo resolver solo. Capacitar de nuevo al equipo de atención no habría cambiado ninguna de las dos cosas.

La adopción es un problema de diseño de proceso y de incentivos

La conclusión operativa de todo lo anterior es esta: la adopción no se resuelve enseñando mejor a usar el botón, se resuelve rediseñando el proceso para que el atajo viejo deje de ser una opción real, y ajustando qué se mide y qué se premia en el rol.

• Retirar o degradar el acceso al canal viejo, la planilla paralela, la bandeja de correo compartida, en vez de dejarlo activo por si acaso, porque ese por si acaso es la puerta de salida que usa todo el equipo bajo presión.
• Cambiar el indicador del rol para que dependa de que el trabajo pase por el sistema, no solo del resultado final: si el resultado cuenta igual sin importar el camino, el camino más corto siempre gana.
• Nombrar un responsable explícito de que la adopción suba, no solo un usuario administrador técnico, porque sin un dueño de negocio, la adopción es responsabilidad de todos y por lo tanto de nadie.
• Diseñar el proceso para que el camino correcto sea también el más corto, aunque eso implique quitarle pasos de verificación al inicio y sumarlos después, cuando ya hay confianza construida.
• Sostener el cambio con una figura interna que resuelva dudas del día a día, del tipo que en otra entrada de este glosario se llama un champion de IA, y con un proceso de onboarding del sistema que no termine el primer día de capacitación.

Ninguno de estos cinco movimientos es técnico. Son decisiones de diseño organizacional que le tocan al dueño del proceso, no al equipo de tecnología ni al proveedor. Esto no significa que capacitar no sirva: existe una guía específica sobre cómo capacitar al equipo para adoptar IA, para la parte que sí depende de habilidad, pero ese paso rinde después de rediseñar el proceso, nunca en lugar de hacerlo. Es la misma lógica que aplica a la madurez de IA de una empresa en general: la tecnología expone el problema, no lo resuelve por sí sola.

Mi criterio

Cuándo la adopción va en serio y cuándo no

Antes de invertir más presupuesto en mejorar la adopción, vale la pena mirar señales concretas de comportamiento, no la sensación general que tiene el comité gerencial.

Señales de que la adopción va en serio

• El volumen de trabajo que pasa por el sistema crece semana a semana sin que nadie esté presionando con recordatorios.
• Cuando el sistema falla o queda fuera de línea, el equipo lo nota de inmediato y reclama, porque ya depende de él para su día a día.
• Aparecen usuarios que piden funciones nuevas o casos de uso adicionales, sin que el área de tecnología los empuje a hacerlo.
• El proceso viejo, la planilla, el correo, el chat interno, empezó a quedar vacío o desactualizado, no por orden, sino porque ya nadie lo alimenta.
• Un mando medio puede explicar, sin mirar el tablero del proveedor, qué parte de su equipo resuelve hoy por el sistema y qué parte todavía no.

Señales de que la adopción está fallando

• El uso sube solo cuando hay una auditoría o la visita de un gerente, y baja apenas termina la observación.
• El equipo maneja dos versiones de la verdad: la que reporta el sistema y la que realmente circula por correo o por chats internos.
• Nadie en el negocio puede nombrar quién es responsable de que la adopción suba; el tema vive solo en la relación comercial con el proveedor.
• La capacitación se repite una y otra vez con el mismo contenido, como si el problema fuera que la gente olvidó cómo usar el sistema.
• El resultado final, la cotización, la póliza, el informe, es indistinguible de cómo se hacía antes, aunque el proceso ahora incluya un paso adicional de IA.

El orden correcto aplicado a la adopción

El orden que sostiene este artículo es el mismo que sostiene cualquier proyecto de IA que funciona: primero el dolor operativo real, después el proceso que hay que rediseñar, después el dato que confirma si ese rediseño funcionó, y al final la herramienta. La adopción es exactamente el punto donde ese orden se rompe más seguido. La empresa compra la herramienta primero, la instala sobre el proceso viejo sin tocarlo, y después se sorprende de que nadie la use de verdad.

No hay atajo para esto. La adopción sube cuando el camino nuevo es más corto que el viejo y cuando alguien responde por el resultado, no cuando se repite la capacitación una vez más. Toda empresa que mide con honestidad cuánto de su trabajo real pasa hoy por el sistema que compró se lleva una sorpresa, y esa sorpresa, incómoda como es, es el punto de partida real de cualquier estrategia de adopción.