Cómo hacer el onboarding de un sistema de IA en tu empresa

El error que se repite en cada lanzamiento

El patrón se repite con tanta frecuencia que ya se puede describir con precisión: una empresa compra o construye un sistema de IA, agenda una capacitación de una hora para el equipo que lo va a usar, cierra la sesión con una ronda de preguntas y da por hecho que el uso llegará solo en las semanas siguientes. En una empresa de manufactura mediana en México, el área de compras recibió justo ese tipo de sesión sobre un sistema que debía sugerir el momento óptimo para reordenar insumos críticos. Pasada la primera semana, el jefe de compras seguía decidiendo el reorden por el mismo criterio de siempre: el correo del proveedor y la hoja de cálculo que ya conocía de memoria.

El sistema no era el problema. Nadie había tocado el proceso de compra en sí: el correo con el proveedor seguía llegando igual, la hoja de cálculo seguía abierta en la pantalla de al lado, y nadie había dicho con claridad en qué paso exacto del proceso debía intervenir el sistema nuevo ni qué pasaba si el equipo prefería seguir con el camino de siempre. Cuando el atajo viejo sigue abierto y sigue funcionando lo suficientemente bien, gana el atajo. No por resistencia al cambio, sino porque cambiar de herramienta sin cambiar el proceso le pide al equipo un esfuerzo extra sin quitarle ninguno.

Esto se repite en sectores muy distintos con el mismo desenlace. En un contact center mediano en Argentina, el sistema que debía resumir llamadas y sugerir la siguiente acción quedó relegado a un puñado de agentes curiosos, mientras el resto seguía llenando el mismo formulario manual que usaba desde antes. El error de fondo es siempre el mismo: se trató el lanzamiento de un sistema de IA como un evento de comunicación, una sesión, un correo, un anuncio, en lugar de tratarlo como lo que en realidad es, un cambio operativo que necesita su propio plan.

Qué es el onboarding de un sistema de IA, en criterio de negocio

Antes de entrar en el plan conviene separar dos cosas que se confunden todo el tiempo: enseñarle a alguien a usar una pantalla y lograr que un sistema quede incrustado en cómo la empresa opera todos los días. La primera es una sesión de capacitación, y ese tema ya se trabaja a fondo en la guía de cómo capacitar al equipo para adoptar IA. La segunda es un plan operativo de lanzamiento, y es exactamente de lo que trata esta página.

Esa definición tiene una palabra que suele pasarse por alto: plan. No es una charla ni un manual, es una secuencia de decisiones operativas que alguien tiene que tomar antes del primer día de uso: en qué paso del proceso entra el sistema, quién queda a cargo de sostenerlo en el área, qué se hace cuando el sistema no sabe responder, y qué número se va a revisar para saber si de verdad se está usando.

Vale además la aclaración que ya está en el propio nombre del término: esto es el onboarding del sistema, no el onboarding de una persona nueva que se suma al equipo, que es un tema distinto cubierto en la guía de cómo hacer el onboarding de una persona de IA. Tampoco es lo mismo que la adopción de IA en general, un concepto más amplio que se desarrolla en la página qué es la adopción de IA: el onboarding del sistema es el plan puntual de los primeros días y semanas, la adopción es el resultado sostenido en el tiempo que ese plan busca conseguir.

Definir el momento exacto del proceso donde entra el sistema

El primer error de casi todo lanzamiento es lanzar el sistema para el área en general, en lugar de para un paso específico del proceso. Un sistema de IA que se presenta como una herramienta disponible para todo lo que el equipo necesite no tiene un momento de uso, y lo que no tiene un momento de uso definido termina, casi siempre, sin usarse. El plan de onboarding empieza por señalar, con precisión de reloj, el punto exacto de la operación donde el sistema debe intervenir.

• ¿En qué paso del proceso, no del área, entra el sistema: al recibir el caso, al aprobar la excepción, al armar la cotización, al cerrar el turno?
• ¿Quién toca ese paso hoy y qué hace exactamente antes de que el sistema exista, para saber qué reemplaza y qué no?
• ¿Qué decisión cambia con el resultado del sistema: se aprueba distinto, se prioriza distinto, se responde más rápido?
• ¿Qué dato o evento dispara la entrada del sistema, para que quede claro cuándo sí corresponde usarlo y cuándo no?
• ¿Qué pasa justo después de que el sistema entrega su resultado: quién lo mira, quién decide, quién queda registrado como responsable?

Cuando esta pregunta no se responde antes del lanzamiento, cada persona del equipo termina decidiendo por su cuenta si el sistema aplica o no a su caso, y esa decisión individual, tomada bajo presión de tiempo, casi siempre se resuelve a favor del camino que ya conoce de memoria.

Cerrar el camino viejo: si el atajo sigue abierto, gana el atajo

Ningún sistema de IA compite en igualdad de condiciones contra un atajo que ya funciona y que el equipo domina de memoria. El plan de onboarding tiene que incluir, con la misma seriedad que el lanzamiento del sistema, el cierre explícito del camino anterior. No basta con presentar el sistema nuevo como alternativa disponible: mientras el atajo viejo siga ahí, cómodo y sin fricción, seguirá ganando, porque no exige ningún esfuerzo de aprendizaje.

• Retirar de la carpeta compartida la plantilla o macro que el equipo usaba antes, en lugar de dejarla ahí por si acaso.
• Cerrar el canal informal donde se resolvía el mismo paso del proceso, como el chat directo con el área que antes aprobaba a mano.
• Fijar una fecha de corte real, comunicada con anticipación, después de la cual el camino viejo deja de ser una opción válida.
• Nombrar en voz alta, frente al equipo, cuál era el atajo que se está cerrando y por qué, en lugar de dar por hecho que todos lo saben.
• Revisar, pasadas dos semanas, si alguien reabrió el atajo por su cuenta, porque esa es la señal más clara de que el cierre no fue real.

Cerrar el camino viejo suele sentirse más incómodo que lanzar el sistema nuevo, porque implica una decisión visible: alguien tiene que decir que esa hoja de cálculo, ese correo o ese comité informal ya no es el camino oficial. Esa incomodidad es exactamente la señal de que el cierre importa. Un lanzamiento que no genera ninguna fricción casi nunca cerró nada de verdad.

Nombrar al champion del área y escribir qué pasa cuando el sistema falla o duda

Un sistema sin nadie que responda por él dentro del área se abandona apenas aparece el primer caso raro. Por eso el plan de onboarding necesita un nombre propio, no un área genérica: la persona que sostiene el uso del sistema en el día a día, resuelve dudas de los compañeros y reporta lo que no está funcionando. Este rol ya tiene nombre en este glosario, se llama champion de IA, y su ausencia es una de las razones más comunes por las que un sistema bien construido termina sin uso real.

Junto con el champion, el plan tiene que escribir, antes del primer día de uso, qué hace el equipo cuando el sistema falla, duda o entrega un resultado que no cuadra con lo que la persona espera. Sin ese protocolo escrito, cada persona improvisa su propia respuesta frente al error, y la improvisación más común es simplemente dejar de usar el sistema.

• A quién se avisa cuando el sistema entrega un resultado dudoso: el champion, un canal específico, no a quien esté disponible en ese momento.
• Qué pasa con el caso mientras se resuelve la duda: se detiene, se deriva a revisión humana, o se marca para seguimiento posterior.
• Cómo queda registrado ese fallo, para que el mismo error no se repita sin que nadie lo note la semana siguiente.
• Cada cuánto revisa el champion los casos marcados como dudosos, en lugar de esperar a que alguien se queje primero.

Este protocolo no busca que el sistema nunca falle, eso no es realista con ningún sistema de IA. Busca que cuando falle, el equipo sepa exactamente qué hacer en los primeros minutos, en lugar de perder la confianza en el sistema completo por un solo caso mal resuelto.

El primer número que se revisa a los 30 días

Todo plan de onboarding necesita una fecha de revisión fijada desde el lanzamiento, no una intención de ver cómo va con el tiempo. La fecha que mejor funciona en la práctica es el día treinta: suficiente tiempo para que el equipo haya probado el sistema en casos reales, y todavía cerca del lanzamiento como para corregir algo antes de que la costumbre vieja vuelva a instalarse por completo.

El número que se revisa ese día no debería ser una cifra de satisfacción ni una encuesta de percepción. Tiene que ser un dato de uso real: cuántos de los casos que debían pasar por el sistema, según el momento exacto del proceso definido al inicio, en realidad pasaron por él. Si ese número es bajo, la causa casi nunca es que el sistema sea malo, casi siempre es que el atajo viejo sigue abierto en algún rincón del proceso, o que nadie definió con claridad ese momento de entrada.

Cómo construir ese número con criterio, y qué hacer cuando sale bajo, es exactamente el tema que desarrolla en profundidad la guía de cómo medir la adopción real de un sistema de IA. Lo que corresponde fijar dentro del plan de onboarding es solo la fecha y el compromiso de mirar ese número sin excusas, no la metodología completa de medición.

Mi criterio

Cuándo el onboarding del sistema está bien hecho y cuándo va a fallar

No todo lanzamiento necesita el mismo nivel de formalidad, pero sí conviene reconocer a tiempo las señales que distinguen un plan de onboarding que va a sostenerse de uno que se va a apagar solo en unas semanas.

Señales de que el onboarding del sistema está bien hecho

• Existe un momento exacto del proceso, no un área completa, donde el equipo sabe que el sistema debe entrar.
• El camino anterior tiene una fecha de cierre real y ya no está disponible como opción cómoda.
• Hay una persona con nombre propio, el champion del área, que responde por el uso del sistema día a día.
• Está escrito, no solo hablado, qué hacer cuando el sistema falla o entrega un resultado dudoso.
• Existe una fecha fijada para revisar un número de uso real, antes de que se cumplan los primeros treinta días.

Señales de que el onboarding va a fallar

• El lanzamiento se resume en una sola sesión de capacitación, sin ningún cambio visible en el proceso de trabajo.
• El equipo puede seguir resolviendo el mismo paso por el camino de siempre sin que nadie lo note ni lo cuestione.
• Nadie del área puede decir, sin dudar, quién es la persona responsable de sostener el uso del sistema.
• No existe ninguna instrucción escrita sobre qué hacer frente a un resultado que el sistema entrega mal o dudoso.
• La primera revisión de uso real, si es que existe, se agenda para más adelante sin una fecha concreta.

El orden correcto aplicado al lanzamiento de un sistema

El onboarding de un sistema de IA que funciona respeta el mismo orden que cualquier cambio operativo serio. Primero el dolor real: el paso del proceso que hoy le cuesta tiempo, calidad o dinero a la empresa, nombrado sin todavía hablar de tecnología. Después el proceso: decidir en qué momento exacto entra el sistema y qué camino anterior se cierra para que no compita con él. Luego el dato: qué número de uso real se va a revisar, y cuándo, para saber si el cambio ocurrió de verdad o solo se anunció. Recién al final la herramienta, el sistema de IA en sí, que sin ese orden previo termina siendo la parte más fácil y la menos determinante de todo el lanzamiento.

Cuando ese orden se invierte, y el sistema llega primero con una sesión de capacitación como único gesto de acompañamiento, lo que queda semanas después es exactamente el escenario con el que arranca esta página: un equipo que asintió en la sesión, un atajo viejo que nunca se cerró, y un sistema que, con toda su capacidad técnica intacta, nadie usa.