Cómo hacer el onboarding de una persona de IA recién contratada

El error de tratar el onboarding de IA como un onboarding técnico

La empresa hizo el proceso de contratación bien. Entrevistó a varios candidatos, pidió portafolio de proyectos anteriores, revisó referencias con cuidado. El problema empezó el primer lunes: le entregaron una laptop, acceso a un par de modelos de IA y un canal de Slack para “explorar casos de uso”. A los tres meses, la persona había producido una carpeta de demos internas, un par de presentaciones sobre “el potencial de la IA para la empresa” y cero procesos movidos. El gerente que aprobó la contratación se preguntaba, con razón, para qué estaba pagando ese sueldo.

Esto no es un caso raro. Es el patrón más común cuando RRHH o dirección onboardean a una persona de IA igual que onboardearían a un analista de sistemas: acceso a herramientas, documentación técnica, un sandbox para practicar. El error de fondo es pensar que el trabajo de esta persona es dominar modelos. No lo es. Su trabajo es mover un proceso real de negocio, y para eso necesita entender el negocio antes que la tecnología.

Sin acceso al dolor real de la operación, sin un proceso concreto asignado y sin un dueño de negocio que valide si el trabajo sirve, la persona llena su tiempo con lo único que tiene a la mano: probar herramientas. No por flojera, sino porque nadie le dio otra cosa que hacer. El resultado a los noventa días es previsible: cero resultado medible, un equipo que empieza a verla como “el proyecto de IA” en lugar de alguien que resuelve problemas, y una alta probabilidad de que el puesto se recorte en la siguiente revisión de presupuesto.

La IA no reemplaza una mala decisión, la expone más rápido. Y un mal onboarding es una mala decisión que se expone en tiempo récord: en dos o tres meses ya es evidente que la contratación “no funcionó”, cuando en realidad lo que no funcionó fue el proceso de integración, no la persona.

Qué es el onboarding de una persona de IA (y qué no es)

Antes de diseñar el proceso, hay que tener claro qué se está onboardeando. No es una posición técnica que necesita rampa de herramientas. Es una posición operativa que necesita rampa de negocio.

• No es un curso de herramientas: sentarla una o dos semanas a revisar documentación de modelos, plataformas o agentes antes de tocar un proceso real.
• No es acceso libre y sin dueño: darle usuario en todos los sistemas de la empresa sin asignarle un proceso concreto con un responsable de negocio detrás.
• No es un sprint de demos: pedirle “casos de uso” o “ideas de IA” sin conectarlos a un problema puntual que alguien está sufriendo hoy.
• No es solo capacitación técnica: enseñarle el stack interno sin enseñarle cómo opera el negocio, quién decide qué y dónde está el cuello de botella real.
• No es un evento de un día: una charla de bienvenida y una carpeta de accesos no es onboarding, es papeleo. El onboarding real dura semanas y tiene seguimiento activo.

Hay una señal que aparece rápido si el onboarding está mal armado: la persona habla todo el tiempo en jerga de agentes, modelos y prompts, y no logra explicar en una frase qué proceso de negocio va a mover ni qué número piensa mejorar. Eso no es un gerente de IA en formación, es el automatizador que cobra por conectar herramientas. Ese contraste y cómo revertirlo está desarrollado en el recorrido /recursos/roadmap-ia-de-automatizador-a-gerente-ia y en /contenido/de-automatizador-a-gerente-ia: un buen onboarding es, de hecho, la primera oportunidad real para empujar a una persona de un perfil al otro.

Primeras semanas: exposición al dolor real del negocio, no a la tecnología

El onboarding correcto invierte el orden que casi todas las empresas usan por defecto. Antes de que la persona toque un modelo o una herramienta, necesita entender cómo gana dinero la empresa, dónde se pierde tiempo hoy y quién sufre el cuello de botella con nombre y apellido.

Qué debe pasar en la primera semana

• Reunión con el dueño de cada proceso candidato: no con el área de sistemas, con la persona que opera el proceso día a día y conoce su dolor de memoria.
• Revisión de datos operativos crudos: tiempos de ciclo, volumen de casos, tasa de error, costos reales, no una presentación corporativa sobre “la empresa”.
• Sombra de operación: una o dos jornadas completas observando cómo trabaja hoy el equipo que sufre el problema, sin proponer soluciones todavía.
• Mapa de decisiones: quién aprueba qué, dónde se atasca una solicitud, qué depende de criterio humano y qué es puramente mecánico y repetitivo.

Qué NO debe pasar en la primera semana

• Instalar o probar media docena de herramientas antes de tener claro qué proceso concreto se va a intervenir.
• Reunirse solo con el área técnica: si al terminar la semana uno no habló con ventas, operaciones, atención al cliente o el área que sufre el dolor, el onboarding está mal armado.

Esta primera etapa no produce entregables vistosos, y eso incomoda a algunos gerentes acostumbrados a medir avance por demos. Pero es la inversión que determina si el resto del onboarding produce resultado o solo actividad.

Acceso a los datos y a un proceso concreto, con dueño

El segundo bloque del onboarding es darle a la persona lo que de verdad necesita para trabajar: datos reales y un proceso acotado con un responsable que va a decir si el resultado sirve.

• Acceso a la fuente, no al resumen: bases de datos, CRM, ERP, sistema de tickets, no solo el dashboard ejecutivo que ya existe y que suaviza los problemas.
• Un proceso, no un área completa: asignarle “todo el marketing” o “toda la logística” equivale a no asignarle nada. Asignarle “la calificación de leads entrantes” o “el armado del reporte diario de rutas” sí es un proceso.
• Un dueño de negocio identificado por nombre: alguien que sufre el proceso hoy, con autoridad para validar si el cambio propuesto funciona o no.
• Permisos reales, no una cuenta de prueba con datos ficticios: trabajar sobre información de mentira produce soluciones de mentira.

Cuando este acceso no existe, la persona termina construyendo prototipos con datos de ejemplo, presentándolos como “prueba de concepto” y descubriendo semanas después que el proceso real tiene excepciones, sistemas paralelos y reglas no escritas que ningún documento menciona. Ese descubrimiento tardío es el que hace que un proyecto de IA que “se veía bien” nunca llegue a producción.

El primer proyecto: acotado, con resultado medible

Con el contexto de negocio y el acceso a datos resueltos, el onboarding necesita un tercer componente: un primer proyecto pequeño, con una meta numérica clara y una fecha de entrega corta.

• Alcance chico, impacto real: un proceso, un indicador, no una transformación completa del área en el primer mes.
• Meta numérica desde el día uno: reducir el tiempo de respuesta de un trámite, bajar la tasa de error de un registro manual, subir la conversión de un paso puntual del embudo.
• Ventana corta de entrega: entre treinta y cuarenta y cinco días para un primer resultado visible, no un trimestre entero calificado como “fase de investigación”.
• Validación con el dueño del proceso, no con el área de tecnología: si quien sufre el dolor no confirma la mejora, no hay resultado, hay opinión técnica.

El objetivo de este primer proyecto no es demostrar sofisticación técnica. Es demostrar que la persona puede tomar un problema real, acotarlo, resolverlo con evidencia y devolver un número que antes no existía. Todo lo demás (el stack, el modelo elegido, la arquitectura) es un medio, no el resultado.

El referente interno y qué medir en las primeras semanas

El cuarto componente es humano: alguien dentro de la empresa que acompañe a la persona de IA durante el onboarding y que no sea del área técnica.

Qué debe hacer el referente

• Traducir contexto de negocio: explicar por qué un proceso funciona como funciona, qué se intentó antes y por qué falló.
• Abrir puertas: presentar a la persona con los dueños de proceso de otras áreas, sin que tenga que pedir cada reunión por su cuenta.
• Dar retroalimentación honesta, no técnica: si el primer avance no conecta con el dolor real, decirlo pronto, no al cierre del trimestre.

Qué medir en las primeras semanas

• Número de reuniones con áreas de negocio, no con sistemas o tecnología.
• Un proceso concreto identificado y validado por su dueño antes de que termine el primer mes.
• Avance del primer proyecto piloto contra el plan acordado, con fecha y meta numérica.
• Retroalimentación cualitativa del dueño del proceso: ¿siente que la persona entendió su dolor o que le vendió una herramienta?
• Tiempo hasta el primer resultado medible, aunque sea pequeño: es el mejor indicador de que el onboarding funcionó.

Cómo se ve en la práctica

Una distribuidora mediana, alrededor de ochenta personas, en Perú, contrató a una persona de IA después de meses de escuchar que “la competencia ya está usando esto”. El onboarding inicial fue el típico: laptop, acceso a un par de herramientas, la instrucción de “explorar oportunidades”. Los primeros dos meses produjeron tres presentaciones internas sobre posibles casos de uso y ningún cambio en ninguna operación. El gerente de logística, que había pedido ayuda hacía un año con el armado manual del reporte diario de rutas de despacho, seguía haciéndolo a mano.

Cuando la dirección revisó el caso, cambió el enfoque del onboarding, no a la persona. La semana siguiente, en lugar de reuniones con sistemas, se organizaron sesiones con el área de despacho. La persona pasó dos jornadas completas junto al despachador, viendo cómo armaba el reporte cada mañana: qué sistemas consultaba, qué reglas no escritas aplicaba, dónde perdía más tiempo.

De ahí salió un primer proyecto acotado: automatizar el armado de ese reporte diario, con el despachador como dueño del proceso y validador directo del resultado. En menos de un mes, la persona entregó una primera versión funcional. El tiempo que el área de despacho dedicaba cada mañana a armar el reporte manualmente bajó de forma sostenida, semana tras semana, algo que el propio despachador pudo confirmar sin que nadie tuviera que explicárselo con una presentación.

Ese primer resultado, pequeño pero real, cambió la conversación interna sobre la contratación: de “no sabemos para qué le pagamos” a “necesitamos que revise el siguiente proceso”. La diferencia no fue la persona ni la tecnología disponible. Fue el onboarding.

Mi criterio

Cómo saber si hiciste bien el onboarding

El onboarding de una persona de IA no se evalúa por cuántas herramientas probó ni por cuántas presentaciones dio. Se evalúa por si logró producir, en sus primeras semanas, un resultado conectado a un dolor real del negocio. Esta checklist sirve para revisarlo con honestidad.

• ¿Habló primero con el negocio, no con sistemas? Si sus primeras reuniones fueron con dueños de proceso y no con el área técnica, vas bien.
• ¿Tiene un proceso concreto asignado, con dueño identificado? No un área completa, un proceso puntual con un responsable que valida el resultado.
• ¿Accedió a datos reales, no a una cuenta de prueba? Si trabaja sobre información ficticia, cualquier resultado también lo será.
• ¿Entregó un primer resultado medible en menos de dos meses? Aunque sea pequeño, tiene que existir un número de antes y un número de después.
• ¿El dueño del proceso lo describe en términos de negocio, no de tecnología? Si dice “nos ahorró tiempo” en vez de “sabe mucho de IA”, el onboarding funcionó.

Si tres o más de estas respuestas son negativas a los sesenta días, el problema no es esperar más tiempo. Es rediseñar el onboarding: menos acceso a herramientas, más acceso al dolor real del negocio.