Resumen ejecutivo

• Pasar de analista de datos a practicar machine learning es un puente de skills (Python, features, evaluación) + 3 proyectos de transición — no un salto obligatorio a ML Engineer.

• Conservá tu ventaja: SQL, negocio y storytelling; sumá modelado supervisado simple con scikit-learn y experimentación honesta.

• Señales de que aún no hace falta un rol full-time de ML: el problema se resuelve con reglas/BI, no hay labels ni infraestructura, o el valor está en el análisis no en la predicción.

• Checklist claro: gaps, proyectos, métricas offline y narrativa de carrera sin humo.

Si ya sos analista y te tienta el machine learning, el riesgo es doble: quedarte solo en tutorials de redes neuronales, o renunciar a tu ventaja de negocio para perseguir un título de ML Engineer antes de tiempo. El ángulo de este artículo es el puente práctico — gaps de skills, tres proyectos de transición y señales de cuándo todavía no hace falta el salto full-time. ¿Por qué ahora? Porque “machine learning” aparece con demanda alta en búsquedas formativas y laborales, y la industria sigue pidiendo perfiles que combinen datos y modelos aplicados: la documentación de scikit-learn Getting Started es el piso técnico más usado para ese primer tramo, y guías de transición (por ejemplo relatos de analistas que evolucionaron hacia roles de ML en Towards AI) coinciden en priorizar proyectos reales y fundamentos de ingeniería sobre teoría aislada.

Qué ya traés (y no tenés que tirar)

• SQL y modelado analítico (grain, joins, métricas).

• Sentido de negocio: KPIs, stakeholders, ambigüedad.

• Visualización y storytelling.

• Higiene de datos: nulls, outliers, definiciones.

Eso es oro en ML aplicado. Un modelo sin pregunta de negocio es un notebook bonito. Si necesitás reafirmar el rol base, volvé a qué hace un data analyst.

Gaps típicos de skills (checklist)

1. Python orientado a datos

pandas para wrangling, funciones claras, notebooks reproducibles, entorno (venv/poetry) y Git básico. No necesitás ser software engineer el día uno, pero sí código legible y versionado.

2. Fundamentos de ML supervisado

• Train/validation/test y por qué existe el leakage.

• Clasificación vs regresión; métricas (accuracy no siempre alcanza: precision/recall, ROC-AUC, MAE/RMSE).

• Baselines simples (media, regla de negocio, modelo lineal) antes de ensembles.

• Feature engineering desde tu SQL mental: agregaciones por entidad, lags, ratios.

3. Evaluación y experimentación

Hipótesis → experimento → resultado → decisión. Cross-validation cuando el dataset lo permite. Documentar supuestos. La doc de scikit-learn sobre pipelines y preprocessing existe justamente para evitar errores de train/serve y scaling mal aplicado.

4. Productización mínima (opcional al inicio)

Guardar el modelo, inferencia batch, monitoreo liviano de drift. Esto diferencia “practiqué ML” de “entrené un .pkl una vez”.

Tres proyectos de transición (de analista a ML práctico)

Proyecto A — Predicción de churn / conversión (clasificación)

Por qué: conecta directo con negocio. Datos: exportá desde SQL features por usuario/cliente. Modelo: logistic regression + random forest como techo inicial. Entrega: métricas, matriz de confusión, importancia de variables, y un párrafo de acción (“a quién contactar primero”). Señal de seniority analítica: comparar contra un baseline de reglas.

Proyecto B — Forecasting de demanda o revenue (regresión / series)

Por qué: los equipos de ops y finanzas entienden el valor. Empezá simple (tendencia + estacionalidad o modelo tabular con lags). Explicá error en unidades de negocio (“nos desviamos X unidades”).

Proyecto C — NLP liviano o scoring de texto (tickets, reviews, leads)

Por qué: mucha IA aplicada en empresas empieza por texto. Clasificá sentimiento o intención con un pipeline clásico o un modelo pequeño; uní el output a un dashboard de analista. Mostrá límites y falsos positivos.

En los tres: README con problema, datos, método, métricas, limitaciones y “qué haría en producción”. Eso es lo que miran en entrevistas de transición.

Señales de que todavía no hace falta saltar a ML Engineer

• El problema se resuelve con mejor definición de KPI, un dashboard o una regla — y nadie usaría el modelo.

• No hay labels confiables ni forma de crearlos.

• No hay ownership de datos ni infraestructura mínima; el “modelo” viviría en tu laptop para siempre.

• Tu objetivo real es impacto de negocio en 3 meses: un rol de analytics fuerte + ML part-time suele rendir más.

• Te atrae el título más que el loop de datos→modelo→decisión.

ML Engineer full-time suele exigir barra de software (estructuras de datos, sistemas, serving). Podés practicar ML desde analytics sin mudarte de título todavía — y eso está bien.

Plan de 8 semanas (part-time)

1. Semanas 1–2: Python + pandas sobre un dataset que ya conocés por SQL.

2. Semanas 3–4: proyecto A end-to-end con scikit-learn Pipeline.

3. Semanas 5–6: proyecto B o C; sumá comparación de modelos y error analysis.

4. Semanas 7–8: pulí READMEs, publicá, contá la historia en LinkedIn; decidí si tu próximo paso es rol híbrido (Analytics + ML) o profundizar ingeniería.

Plantilla de README para tus proyectos ML (copiá y adaptá)

1. Problema de negocio: qué decisión habilita el modelo.

2. Datos: fuente, período, unidad de análisis, cómo evitaste leakage temporal.

3. Baseline: regla o promedio; métrica y resultado.

4. Modelo: algoritmo, features clave, hiperparámetros relevantes.

5. Evaluación: métrica alineada al costo del error (ej. recall si perder un churn duele más).

6. Error analysis: 5–10 casos donde falla y por qué.

7. Uso: cómo lo consumiría un equipo (lista priorizada, alerta, dashboard).

8. Limitaciones y ética: sesgos, poblaciones poco representadas, riesgo de uso indebido.

Si tu README responde eso, ya estás por encima de la mayoría de notebooks de Kaggle sin contexto. En entrevistas, ese documento es tu guion.

Cómo hablar de ML sin exagerar tu seniority

Frases útiles:

• “Entrené un modelo supervisado con validación temporal; el lift vs baseline fue X.”

• “Todavía no lo servi en producción; el siguiente paso sería batch scoring semanal y monitoreo de drift.”

• “Elegí un modelo interpretable porque el stakeholder necesitaba explicabilidad para una campaña.”

Evítá: “soy ML Engineer” si tu día a día sigue siendo analytics sin ownership de sistemas. La honestidad calibrada genera más confianza que el title inflation.

Cursos recomendados de Coderhouse

Si tu base analítica todavía necesita estructura y proyectos, el Curso de Data Analytics y la Carrera de Data Analytics consolidan SQL, análisis y storytelling — el piso desde el cual el ML tiene sentido. Como complemento de mindset y herramientas de IA aplicada al trabajo, Introducción a la Inteligencia Artificial ayuda a ubicar modelos, límites y casos de uso sin venderte una reconversión falsa.

CTA: esta semana elegí el Proyecto A (churn/conversión), definí la métrica de negocio y entrená un baseline + un modelo simple. Publicá el README. Si necesitás reforzar la base analítica, mirá Data Analytics en Coderhouse y usá ese dataset real como puente a ML.

Preguntas frecuentes

¿Tengo que aprender deep learning ya? No. Para la mayoría de problemas tabulares de empresa, modelos clásicos bien evaluados alcanzan al inicio.

¿SQL se vuelve inútil? Al contrario: sigue siendo la fuente de features. El analista que sabe SQL + ML liviano es muy valioso.

¿Cuándo pongo “Machine Learning” en el LinkedIn? Cuando tengas al menos un proyecto end-to-end con métricas y puedas defender leakage, baseline y decisión de negocio.

¿ML Engineer es el único destino? No. Analytics Engineer, Product Analyst con modelos, o Data Scientist aplicado son puentes válidos según la empresa.