Quién lidera un proyecto de IA en una empresa (y quién no debería)

El proyecto que “avanza” sin mover nada

Una aseguradora mediana arranca un proyecto para anticipar qué pólizas van a caer en mora. El área de sistemas firma el contrato con el proveedor, conecta los datos, entrena el modelo, entrega un tablero con el riesgo de cada póliza actualizado cada noche. En la demo del comité todos aplauden: el modelo acierta, la integración corre sola, el dashboard se ve bien. Seis meses después nadie en cobranzas cambió su rutina. Siguen llamando en el mismo orden de la lista de siempre, porque nadie con autoridad le dijo al área que a partir de ahora la prioridad la marca el modelo y no la antigüedad del expediente. El proyecto “funciona” en el sentido técnico y no existe en el sentido de negocio.

Esto no pasa por mala fe ni por incompetencia de nadie en particular. Pasa porque la pregunta de quién lidera se resolvió por default, a favor de quien firmó el primer contrato con el proveedor y tenía el presupuesto de tecnología para hacerlo. Sistemas puede construir el modelo y entregar la integración. Lo que sistemas no puede hacer, porque nadie se lo dio, es entrar a la oficina del gerente de cobranzas y decirle que su equipo va a trabajar distinto a partir de mañana. Y sin esa autoridad, el proyecto se queda exactamente donde nació: en la infraestructura, sin tocar el proceso que era, desde el principio, el verdadero objetivo.

Las cuatro manos que se disputan el mando

Cuando una empresa lanza un proyecto de inteligencia artificial casi nunca alguien se sienta a decidir con calma quién va a liderarlo. La pregunta se resuelve sola, casi siempre a favor de quien tiene el presupuesto o el contacto con el proveedor. Pero en la práctica compiten cuatro candidatos, y cada uno gana algo real y pierde algo real:

• Sistemas (o TI): gana velocidad de ejecución y dominio técnico sobre datos, modelos e integraciones. Pierde mandato sobre el resto de la empresa: no puede exigirle a ventas, cobranzas u operaciones que cambien cómo trabajan, así que el proyecto termina midiéndose por entregas técnicas (modelo entrenado, API conectada) en lugar de por el proceso que debía transformar.
• Operaciones: gana autoridad natural sobre el proceso y la costumbre de medir con indicadores de negocio, no de tecnología. Pierde criterio técnico propio para juzgar si un proveedor promete algo razonable o si un modelo está listo para producción, y por eso necesita apoyarse en alguien que sí domine esa parte.
• Un comité: gana que la decisión se reparte entre varias áreas y ninguna gerencia se queda con todo el poder sobre el proyecto. Pierde casi siempre velocidad: nadie firma solo, todo pasa por consenso, y un proyecto que depende de que cinco gerentes se pongan de acuerdo cada semana avanza a la velocidad del más lento del grupo.
• Un externo (proveedor o consultor): gana experiencia acumulada en proyectos parecidos en otras empresas y no carga con intereses de área que defender puertas adentro. Pierde autoridad formal dentro de la organización: puede recomendar, no puede exigir, y el día que un gerente decide ignorar la recomendación, el externo no tiene forma de hacer que se cumpla.

Esta pregunta (quién lidera este proyecto puntual) es distinta, aunque está emparentada, de quién lidera el gobierno de IA en toda la empresa: esa segunda instancia decide con qué reglas y límites se ejecutan todos los proyectos presentes y futuros, no solo el que tienes enfrente.

Por qué sistemas es la opción por defecto, y por qué se queda corta

Sistemas termina liderando la mayoría de proyectos de IA por una razón simple: es el área que entiende el lenguaje del proveedor, la que sabe qué es una API y un pipeline de datos, y la que suele controlar el presupuesto de tecnología. Ninguna de esas ventajas es menor. El problema aparece cuando esa competencia técnica se confunde con mandato de negocio, que es algo completamente distinto y que sistemas casi nunca tiene.

La consecuencia se ve siempre igual. Como sistemas no puede ordenarle a otra área que cambie su forma de trabajar, el proyecto se termina midiendo con los indicadores que sistemas sí controla: si el modelo entrena, si la integración no se cae, si el dashboard carga a tiempo. Son métricas legítimas de un proyecto técnico y completamente ciegas a la pregunta real, que es si cobranzas, ventas o el área que corresponda cambió algo en cómo decide todos los días. No es un defecto de las personas de sistemas: es un problema de diseño, de haberle puesto el proyecto a quien no tenía, desde el inicio, el poder de tocar el proceso ajeno.

Por qué operaciones suele ser la mejor casa

Operaciones (o el área dueña del proceso que la IA va a tocar) parte con dos ventajas que ninguna otra opción junta: ya tiene autoridad reconocida sobre cómo trabaja su gente, y ya mide su desempeño con indicadores de negocio (tiempo de ciclo, tasa de conversión, mora, rotación) en lugar de indicadores de entrega técnica. Cuando operaciones lidera, la pregunta de fondo deja de ser “¿el modelo funciona?” y pasa a ser “¿bajó la mora, subió la conversión, se redujo el tiempo de respuesta?”, que es la pregunta que en realidad le importa al negocio.

La condición para que esto funcione es que operaciones no intente sustituir el criterio técnico que no tiene. Necesita a alguien, interno o externo, que le diga con honestidad si un modelo está listo, si el proveedor promete algo razonable y qué límites tiene la solución. Liderar no significa saber programar el modelo: significa tener la autoridad y la responsabilidad de que el proceso cambie, y sostener esa gestión del cambio en el proyecto de IA frente a su propia gente, que es exactamente la parte que sistemas no puede hacer por ellos.

El mandato explícito que necesita quien lidera

No basta con nombrar a alguien “líder del proyecto” en un correo. El mandato tiene que ser explícito, escrito y venir de quien tiene autoridad sobre todas las áreas involucradas (gerencia general o el nivel equivalente), porque lo que se está autorizando es que una persona entre a territorio de otra gerencia. Sin ese respaldo por escrito, el líder queda dependiendo de la buena voluntad de cada gerente de área, y la buena voluntad se agota en la primera semana difícil.

• Qué procesos y qué áreas puede tocar, nombrados uno por uno, no “todo lo relacionado con IA” en abstracto.
• Qué puede exigir sin pedir permiso cada vez, como acceso a datos, tiempo de un equipo o un cambio puntual de rutina.
• A quién escala cuando un gerente de área se niega, y en cuánto tiempo esa escalada tiene que resolverse.
• Cómo se mide su éxito, en indicadores de proceso y de negocio, nunca solo en hitos técnicos entregados.

Un Gerente de IA sin ese mandato por escrito termina en la misma trampa que sistemas: con el título de líder y sin el poder real de mover nada fuera de su propia área.

Qué decisiones puede tomar solo, sin subir la escalera

Un mandato mal diseñado castiga en los dos sentidos: si el líder tiene que subir cada decisión a gerencia general, el proyecto se vuelve tan lento como un comité. Si puede decidir cualquier cosa sin reportar a nadie, tarde o temprano atropella a un área sin haberla escuchado. Lo que funciona es una lista corta y explícita de lo que decide solo:

• Priorizar qué proceso ataca primero dentro del alcance ya aprobado del proyecto, sin pedir turno cada vez que cambia el orden.
• Pausar o rechazar una entrega del proveedor que no cumple lo prometido, sin esperar a la siguiente reunión de comité para decirlo.
• Pedir datos y tiempo de un equipo de las áreas ya incluidas en el mandato, dentro de límites razonables ya conversados.
• Ajustar el alcance de un piloto (qué región, qué producto, qué volumen de casos) para aprender más rápido sin comprometer todo el proceso de una vez.

Lo que no decide solo es todo lo que implica incluir una nueva área que no estaba en el mandato original, cambiar el presupuesto aprobado o extender el proyecto a un proceso que ninguna gerencia autorizó tocar. Esa línea, entre lo operativo del día a día y lo que redefine el alcance, es la que hay que dejar escrita antes de arrancar, no negociarla a mitad de camino.

Cómo conviven el líder interno y el proveedor externo

El error más común es tratar esto como una competencia: o lidera el interno o lidera el externo. En los proyectos que de verdad avanzan, los dos cumplen roles distintos y complementarios. El proveedor o consultor de IA aporta lo que la empresa no tiene todavía: experiencia técnica acumulada en proyectos parecidos, criterio para evaluar si un modelo está listo y una mirada que no está contaminada por la política interna. El líder interno aporta lo que ningún externo puede tener el primer día: mandato, conocimiento fino del proceso real y la relación de confianza con la gente que va a tener que cambiar su rutina.

Cuando esta división no queda clara por escrito, pasan dos cosas malas. O el externo termina tomando decisiones de negocio que no le corresponden porque nadie interno se hizo cargo, o el interno se esconde detrás del proveedor cada vez que hay que dar una noticia incómoda a otra gerencia. Ninguna de las dos deja al proyecto con un dueño real. Por eso armar un equipo de IA interno no significa prescindir del externo: significa tener a alguien adentro con la autoridad y la continuidad que el proveedor, por definición, no se queda a sostener cuando el contrato termina.

Mi criterio sobre quién debería tener la última palabra

Qué pasa cuando nadie lidera: el proyecto no muere, se apaga

Cuando nadie tiene mandato claro, el proyecto no colapsa de un día para otro. Se apaga despacio. Aparecen dos o tres personas que dicen ser “parte del liderazgo”, ninguna con autoridad completa. Sistemas sigue entregando versiones del modelo que nadie termina de usar. Operaciones asiste a las reuniones pero no cambia su proceso, porque técnicamente nadie se lo ordenó. El proveedor manda reportes de avance cada vez menos leídos. Nadie decide matarlo formalmente: en algún momento, seis o nueve meses después, alguien en el comité pregunta qué pasó con “aquel proyecto de IA” y la respuesta es un silencio incómodo, no un fracaso que se pueda señalar con un nombre.

No decidir quién lidera es, en los hechos, decidir que nada va a cambiar. Es la forma más cara de fracasar, porque no deja ni el aprendizaje de un error visible ni la lección de una decisión mal tomada: deja solo el costo hundido del proveedor, los meses de calendario y la credibilidad interna gastada para el siguiente intento, que ahora arranca con un comité todavía más escéptico. Antes de definir las fases de implementación de IA en una empresa o elegir proveedor, la primera decisión, la que de verdad determina si el resto importa, es nombrar con nombre y apellido a quién se le va a dar la autoridad de incomodar a otras áreas. Sin esa persona, todo lo demás es infraestructura esperando un dueño que nunca llega.