Cómo armar un roadmap de IA que sobreviva al próximo modelo
Un roadmap de IA compromete fechas solo a corto plazo y resultados a largo plazo. El formato Ahora-Siguiente-Después, supuestos a registrar y cómo priorizar.
¿Por qué un roadmap tradicional falla con IA?
Un roadmap de doce meses con funciones y fechas supone que la tecnología base se queda quieta. Con IA no pasa. Pmtoolkit lo resume así: una sola versión de un modelo puede invalidar un roadmap de funciones a doce meses. Algo que se pospuso porque el modelo no era fiable puede volverse trivial meses después, y una función comprometida con fecha puede dejar de hacer falta sin que nadie lo haya decidido.
El problema no es planear poco. Es comprometerse en el lugar equivocado. Lo que cambia con la tecnología es el mecanismo para lograr algo; el problema del usuario suele seguir igual durante años. Por eso la solución es comprometer el problema y dejar abierto el método.
¿Cómo se estructura un roadmap de IA?
Pmtoolkit propone una planeación por horizontes anclada en resultados: cada elemento se ata a un resultado de usuario, no a una implementación, y el plan se vuelve menos específico cuanto más lejos mira.
| Horizonte | Qué se compromete | Frecuencia de revisión |
|---|---|---|
| Ahora (0 a 3 meses) | Funciones con responsable, fecha y métrica de éxito | Semanal |
| Siguiente (3 a 9 meses) | Un resultado y dos o tres enfoques candidatos, sin elegir uno | Mensual |
| Después (9 a 24 meses) | Solo un resultado de usuario | Trimestral |
Esto se parece a Ahora-Siguiente-Después, pero con una diferencia importante: cada columna tiene un tipo de contenido distinto. Teresa Torres lo formula así: soluciones en Ahora, oportunidades en Siguiente y resultados en Después. Elezea considera que este formato encaja bien en un mundo asistido por IA, porque permite cambiar el cómo sin cambiar el porqué.
Pmtoolkit da un ejemplo de los tres niveles con un mismo resultado. En Ahora: bajar la generación de informes de analistas de 40 minutos a menos de 5, con una exportación con plantilla para el 15 de marzo. En Siguiente: reducir el tiempo hasta el primer informe, con tres candidatos (exportación con plantilla, consulta en lenguaje natural o resúmenes programados). En Después: que los analistas produzcan el informe semanal sin un equipo de datos en medio.
Si un ejecutivo pide fechas de funciones para el largo plazo, la respuesta que sugiere Pmtoolkit es dar el resultado y la fecha de la próxima revisión: “Nos comprometemos con este resultado y revisaremos el enfoque en el tercer trimestre”. Además, la estrategia se prueba en Después: si un resultado no se puede atar a una necesidad de mercado validada, el problema es de ajuste producto-mercado, no del formato del roadmap.
¿Qué supuestos conviene registrar?
Para cada elemento de Siguiente y Después, escribe en una línea los supuestos que lo sostienen. Pmtoolkit propone tres categorías:
- Capacidad del modelo: qué debe hacer de forma fiable y con qué nivel de fiabilidad.
- Curva de costo: el precio de inferencia que asumen las cuentas del producto.
- Regulación: la regla pendiente concreta que podría restringir la función.
Ejemplo ilustrativo: “el modelo resume contratos con menos de 5% de error” o “el costo por consulta se mantiene por debajo de un centavo”.
Revisar supuestos es distinto de revisar avance: la primera revisión pregunta si la apuesta sigue teniendo sentido, la segunda si el trabajo va a tiempo. Según Pmtoolkit, la revisión de supuestos puede destapar problemas antes que las métricas de resultado.
Cuando sale un modelo nuevo o se rompe un supuesto, vuelve a evaluar la iniciativa con la evidencia nueva. Si usas RICE, mira cuál de los cuatro factores cambió. Pmtoolkit advierte que una capacidad nueva no sube la confianza automáticamente: re-puntúa solo donde la evidencia lo respalde.
¿Cómo se prioriza con incertidumbre de IA?
RICE puntúa alcance, impacto, confianza y esfuerzo; ICE, impacto, confianza y facilidad. GetWidget sostiene que RICE, ICE y WSJF omiten dos riesgos propios de la IA:
- ¿Existen los datos en forma usable? Una función puede tener alto impacto y ser inviable si el dato no existe o no se puede usar.
- ¿Qué pasa cuando el sistema se equivoca y qué tan rápido se deshace? Si el error es barato y se corrige fácil, la apuesta es distinta a si el fallo es irrecuperable porque afecta dinero o salud.
Como criterio práctico, las iniciativas reversibles con bajo costo de error pueden empezar antes que las irreversibles, aunque su valor aparente sea menor: aprendes más rápido y arriesgas menos.
Una advertencia sobre usar IA para priorizar: Pmtoolkit acepta que un modelo resuma tickets, agrupe pedidos o encuentre puntos de abandono, pero dice que el equipo debe seguir siendo responsable del orden. Un modelo puede contar 200 tickets de un error de exportación; no puede compararlos con una migración que el equipo sí conoce.
¿Cómo se ponen condiciones a los hitos?
Un hito útil lleva responsable, entregable, umbral de evidencia, la decisión que se tomará al alcanzarlo, la consecuencia si no se alcanza y fecha de revisión. VarenyaZ coincide en que un plan de IA debe incluir puntos de decisión y trabajo para detener o revisar las iniciativas que no cumplen los criterios.
El umbral de evidencia es la parte más útil. Ejemplo ilustrativo: “el piloto funciona” no dice nada; “70% de las tareas se completan sin corrección durante dos semanas, con 200 casos reales” dice cuándo seguir y cuándo parar. Lo mismo vale para las fechas y los beneficios esperados: trátalos como supuestos sujetos a evidencia, no como hechos.
Ejemplo
Ejemplo ilustrativo: una plataforma de compras quiere reducir el tiempo de búsqueda de productos. En Ahora, el equipo compromete una función de búsqueda por lenguaje natural con un piloto de cuatro semanas, responsable y umbral de evidencia. En Siguiente, el problema es “los usuarios no encuentran variantes de talla”, con dos enfoques candidatos: embeddings o un filtro asistido. En Después, el resultado es “encontrar el producto correcto en menos de dos búsquedas”. Cuando sale un modelo más barato, el equipo revisa el supuesto de costo, no el plan entero. Los dos enfoques de Siguiente se re-puntúan y uno sube de prioridad.
Errores comunes
- Comprometer fechas de funciones que dependen de una capacidad del modelo que aún no existe.
- Poner soluciones en las tres columnas del roadmap.
- Priorizar solo por impacto y esfuerzo, sin preguntar por los datos ni por el costo del error.
- Definir hitos sin umbral de evidencia.
- No registrar supuestos, así que nadie sabe qué invalidaría el plan.
- Subir la confianza de una iniciativa solo porque salió un modelo nuevo, sin evidencia.
- Tratar el roadmap como un compromiso fijo y no como un plan que se revisa.
Cuándo NO conviene
Cuando el equipo tiene una sola iniciativa de IA y un plazo claro, un roadmap por horizontes puede ser excesivo; basta una lista de hitos con umbrales. También cuando la dirección exige compromisos firmes de fecha por razones contractuales. En ese caso, comprométete con un alcance mínimo y deja explícito qué supuestos podrían forzar un cambio.
Para decidir qué iniciativas merecen entrar al roadmap, revisa estrategia de producto con IA y ROI de features de IA.