Qué hace un Gerente de IA en una empresa

El puesto se abre después del primer fracaso, no antes

La conversación que más se repite en mi escritorio empieza así: la empresa ya invirtió. Compró licencias para todo el equipo, contrató a alguien que armó automatizaciones en una herramienta no-code, tiene un piloto de asistente interno que usa el 8% de la gente y otro que se apagó sin que nadie lo anunciara. Nadie sabe cuánto se gastó en total porque el gasto está repartido en tres áreas distintas. Y cuando el directorio pregunta qué retorno hubo, la respuesta es una demo bonita y ningún número. Ese es el momento exacto en que se abre el puesto de Gerente de IA.

El problema es que la empresa suele leer mal la causa. Concluye que le faltó capacidad técnica y sale a buscar a alguien que domine modelos, agentes y herramientas. Pero lo que falló no fue la técnica: las automatizaciones funcionaban, el asistente respondía, el modelo daba respuestas correctas. Lo que falló fue la decisión previa. Nadie eligió qué proceso valía la pena tocar, nadie definió qué número tenía que moverse, nadie preparó al área que iba a recibir el cambio y nadie tuvo la autoridad para decir que dos de esas tres iniciativas no debían haber empezado.

Por eso insisto con esto: la IA no reemplaza una mala priorización, la hace más cara y más visible. Un Gerente de IA existe para arreglar el problema de decisión, no el problema de implementación. Si contratas a esta persona esperando que el valor venga de su dominio técnico, vas a repetir el mismo ciclo con herramientas más nuevas y una factura más alta.

Qué es de verdad: un gerente de operaciones que entiende de IA

Un buen Gerente de IA se parece muchísimo más a un gerente de operaciones que a un ingeniero. Su materia prima no son los modelos, son los procesos de la empresa: dónde se pierde tiempo, dónde se cae información entre dos áreas, qué tarea repetitiva está consumiendo horas de gente cara, qué error operativo se paga en dinero todos los meses. Ese mapa es el que define qué hace la IA en la empresa, y ese mapa se construye con capacidad de análisis y gestión de procesos, no con dominio de herramientas.

El segundo componente del rol es la traducción. Dirección habla en márgenes, plazos y riesgo. El equipo técnico habla en integraciones, latencia y contexto. Entre esos dos idiomas se pierden la mayoría de proyectos: dirección aprueba algo que no entiende y técnica construye algo que nadie pidió. El Gerente de IA vive en ese medio y su valor se mide por cuánto reduce esa distancia. Tiene que poder explicarle al gerente comercial por qué su idea de agente de ventas no va primero, y explicarle al equipo técnico por qué el caso aburrido de conciliación de facturas sí va primero.

El tercer componente es el que menos se menciona en las descripciones de puesto y el que más pesa en la práctica: saber decir que no. En una empresa que se entusiasmó con IA, cada gerencia llega con su idea. El Gerente de IA que aprueba todo para quedar bien políticamente termina con doce iniciativas de bajo impacto y ningún resultado defendible. El que sabe frenar, argumentar el porqué y sostener la decisión en el comité es el que consigue que dos o tres casos lleguen a producción de verdad.

Qué hace en la semana real, sin adornos

Cuando alguien me pregunta cómo se ve el día a día del puesto, la respuesta desilusiona a quien esperaba trabajo de laboratorio. La agenda de un Gerente de IA se parece a la de cualquier gerente de operaciones que está sacando adelante un cambio transversal: muchas reuniones con áreas, mucho seguimiento, y bastante tiempo mirando datos de proceso para entender dónde está el cuello de botella real.

El trabajo concreto de la semana

• Mapear y priorizar casos de uso: levantar con cada área qué proceso duele, cuánto cuesta ese dolor en horas o en dinero, y ordenar la lista por impacto y viabilidad, no por entusiasmo del solicitante.
• Construir y defender el caso de negocio: qué se invierte, qué se espera mover, en cuánto tiempo, y qué pasa si no funciona. Sin esto, cualquier iniciativa se vuelve un gasto sin dueño.
• Coordinar a los que construyen: equipo interno, proveedor externo o ambos. Definir alcance, revisar entregables contra el resultado esperado y evitar que el proyecto crezca de tamaño sin que nadie lo note.
• Preparar al área que recibe el cambio: quién deja de hacer qué, quién revisa lo que produce el sistema, qué pasa cuando se equivoca y quién responde. La mayoría de implementaciones fallidas fallaron acá, no en el código.
• Definir y sostener la medición: acordar antes de empezar qué número se mira, con qué línea base, y revisarlo mes a mes aunque el resultado incomode.
• Cuidar el riesgo y las reglas: qué datos pueden entrar al sistema, qué decisiones no puede tomar la IA sin revisión humana, y cómo queda registrado lo que hizo el sistema.
• Matar lo que no funciona: cerrar pilotos que no movieron nada, documentar por qué y recuperar el presupuesto para el siguiente caso.

Fíjate en algo: de las siete responsabilidades, seis son de gestión y una sola roza lo técnico. Esa proporción no es un accidente de esta lista, es la forma real del puesto. Un Gerente de IA que pasa el 80% de su tiempo probando herramientas nuevas está haciendo el trabajo de otra persona y dejando el suyo sin hacer.

Qué NO es un Gerente de IA (y por qué el automatizador no califica)

La anti-tesis del rol tiene nombre y está muy bien pagada en el mercado actual: el automatizador. La persona que cobra por conectar herramientas, que te muestra un lienzo lleno de nodos y flechas, que entrega el flujo funcionando y se va. No tengo nada contra ese perfil, es un oficio legítimo y muchas veces necesario. El problema es contratarlo creyendo que va a hacer el trabajo de un Gerente de IA, porque su unidad de entrega es el flujo, no el resultado. Si le preguntas qué problema de negocio resuelve lo que acaba de construir, la respuesta honesta suele ser: el que me pidieron.

• No es el que más sabe de modelos y agentes. Ese conocimiento es útil, pero es insumo, no es el trabajo. Un especialista técnico puede sentarse a su lado; no debería sentarse en su silla.
• No es el jefe de sistemas con un sombrero nuevo. Sistemas cuida la infraestructura y la seguridad. El Gerente de IA cambia cómo trabajan las áreas, que es un problema de operación y de gente.
• No es un evangelizador interno. Dar charlas y armar comunidades de entusiastas no mueve ningún indicador si detrás no hay procesos rediseñados.
• No es un comprador de licencias. Firmar acuerdos con proveedores es la parte fácil y la que menos valor agrega. Cualquiera puede gastar el presupuesto.
• No es el dueño de todos los datos de la empresa. Necesita que los datos estén en orden, pero el gobierno de datos y su calidad son un trabajo aparte, con otro responsable.

Qué evaluar al contratar uno: negocio y procesos primero, credenciales después

Este es el punto donde más empresas se equivocan, y el error es sistemático: arman el perfil del puesto con una lista de tecnologías y descartan candidatos por no manejar la herramienta de moda. Un Gerente de IA se contrata por resultados entregados, no por títulos ni certificaciones. Lo que más pesa es la capacidad de análisis y de gestión de procesos. Todo lo demás se aprende o se compra.

Primero: criterio de negocio y gestión de procesos

• Que pueda contarte un proceso que rediseñó de punta a punta: cómo era antes, qué cambió, qué número se movió y en cuánto tiempo. Si solo puede describir la herramienta que usó, no rediseñó nada.
• Que tenga una decisión de no hacer que pueda defender. Pídele un caso en el que frenó un proyecto y por qué. Un candidato que nunca frenó nada, o nunca tuvo autoridad real, o nunca aplicó criterio.
• Que sepa priorizar delante de ti. Dale tres iniciativas reales de tu empresa y pídele que las ordene y justifique. Vas a ver en diez minutos si piensa en dolor y retorno o en qué es más entretenido de construir.
• Que explique cómo mediría el caso antes de construirlo. Línea base, indicador, plazo y qué evidencia lo haría abandonar el proyecto.
• Que sepa conducir una conversación difícil con un área. El 70% del trabajo es convencer a gente que no pidió el cambio. Pregúntale por la vez que un área se le opuso y qué hizo.
• Que hable de costo total y no solo de implementación. Mantenimiento, supervisión humana, cambios del proveedor y qué pasa cuando el sistema se equivoca a las tres de la mañana.
• Que tenga una historia de fracaso contada sin maquillaje. Lo que aprendió es más valioso para ti que cualquier caso de éxito pulido para la entrevista.

Después, y relativizado: la parte técnica

• Criterio técnico suficiente para no ser engañado, que no es lo mismo que dominio. Debe distinguir una promesa razonable de una que va a costar el triple de mantener.
• Entendimiento de riesgos de datos: qué información no puede salir de la empresa y qué decisiones exigen revisión humana. Esto sí es innegociable, aunque no requiere ser ingeniero.
• Capacidad de evaluar a un proveedor: saber qué preguntar sobre alcance, soporte y qué pasa el día que se van. Es una habilidad de compras técnicas, no de programación.
• Certificaciones y cursos: útiles como señal de interés, irrelevantes como predictor de desempeño. Nunca ordenes tu lista corta de candidatos por esto.

Cuándo abrir el puesto y cuándo estás adelantando un costo fijo

Tiene sentido abrirlo cuando

• Ya hay varias iniciativas de IA activas en áreas distintas, sin nadie que las priorice ni las conecte entre sí.
• El presupuesto de IA dejó de ser un experimento puntual y se volvió un gasto recurrente que alguien tiene que defender ante el directorio.
• Hay proveedores externos trabajando sin un dueño interno claro, y las decisiones de alcance las está tomando el proveedor.
• La empresa ya vivió una implementación que no dio resultado y necesita entender por qué antes de volver a invertir.
• Existen procesos transversales, que cruzan dos o tres áreas, donde nadie tiene autoridad para rediseñar de punta a punta.

Todavía no lo abras si

• Tienes una sola automatización funcionando y ninguna hoja de ruta. Un gerente sin cartera de casos se convierte en un costo buscando trabajo.
• Dirección no está dispuesta a darle autoridad para frenar iniciativas de otras gerencias. Sin ese mandato, el puesto es decorativo.
• El problema real es de datos desordenados y procesos sin documentar. Eso se arregla antes, y no necesariamente con este perfil.
• Lo abres para tener a alguien a quien culpar cuando el próximo proyecto no funcione. Ese puesto se quema en seis meses y el problema de fondo sigue igual.

Errores típicos que veo en empresas reales

• Contratar al perfil más técnico de la lista corta porque impresionó en la entrevista con vocabulario que nadie en el comité entendió. Seis meses después hay una arquitectura elegante y ningún proceso mejorado.
• Colgar el puesto de sistemas. El rol pierde acceso político a las áreas y termina midiéndose por entregas de software en vez de por impacto operativo.
• Darle responsabilidad sin presupuesto ni autoridad. Un gerente que tiene que pedir permiso a tres gerencias para tocar un proceso no va a mover nada relevante en su primer año.
• Pedirle una hoja de ruta de dos años en su primera semana. Lo que necesitas de él en los primeros noventa días es un diagnóstico honesto y dos casos priorizados, no un plan de diapositivas.
• Evaluarlo por cantidad de proyectos lanzados. Ese indicador premia exactamente el comportamiento que quieres evitar: decir que sí a todo y no terminar nada.
• Confundir su rol con el del proveedor. Si el proveedor decide qué se construye y en qué orden, ya no tienes un Gerente de IA, tienes un coordinador de tickets con título de gerente.

Cómo saber a los seis meses si el Gerente de IA está funcionando

La evaluación de este puesto se presta a la vanidad: número de iniciativas lanzadas, herramientas implementadas, gente capacitada, charlas internas dictadas. Nada de eso te dice si la empresa está mejor. Las señales que sí importan son incómodas de mirar porque exigen comparar con una línea base que alguien debió registrar antes de empezar.

• Procesos con antes y después medible: al menos dos procesos concretos con tiempo, costo o tasa de error documentados antes de la intervención y después de ella.
• Uso sostenido pasado el tercer mes: si el área volvió a su método anterior en cuanto bajó la presión, el proyecto no se adoptó, solo se lanzó.
• Decisiones de cierre tomadas: cuántas iniciativas frenó o apagó a tiempo, con el motivo documentado. Cero cierres en seis meses es una señal mala, no buena.
• Costo por caso en producción, no gasto total: cuánto costó llevar cada caso a operación estable, incluyendo mantenimiento, no solo la implementación inicial.
• Reducción de dependencia del proveedor externo: si al sexto mes la empresa entiende y puede operar lo que compró, el gerente hizo su trabajo. Si nadie interno sabe cómo funciona, no.
• Las áreas lo buscan por iniciativa propia: cuando operaciones o comercial vienen a proponerle un caso sin que se los pidan, el rol dejó de ser una imposición y se volvió útil.
• Riesgos bajo control: reglas claras de qué datos entran, qué decisiones exigen revisión humana y registro de lo que hizo el sistema. Que nada haya explotado no es lo mismo que estar cubierto.

Si a los seis meses no puedes señalar ni un solo proceso con números antes y después, el problema rara vez es la persona sola. Casi siempre es que el puesto se abrió sin mandato, sin presupuesto propio o sin acceso a las áreas donde estaba el dolor. Antes de cambiar al gerente, revisa si alguna vez le diste las condiciones para hacer el trabajo por el que lo contrataste.