El modelo en el notebook tiene AUC 0.87. En producción la solicitud de crédito espera 14 días, porque la feature «número de transacciones a 30 días» es un export manual de GUI a CSV. O el p99 de inferencia salta por encima de 500 ms, porque alguien metió un pickle de un artefacto del portátil en un contenedor sin Feature Store.
Esto no es un problema de algoritmo. Es un problema de pipeline. La analítica predictiva en enterprise muere en un híbrido: Jupyter y Dataiku de un lado, Spark CLI, Airflow y kubectl del otro. El equipo clica, pega, exporta. El modelo envejece al ritmo del backlog «to deploy».
Lo que falta en la mayoría de los briefs «necesitamos un Data Scientist»: cuándo alquilar a una persona (data science staff augmentation, body leasing) y cuándo el pipeline necesita un squad de DE + DS + MLOps. Las tarifas horarias están en otro artículo: tarifas de body leasing IT en Polonia 2026. Aquí contamos por qué el AUC solo nunca llega a producción.
Una frase que nunca entra en la diapositiva comercial
Un Data Scientist sin un pipeline de datos es un investigador con un tope de 8 horas en Jira. Un pipeline sin Data Scientist es ETL que no predice nada. Hacer staff augmentation de un rol funciona cuando el otro ya está en su equipo. Si no, compraron un timesheet, no una predicción.
1. Anatomía: un notebook no es un producto
Un día típico de un equipo de analítica predictiva en un banco, telco o retailer no parece un tutorial de scikit-learn. Parece un cambio de modalidades:
- GUI: controles de calidad en una herramienta BI, un export manual del warehouse, clicar retrain en Dataiku / SageMaker Studio, mirar el drift en un dashboard.
- CLI / API: Spark-submit, dbt run, airflow dags trigger, kubectl rollout, MLflow log, un batch de BigQuery.
Cada cambio es donde muere la reproducibilidad. Una feature calculada en un notebook no es la feature calculada en el servicio. Eso es training-serving skew: el modelo aprende una definición que producción no va a repetir. Sculley et al. lo llamaron en 2015 pipeline jungles y glue code — deuda técnica de ML que crece más rápido que el propio modelo.
Tres señales de que tienen un jungle, no una plataforma:
- CSV como interfaz. La fuente de verdad es el export de ayer. Nadie sabe decir de qué tabla y con qué filtro.
- La feature se calcula dos veces. Pandas en un portátil, SQL en Airflow. Un gap de 0.3 pp en fill-rate aparece un trimestre después, cuando el drift ya está dentro de la decisión de crédito.
- El deployment como ticket a DevOps. El Data Scientist termina en «model.pkl». Otro empaqueta la imagen, un tercero configura el probe. De idea a inferencia: semanas, no días.
Por eso un brief «contratar un Data Scientist» sin contexto de pipeline es la forma más cara de conseguir otro notebook. Las competencias que de verdad ponen analítica predictiva en producción están en tres landings: Data Science y BI, Data Engineering, MLOps.
2. Lo que dicen los papers, no los decks de MLOps
No necesitan otra definición de «MLOps maturity». Necesitan los umbrales en los que un modelo no sale del laboratorio.
- La deuda de ML vive en el glue, no en el loss. Sculley et al., Hidden Technical Debt in Machine Learning Systems (NIPS 2015): en los sistemas de ML el código de aprendizaje suele ser una fracción pequeña. El resto es configuración, recolección, verificación, serving, monitoring. «Cambiar una feature» detona una cascada, porque las dependencias están ocultas. Un pipeline jungle crece cuando añaden caminos en vez de borrar los viejos.
- El trabajo en el ordenador es híbrido. Shi, Wang, Fang, Liang et al., CUA-Universe (arXiv:2609.05374, septiembre de 2026): el trabajo real mezcla inspección del estado visual con CLI preciso sobre un estado de aplicación compartido. Los agentes solo-GUI producen trayectorias ineficientes; los agentes solo-CLI se quedan ciegos al layout. El entrenamiento en híbrido GUI+CLI movió un modelo 9B: CUA-Verse +39.3 pts, −37% steps, −60% tokens; OSWorld SR +16.8 pts, −57% steps, −44% tokens. Esto no es un paper sobre scoring de crédito. Es una medición de lo que cuesta hacer malabares entre ventana y terminal. Un equipo de Data Science que clica en Studio y pega comandos en Confluence paga el mismo impuesto.
- La entrega es una métrica de equipo, no de notebook. DORA 2024: elite vs low es un orden de magnitud en frecuencia de deploy y change lead time. Esos números describen equipos con una Definition of Done compartida. Cinco timesheets separados (DS del vendor A, DE del B, «alguien de Kubernetes» del C) no componen un lead time. Componen tres SLA de reemplazo y un estado «in progress». Desmontamos ese modo de fallo en team leasing vs staff augmentation 2026.
La conclusión de arquitectura
Estandarizar el pipeline no es «comprar SageMaker». Es matar el cambio GUI↔CLI allí donde un API y IaC pueden sustituirlo. Feature Store, un DAG, una imagen de serving, un test de esquema en el PR. El resto es cosmética de vendor. Si su Data Scientist no puede reproducir una feature desde un commit, no tienen analítica predictiva. Tienen una demo.
3. Caso de producción: scoring que se retrasaba un sprint
Desde la práctica de ingeniería: de 3 semanas a 3 días
Una institución financiera, una cartera de millones de clientes. Scoring de solicitudes y detección de fraude. Fuentes: Oracle / PostgreSQL, un data lake (S3 + Hive), logs en Elasticsearch. El equipo de analítica predictiva trabajaba así:
- extracción: SQL escrito a mano, export CSV,
- features: Pandas en un portátil, joins en Excel «por si acaso»,
- entrenamiento: GUI de Dataiku, export manual del artefacto,
- release: un ticket a DevOps, Docker «como salga», API Gateway, Kubernetes sin test de esquema.
Problema: de idea a inferencia 3–4 semanas. Los modelos ya estaban obsoletos el día del go-live. p99 de las predicciones críticas > 500 ms. El coste de operación crecía con cada pickle nuevo.
Cambio: pipelines Spark orquestados por Airflow hacia un Feature Store (Hopsworks). Cada etapa (datos, train, validate, serve) en una imagen. GitOps al clúster. Monitoring de feature-drift y de calidad de datos (Prometheus / Grafana). DS deja de exportar CSV. DE deja de adivinar qué versión de feature meter en el batch.
Medido después: time-to-production 3 días en lugar de 3 semanas. Errores de pipeline y de deploy −85%. p99 de inferencia < 80 ms. Coste de infra MLOps −40% — no por una nube más barata, por no apagar fuegos a mano ni retrains abandonados.
Ese resultado no salió de «un XGBoost mejor». Salió de dejar el GUI para la inspección y el CLI/API para el camino que tiene que repetirse a las 03:00. La misma lección que CUA-Universe mide en agentes: el híbrido funciona cuando ambas modalidades comparten estado — no cuando un humano es el bus entre ventanas.
4. Tabla de decisión: qué pipeline, qué alineación
| Enfoque | Complejidad | Latencia p95/p99 | Coste de infra | Overhead de equipo | Cuándo usarlo |
|---|---|---|---|---|---|
| Notebook + ad-hoc ETL | Baja al inicio, crece de forma exponencial | Segundos–minutos, a menudo manual | Bajo al inicio | Alto (glue, debugging) | PoC, un analista, sin SLA |
| MLOps OSS (Airflow, MLflow, Kubeflow, Feast/Hopsworks) | Alta (plataforma) | ms–s, repetible | Medio | Medio–alto (DE + MLOps) | Enterprise que necesita control y on-prem / híbrido |
| Servicio gestionado (SageMaker, Vertex, Azure ML) | Media (integración cloud) | ms–s | Medio–alto (contadores del servicio) | Menor en lo operativo | Cuando ya viven en un único IAM de cloud y no arrastran un GUI legacy |
| Híbrido + alineación T&M | Muy alta | La marca el conector más débil | Alto | Alto hasta que GUI y API están cosidos | Banco, pharma, datos que no salen. Normalmente un squad, no un rol. |
Python CRUD y Python para pipelines de datos son dos oficios. Bandas de backend 145–200 / 200–280 PLN/h (contratista / cliente). Los data pipelines están en la parte alta de esa banda. AI/LLM en producción: 180–250 / 240–350 PLN/h. Margen 10–25%. Un mapa, no un tarifario — detalle en el artículo de tarifas 2026.
5. Antipatrones que no encontrarán en un tutorial de Kubeflow
- Un brief «Python Developer» para scoring. Les llega Django. No les llega un Feature Store. El mercado se partió: el backend clásico tiene oferta, los ingenieros de pipeline y LLM no. Un anuncio mal etiquetado se llena de CV en 48 h y cero competencia de drift.
- Sin tests de datos. El CI hace lint del modelo, no del esquema de entrada. Un cambio silencioso de nulls en la fuente llega a producción. La predicción está «en verde». La decisión de negocio no.
- Una feature sin dueño. DS la calcula en un notebook, DE en dbt, BI en Power Query. Tres definiciones de churn. Un dashboard, tres guerras en el stand-up.
- Un equipo de analítica falso. DS del vendor A, DE del B, MLOps «cuando haya tiempo» del DevOps interno. Tres onboardings, ningún DAG compartido. Eso no es staff augmentation. Es el impuesto de integración descrito en IT team leasing.
6. Playbook: a quién alquilar, y en qué orden
No empiecen por el modelo. Empiecen por qué modalidad está bloqueando el SLA.
- Un hueco en un pipeline existente. Tienen Airflow, un Feature Store y alguien que revisa PRs. Falta un senior del modelo o de Spark. Eso es data science staff augmentation clásico o un Data Engineer: una persona, su stand-up, su DoD. Primeros perfiles en días, no en un trimestre — sourcemos bajo demanda, no vendemos un banquillo nominativo para mañana por la mañana.
- El notebook es el producto. No hay DAG, no hay test de esquema, no hay serving. Una persona no lo cosa. Alineación 3–5: DE (fuentes, dbt/Spark), DS (modelo, validación), MLOps (imagen, monitoring de drift). Más cerca de team leasing que de «añadimos un analista más».
- Los datos no salen del VPC. Contratista en su IAM, su cloud, NDA y términos de tratamiento. Colab con un dump de producción es una fuga, no un atajo. Cómputo de features offline en batch, serving online con el mismo código de feature.
- Ramp-up. Una persona en un equipo existente: primeros CV en 24–48 h, arranque tras sus entrevistas y el contrato. Un squad desde cero: semanas, no un sprint, porque están cosiendo accesos, datos y DoD. «Tres senior Python desde el lunes» es un pack de CV o un banquillo que no tenemos — y no vamos a fingir que lo tenemos.
Commoditech hace T&M y búsqueda permanente desde Varsovia desde 2012. 80+ especialistas en red, no un idle bench. Un brief T&M o success-fee se puede presentar desde un IDE vía MCP para agentes AI, no solo desde un formulario de contacto. Un humano cotiza un stack; los rangos viven en el artículo de tarifas, no en el JSON del agente.
FAQ
¿En qué se diferencia data science staff augmentation de contratar a un Data Scientist?
Una contratación permanente es un FTE en su HR. La vida media de un anuncio IT en JobHunt en septiembre de 2026 es de 50 días — antes incluso de entrevistar. Data science staff augmentation es T&M: la persona en su equipo, su Git, su SLA, con cláusula de reemplazo de rol. No compran «un modelo en suscripción». Compran una hora de competencia. El TCO vs nómina (reclutamiento, bench, indemnizaciones, hardware) está en las tarifas 2026.
¿Cuándo alquilar a una persona y cuándo un squad de Data Science?
Una persona cuando el pipeline ya existe y falta un hueco: senior DS, Spark, MLOps. Un squad de 3–5 personas cuando el notebook es el único artefacto. Un Data Scientist solo entregará AUC. No entregará p99, un test de esquema ni un retrain a las 03:00. Si nadie de su lado puede revisar el PR del contratista, no compren staff augmentation. Compren un lead más un rol, o un squad.
¿Cuánto cuesta data science staff augmentation en Polonia en 2026?
Python para pipelines de datos no es CRUD: en la práctica el cliente paga la parte alta de la banda senior de 200–280 PLN/h. Cuando el modelo sale a producción con LLM / RAG, más cerca de 240–350 PLN/h. Margen del vendor 10–25% — si alguien promete 8% con reemplazo en 5 días, está en otra línea. Un mapa de mercado, no una oferta. Un humano pone precio al brief.
¿Puede un contratista de Data Science trabajar con datos bajo NDA y GDPR?
Sí: su entorno, su IAM, su cloud u on-prem, un contrato con NDA, términos de tratamiento e IP del lado del cliente. Un notebook en un portátil privado con un dump de producción es una fuga. Features offline en batch, serving online con el mismo código. La auditoría de acceso es suya. El contratista no se lleva el dataset «para calcular más rápido».
Fuentes
- Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. NIPS 2015. papers.nips.cc
- Shi, H., Wang, W., Fang, W., Liang, Y. et al. (2026). CUA-Universe: A Scalable and Dynamic Environment for Hybrid GUI+CLI Agents. arXiv:2609.05374. arxiv.org/abs/2609.05374
- DORA / Google Cloud (2024). Accelerate State of DevOps Report.
- JobHunt.pl (1 de septiembre de 2026). 21,211 roles IT activos, vida media del anuncio de 50 días — contexto de time-to-hire vs T&M.