Casi todas las hojas de ruta de preparación para IA son presentaciones. Doce meses de líneas de trabajo, un modelo de madurez con cinco etapas muy ordenadas y un centro de excelencia que nadie va a dotar de personal. Seis meses después no hay ningún sistema en producción, solo una presentación más bonita. Si tu hoja de ruta no puede señalar algo que funciona y que una persona real usó este trimestre, no es una hoja de ruta. Es una excusa para no avanzar.
Una hoja de ruta de IA que sirva es corta, barata y termina en una decisión. Esta es la versión de 90 días que aplicamos: mide dónde estás realmente, elige una o dos oportunidades, escribe el eval antes de construir, haz un piloto con un usuario real, mide costo y resultado, y decide si escalas o paras. Noventa días, un piloto en producción y una respuesta honesta.
Días 1 a 15: mide la postura, no la ambición
La preparación tiene cuatro dimensiones. Puntúa cada una sin autoengaño, porque la más débil limita todo lo que venga después.
- Acceso a los datos. ¿Puedes conseguir los datos que un agente necesita, en menos de una semana, sin pedirle un favor a alguien de otro departamento? Si la respuesta vive en un PDF, en un ERP heredado del que nadie tiene credenciales o en una hoja de cálculo en el portátil de una sola persona, ese no es un problema de datos que se resuelva durante el build. Resuélvelo ahora o elige otra oportunidad.
- Postura de seguridad. ¿Adónde van los datos cuando salen de tus muros? ¿Quién lo aprobó? Si no sabes qué pasa cuando un LLM ve el registro de un cliente, no estás listo para enviarle uno. Ten claras tu clasificación de datos, los términos de tus proveedores y tus límites de datos personales antes de la primera línea de código.
- Equipo. Una persona tiene que ser dueña del resultado y tener tiempo para validar el output. No un comité de dirección. Alguien capaz de decir «esto está bien» o «esto está mal» cincuenta veces durante un piloto.
- Madurez del proceso. ¿El proceso que quieres automatizar es estable y está documentado, o es conocimiento tribal con tres excepciones que nadie escribió? No puedes automatizar un proceso que nadie sabe describir.
No necesitas un 5 en las cuatro. Necesitas conocer tu número real en cada una, porque eso decide qué puedes construir en los 75 días siguientes.
Días 15 a 30: elige una o dos, y ponlo por escrito
Resiste la tentación del portafolio. La primera hoja de ruta entrega un piloto, quizá dos; no un programa. Elige oportunidades de alto volumen, con costo alto del error, estables, con dueño y medibles. Las aburridas y operativas: la cola de clasificación, el impuesto de copiar y pegar entre dos sistemas, el reporte que alguien arma a mano cada mes.
Escribe un alcance de una página por cada elección. Qué entra, qué queda fuera, quién es el usuario, qué significa «correcto» y el único número que vas a mover. Si no puedes llenar esa página, todavía no entiendes la oportunidad lo suficiente como para construirla. Eso es un hallazgo, no un fracaso, y llega mucho mejor ahora que en el tercer mes.
Días 30 a 45: define el eval antes de construir
Aquí es donde casi todas las hojas de ruta se saltan un paso y lo pagan después. Antes de que nadie escriba un prompt, define cómo vas a saber que el sistema funciona. ¿Qué aspecto tiene un buen output? ¿Cuál es el fallo que no puedes poner en producción? Reúne entre 30 y 50 ejemplos reales con sus respuestas correctas conocidas y conviértelos en una prueba que puedas ejecutar cuando quieras.
Si no podemos escribir un eval defendible, lo decimos y paramos aquí: es el dinero más barato que vas a gastar. Un proceso demasiado difuso para calificarlo es un proceso demasiado difuso para automatizarlo, y descubrirlo el día 40 no cuesta nada. Descubrirlo después de haberlo puesto en producción cuesta confianza.
Días 45 a 75: piloto acotado con un usuario real
Ahora sí, construye, pero estrecho. Un workflow, un usuario, datos reales, ejecutándose contra el eval que ya escribiste. Nada de demo para el comité ejecutivo. Una persona haciendo su trabajo real, con el sistema dentro del loop, durante dos o tres semanas.
Mantén al humano al mando. El agente redacta, clasifica o extrae; la persona aprueba. Estás midiendo dos cosas a la vez: ¿el output pasa el eval?, y ¿el usuario real lo adopta o lo esquiva en silencio? Las demos mienten sobre ambas. Un usuario real en el día doce te dice la verdad: dónde se rompe, qué casos límite no imaginaste y si ahorra tiempo o solo mueve el trabajo de sitio.
Días 75 a 90: mide costo y resultado, y decide
Pon dos números uno al lado del otro. El resultado —horas ahorradas, tasa de error a la baja, tiempos de respuesta más cortos, lo que hayas escrito en el alcance— y el costo: gasto de modelo por ejecución, más la ingeniería de construirlo y mantenerlo. No proyectado. Medido, a partir del piloto.
Y después toma la decisión en voz alta: escalar, iterar o parar. Escalar un piloto que pasó su eval y fue adoptado es dinero fácil. Matar uno que no lo consiguió es disciplina, y sale barato, porque gastaste 90 días y un piloto en lugar de un año y un programa entero. Una hoja de ruta incapaz de decir «para» no está gestionando el riesgo: lo está escondiendo.
El antipatrón que conviene nombrar
El modo de fallo no es ir demasiado lento. Es la presentación de estrategia sin un solo sistema en producción: evaluación interminable, curvas de madurez y hojas de ruta que nunca tocan producción. La preparación no es un documento al que llegas. Se demuestra con un piloto que funciona, medido con honestidad, que se ganó el derecho a convertirse en dos.
Ese ciclo de 90 días —medir, acotar, escribir el eval, pilotar, decidir— es exactamente lo que ejecuta por ti nuestra Evaluación de Preparación para IA. Salimos del otro lado con una hoja de ruta defendible, un piloto en producción y los dos números que te dicen si escalar. Si llevas tiempo dando vueltas alrededor de una presentación de estrategia y prefieres un sistema que funcione, esa es la evaluación que hay que agendar.