Por qué los proyectos de IA no llegan a producción

La mayoría de los pilotos de IA muere entre la demo y producción por tres razones: se eligió la tecnología antes de definir el problema de negocio, no hay dueño operativo cuando el proveedor termina, y la arquitectura no resiste datos reales. Un MVP funcional en la semana 4 obliga a descubrir las tres a tiempo.

Por qué ocurre: la demo y la producción no se parecen

Una demo de IA corre sobre datos elegidos, con volúmenes cómodos y sin nadie esperando del otro lado. Producción es lo contrario: datos sucios, casos que nadie previó, y un usuario que abandona si la respuesta tarda.

El primer motivo es de orden. Cuando la conversación empieza por la herramienta —qué modelo, qué proveedor, qué plataforma— el problema de negocio se define después, y termina moldeado para que encaje con lo que la herramienta hace bien. Se construye algo que funciona, pero que no resuelve lo que dolía. Negocio primero, tecnología después, no al revés.

El segundo es de propiedad. El piloto lo construye un equipo externo que conoce cada decisión que tomó. Cuando el contrato termina, el sistema queda en manos de gente que no participó de esas decisiones. No falla por mala calidad: falla porque nadie adentro puede evolucionarlo sin llamar a quien lo hizo. Una arquitectura que el equipo del cliente no puede tocar es una dependencia, no una entrega.

El tercero es de escala. Un modelo que responde bien sobre mil registros curados se comporta distinto sobre el histórico completo, con los campos vacíos, los duplicados y las categorías que alguien inventó en 2019. Ese descubrimiento llega tarde casi siempre, porque el piloto se diseñó para demostrar que la idea funciona, no para descubrir dónde se rompe.

Cómo detectarlo antes de aprobar el presupuesto

Cuatro preguntas antes de firmar.

¿Qué decisión de negocio cambia si esto funciona? Si la respuesta describe una capacidad técnica —«vamos a clasificar documentos automáticamente»— y no una decisión —«el equipo legal deja de revisar 400 contratos por mes»— el problema todavía no está definido.

¿Sobre qué datos corre la demo? Si son datos preparados, pregunte cuándo se va a probar sobre los reales. Si la respuesta es «más adelante», ese riesgo está entero por delante.

¿Quién lo opera dentro de seis meses? Debe haber un nombre, o al menos un rol. Si la respuesta es el proveedor, el proyecto no termina nunca.

¿Cuándo veo algo funcionando? Si la primera entrega tangible está a más de un mes, el proyecto está apostando a que el análisis inicial fue correcto. Rara vez lo es.

Qué cambia con entrega incremental

La alternativa no es analizar menos. Es cerrar el ciclo antes.

Un MVP funcional desde la semana 4 no busca estar completo: busca poner algo real frente a usuarios reales mientras el presupuesto todavía se puede redirigir. A partir de ahí, sprints de dos semanas con feedback constante, que es el intervalo en el que un error de supuesto todavía cuesta barato.

Ese ritmo tiene una consecuencia que conviene decir de frente: exige disposición a iterar del lado del cliente. Si la organización no puede dar feedback cada dos semanas, el método no funciona y conviene saberlo antes de empezar.

Y el criterio de cierre no es que el sistema ande. Es que el equipo interno pueda evolucionarlo sin depender del proveedor que lo construyó. Esa es la diferencia entre una entrega y una dependencia, y se decide en la arquitectura, no en la reunión final.

El punto de partida

Si la idea existe pero no está claro cómo ejecutarla técnicamente, ese es el escenario para el que está pensado el discovery: definir el problema de negocio y la arquitectura antes de escribir la primera línea.

Conozca el enfoque de innovación digital y soluciones con IA de Latam Digital — discovery, arquitectura y entrega incremental, con el equipo del cliente adentro.