Machine learning consultor en LATAM: framework de contratación, presupuestos y use cases 2026

Resumen en 60 segundos

El 70% de los proyectos de machine learning en LATAM muere en POC, según Stanford AI Index 2025. La causa no es la tecnología: es comprar el modelo antes de tener la pregunta de negocio, los datos y la infraestructura. Esta página describe cómo debe operar un machine learning consultor en la región, cuándo contratarlo, y por qué 4 de cada 10 proyectos queman USD 80 000+ antes de la primera métrica en producción.

• Adopción real: menos del 2% de las empresas en LATAM usa ML en producción (Stanford AI Index 2025). Cerca del 70% sigue atorado en POC; otro 20% llama «AI» a un junior con un Jupyter notebook.
• Qué hace un machine learning consultor: traduce el problema de negocio en un problema de aprendizaje, verifica que los datos alcanzan, y lleva el modelo a producción con stack MLOps. No «hace AI», no «calcula ROI en slides», no «entrena GPT-4 con tus datos en una semana».
• 4 use cases que se pagan en LATAM: demand forecasting (retail y QSR), fraud detection (fintech y banca), churn prediction (telecom y SaaS), lead scoring (ventas B2B).
• Presupuestos: USD 25 000–80 000 para un MVP de 8–12 semanas hasta el primer modelo en producción. USD 80 000–300 000 para proyecto completo con MLOps y handoff. Más barato es plantilla de GitHub disfrazada de consultoría.
• Regulación por país: Chile Ley 21.521 (sistema de finanzas abiertas), México INAI (Ley Federal de Protección de Datos), Argentina AAIP (Ley 25.326), Colombia CONPES 3975, Perú Ley 29733. Ignorarlas equivale a modelo en el cajón después de la primera auditoría.
• Cuándo NO contratar: menos de 50 000 registros limpios, sin data engineer interno, sin KPI con números. «Queremos usar AI» no es un objetivo de proyecto.

Tres olas de ML en LATAM (2017 a 2026)

El machine learning en la región cruzó tres etapas claras, y cada una dejó cicatrices distintas en los presupuestos.

#1. 2017–2020: las nubes venden la plataforma, los POC mueren

AWS, Microsoft y GCP empujan «AI as a service» con los Big-4 como integradores. Bancos y retail grande compran. El resultado es presentaciones en Google Drive y demos que nunca llegan a tráfico real. Las historias en producción de la era se cuentan con los dedos: motor de recomendaciones de Mercado Libre, fraud detection de Itaú, inventario de Falabella.

#2. 2021–2023: open-source pasa a production-ready

scikit-learn, XGBoost, PyTorch, MLflow y DVC salen de beta. Aparecen los primeros proyectos serios de segunda ola: credit scoring de Nubank, delivery routing de Rappi, computer vision de Dodo Pizza, claims processing de QIC (MENA), pricing de seguros de AlfaStrakhovanie (RU). Los precios siguen altos: equipos de 30+ personas, 12–18 meses, decenas de millones de USD.

#3. 2024–2026: el costo baja, la PYME entra en juego

Los LLM abarataron parte del pipeline (data labeling, document parsing, embeddings) pero no reemplazaron al ML clásico para tabular, time-series y forecasting. El stack MLOps maduró. Un proyecto en producción hoy lo arma un equipo de 3–5 personas en 3–6 meses. Esta es la ventana para PYME y mediana empresa: lo que en 2020 costaba USD 1M, en 2026 cuesta USD 80k.

En paralelo apareció la madurez regulatoria. El OECD AI Policy Observatory rastrea 11 países LATAM; 6 ya tienen estrategia o proyecto de ley nacional. CEPAL publicó varios reportes sobre ética en AI. Chile aprobó en 2023 la Ley 21.521 (Sistema de Finanzas Abiertas), que liberó datos bancarios para ML pero exige cumplimiento de protección de datos. Colombia ejecuta CONPES 3975. México empezó a sancionar vía INAI por uso indebido de datos personales en modelos. Argentina aplica Ley 25.326 a sistemas de AI vía AAIP.

Qué hace un machine learning consultor: metodología sin humo

Un proyecto bien armado se mueve por cinco etapas. Saltarse una garantiza desastre — y todas las que se han saltado en LATAM han terminado igual.

#1. Data discovery + auditoría (1–2 semanas)

La primera reunión con el cliente no trata de modelos. Trata de si la empresa tiene datos. En esta etapa el consultor:

• cuenta registros por cada tabla relevante para la tarea;
• mide la profundidad histórica (menos de 6 meses es poco, más de 24 meses es base sólida);
• evalúa calidad: porcentaje de nulls, duplicados, distribution shift temporal;
• mapea el data lineage — de dónde vienen los datos, quién los toca, por qué ETLs pasan.

Si en esta fase aparece que hay menos de 50 000 registros limpios, o que los datos viven en un Excel del contador, el proyecto ML se detiene. Pasa primero por data engineering. El consultor que se salta este paso vende modelo en el aire.

#2. Baseline + feature engineering (3–4 semanas)

Cero gradient boosting, LSTM o transformers hasta que un modelo baseline (regresión logística, ridge o RandomForest con 5–8 features) muestre una métrica decente.

Por qué importa el baseline:

• fija el piso de métrica por debajo del cual no se debe caer;
• muestra si hay señal real en los datos o solo ruido;
• si baseline empata con XGBoost, el modelo aprende de algo distinto al objetivo y el planteamiento del problema está mal.

El feature engineering para LATAM exige contexto local: feriados y calendario (semana santa, fiestas patrias, navidad — cada región tiene su patrón), tipo de cambio USD (crítico para importadores, ruido para domestic), ventanas regulatorias (los reportes trimestrales SUNAT, SII, DIAN crean spikes en los datos).

#3. Selección de modelo + validación temporal (2–3 semanas)

Se entrenan 3–5 modelos: baseline, XGBoost o LightGBM, red neuronal (si hay datos), y un modelo específico para la tarea (Prophet o SARIMA para forecasting, GraphSAGE para fraud por grafos, transformers para NLP).

Validación: split temporal, no aleatorio. Un k-fold aleatorio sobre time-series es un error académico que paga ROC-AUC 0,92 en el papel y pierde 15 puntos de accuracy en el primer mes de producción. Los datos del futuro filtran al training set y todo se vuelve fantasía.

#4. Deployment + MLOps (4–6 semanas)

Stack mínimo viable:

• model registry (MLflow o equivalente);
• serving endpoint (FastAPI, BentoML, o SageMaker endpoint);
• monitoring de data drift, prediction drift y performance decay;
• schedule de retraining — de semanal a trimestral según estabilidad de datos;
• infraestructura A/B (shadow mode → 10% de tráfico → full);
• plan de rollback ante degradación.

Sin MLOps, el modelo muere en 2–4 trimestres por data drift que nadie monitorea. Es la causa #1 de proyectos que vuelven al consultor pidiendo «rescate».

#5. Monitoring + retraining (proceso continuo)

La parte larga. Un buen consultor deja al cliente:

• runbook con condiciones de retraining;
• alerting vía Grafana, PagerDuty o Slack;
• dashboard de KPI con conexión directa entre métrica de negocio y output del modelo.

Sin esto, a los 6 meses el modelo está muerto y el equipo paga otra vez por un «rescate». El buen consultor no vende reincidencia: construye para que el equipo interno se sostenga solo.

4 industrias donde el ML se paga solo en LATAM

#1. Retail y QSR: demand forecasting

Una cadena de 60+ restaurantes QSR hace forecast diario de 200+ SKU por local. Sin ML: overstock 18–25% y spoilage 6–8% del margen. Con ML: overstock 6–8%, spoilage 2–3%. Sobre facturación de USD 30M anuales, son USD 1,8–2,5M de ahorro.

Stack: SARIMA o Prophet para forecast base, XGBoost con features exógenas (clima, feriados, eventos locales), Bayesian hierarchical models para SKU en cascada.

#2. Fintech y banca: fraud detection

Las fintech LATAM (Mercado Pago, Nubank en Brasil, Yape en Perú, Nequi en Colombia, Ualá en Argentina) pierden entre 0,5% y 2,5% del volumen en fraude. El sistema rule-based clásico atrapa 60–70% de los casos. Gradient boosting (XGBoost, LightGBM) sube el recall a 88–93% con el mismo false positive rate. Sobre un volumen anual de USD 1B, son USD 5–25M rescatados.

Stack: scoring en tiempo real vía Kafka + feature store, graph neural networks para money mule detection, autoencoders para anomaly detection transaccional. Ver fraud detection: pipeline real-time para fintech.

#3. Telecom y SaaS: churn prediction

El SaaS LATAM (Globant, dLocal, Kavak, Bitso) crece rápido pero retiene mal: 65–75% MoM contra 80–90% de los SaaS US del mismo segmento. Un modelo de churn detecta el top 5% de clientes con riesgo a 30 días. Customer Success los trabaja uno a uno. Conversion to save: 40–55%, lo que recorta 2–3 puntos porcentuales del churn mensual. Ver churn prediction: metodología detallada.

#4. Ventas B2B: lead scoring

El CRM B2B típico en LATAM es un desastre: Odoo con millones de tags manuales, clientes duplicados, deals incompletos. Un lead scoring con XGBoost sobre 10–15 features sube el win rate de 8–12% a 18–25%. Sobre un pipeline trimestral de USD 5M, son USD 300k–650k extra cerrados. Ver lead scoring para ventas B2B en LATAM.

Cuándo contratar — y cuándo no

#1. Funciona — contrata

Situación A: tienes 50 000+ registros históricos, un data engineer interno, y un KPI fijado en cifras. Escenario ideal. Lead time del proyecto: 3–6 meses, MVP en producción a las 8–12 semanas. Equipo del consultor: 2–3 personas (senior ML engineer + data engineer + product manager). Presupuesto: USD 80k–200k.

#2. Funciona distinto — contrata pero con otro scope

Situación B: hay pocos datos (10k–50k registros) pero el proceso está mapeado y se logea. No se construye ML desde cero. Primero se monta un sistema rule-based que registra sus decisiones. A los 6–12 meses de acumular datos, se transita a ML. El consultor entrega un híbrido: rule-based engine + data pipeline + roadmap de retraining para el futuro.

Situación C: hay datos y KPI claro, pero el equipo es solo de analistas de negocio. El proyecto arranca, pero incluye data engineering y handoff a los equipos de accounting y operaciones en el scope. Presupuesto crece 30–50%. Plazo: 5–8 meses. Realista, pero más caro.

#3. No funciona — no contrates

Situación D: «queremos usar AI». No es un proyecto. Es presión de marketing por un CEO que leyó McKinsey en el avión. Un consultor honesto dice que no. El alternativo: USD 80k quemados y un deck en Google Drive que nadie abre al trimestre siguiente.

Situación E: menos de 10 000 registros, historia menor a 6 meses. El ML no funciona matemáticamente. Ningún XGBoost saca señal de 5k registros con ruido del 30%. Primero data engineering, acumulación, después ML. Sin atajos.

Situación F: KPI = «mejorar el proceso». Difusidad equivale a muerte. Si el KPI no es «reducir 15% el churn en un trimestre» o «subir 8 puntos en accuracy de forecast», no hay success criteria definidos. El consultor no puede demostrar que el proyecto se pagó, y a los 12 meses lo botan. El ML interno queda con fama de «no funciona».

5 errores que queman USD 80k+

#1. Comprar el modelo antes de definir el problema

El más frecuente. El CEO ve un slide en AWS Summit Buenos Aires que dice «AI baja el churn 30%» y va a comprar. Un consultor que sirva devuelve la conversación en la primera reunión: cuál es la pregunta de negocio, cuál es el KPI, cuáles son los datos. Sin respuestas, no arranca el proyecto.

#2. Ignorar la calidad de los datos

«Tenemos 5 millones de transacciones» suena bien hasta que sale que 40% están duplicadas, 25% tienen client_id roto y 15% son data de testing. El volumen real son 1M de registros limpios, y parte de las features no está disponible. Una auditoría de datos en la etapa 1 son 2 semanas de trabajo y un ahorro del 50% en la etapa 3.

#3. No tener data engineer dedicado del lado del cliente

El consultor no debe ser simultáneamente el data engineer del cliente. Es colapso de roles y bus factor 1: cuando se va el consultor, el modelo deja de mantenerse. Internamente debe haber alguien que sepa de dónde vienen los datos y a dónde van. Si no existe, el primer mes del proyecto se gasta contratando esa figura. La alternativa: a los 3 meses post-deploy el modelo muere y no hay quién lo arregle.

#4. No tener MLOps — el modelo «se despliega» en Jupyter

Caso real en un banco LATAM (anonimizado): el modelo de fraud detection se desplegaba copiando un Jupyter notebook al servidor de producción una vez al mes. A los 12 meses el data drift bajó el recall de 0,89 a 0,42, y el equipo de fraude no se dio cuenta hasta que la pérdida llegó a USD 4M. MLOps no es nice-to-have, es condición obligatoria de producción.

#5. «El mejor modelo posible» en lugar de «suficientemente bueno ahora»

El equipo gasta 2 semanas haciendo hyper-tuning de XGBoost para sacar +0,3% AUC. En métrica de negocio son +0,1%. Esas mismas 2 semanas alcanzaban para armar el pipeline de retraining, y a los 3 meses el modelo seguiría vivo en vez de degradarse por data drift. Prioridad correcta: deploy → monitor → iterate. No «perfect → deploy → cruzar dedos».

Caso anónimo: fraud detection en promocódigos, multi-marca

Caso anonimizado basado en trabajo con un grupo de 11 marcas de cosmética en Europa del Este y LATAM. El case study completo vive en Estée Lauder pricing & promo fraud.

Situación. Grupo de 11 marcas con plataforma común de promocódigos (e-commerce + boutiques offline, 6 países). Antes del proyecto operaba con fraud detection rule-based: bloqueo de códigos tras N usos desde la misma IP + review manual de casos sospechosos. El fraude promocional consumía 9–14% del presupuesto de campañas — códigos revendidos en grupos de Telegram, usados vía VPN, combinados con importación gris.

Qué se hizo.

• Etapa 1 (2 semanas): auditoría de datos — 18 meses de histórico, 4,5M de transacciones promocionales sobre 11 marcas. Clickstream completo + logs de checkout.
• Etapa 2 (4 semanas): baseline — regresión logística sobre 8 features (frequency, IP entropy, device fingerprint, tiempo entre códigos). ROC-AUC 0,78.
• Etapa 3 (4 semanas): XGBoost con 35 features + graph features (IPs y devices compartidos entre promocódigos) → ROC-AUC 0,91. El top 5% de casos sospechosos se enrutaba a review manual.
• Etapa 4 (6 semanas): scoring real-time vía Kafka + FastAPI endpoint, MLflow para versionado, retraining semanal vía Airflow DAG.

Resultado. El fraude promocional bajó de 11% a 3,2% del presupuesto de campañas en 6 meses. Sobre un presupuesto anual de USD 12M, eso son USD 940k de ahorro neto menos USD 180k de costo del proyecto = USD 760k de ROI neto en el primer año. A los 12 meses la pila había pasado 23 ciclos de retraining sin intervención humana, y el equipo cliente sostiene el pipeline solo.

«El día que decidimos cerrar la lista de features y deployar XGBoost recortó dos meses de proyecto. Lo difícil no fue elegir el algoritmo: fue saber que ese 0,91 alcanzaba.»

Checklist antes de arrancar un proyecto ML

14 preguntas que separan «equipo listo para ML» de «equipo que necesita primero data engineering». En 20 minutos sabes en qué cuadrante estás:

• Volumen y calidad de datos por evento de interés;
• Definición clara del KPI con número objetivo;
• Presencia de data engineer interno;
• Compliance regulatorio del país (INAI, DIAN, SUNAT, SII, AAIP, según corresponda);
• Madurez del stack de logging y observabilidad;
• Plan de retraining y monitoring post-deploy;
• Sponsor ejecutivo con bandwidth real.

El recurso completo (PDF + Excel con cálculo de ROI sobre los 4 use cases) está disponible en ML-readiness assessment LATAM.

Preguntas frecuentes