Plan de 90 días para implementar IA en una empresa

El problema no es la IA, es que nadie sabe qué va a estar distinto en marzo

Un directorio aprueba un presupuesto para meter inteligencia artificial en la empresa después de una presentación con casos de éxito de otras compañías del sector. El gerente que defendió el proyecto sale de esa reunión con una fecha, fin de trimestre, y ninguna definición operativa de qué va a lucir distinto ese día. Tres meses después llega el reporte de avance: se hicieron talleres, se probaron dos herramientas, el equipo de sistemas sigue “evaluando proveedores”. Nada de eso es falso, y nada de eso responde la pregunta que el directorio hizo en realidad cuando aprobó el gasto.

Ese es el dolor real detrás de casi cualquier búsqueda de un plan de implementación: no falta entusiasmo ni presupuesto, falta un compromiso acotado con un entregable verificable. La empresa promedio no necesita otro comité de innovación ni otra charla sobre qué es la inteligencia artificial. Necesita saber, con fecha y nombre propio, qué proceso concreto va a medirse distinto dentro de tres meses. Sin esa definición, cualquier plazo (30, 90 o 180 días) es solo una fecha en un calendario esperando a que alguien la note vencida, algo que se nota todavía más cuando se compara contra cuánto tiempo toma en serio implementar IA en una empresa.

Qué es (y qué no es) un plan de 90 días para implementar IA

Un plan de 90 días no es un cronograma de proyecto ni una lista de entregables de un proveedor. Es una apuesta acotada: se elige un proceso, se mide su estado actual, se interviene con lo mínimo necesario y se comprueba si el número cambió. El plazo importa menos que la disciplina de cerrar el ciclo completo, medir, ordenar, construir y volver a medir, en un tiempo corto y verificable. Noventa días alcanza para eso. No alcanza, y nadie serio debería prometer que alcanza, para rehacer la cultura de una empresa ni para convertirla de la noche a la mañana en lo que hoy se llama una empresa AI Native.

La confusión más cara ocurre cuando se vende el plan de 90 días como si fuera el proyecto completo de transformación, en vez de como el primer tramo verificable de algo más largo. Por eso conviene mirarlo junto a un roadmap de IA a doce meses: el plan de 90 días es el primer bloque de ese roadmap, el que demuestra que vale la pena seguir invirtiendo en los siguientes tres trimestres. Prometer más que eso en tres meses no es ambición, es la forma más común de quemar la credibilidad del segundo proyecto antes de que empiece.

Días 1 a 15: medir el estado actual antes de tocar nada

Los primeros quince días no sirven para elegir herramienta ni para escribir un caso de negocio bonito. Sirven para responder, con datos y no con opinión, cómo se comporta hoy el proceso que se va a intervenir. La tentación en esta etapa es saltarla porque “ya sabemos cuál es el problema”: es exactamente la tentación que hay que resistir, porque lo que el gerente cree que pasa y lo que de verdad pasa en el proceso casi nunca coinciden del todo.

• El volumen real: cuántos casos pasan por ese proceso a la semana, no la cifra que alguien recuerda de memoria.
• El tiempo actual: cuánto tarda hoy resolver un caso de principio a fin, medido, no estimado.
• El costo del error: qué pasa y cuánto cuesta cuando ese proceso se hace mal, en plata o en tiempo perdido.
• Quién decide hoy: qué persona toma la decisión final y con qué información cuenta en ese momento.

El entregable que cierra este primer bloque es un documento corto con esos cuatro puntos y una sola frase: “hoy este proceso tarda X y falla Y veces por cada Z casos”. Si al día quince nadie puede escribir esa frase con datos propios de la empresa, el plan no avanza al siguiente bloque, porque construir sobre un diagnóstico inventado es la forma más rápida de llegar al día 90 sin nada real que mostrar.

Días 16 a 30: ordenar el proceso antes de automatizar nada

La segunda quincena es la que más se salta y la que más factura después. Ordenar el proceso significa escribirlo tal como ocurre hoy, con sus excepciones y sus atajos informales, y decidir cuál de esas variantes va a ser la única versión que el sistema va a soportar. Ningún modelo ni ningún agente rinde sobre un proceso que cambia de forma según quién lo ejecuta ese día. Ordenar antes de construir es, de hecho, una de las fases de implementación de IA en una empresa que más se saltan bajo presión de mostrar avance rápido.

• El paso a paso real: no el diagrama oficial que nadie sigue, el que de verdad hacen las personas que ejecutan el proceso.
• La fuente de datos única: qué sistema o planilla va a ser la fuente de verdad, y quién deja de mantener las otras versiones paralelas.
• Las excepciones que se eliminan: cuáles de las variantes especiales del proceso se cortan porque cuestan más de lo que resuelven.
• El dueño del proceso: una persona con nombre y apellido responsable de que el proceso ordenado se sostenga después del día 90.

El entregable de este bloque es el proceso documentado en una página, no en veinte, con la fuente de datos ya limpia y validada. Este paso todavía no toca ninguna herramienta de inteligencia artificial, y esa es la señal de que se está haciendo bien: se está ordenando el terreno, no comprando el tractor antes de arar.

Días 31 a 60: construir lo mínimo que puede operar en producción

El mes de en medio es donde se construye, y donde más se cae en el error de construir de más. Lo mínimo no significa una demo ni un prototipo que solo funciona en la laptop del consultor: significa la versión más chica de una solución que ya opera con datos reales, sobre el proceso ordenado en el bloque anterior, con al menos una persona del equipo usándola de verdad. La diferencia entre esto y una prueba de concepto de IA en dos semanas es que aquí ya no se está probando si la tecnología funciona: eso se asume resuelto y se construye para producción desde el primer día.

• Un solo caso de uso: no la plataforma completa, un flujo específico dentro del proceso ya ordenado.
• Datos reales, no de prueba: conectado a la fuente de datos que se limpió en el bloque anterior, no a un archivo de ejemplo.
• Una persona usándolo en su trabajo diario: si nadie lo usa de verdad para el día 60, no hay nada que medir en el bloque siguiente.
• Un límite explícito de lo que no hace: para que nadie reclame después algo que nunca estuvo en el alcance.

El entregable que cierra este bloque no es el código ni la herramienta: es que ese caso de uso esté operando con al menos una persona real, sobre datos reales, todos los días, durante las últimas dos semanas del tramo. Si al día sesenta lo único que existe es una demo que funciona cuando el consultor la presenta, el plan está atrasado, aunque el cronograma diga lo contrario.

Días 61 a 90: operar, medir y documentar lo que cambió

El último tramo no es para agregar funciones nuevas ni para conectar el siguiente caso de uso. Es para dejar lo construido operando sin ayuda constante del equipo que lo armó, y para volver a medir exactamente lo mismo que se midió en los primeros quince días, con la misma definición y las mismas unidades. Si el número del día 15 fue “este proceso tarda X y falla Y veces por cada Z casos”, el número del día 90 tiene que responder esa misma frase, no una versión más generosa de ella.

El entregable final de todo el plan es un reporte corto con tres partes: el número de antes, el número de después y el proceso documentado que ahora opera distinto. Ese documento, y no una presentación con capturas de pantalla, es lo que se lleva al directorio. Es también, siguiendo la tesis de fondo de este plan, lo único que compra el permiso para el siguiente proyecto, sea repetir el mismo ciclo en otro proceso o escalar ese piloto a toda la empresa. Nadie aprueba un segundo presupuesto de IA sobre la palabra de que “funcionó”, lo aprueba sobre un número que bajó o subió y que se puede auditar.

Qué hacer si a los 45 días el número no se movió

El punto medio del plan, alrededor del día 45, es el momento de revisar si el número empezó a moverse aunque sea un poco. No se espera el resultado final ahí, se espera una señal de dirección. Cuando a esa altura nada cambió, la reacción más común y más equivocada es pedir más tiempo con la misma estrategia. Antes de extender el plazo hay que revisar tres causas, en este orden.

• El proceso seguía sin ordenar: si el bloque de los días 16 a 30 se hizo rápido y mal, ninguna construcción posterior tiene una base sólida donde apoyarse.
• El caso de uso era demasiado grande: se intentó resolver el proceso entero en vez de un flujo específico dentro de él, y eso siempre tarda más de lo previsto.
• Nadie lo estaba usando de verdad: la herramienta existe pero la persona asignada sigue resolviendo el trabajo por el camino de siempre, y nadie lo notó a tiempo.

Si la causa es alguna de esas tres, la corrección es reducir el alcance, no extender el calendario: es preferible cerrar el plan con un caso de uso más chico pero operando, que estirarlo 60 días más persiguiendo el alcance original. Si después de corregir el alcance el número sigue sin moverse, ahí sí hay que aceptar una conclusión menos cómoda: el proceso elegido no tenía, para empezar, un problema que la inteligencia artificial pudiera resolver, y el error se cometió el día 1, no el día 45.

Mi criterio sobre por qué 90 días y no otro número

El día 91 no es el final, es la prueba de que el proceso aguanta solo

El día 91 no trae una ceremonia de cierre ni un contrato nuevo firmado en automático. Trae una pregunta incómoda y necesaria: ¿el proceso sigue operando distinto sin que el equipo que lo construyó esté encima todos los días? Si la respuesta es sí, el plan cumplió su función real, que nunca fue impresionar a nadie en una presentación, fue instalar un cambio que no depende de la presencia constante de quien lo instaló.

Lo que sostengo, y por lo que discuto cuando un cliente pide otro plan de 90 días para otro proceso sin cerrar el anterior, es que el segundo plan solo tiene sentido si el primero sigue vivo sin ayuda. Un plan de 90 días que se apaga en cuanto el consultor se va no demostró nada, solo prestó una operación por tres meses. La empresa que entiende esto deja de pedir más IA y empieza a pedir el siguiente proceso concreto que merece el mismo tratamiento: medir, ordenar, construir lo mínimo, operar y volver a medir. Esa disciplina, repetida proceso por proceso, es lo más parecido a una transformación real que va a ver una empresa, y no se parece en nada a la promesa de transformación que le vendieron en el comité.