El mercado de la IA corporativa se llenó de decks. Hay un diagnóstico de 80 páginas, un mapa de calor de casos de uso y una hoja de ruta a 18 meses. Lo que casi nunca hay es algo que un equipo pueda usar el lunes siguiente.
Esa distancia —entre el slide y el sistema— es el problema que resolvemos. No con más teatro. Con un recorte deliberado: pasar de un diagnóstico honesto a un prototipo que opera, en aproximadamente tres semanas.
Por qué el “proyecto de IA” se queda en el deck
La receta habitual es conocida. Se entrevista a diez personas, se dibuja un funnel, se lista “oportunidades” y se presenta un portafolio de iniciativas. El comité asiente. Después nadie es dueño de la primera versión, el dato no está donde se prometió y el vendor necesita tres meses de discovery adicional.
El deck no es inútil. El error es tratarlo como entregable final. Un diagnóstico sin artefacto operable deja a la organización en el mismo lugar: con opiniones más sofisticadas y sin evidencia de que el caso de uso cabe en su operación.
Tres semanas no son un milagro. Son un marco que obliga a elegir.
Qué cabe en ~tres semanas — y qué no
Cabe un recorte: un flujo real, con datos reales (o un subconjunto fiel), usado por personas reales. Cabe un prototipo que responde, clasifica, resume o rutea con la calidad suficiente para decidir si vale la pena integrarlo. Cabe, sobre todo, una conversación distinta al final: ya no “¿y si tuviéramos IA?” sino “¿esto entra a producción o no?”.
No cabe una plataforma. No cabe rehacer el ERP. No cabe un modelo fundacional propio. No cabe “IA en toda la compañía”. Quien venda eso en un sprint está vendiendo un segundo deck.
El plazo es corto a propósito. Si el caso no sobrevive tres semanas de contacto con la operación, no iba a sobrevivir un año de programa.
Diagnóstico con el modelo de negocio, no con la moda
Empezamos por el negocio, no por el modelo. Mapeamos cómo crea, entrega y captura valor la empresa: operaciones, personas, tecnología. El Business Model Canvas no es un poster de workshop; es la malla contra la que chocan los casos de uso.
Preguntamos dónde se pierde tiempo, dónde hay juicio repetido, dónde el dato ya existe y nadie lo usa. Priorizamos por ROI verificable, no por brillo. Un clasificador de tickets puede valer más que un copiloto espectacular que nadie abre.
El diagnóstico cabe en días, no en trimestres, porque su propósito no es agotar el universo de oportunidades. Es elegir una apuesta que se pueda prototipar.
El prototipo como prueba operable
Un prototipo de feria se ve bien en una sala. Un prototipo operable se usa en un escritorio, con los casos feos, con el usuario que no leyó el manual.
Eso implica límites explícitos: qué entra, qué queda fuera, qué pasa cuando el modelo duda. Implica instrumentar lo suficiente para ver si acierta. Implica que el equipo del cliente toque el flujo —no que mire una demo con datos de muestra.
Al cabo de ~tres semanas no prometemos transformación. Prometemos evidencia. Si el prototipo no sostiene la tesis, mejor saberlo barato.
Después: integración y adopción, sin vender un segundo producto
Cuando el prototipo sostiene la tesis, el trabajo cambia de naturaleza. Hay que integrar con los sistemas que ya existen, gobernar el dato, entrenar al equipo que va a convivir con la herramienta. Eso no es “la fase 2 de la misma charla”. Es otro oficio, con otros riesgos.
Lo que no hacemos es empujar un producto empaquetado que la empresa no pidió. El prototipo es de ustedes: prueba que el caso cabe. La integración se diseña sobre esa prueba, no sobre un roadmap genérico.
Tres semanas no reemplazan una estrategia. Evitan que la estrategia se quede, otra vez, en el PDF.