¿Cuántos Proyectos IA Completas Anualmente?

Solo el 32% de los proyectos de machine learning que inician las empresas terminan en producción. Aunque el 85-87% comienza con entusiasmo, la realidad es brutalmente diferente: la mayoría se estanca en la fase experimental, se queda sin presupuesto o muere en la transición entre laboratorio y producción. La verdad incómoda es que escribir código para un modelo es lo fácil; hacerlo funcionar en producción a escala, mantenido y reentrenado, es completamente otra cosa.

Un proyecto de machine learning en producción es un modelo entrenado, desplegado y monitoreado en un sistema real que toma decisiones o genera predicciones recurrentemente. No es un notebook que funciona en tu máquina local ni un prototipo que mostras en una reunión (spoiler: no funcionan casi nunca). Es una pieza de ingeniería con data pipelines, versionado, reentrenamiento automático y alertas cuando el modelo empieza a degraparse.

¿Cuál es la realidad de los proyectos ML en producción?

Mirá los números: el 88% de las empresas dice que usa IA. Suena bien hasta que te enteras de que solo el 25% de ellas logró llevar el 40% de sus iniciativas a producción. La brecha no es pequeña, es un abismo. Estamos hablando de que si tu empresa lanzó 100 iniciativas de IA, apenas 25 de ellas vieron la luz de verdad.

Según KDnuggets, el 78% de los proyectos se estancan antes del deployment. No fallan explosivamente en producción (eso también pasa, pero es lo menos). Se pierden en la nada. El equipo original ya no está, la prioridad cambió, alguien se fue, y el proyecto queda flotando en el limbo del “cuando terminemos esto”.

La diferencia entre “usamos IA” y “tenemos ML en producción” es la diferencia entre decir que tenés un auto en el garaje y decir que lo usás para ir al laburo todos los días. Donweb ve esto constantemente con clientes que contratan para “implementar IA” en sus sites. Muchos arrancan con entusiasmo. Pocos terminan.

El cuello de botella: del experimento a la producción

Si mirás cómo los data scientists gastan el tiempo, encontrás esto: 41% en limpieza y preparación de datos, 26% en feature engineering, 17% en algoritmos y modelado, 9% en deployment, 7% en extracción de datos. (Sí, en serio, deployment es el punto más pequeño. Y después nos preguntamos por qué nada llega a producción.)

Según The New Stack, el 40% de las empresas tarda más de un mes en desplegar un modelo. El 28% toma entre 8 y 30 días. Solo el 14% lo hace en menos de 7 días. Ahora imaginate: invertiste tres meses en build y tardás un mes en deployar. Es como construir un auto lentísimo y después tardar una eternidad en ponerlo en el camino.

Netflix tardó años en lograr 99.9% de precisión en producción en recomendaciones cuando en laboratorio alcanzaba 90% en dos semanas, subís el modelo, lo probás en local, funciona bárbaro, lo mandás a producción y de repente todo se rompe porque el tokenizer no era el mismo, las dependencias no matcheaban, la data en producción era diferente de la del training, y nadie había documentado nada de esto.

Cinco problemas que sabotean proyectos ML desde dentro

Data leakage. Incluyó información en el training que no tenías en el momento de la predicción. El modelo aprende algo que no puede reproducir en el mundo real. Tus métricas parecen de ensueño, la producción es un desastre. Esto se conecta con lo que analizamos en implementar medidas de seguridad robustas.

Model drift y data drift. El modelo entrenado en 2024 funcionaba perfecto. Ahora estamos en 2026 y la distribución de datos cambió (data drift), o el patrón subyacente cambió (concept drift). El modelo sigue haciendo exactamente lo que aprendió, pero ya no sirve. Según NannyML, el 80% de los ML practitioners no logra reproducir resultados después de 3 meses sin versionado ni reentrenamiento automático.

Train-serve skew. El modelo en training usa features calculadas de una forma; en producción, otra. Los pipelines no están sincronizados. Es decir que el modelo nunca vio en entrenamiento los datos exactos que ve en producción (spoiler: terrible idea).

Falta de gobernanza de datos. Nadie sabe quién etiquetó los datos, con qué criterio, cuáles son las clases desbalanceadas, si hay duplicados, qué tan sesgados son. Terminás con un dataset que parece Frankensteined de tres fuentes distintas.

Silos organizacionales. Los data scientists construyen. Los engineers dicen que el código es un desastre y hay que reescribirlo. El producto no entiende por qué tarda tanto. La empresa corta presupuesto. El proyecto muere sin que nadie sea responsable.

Las cinco causas raíz del fracaso según RAND Corporation

RAND Corporation entrevistó a 65 data scientists y ML engineers. Las cinco causas raíz recurrentes fueron:

1) Elegiste el problema equivocado. Bonito el modelo que sacaste, pero ¿resuelve un problema que el negocio realmente necesita resolver? Ponele que optimizaste predicciones en un área donde nadie paga por precisión. Desplegás, nadie lo usa, muere.

2) Data de mala calidad o etiquetado inconsistente. Basura adentro, basura afuera. InfoQ reporta que data quality es el 80% del esfuerzo real en proyectos ML. Si la data está sesgada, con ruido o etiquetada inconsistentemente, el modelo jamás aprende correctamente.

3) El gap model-to-product: silos entre data science e ingeniería. El DS construye en Python con librerías. El engineer dice que eso no se puede deployar en C++ a escala. Empiezan las negociaciones. Seis meses después, el proyecto se paralizó.

4) Mismatch offline-online (train-serve skew).⁣ Validaste offline y la métrica subió 15%. Desplegaste online y los usuarios dicen que es una basura. Porque online hay latencia, el feedback es diferentes, las features calculan distinto.

5) Blockers no técnicos: organizacionales, presupuestarios, falta de talento.⁣ El proyecto necesita un ML engineer senior. No hay. Necesita infraestructura en la nube. El presupuesto se congeló. Hay rotación de liderazgo. Un blocker técnico, lo resolvés codificando. Estos, no. Más contexto en herramientas como ChatGPT en tus proyectos.

Cómo Netflix, Google y Spotify lo hacen correctamente

Netflix: el imperio de las recomendaciones. Según análisis de arquitectura de Netflix, el 80% del consumo viene de recomendaciones, eso le ahorra aproximadamente $1 mil millones en churn anual. ¿Cómo? Feature store centralizado, pipelines que van desde 10 mil candidatos a 1 mil a 50 finales. Testing A/B riguroso. El modelo no es complicado; lo que es complicado es la infraestructura que lo rodea.

Spotify: escala y resiliencia. Spotify ejecuta 20 mil jobs de procesamiento de datos diarios y migró 1.200 servicios a la nube. Conseguís resiliencia no escribiendo un modelo increíble, sino teniendo pipelines que no se caen, monitoreo que alerta en minutos, y rollback automático si algo falla.

Google: la infraestructura es la característica. Google trata la capacidad de experimentar rápido como arquitectura de primer nivel. Tienen sistemas de testing A/B integrados, feature stores, data lakes versionados. El punto no es que los ingenieros de Google sean mejores (bueno, sí, pero ese no es el punto). Es que tienen la infraestructura que permite iterar seguro 100 veces al día sin romper nada.

El contexto en Latinoamérica: oportunidad con brechas reales

En América Latina, el panorama es diferente pero con el mismo patrón: 41.9% de las empresas usa IA (comparado a 16.9% en 2022). Suena bien, ¿viste? Pero aquí está lo importante: el 31% dice que no tiene skills en el equipo, el 30% tiene infraestructura insuficiente, el 28% enfrenta resistencia organizacional. Brasil está más adelante con mayor porcentaje de compañías con IA operativa, pero sigue siendo una minoría.

Para una empresa tecnológica o agencia en la región, hay una oportunidad clara: si dominás el deployment de ML en producción, te diferenciás de la mayoría. Hosters como donweb.com empiezan a notar que muchos clientes quieren alojar modelos, pipelines, microservicios de ML. Los que lo hacen bien, generan valor real.

Timelines reales: cuánto tarda cada fase

Roadmap realista: MLOps básico en 90 días

Semanas 1-3: Infraestructura mínima viable. Pipelines de data reproducibles. Data versionado. Model registry (qué versión del modelo está en qué ambiente). CI/CD básico.

Semanas 4-6: Entrenamiento y evaluación automatizados. El modelo se reentrana solo cuando hay data nueva. Evaluación automática contra métricas preestablecidas. Si cae la performance, no se despliega.

Semanas 7-9: Monitoreo y alertas. Sabés en tiempo real si el modelo está degradándose (drift). Alertas a Slack si algo falla. Logs de decisiones para auditoría.

Semanas 10-12: Rollback y estrategia de shadow deployment. Podés volver a la versión anterior en 5 minutos sin downtime. El nuevo modelo corre en paralelo, generando predicciones, sin que los usuarios vean.

Eso es madurez básica. Madurez avanzada (feedback loops, reentrenamiento online, A/B testing integrado) tarda 6-12 meses más. Ya lo cubrimos antes en modelos de GPT para producción.

Cómo medir éxito (spoiler: no es solo “modelo en producción”)

Muchas empresas celebran cuando despliegan. Error. El deployment es el inicio, no la meta.

Métrica 1: Adoption. ¿El modelo se está usando? ¿Las predicciones se consumen? He visto modelos en “producción” que generaban predicciones cada día pero nadie las leía.

Métrica 2: Model performance vs baseline. ¿Mejora respecto a lo que había antes? Si el baseline era tirar una moneda y tu modelo es 2% mejor, no es Victoria.

Métrica 3: Drift detectado y accionado. ¿Monitoreas drift? ¿Reentrenás cuando degrada? Si los primeros tres meses funcionó bien y después se fue a pique sin que nadie se entere, no medís nada.

Métrica 4: Latencia y disponibilidad. El modelo perfecto que tarde 30 segundos por predicción no sirve si necesitás respuesta en 200ms. El uptime importa.

Si no medís esto, estás operando a ciegas.

Cinco errores comunes que vemos una y otra vez

Error 1: No documentar el training set. Pasó un año. El ML engineer original se fue. Nadie sabe en qué data se entrenó el modelo, con qué splits, cuál fue el seed random. Cuando falla, nadie puede reproducirlo. Regla de oro: documentá TODO como si fueras a desaparecer mañana.

Error 2: Validar offline, deployar sin testear online. Offline: 92% de accuracy. Online: 47% de precision real en casos edge. Pasó porque la data en producción es diferente, más ruidosa, con distribuciones que nunca viste. Siempre shadowing primero. Siempre. Complementá con alternativas como Gemini disponibles.

Error 3: Modelo en una box negra, sin explicabilidad. El modelo dice sí o no. ¿Por qué? Nadie sabe. Cuando falla y querés debuggear, no tenés idea de dónde empezar. SHAP, LIME, o al menos logs de features importancia. Explicabilidad no es lujo, es necesario.

Error 4: No definir cuándo reentrenar. ¿Cada día? ¿Cada semana? ¿Cuando la accuracy cae 5%? Sin regla clara, terminas reentrenando demasiado (costo, inestabilidad) o muy poco (degradación no detectada).

Error 5: Despreciar el feedback manual de usuarios. Los usuarios descubren edge cases que tu test suite no predijo. Si ignorás su feedback diciendo “el modelo está en producción, así que está listo”, te equivocás. Los mejores datasets para reentrenamiento son los casos donde el modelo falló en el mundo real.

Preguntas frecuentes

¿Cuántos proyectos ML completa una empresa típica por año?

Una empresa mediana completa 1-3 proyectos ML a producción por año. Una grande, 5-15. Eso incluye refrescos y actualizaciones de modelos existentes. Si tenés 10 iniciativas activas y 2 llegan a producción, sos en línea con la media.

¿Por qué el 85% de los proyectos ML nunca llegan a producción?

Porque la brecha entre “modelo que funciona en un notebook” e “infraestructura que soporta un modelo en producción” es enorme. Requiere data pipelines, monitoreo, reentrenamiento automático, alertas, logs, versionado. Eso no viene con scikit-learn. Hay que construirlo.

¿Cuál es el tiempo promedio para desplegar un modelo ML?

Entre 8 y 30 días para el 28% de las empresas, más de 30 para el 40%. Si tenés MLOps básico, podés bajar a 1-2 días. Si no, cada deployment es una aventura.

¿Qué tan importante es monitorear el modelo después de deployado?

Es criticoo. Sin monitoreo, el modelo degrada silenciosamente. Eso es peor que fallido obviamente, porque engañás a usuarios durante meses con predicciones que empeoraron gradualmente. Monitorea drift, accuracy, latencia, tasa de rechazo.

¿Cuál es la diferencia entre model drift y data drift?

Data drift: la distribución de datos cambió (ej. usuarios nuevos, patrón estacional). El modelo es el mismo, pero ya no match. Model drift (o concept drift): la relación entre features y target cambió (ej. en 2024 la gente compraba X, ahora compra Y). Ambos requieren reentrenamiento.

Conclusión

La realidad es que completar un proyecto de machine learning en producción es más difícil de lo que parece. No porque el machine learning sea complicado técnicamente, sino porque deployar, monitorear y mantener un modelo a escala requiere infraestructura, disciplina y perseverancia que la mayoría de las empresas no tiene.

El 85% de los proyectos falla no en la fase de modelado, sino en la de productivización. Es como cocinar bien en tu cocina pero no poder cocinar en un restaurante al mismo tiempo.

Si el desafío te atrae, hay oportunidad. En Latinoamérica especialmente, donde apenas el 25% de iniciativas de IA llegó a producción, cualquiera que domine MLOps se diferencia. No necesitás ser data scientist de Google. Necesitás disciplina: versionado, pipelines, monitoreo, reentrenamiento automático, y la paciencia de mantenerlo funcionando año tras año.

Los que lo hacen bien no son más inteligentes. Solo fueron consistentes.

Fuentes

• KDnuggets – Survey: Machine Learning Projects Still Routinely Fail to Deploy
• InfoQ – Why Machine Learning Projects Fail in Production
• RAND Corporation – Challenges to Deploying Machine Learning Systems
• The New Stack – How Long Does a Machine Learning Deployment Take?
• NannyML – 3 Common Causes of ML Model Failure in Production