Commoditech Hablemos
← Volver a los artículos

Servicios MLOps: deriva de datos, CI/CD y body leasing

Publicado: 10 de septiembre de 2026 • Guía B2B / MLOps

El modelo tiene un F1 de 0,81 en el conjunto de abril. En agosto, el mismo endpoint aprueba solicitudes que nadie firmaría a mano. Nadie calculó el PSI. Nadie ejecutó un reentrenamiento. O al revés: un cron quema GPU todos los domingos porque «así figura en el runbook», y la distribución de features no se ha movido en seis semanas.

Esto no es un problema del algoritmo. Es un problema del bucle. Los servicios de MLOps no son «un DevOps que sabe Python». Son CI/CD más continuous training: detección de drift, puerta de reentrenamiento, registro de modelos, serving con el mismo código de feature que en el entrenamiento. Sin este bucle, compráis un pickle en un ticket para la plataforma.

A continuación, la distinción que falta en los briefs de «buscamos un MLOps»: cuándo contratar a una persona (body leasing de un ingeniero MLOps) y cuándo el drift y el serving requieren un squad de DE + DS + MLOps. Desglosamos las tarifas por hora por separado: cuánto cuesta el body leasing IT en 2026. Aquí calculamos por qué el reentrenamiento por temporizador es la forma más cara de mantener un F1 estable.

Una frase que no aparece en la diapositiva de «ML platform»

Kubeflow sin un responsable del drift es CI para imágenes. No servicios de MLOps. Un PSI superior a 0,25 es una señal, no un dashboard. Si nadie tiene permisos para detener el serving y lanzar el reentrenamiento desde un commit, tenéis una demo con GPU.

1. Anatomía: calendar retraining no es continuous training

Una semana típica de un modelo en producción en un banco, telco o retail no se parece a un tutorial de MLflow. Se parece a tres bucles desconectados:

  • Entrenamiento. Data Scientist en Studio / un notebook. Artefacto: model.pkl o una tarjeta en Model Registry, que nadie promueve.
  • Despliegue. Un ticket para DevOps. Imagen, probe, Ingress. El equipo de plataforma sabe hacer rollback. Nadie sabe hacer rollback de la definición de característica.
  • "Monitorización". Grafana para latencia y 5xx. No para Population Stability Index, no para KS, no para la caída de F1 en una etiqueta retrasada.

Kreuzberger, Kühl y Hirschl en su revisión de la arquitectura MLOps (IEEE Access, 2023) separan CI/CD de continuous training (CT): el cuarto bucle que une datos, modelo y serving. Sin CT, ustedes tienen un pipeline de software. No un pipeline de aprendizaje. Sculley et al. (NIPS 2015) lo llamaron antes: el código de aprendizaje es normalmente una pequeña fracción del sistema; el resto es pegamento, configuración y dependencias ocultas. El cambio de una característica provoca una avalancha — CACE, changing anything changes everything.

Tres síntomas de que tienen cron, no CT:

  1. Retraining en el calendario. Domingo 02:00, independientemente del PSI. O nunca, "porque el modelo es suficientemente bueno". Ambas variantes queman la calidad o la nube.
  2. Característica calculada dos veces. Pandas en un portátil, SQL en Airflow. El fill-rate se desvía en 0,3 pp y se descubre después de un trimestre, cuando el drift ya está en la decisión.
  3. Etiqueta retrasada, métrica ciega. F1 en producción se puede calcular después de semanas. Hasta entonces, la única señal es el drift de entrada (PSI, KS, KL, MMD) — o nada.

Por eso, el brief "alquiler de un DevOps para modelos" sin el contexto de drift es la forma más cara de conseguir otro pickle. Las competencias que realmente componen los servicios de MLOps, se encuentran en tres landing pages: ingenieros MLOps, Data Engineering, Data Science. GPU serving y LLM añaden AI / RAG y DevOps / SRE.

2. Lo que dice la investigación, no los decks de „ML platform”

No necesitan otra definición de madurez MLOps. Necesitan un umbral en el que el retrening pueda iniciarse — y el derecho a que no se inicie cuando la distribución permanece estable.

  • PSI > 0,25 no es la opinión de un dashboard. Katalay, Dimandja y Masakuna, A Multi-Criteria Automated MLOps Pipeline for Cost-Effective Cloud-Based Classifier Retraining in Response to Data Distribution Shifts (arXiv:2512.11541, diciembre de 2025): combinan KS, KL, PSI, MMD y ΔAcc/ΔF1 en un solo score y activan el retrening solo después de superar el umbral. En la literatura de scoring, un PSI superior a 0,25 ha significado durante años una deriva significativa; por debajo de 0,10 — ruido. El pipeline no adivina. Calcula.
  • El retraining ante cada alarma es más caro que la deriva. En el mismo experimento (autoencoder, conjuntos de anomaly detection) cuatro políticas: STATIC (cero retrening) mantiene una accuracy de 0,69±0,2 con un coste de 54,8; FIXED (intervalo fijo) y NAIVE (retrain ante cada deriva) alcanzan 0,75, pero cuestan 160,6 y 130,5 con 3,0 y 4,3 retrainings. Auto-MLOps: el mismo 0,75±0,03, coste 108,1, retrainings 1,4±1,2. La misma calidad que el calendario, un tercio más barato que FIXED, tres veces menos activaciones que NAIVE.
  • Una arquitectura sin roles es una diapositiva. Kreuzberger et al. (2023): MLOps son prácticas y roles (ML Engineer, Data Engineer, DevOps), no un producto de marketplace. CT es un bucle, no un botón en Vertex. DORA 2024 añade: elite vs low es un orden de magnitud en la frecuencia de despliegue y el lead time. Cinco hojas de tiempo (DS de un proveedor A, DE de B, „alguien de Kubernetes” de C) no construirán un lead time. Resultarán en tres SLA de reemplazo. Hemos detallado la anatomía de este error en team leasing vs body leasing 2026. El pipeline de datos que alimenta a CT está en el artículo sobre analítica predictiva.

Conclusión arquitectónica clave

Los servicios MLOps comienzan con una puerta de enlace, no con un clúster. El detector de deriva (PSI/KS/KL) escribe un evento. La política decide si mezclar el conjunto de datos y entrenar. CI valida el esquema de la característica y la métrica vs baseline. CD promueve la versión en el registro. Serving lee la misma definición de característica. Si cualquiera de los pasos es una persona pegando CSV, no tienen CT. Tienen una guardia.

3. Estudio de producción: retraining dominical que no solucionaba nada

De la práctica de ingeniería: de cron a PSI

Scoring de fraude, retail / pagos. Fuentes: Postgres, eventos en Kafka, características en dbt, serving en Kubernetes. El equipo trabajaba así:

  • entrenamiento: Data Scientist, SageMaker Studio, exportación manual de artefacto,
  • despliegue: ticket, Docker, Helm, sin prueba de esquema de entrada,
  • retraining: cron el domingo, conjunto completo, GPU durante cuatro horas,
  • monitoring: p99 y 5xx. Nadie calculaba el PSI.

Problema: tras el cambio en la mezcla de canales (nuevo socio de pagos), el F1 en la etiqueta retrasada disminuyó en dos semanas. El cron del domingo entrenaba con una mezcla en la que el nuevo canal era ruido. El coste de la GPU aumentaba. La calidad no.

Cambio: cálculo de PSI y KS en una muestra de VPC, umbral de 0,25 como alerta en CI, no en Slack «por si acaso». Retraining solo cuando el score de deriva supera τ y ΔF1 en el holdout es negativo. El registro del modelo (MLflow) promueve la versión. Serving con el mismo código de característica (offline batch = online). DevOps se mantiene con la imagen e IAM. MLOps se mantiene con la puerta de enlace.

Medición: número de retrainings de 4/mes a ~1,5. El mismo orden de magnitud de accuracy que «entrenar siempre», factura de GPU más cerca de Auto-MLOps de Katalaya que de FIXED. Tiempo desde la alerta de PSI hasta la nueva versión en producción: horas, no un sprint. No es magia de Vertex. Es el propietario del bucle de CT.

Las cifras del documento no se trasladan 1:1 a su scoring. Lo que se traslada es la mecánica: el calendario y una alarma ingenua son dos formas de quemar el presupuesto. Una puerta de enlace con múltiples criterios es la tercera — y la única que se puede auditar ante un comité de riesgos.

4. Tabla de decisión: qué CT, qué configuración

Enfoque Complejidad Calidad ante el drift Costo de la nube / GPU Sobrecarga para el equipo Cuándo aplicar
STATIC — modelo una vez, cero reentrenamiento Baja Cae con el drift (en el paper 0,69 vs 0,75) Bajo Bajo, hasta que explote PoC, sin SLA, el conjunto de datos permanece estático
FIXED — reentrenamiento programado Baja-media Mantiene la calidad cuando el drift es regular Alto (en el paper 160,6 vs 108,1) Medio (guardia dominical) Batch regulado, etiqueta fiable, el presupuesto de GPU no es un problema
NAIVE — reentrenar con cada alerta de drift Media Mantiene la calidad, muchos false starts Alto (4,3 reentrenamientos vs 1,4) Alto (ruido de alertas) Cuando el detector es deficiente y se teme perder un shift
Umbral multicriterio (PSI/KS/KL + ΔF1 + CI/CD) Alta Del mismo orden que FIXED/NAIVE Medio (el más bajo entre los bucles) Alto al inicio, disminuye cuando el bucle está estable Enterprise, NDA, GPU, la comisión de riesgos requiere una auditoría de "por qué ahora"
Servicio gestionado (SageMaker / Vertex / Azure ML) + propietario de CT Media (integración) Depende de si activan el detector, no solo la UI Medio-alto (métricas de servicio) Menor operativamente, si IAM ya está Una nube, un IAM, alguien de todos modos debe establecer el umbral

MLOps no es Python CRUD y no es un "DevOps común". Rangos DevOps/SRE: 140–200 / 200–325 PLN/h (especialista / cliente). AI/LLM en producción: 180–250 / 240–350 PLN/h. Un ingeniero MLOps con GPU serving y drift se sitúa en este rango, más cerca del extremo superior cuando el reentrenamiento está en el SLA. Margen 10–25%. Un mapa, no una lista de precios — detalles en las tarifas 2026.

5. Anti-patrones que no están en el tutorial de Kubeflow

  1. Brief "DevOps con conocimiento de Python" para CT. Recibirán Helm y probe. No recibirán PSI ni prueba de esquema de características. El mercado se ha fracturado: el DevOps clásico tiene oferta, el ingeniero de bucle de ML no. Un anuncio con una etiqueta errónea recoge CV en 48 h y cero competencias para el drift.
  2. Dashboard en lugar de una puerta de enlace. Evidently en Grafana, alerta en Slack, reentrenamiento manual "cuando haya tiempo". Esto es monitoring. No son servicios MLOps. La puerta de enlace tiene derecho a detener la promoción de una versión sin intervención humana en el canal.
  3. Reentrenamiento en el conjunto completo, porque es más sencillo. Katalay et al. muestran para qué mezclar el nuevo drift con el conjunto antiguo en lugar de entrenar desde cero cada semana. Un reentrenamiento completo sin detector es el FIXED del paper: la calidad está ahí, la factura también.
  4. Falso equipo de ML. DS del vendor A, DE del B, MLOps "al 20% de la plataforma". Tres onboardings, cero DAG compartido, cero Definition of Done compartido para la promoción del modelo. Esto no es staff augmentation. Es un impuesto de integración descrito en leasing de equipos de TI.

6. Playbook: a quién contratar y en qué orden

No empiecen por el clúster. Empiecen por la pregunta de qué bucle está bloqueando el SLA: datos, modelo, dryf o serving.

  1. Una brecha en el bucle existente. Tienen Airflow, un registro y alguien que revisa los PR. Falta un propietario de PSI y de CD del modelo. Esto es el clásico body leasing de ingenieros MLOps: una persona, su stand-up, su DoD. Primeros perfiles en días, no en un trimestre — hacemos sourcing bajo demanda, no vendemos un banco de nombres para mañana por la mañana.
  2. El Notebook es el único artefacto. No hay DAG, no hay prueba de esquema, no hay serving. Una sola persona no lo unirá. Composición 3–5: DE (fuentes, dbt/Spark), DS (modelo, validación), MLOps (imagen, dryf, promoción). Esto está más cerca del team leasing que de «compraremos otro DevOps».
  3. Los datos no salen de la VPC. Contratista en su IAM, su nube, NDA y encargo. Colab con un volcado de producción «para calcular PSI» es una fuga. Características offline en batch, serving online con el mismo código.
  4. Ramp-up. Persona para un equipo existente: primer CV 24–48 h, inicio después de sus entrevistas y contrato. Squad desde cero: semanas, no un sprint, porque están uniendo permisos, datos y DoD para la promoción del modelo. La mentira de «tres seniors MLOps desde el lunes» es un CV o un banco que no tenemos — y no vamos a fingir.

Commoditech desde 2012 realiza T&M y reclutamiento permanente desde Varsovia. Más de 80 especialistas en la red, no un idle bench. Un brief de T&M o success fee se puede enviar desde el IDE a través de MCP para agentes de IA, no solo desde el formulario. Los importes para un stack específico los calcula una persona; los rangos están en el artículo sobre tarifas, no en el JSON del agente.

FAQ

¿En qué se diferencian los servicios MLOps del DevOps habitual para modelos ML?

DevOps entregará la imagen, la sonda y el rollback. MLOps entregará además: el registro del modelo, la prueba del esquema de características, la detección de deriva (PSI, KS, KL), la puerta de reentrenamiento y el serving con el mismo código de característica que el entrenamiento. CI/CD sin continuous training es un deploy de pickle. No es una plataforma. Kreuzberger et al. (2023) distinguen explícitamente CT como un bucle separado, no "otro job en Jenkins".

¿Cuándo contratar a un solo ingeniero MLOps y cuándo a un equipo?

Una persona, cuando el DAG, el registro y el IAM ya están implementados, y falta un propietario de la deriva y del CD del modelo. Un equipo de 3–5 (DE + DS + MLOps), cuando el único artefacto es un notebook y el reentrenamiento es un ticket en Jira. Un MLOps solo sin DE no reparará la fuente. Un Data Scientist solo sin MLOps entregará el AUC. No entregará el p99 ni la auditoría de "por qué esta versión". Si no tienen a quién revisar el PR de un contratista, no compren body leasing. Contraten un lead más un rol o un squad.

¿Cuánto cuesta el body leasing de un ingeniero MLOps en Polonia en 2026?

MLOps se sitúa entre DevOps/SRE (cliente 200–325 PLN/h) y AI/LLM de producción (240–350 PLN/h). El serving de GPU y el reentrenamiento por deriva empujan la tarifa hacia el extremo superior del rango. Margen del proveedor 10–25% — si alguien promete un 8% con reemplazo en 5 días, añádanlo en otra línea. Esto es un mapa del mercado, no una oferta. El importe para el brief lo calcula una persona. Detalles en las tarifas de 2026.

¿Puede un contratista MLOps trabajar con datos bajo NDA y RODO?

Sí: Su entorno, su IAM, su nube o on-prem, contrato T&M con NDA, encargo y IP por parte del cliente. Un volcado de producción en el portátil del contratista "para calcular PSI más rápido" es una fuga. La deriva se calcula en una muestra en la VPC, no en Colab. La auditoría de acceso es suya. Cláusulas: contratos, márgenes, IP.

Fuentes