Cómo medir la adopción real de un sistema de IA

El problema: reportar adopción con logins y capacitación asistida

Tres meses después del lanzamiento, el reporte al comité dice que el sistema fue un éxito: noventa por ciento del equipo asistió a la capacitación, setenta por ciento tiene una cuenta activa y hubo cero incidentes críticos. Nadie miente en ese reporte, y aun así la operación real no cambió: los vendedores siguen armando sus propuestas en la plantilla de Word de siempre, los abogados siguen pidiéndole el primer borrador a la secretaria por costumbre, el área de soporte sigue resolviendo tickets copiando y pegando la misma respuesta manual. El sistema existe, se usó una vez para la foto, y después volvió al cajón.

Esto pasa porque es mucho más fácil sacar un número de un panel de administración (cuántos logins, cuántos asistieron a la capacitación, cuántas licencias activas) que preguntarse si alguien cambió de verdad su manera de trabajar. El primer tipo de dato está a un clic; el segundo exige mirar el comportamiento real, semana a semana, tarea por tarea. Y como el primer reporte es el que se puede entregar rápido, es el que casi siempre se entrega.

El costo de medir mal esto no es solo cosmético. Un sistema con adopción de fachada sigue consumiendo presupuesto, licencias y soporte técnico mientras el proceso viejo corre en paralelo, duplicando el trabajo en vez de reducirlo. Y como el reporte inicial dijo “éxito”, nadie vuelve a auditar el asunto hasta que alguien de finanzas pregunta por qué el gasto en IA no se refleja en ningún número de negocio.

Qué significa medir adopción real (y qué no mide nada)

Medir adopción real es distinto a medir despliegue. El despliegue terminó el día que se entregaron las cuentas y se dictó la capacitación; la adopción se demuestra después, en el comportamiento sostenido de la persona cuando nadie la está mirando. La pregunta no es “¿la gente sabe usar la herramienta?”, es “¿la gente eligió seguir usándola en la tarea que de verdad importa, semana tras semana, en vez del método anterior?”.

También es distinto de medir satisfacción. Una encuesta puede decir que “el 85% está conforme con la herramienta” y eso no dice nada sobre si esa persona la usó dos veces esta semana en la tarea núcleo de su puesto o si contestó la encuesta con buena voluntad y siguió trabajando exactamente igual que antes. La satisfacción es una opinión declarada; la adopción es un patrón de comportamiento medido con datos duros: logs de uso, documentos generados, tareas cerradas dentro del sistema.

• Número de logins o sesiones abiertas: abrir la herramienta no implica usarla para la tarea que importa.
• Porcentaje de asistencia a la capacitación: asistir no es lo mismo que incorporar el cambio al trabajo diario.
• Encuestas de satisfacción o autopercepción de uso, sin cruce contra logs reales de actividad.
• Número de cuentas o licencias activadas: una licencia activa puede llevar semanas sin un solo uso real.

El paso a paso para medir adopción real

Este paso viene después del diagnóstico de madurez y de la capacitación inicial (ver la guía hermana de cómo capacitar a un equipo para adoptar IA): ya se identificaron los early adopters, ya se dio el tiempo protegido para practicar y ya pasó al menos un ciclo completo de trabajo real, no solo el sprint de lanzamiento. A partir de ahí, medir adopción real sigue este orden:

• Define la tarea núcleo que el sistema debía reemplazar o mejorar, no la plataforma en general. No mides “uso de la herramienta de IA”, mides “redacción de contratos”, “calificación de leads” o “respuesta de tickets de nivel uno”: la tarea concreta del puesto, la misma que se usó para justificar el proyecto.
• Mide frecuencia de uso en esa tarea específica, con datos del sistema, no con lo que la persona dice que hace. Si el sistema genera quince borradores de contrato al mes entre ocho abogados, la adopción real está en cuántos de esos ocho generaron al menos uno cada semana, no en si los ocho tienen su cuenta activa.
• Verifica si el proceso viejo sigue vivo en paralelo. Busca la hoja de cálculo compartida de siempre, el grupo de WhatsApp donde se sigue pidiendo el favor a mano, la plantilla de Word que todavía circula por correo. Si el atajo anterior sigue funcionando sin fricción, la persona va a volver a él en cuanto baje la presión del lanzamiento.
• Detecta la recomendación espontánea entre pares. Pregunta, en entrevistas cortas y sin previo aviso, si alguien le enseñó el sistema a un compañero sin que se lo pidieran desde arriba. Cuando la adopción es real, el uso se contagia lateralmente; cuando es de fachada, cada persona lo aprende solo porque a ella le tocó la capacitación.
• Segmenta la medición por persona y por rol, nunca solo en agregado. Un promedio de 70% de adopción puede esconder un área al 95% y otra al 20%. El número agregado tranquiliza a un comité de dirección y esconde justo el bolsón de resistencia que hay que resolver.
• Cruza el uso con un dato duro del negocio, no solo con el dato de actividad dentro del sistema: tiempo de ciclo de la tarea, tasa de error, volumen atendido por persona. Uso alto sin mejora en el número de negocio también es una señal de alerta, no solo uso bajo.

Errores comunes al medir adopción

• Confundir “sistema instalado” con “sistema adoptado”: la fecha de lanzamiento no es la fecha en que se puede medir adopción, es apenas el punto de partida.
• Medir una sola vez, en el mes uno, y no volver a mirar el dato en el mes tres o seis, que es exactamente cuando la novedad se apaga y se ve el comportamiento real.
• Usar solo autopercepción (“¿usas la herramienta?” en una encuesta) sin cruzarla contra logs reales de actividad del sistema.
• No distinguir entre uso obligado por política (“hay que usarlo porque lo pidió el jefe”) y uso elegido por la persona porque le resuelve el trabajo más rápido que el método anterior.
• Premiar y reportar el número de logins en vez de premiar el resultado del proceso que el sistema debía mejorar: eso enseña al equipo a optimizar la métrica, no el trabajo.

Cómo se ve esto en la práctica

Una empresa de servicios legales implementó un sistema de IA para generar el primer borrador de contratos estándar. A los tres meses, el reporte interno mostraba noventa y tres por ciento de asistencia a la capacitación y todas las cuentas de abogados activas. El equipo de dirección lo dio por adoptado y siguió adelante con la siguiente prioridad.

Al revisar los logs reales del sistema (no la encuesta de satisfacción, los documentos efectivamente generados), aparecía otro cuadro: solo tres de catorce abogados habían generado un borrador nuevo en las últimas dos semanas. El resto seguía mandando el contrato base por correo a la asistente legal y pidiéndole que lo adaptara “como siempre”, exactamente el proceso que el sistema debía reemplazar. Las cuentas estaban activas porque alguien las había abierto una vez para la capacitación, no porque se usaran cada semana.

La señal de adopción de fachada apareció al cruzar dos datos: los picos de uso coincidían casi exactamente con las semanas en que el socio director pedía un reporte de uso al equipo, y caían el resto del mes. El sistema se usaba para la foto, no para el trabajo. Reconstruir eso llevó a entrevistar a los abogados que no lo usaban, y la razón real no era falta de capacitación: el sistema generaba borradores genéricos que igual había que reescribir casi por completo para casos con cláusulas particulares, así que para esos abogados el atajo viejo (pedirle a la asistente) seguía siendo más rápido que corregir el borrador de la IA.

Mi criterio sobre la adopción de fachada

Cómo saber que esta medición está bien hecha

• Frecuencia de uso en la tarea núcleo por persona y por semana, no uso general de la plataforma.
• Porcentaje de personas que abandonaron de verdad el proceso paralelo anterior, verificado y no solo declarado.
• Tasa de recomendación espontánea entre compañeros, detectada en conversación, no en una pregunta cerrada de encuesta.
• Distribución por persona y por rol, para exponer bolsones de resistencia que el promedio agregado esconde.
• Tendencia mes a mes del dato de uso real, no una sola foto tomada en el lanzamiento.
• Al menos un dato duro de negocio (tiempo de ciclo, volumen atendido, tasa de error) cruzado con el nivel de uso, no solo actividad dentro del sistema.

Si estas seis señales están en verde y sostenidas durante dos o tres meses seguidos, la adopción es real. Si el sistema pasa la primera medición pero se cae en la segunda, el problema no fue la capacitación inicial: fue que nadie volvió a mirar el dato después del lanzamiento.