Roadmap de inteligencia artificial para empresas: cómo armarlo a 12 meses

Doce proyectos en una hoja de cálculo y ningún resultado a la vista

La escena se repite con variaciones menores en cualquier empresa que decide “meterle IA” en serio. Un consultor, un gerente de innovación o el propio CEO arma una presentación con una fila por trimestre y una columna por área: marketing prueba un generador de contenido, operaciones prueba un bot de soporte, finanzas prueba un modelo de cobranza. Cada fila tiene una fecha de arranque y una de entrega, y en la reunión todos asienten porque el documento se ve ordenado. El problema aparece seis meses después, cuando alguien pregunta qué de todo eso quedó funcionando y la respuesta es un silencio incómodo seguido de excusas: “nos faltó gente”, “los datos no estaban listos”, “cambiamos de prioridad”.

Ese silencio no es casualidad ni mala suerte, es la consecuencia directa de haber armado una lista en vez de una secuencia. El bot de soporte de operaciones necesitaba un histórico de tickets clasificado que nadie tenía. El modelo de cobranza necesitaba datos de pagos limpios que vivían en tres sistemas distintos sin cruzar. El generador de contenido sí funcionó, porque no dependía de ningún dato interno, y por eso terminó siendo la única iniciativa “exitosa” del año, aunque fuera la que menos impacto real tenía sobre el negocio. Cuando el roadmap no encadena nada, gana lo más fácil de mostrar, no lo más importante de resolver.

Qué es en realidad un roadmap de IA (y qué no)

Antes de seguir conviene ponerle nombre exacto a lo que falló en el ejemplo anterior. Un roadmap de IA no es una agenda de proyectos con fecha de entrega, aunque se parezca a uno en el documento. Es una secuencia de trimestres donde cada uno instala una capacidad (de datos, de proceso, de gobierno o de talento) que el siguiente trimestre necesita para poder intentar algo más ambicioso. La diferencia no es de forma, es de causalidad: en una lista de proyectos el orden es arbitrario y se puede reordenar sin costo; en una secuencia real el orden importa porque el tercer trimestre literalmente no puede empezar sin lo que dejó construido el segundo.

Esa diferencia explica por qué el documento con doce filas del ejemplo anterior no sirvió de nada: se podía leer de abajo hacia arriba y seguía teniendo la misma lógica, es decir, no tenía ninguna. Un roadmap que merece el nombre pasa una prueba sencilla: si se mueve el trimestre tres al lugar del trimestre uno, el plan deja de tener sentido, porque la capacidad que necesita todavía no existe. Esa prueba (¿se puede reordenar esto sin que se rompa?) es la forma más rápida de distinguir un plan real de una lista disfrazada de plan.

Por qué el primer trimestre casi nunca es un proyecto de IA

La objeción más común a esta idea llega apenas se menciona el primer trimestre: si el objetivo es tener IA funcionando, ¿por qué el primer cuarto del año no debería tener ya un modelo corriendo? La respuesta incómoda es que casi ninguna empresa llega con lo que un modelo necesita para funcionar de verdad. Le falta un histórico limpio de la decisión que quiere mejorar, le falta un dueño claro de esos datos, y le falta un criterio para medir si el resultado mejoró algo o solo agregó tecnología encima del mismo problema. Meter un proyecto de IA sobre esa base no acelera nada: expone el desorden más rápido, con una etiqueta más cara.

Por eso el primer trimestre de un roadmap serio se parece más a una auditoría que a un lanzamiento. Se levanta qué decisiones repetidas cuesta dinero errar, dónde vive el histórico de cada una, quién es su dueño real y qué tan bien se decide hoy sin ayuda de ningún modelo. Ese último número, el punto de partida, es el que después permite demostrar que algo mejoró; sin él, cualquier proyecto que llegue en el trimestre dos se defiende con anécdotas, no con evidencia. Este orden coincide con las fases de implementación de IA en una empresa: el diagnóstico va antes que la tecnología, no después.

Lo que sí puede, y debe, pasar en el primer trimestre es una prueba acotada, de bajo riesgo, sobre un proceso ya bien entendido: automatizar una tarea manual y repetitiva, ordenar una fuente de datos que se sabe desordenada, o definir con precisión el primer caso de uso que se va a atacar en el trimestre siguiente. Ninguna de esas tres cosas suena a “transformación con IA” en una presentación a la junta, y esa es exactamente la razón por la que casi nadie las hace bien: no dan para una foto vistosa, y por eso se saltan directo al modelo.

Los cuatro trimestres y la capacidad que instala cada uno

Con esa base, la secuencia completa de un año se puede describir en cuatro bloques. No son inamovibles ni funcionan igual para cualquier empresa (el ritmo cambia según el tamaño y la urgencia real del negocio), pero el orden de las capacidades sí se sostiene con pocas excepciones:

• Trimestre uno, diagnóstico y orden: se mapean las decisiones repetidas más costosas de errar, se audita dónde vive su histórico, se define el punto de partida (qué tan bien se decide hoy) y se elige, con criterio y no por entusiasmo, el primer caso de uso real.
• Trimestre dos, primer caso de uso con dueño: se ejecuta esa primera iniciativa acotada, con un responsable de negocio, no solo de tecnología, un dato ya ordenado y una métrica definida desde antes de empezar. El objetivo no es impresionar, es dejar un método de trabajo repetible.
• Trimestre tres, extensión y gobierno: con un primer resultado medible en la mano, se extiende el mismo patrón a un segundo proceso parecido y se instala lo mínimo de gobierno que evita el caos: quién aprueba un nuevo caso de uso, quién revisa riesgos, qué pasa si un modelo empieza a fallar.
• Trimestre cuatro, escala selectiva: se decide, con datos de los tres trimestres anteriores, qué iniciativas merecen más presupuesto para el año siguiente y cuáles se cierran sin culpa. Escalar sin este filtro es la forma más común de multiplicar el desorden, no el resultado.

Esta secuencia no es un capricho de consultoría, es la misma lógica detrás de el framework Arquitectura IA: cada capacidad que se instala en un trimestre es la condición de entrada del siguiente, y saltarse un paso no ahorra tiempo, lo pide prestado con interés.

Cómo priorizar la cartera de iniciativas sin que gane el que grita más fuerte

Ya en el segundo trimestre, y sobre todo en el tercero y el cuarto, va a sobrar cartera: cada gerente de área va a llegar con su propia idea de qué merece el siguiente cupo del roadmap, y casi todos van a defenderla con la misma frase: “esto nos va a ahorrar muchísimo tiempo”. Si la priorización se decide por jerarquía o por quién insiste más en el comité, el roadmap deja de encadenar capacidades y vuelve a ser la lista de deseos del principio, solo que con más reuniones encima.

El criterio que sostiene mejor la conversación combina tres condiciones, en este orden:

• Que la decisión se repita: tiene que repetirse lo suficiente como para que el error acumulado importe de verdad, no ser un caso aislado que ocurrió una vez.
• Que exista el histórico: tiene que haber ya un registro de esa decisión con el resultado marcado, o el trabajo real empieza por ordenar ese dato, no por modelarlo.
• Que haya un dueño dispuesto: el área responsable del proceso necesita a alguien dispuesto a comprometerse con el resultado, no solo a pedir la iniciativa en el comité.

Una iniciativa que falla en el primer punto no es candidata todavía, sin importar cuánto entusiasmo genere. La guía para resolver esa primera elección está en cómo elegir el primer caso de uso de IA que sí va a funcionar, y el mismo filtro sirve para el quinto caso de uso, no solo para el primero.

Lo que casi nunca funciona es priorizar por “impacto potencial” calculado en una hoja de cálculo antes de tocar un solo dato real. Ese número siempre sale espectacular porque nadie lo contrasta con nada; la disciplina aparece cuando se exige, además del impacto proyectado, evidencia de que el dato existe, está limpio y tiene dueño. Entre dos iniciativas con el mismo impacto en el papel, gana la que tiene los datos más listos, no la que suena mejor en la presentación.

Qué hacer con las automatizaciones y pilotos que ya están corriendo sin plan

Casi ninguna empresa arma su roadmap sobre una hoja en blanco. Para cuando alguien se sienta a ordenar la secuencia trimestral, ya existen dos o tres automatizaciones sueltas que un área montó por su cuenta (un chatbot de atención al cliente, una plantilla de correos generados con IA, un script que clasifica facturas) sin que nadie las conecte con ninguna estrategia. El error más común al armar el roadmap es ignorarlas, como si el plan empezara de cero; el segundo error, igual de caro, es meterlas todas dentro sin revisarlas solo porque ya existen.

Lo que sí funciona es tratarlas como cualquier otra candidata de la cartera: se audita qué decisión resuelven, si tienen dueño, qué tan bien, o mal, están funcionando, y si el problema que atacan sigue siendo relevante para el negocio. Algunas van a calificar directo para el trimestre dos o tres, porque ya resolvieron buena parte del trabajo de diagnóstico sin que nadie lo llamara así. Otras van a resultar huérfanas: nadie las revisa, nadie sabe si siguen funcionando bien y el área que las montó ya perdió interés. Esas segundas son las que más cuesta cerrar, porque cerrarlas se siente como admitir un error, cuando en realidad es la única forma honesta de liberar presupuesto para lo que sí tiene dueño.

Cómo se revisa el roadmap sin reescribirlo entero cada trimestre

Un roadmap que no se revisa nunca se vuelve una promesa incumplida; uno que se revisa cada mes se vuelve una hoja de intenciones que nadie toma en serio, porque cambia antes de que cualquier iniciativa alcance a mostrar resultado. El punto medio que funciona en la práctica es una revisión al cierre de cada trimestre, coincidiendo exactamente con el punto donde una capacidad debería estar lista para que la siguiente arranque.

Lo que se revisa en ese corte no es qué tan bien se siente el equipo con el plan, son tres cosas puntuales: si la capacidad prometida para ese trimestre quedó instalada de verdad (no a medias, no “casi”), si el trimestre siguiente sigue siendo viable con lo que existe hoy, y si apareció alguna señal externa (un cambio regulatorio, un competidor, una caída de presupuesto) que obligue a mover algo. Cuando la respuesta a las dos primeras es sí, el roadmap no se toca: se ejecuta el trimestre que ya estaba escrito. Reescribir un plan que sigue siendo válido solo porque llegó la fecha de revisión es tan dañino como no revisarlo nunca.

Lo que sí cambia con frecuencia, y está bien que cambie, es el orden dentro de un mismo trimestre o el detalle de una iniciativa puntual. Lo que casi nunca debería cambiar sin una razón de peso es la secuencia completa: si el trimestre cuatro dependía de una capacidad de gobierno instalada en el tres, mover el cuatro hacia adelante sin esa base no es agilidad, es repetir el error del roadmap de deseos. Esta disciplina de revisión conecta directamente con por dónde empezar con IA en una empresa: qué área va primero, porque la misma lógica de secuencia que ordena el arranque es la que protege la revisión de convertirse en un reinicio constante.

El roadmap de una empresa que ya tiene pilotos parados

El caso más pedido en la práctica no es el de la empresa que arranca de cero, es el de la que ya intentó algo, gastó presupuesto y hoy tiene dos o tres pilotos parados que nadie se atreve a declarar oficialmente muertos. Ahí el roadmap no arranca en el trimestre uno del calendario, arranca en un diagnóstico honesto de por qué se detuvo cada piloto: ¿faltó dato, faltó dueño, cambió la prioridad del negocio, o el resultado nunca se midió y por eso nadie sabe si valía la pena seguir?

La tentación en ese escenario es relanzar los mismos pilotos con más presupuesto, asumiendo que lo que faltó fue dinero o mejor tecnología. Casi nunca es así. Lo que faltó, en la mayoría de los casos que he visto, fue exactamente lo que instala un primer trimestre bien hecho: un histórico ordenado, un dueño de negocio comprometido, y una forma de medir si el resultado mejoró algo. Relanzar sin resolver eso primero produce el mismo piloto parado, solo que con una segunda inversión encima. Esta diferencia se nota más cuando la empresa es mediana y no tiene un equipo de datos dedicado, un contraste que se explica con más detalle en implementación de IA en pymes y en empresas grandes: qué cambia.

El roadmap correcto para esta empresa no empieza de cero ni continúa donde quedó: empieza por declarar oficialmente qué pilotos se cierran, cuáles se congelan hasta tener el dato que les falta y cuál, como máximo uno o dos, se retoma ya, pero con el diagnóstico que debió hacerse antes de lanzarlo. Ese ejercicio incomoda porque obliga a admitir en voz alta que hubo presupuesto mal gastado, pero sale más barato que seguir sumando pilotos parados a la pila.

El criterio que sostiene todo roadmap que funciona

Un roadmap de IA se puede juzgar con una sola pregunta, sin necesidad de leer las doce filas del documento: si se borra el trimestre dos, ¿el trimestre tres sigue teniendo sentido? Si la respuesta es sí, lo que hay es una lista de proyectos en paralelo disfrazada de plan. Si la respuesta es no, porque el tres literalmente necesita lo que el dos dejó instalado, hay una secuencia real, y esa es la única propiedad que distingue un roadmap de un catálogo de buenas intenciones con fechas.

Ese criterio no se negocia por presión de calendario ni por la ansiedad de mostrar avance rápido a la junta directiva. Un trimestre que se salta la capacidad que le tocaba instalar no ahorra tiempo: lo traslada al trimestre siguiente, con intereses, en forma de un modelo que no tiene con qué funcionar o un piloto que nadie sabe medir. La disciplina de sostener la secuencia, más que cualquier tecnología elegida, es lo que separa a la empresa que en doce meses instaló una forma nueva de decidir de la que en doce meses solo cambió de proveedor tres veces.