En el módulo 4 decidiste la aproximación: construir el modelo desde cero, comprar una plataforma cerrada o apoyarte en una API (Application Programming Interface, la interfaz por la que un proveedor te presta su modelo como servicio). Con esa decisión tomada, el terreno cambia: ya no discutes con qué vas a construir, sino cómo llegas de aquí a producción sin quedarte a mitad de camino. Y ahí aparece el problema propio de este módulo, el que hace que planificar IA no se parezca a planificar software normal: no sabes qué tan bueno es tu producto hasta que lo pruebas con datos reales. En software determinista, si el código compila y pasa los tests, la feature funciona. En IA, el código puede estar perfecto y el producto ser inservible porque el modelo acierta el 62% de las veces cuando necesitabas 90%. Un roadmap que no absorbe esa incertidumbre no es un plan: es una lista de deseos con fechas.

La tesis del módulo

Un roadmap de IA no promete features en fechas, promete niveles de calidad y aprendizaje en fases. Planificar un producto de IA como si fuera software determinista es firmar un cheque que la incertidumbre no puede cobrar. El calendario tradicional dice “el chatbot sale el 15 de marzo”; el roadmap de IA dice “para marzo sabremos si el chatbot alcanza 85% de resolución sin escalar a un humano, y solo entonces decidimos si lanza”. La fecha deja de ser una promesa y pasa a ser un punto de decisión.

Por qué el plan tradicional se rompe en IA

Un roadmap (hoja de ruta, el plan de qué se construye y en qué orden) de software clásico funciona porque la relación entre esfuerzo y resultado es predecible: sabes que implementar un formulario toma tres días y que, cuando esté, funcionará. La estimación puede fallar en el cuándo, casi nunca en el si.

En IA esa certeza desaparece por tres razones:

La calidad es una variable, no un dado. No sabes si el sistema alcanzará el nivel que necesitas hasta que lo mides sobre datos reales. Puede que el 80% se logre en dos semanas y el 90% no se logre nunca.
La mejora no es lineal. Subir de 70% a 80% puede costar una semana; subir de 90% a 95%, tres meses o un rediseño completo. El esfuerzo se dispara justo cuando el margen que queda es pequeño.
El dato manda sobre el calendario. Descubres el problema real recién cuando el sistema toca casos que no anticipaste. El roadmap tiene que dejar espacio para que la evidencia diga “todavía no”.

Por eso el roadmap de IA se organiza en fases con criterio de salida, no en features con fecha. Cada fase responde una pregunta distinta, y solo se avanza si la respuesta es sí.

Las cuatro fases y sus puertas

Cada fase tiene un objetivo, un gate (puerta, el criterio medible que hay que cruzar para avanzar) y una decisión go / no-go (seguir / parar). Saltarse un gate es la forma más común de terminar en producción con algo que nunca funcionó.

PoC — prueba de concepto (Proof of Concept, la demostración de que la idea es técnicamente posible). Pregunta: ¿se puede? Se mide la calidad sobre un conjunto acotado y controlado de casos. No hay usuarios reales todavía. El gate es un número: “el sistema resuelve el X% de un set representativo de N casos”.
Piloto. Pregunta: ¿funciona con usuarios reales y datos reales, en pequeño? Se pone frente a un grupo limitado y real. Aquí aparecen los casos raros que el PoC no vio y el comportamiento de usuarios que no leen el manual. El gate mezcla calidad y adopción: “el X% de los usuarios del piloto lo usa una segunda vez y la calidad se sostiene fuera del set curado”.
Producción. Pregunta: ¿escala, es confiable y sostenible? Se abre a todos. El gate ya no es solo calidad: es latencia, costo por operación, tasa de error bajo carga y un plan de qué hacer cuando el modelo se equivoca en vivo. (Qué cambia exactamente al cruzar esta puerta está en qué cambia en producción.)
Mejora continua. Pregunta: ¿cómo se mantiene bueno con el tiempo? No tiene gate de salida porque no termina: los datos cambian, los usuarios cambian, el modelo del proveedor cambia por debajo. Este es el tema de operar y evolucionar.

        LAS FASES Y SUS PUERTAS DE DECISIÓN

  ┌─────────┐   gate    ┌─────────┐   gate
  │  PoC    │ calidad   │ PILOTO  │ calidad +
  │ ¿se     │ en set    │ ¿real   │ adopción
  │ puede?  │ acotado   │ y chico?│ real
  └────┬────┘           └────┬────┘
       │ go/no-go            │ go/no-go
       ▼                     ▼
  ┌─────────────┐       ┌─────────────┐
  │ si no pasa: │       │ PRODUCCIÓN  │  gate
  │ pivotar o   │       │ ¿escala y   │ fiable +
  │ archivar    │       │ es fiable?  │ sostenible
  └─────────────┘       └──────┬──────┘
                               │ go/no-go
                               ▼
                        ┌─────────────┐
                        │   MEJORA    │ ◄─┐
                        │  CONTINUA   │   │ sin
                        │ (no acaba)  │ ──┘ fin
                        └─────────────┘

El diagrama enseña dos cosas que el calendario esconde. Primero, que cada flecha hacia adelante pasa por una decisión, no por una fecha: cruzar de PoC a piloto es un acto de gobernanza, alguien firma que el número se alcanzó. Segundo, que el “no pasa” es un resultado legítimo, no un fracaso del equipo: un PoC que demuestra que la idea no llega al umbral ahorró el presupuesto del piloto.

El PoC purgatory: la trampa más cara del sector

Aquí es donde mueren la mayoría de los proyectos de IA. El PoC purgatory (purgatorio del PoC, el limbo de proyectos que impresionan en una demo pero nunca llegan a producción) es el patrón: la organización acumula demos brillantes que nunca se convierten en producto. Encuestas de industria de 2024–2025 (McKinsey, Gartner) reportan sistemáticamente que la mayoría de las iniciativas de IA generativa no pasan del piloto; las cifras exactas varían según el estudio, pero el patrón es consistente y conocido.

La causa es un desajuste de incentivos. Una demo se construye para impresionar, y para impresionar se eligen los casos: los ejemplos limpios, las preguntas fáciles, el flujo feliz. Producción no elige los casos — los recibe todos, incluido el peor. Un sistema que brilla en la demo con 15 ejemplos curados puede desplomarse cuando enfrenta los 15.000 casos reales, con sus faltas de ortografía, sus preguntas ambiguas y sus intentos de romperlo.

Ojo: el PoC purgatory casi nunca es un problema técnico. Es un problema de definición. El equipo optimizó lo que se medía —la demo— en vez de lo que importaba —el caso peor en producción—. Optimizaste para el aplauso, no para el usuario número diez mil.

Cómo se escapa, en tres movimientos:

Define los criterios de producción el día uno, no al final. Antes de escribir el PoC, escribe qué números tendría que dar para lanzar: qué calidad, sobre qué casos, con qué latencia y costo. Sin eso, el PoC no tiene meta y siempre “casi está”.
Prueba el caso peor desde el PoC, no el mejor. Mete en el set de evaluación los casos difíciles, ambiguos y adversariales desde el principio. Una demo que sobrevive los casos feos es una demo que puede escalar.
No optimices la demo. Cada hora que gastas puliendo el ejemplo que le muestras al comité es una hora que no gastas cerrando la brecha hacia producción. La demo bonita es el enemigo del producto real.

Roadmap por outcomes, no por features

Aquí está el cambio mental central del módulo. Un roadmap por features (funcionalidades) promete cosas: “lanzar el chatbot en marzo”, “añadir búsqueda semántica en abril”. Un roadmap por outcomes (resultados, el efecto medible que buscas) promete efectos: “reducir el tiempo de respuesta al cliente un 40%”, “que el 60% de las consultas se resuelvan sin humano”.

En software determinista, prometer la feature es aceptable, porque feature entregada equivale a resultado. En IA no: puedes entregar el chatbot perfectamente en marzo y no reducir nada, porque el modelo no acierta lo suficiente. El outcome es lo único honesto que puedes comprometer, porque es lo único que de verdad controlas: si no lo alcanzas, no cruzas el gate, y eso es información, no incumplimiento.

El formato de horizontes now / next / later (ahora / siguiente / después, un roadmap sin fechas duras popularizado en la comunidad de producto —Janna Bastow, ProdPad— justamente para trabajar bajo incertidumbre) encaja perfecto con IA:

Now (ahora): lo que está en marcha, con outcome comprometido y gate cercano.
Next (siguiente): lo que sigue si el “now” cruza su gate. Es condicional, no calendarizado.
Later (después): apuestas de dirección, sin compromiso de calidad todavía.

La gracia es que “next” y “later” dependen del resultado de “now”. Si el PoC del “now” no alcanza el umbral, el “next” cambia. Un roadmap con fechas duras miente sobre esa dependencia; uno por horizontes la hace explícita.

La relación calidad ↔ alcance: cuánto es “suficiente”

La decisión más difícil del roadmap no es qué construir, es hasta qué calidad. Y el enemigo es la curva: los últimos puntos porcentuales son los más caros.

Subir de 80% a 95% de acierto puede costar más —en tiempo, dato y dinero— que todo lo que hiciste para llegar a 80%. Cada punto adicional exige casos más raros, más datos etiquetados, más ajuste fino. Por eso la pregunta de roadmap no es “¿cómo llegamos al 100%?” —no se llega— sino “¿qué nivel de calidad es suficiente para lanzar, dado lo que cuesta el siguiente punto?”.

La respuesta depende del costo del error. Un sistema que sugiere etiquetas de correo puede lanzar al 80%: equivocarse es barato, el usuario corrige. Un sistema que aprueba préstamos no lanza al 95%: cada error tiene consecuencias legales y humanas. El umbral de lanzamiento sale del costo de equivocarse, no de un número redondo. (Cómo se fija y se mide ese umbral es el tema de métricas y KPI.)

     COSTO DE MEJORA vs NIVEL DE CALIDAD

 esfuerzo
   ▲
   │                                    ╱
   │                                  ╱  ◄ cada punto
   │                               ╱      cuesta más
   │                            ╱
   │                       ╱
   │                 ╱
   │          ╱
   │    ╱
   │ ╱
   └──────────────────────────────────────► calidad
     50%     70%    [80%]   90%   95%  99%
                      │
                      └─ "suficiente para lanzar",
                         según el costo del error

Cuidado: perseguir el 99% “porque queda mejor” es una de las formas más caras de quemar presupuesto en IA. Muchas veces el 99% no aporta valor sobre el 90% —el usuario no nota la diferencia— pero cuesta el triple. Fija el umbral por el costo del error, lánzalo, y recién entonces decide si el siguiente punto vale la pena.

Artefacto: plantilla de roadmap por fases

Esta es la plantilla que reemplaza el diagrama de Gantt con fechas. Cada fila es una fase; ninguna columna es una fecha de entrega, todas son criterios y decisiones. (Números ilustrativos, para mostrar la forma.)

## Roadmap — Asistente de soporte (por fases)

### Fase 1 · PoC
- Objetivo: probar que el asistente responde consultas
  frecuentes de soporte con calidad utilizable.
- Criterio de salida (gate): ≥ 75% de respuestas correctas
  sobre un set de 200 consultas reales anonimizadas,
  incluyendo 40 casos difíciles/ambiguos.
- Riesgo principal: el set curado no representa el caso peor.
- Decisión go/no-go: si < 75%, pivotar el alcance (menos
  tipos de consulta) o archivar. NO avanzar a piloto.

### Fase 2 · Piloto
- Objetivo: validar con usuarios y datos reales, en pequeño.
- Criterio de salida (gate): calidad se sostiene ≥ 75% fuera
  del set curado Y ≥ 50% de los agentes del piloto lo usan
  una segunda semana.
- Riesgo principal: adopción baja aunque la calidad sea buena.
- Decisión go/no-go: si la calidad cae o nadie lo reusa,
  volver a PoC con los casos que fallaron.

### Fase 3 · Producción
- Objetivo: abrir a toda el área de soporte de forma fiable.
- Criterio de salida (gate): latencia p95 < 3s, costo por
  consulta < umbral definido, plan de fallback humano activo.
- Riesgo principal: el costo por consulta no escala.
- Decisión go/no-go: si no cumple costo/latencia, optimizar
  antes de abrir; no lanzar "a ver qué pasa".

### Fase 4 · Mejora continua (sin fin)
- Objetivo: sostener y elevar la calidad en el tiempo.
- No tiene gate de salida: tiene un ciclo de reentrenamiento
  y evals que corren de forma permanente.

Y el mismo producto visto como now / next / later, que es lo que se le muestra a la dirección:

NOW    → PoC del asistente de soporte.
          Outcome: demostrar ≥75% en 200 casos reales.
NEXT   → (si el PoC pasa) Piloto con un equipo.
          Outcome: sostener calidad + ≥50% de reuso.
LATER  → Extender a ventas y a idioma inglés.
          Apuesta de dirección, sin compromiso de calidad aún.

Tabla: PoC vs piloto vs producción

Dimensión	PoC	Piloto	Producción
Pregunta	¿Se puede?	¿Funciona real y chico?	¿Escala y es fiable?
Usuarios	Ninguno (equipo)	Grupo pequeño real	Todos
Datos	Set curado y acotado	Reales, volumen bajo	Reales, volumen pleno
Criterio de éxito	Calidad sobre el set	Calidad sostenida + reuso	Fiabilidad, latencia, costo
Riesgo típico	El set no es el caso peor	Adopción baja pese a calidad	El costo no escala
Qué se decide	¿Vale seguir?	¿Vale abrir?	¿Cómo se mantiene?

La columna que más se olvida es la del riesgo típico: cada fase falla por una razón distinta, y planificar sin nombrar ese riesgo es planificar a ciegas. El PoC no falla por falta de talento, falla porque el set curado mintió. El piloto no falla por mala calidad, falla porque a nadie le sirvió. Producción no falla por acierto, falla por costo.

Errores comunes

Prometer features con fecha en vez de outcomes con gate. “El chatbot sale el 15 de marzo” es un cheque que la incertidumbre no puede cobrar. Promete el resultado medible; la fecha es un punto de decisión, no una entrega garantizada.
Optimizar la demo en vez del caso peor. La demo bonita es el camino directo al PoC purgatory. Los casos difíciles van en el set de evaluación desde el día uno, no al final.
Definir los criterios de producción al terminar el PoC. Sin meta escrita antes de empezar, el PoC “casi está” para siempre. Los números para lanzar se escriben antes de la primera línea de código.
Saltarse un gate porque “ya invertimos mucho”. El costo hundido no es un argumento para avanzar. Un PoC que no pasa su gate ahorró el presupuesto del piloto; forzar el paso solo mueve el fracaso a una fase más cara.
Perseguir el 99% por defecto. El umbral de lanzamiento sale del costo del error, no de un número redondo. Muchos productos deben lanzar al 80% y mejorar en vivo; otros no pueden lanzar bajo 99%. Confundirlos quema presupuesto o expone al usuario.
Tratar “mejora continua” como una fase que termina. Un producto de IA no tiene fecha de fin: los datos, los usuarios y el modelo del proveedor cambian. Un roadmap que acaba en “producción” olvida la mitad de la vida del producto.

La frase para llevarse

“En software prometes que la feature estará; en IA solo puedes prometer que sabrás si funciona. El roadmap de IA no vende fechas: vende puertas de decisión, y cada puerta es un lugar donde parar es tan válido como seguir.”

Qué viene

Módulo 6: priorización. Ya tienes las fases y los outcomes, pero siempre habrá más ideas que capacidad para construirlas. ¿Qué se hace primero cuando todo parece urgente y el equipo es finito? Vamos a bajar frameworks concretos —RICE, valor vs esfuerzo— al terreno de la IA, donde el “esfuerzo” incluye una variable que el software normal no tiene: la incertidumbre sobre si siquiera va a funcionar. Priorizar apuestas cuya calidad no conoces es un arte distinto, y tiene sus propias reglas.

Producto de IA — Módulo 5: el roadmap de un producto de IA