MLOps: ¿competencia complementaria o trayectoria de carrera propia?

La pregunta mal planteada: «¿qué herramientas hay que conocer?»

MLOps suele reducirse a una lista: contenedores, orquestación, integración continua, una herramienta de seguimiento de experimentos, un registro de modelos. Esas piezas existen, se aprenden, y dominarlas por sí solas no consigue un puesto ni mantiene un sistema en producción. Un perfil que recita herramientas sin poder explicar qué vigila, por qué, y qué hace cuando un indicador se degrada, no se distingue de un perfil DevOps generalista.

La pregunta profesional es más bien: ¿de qué respondes entre el momento en que un modelo funciona en un portátil y el momento en que un servicio depende de él a diario? Ese intervalo define el oficio, y no tiene el mismo contenido en todas las organizaciones.

Las responsabilidades reales a lo largo del ciclo de vida

Reproducibilidad y datos

Un resultado que no se sabe reproducir no es un resultado explotable. Reproducir supone saber qué datos se usaron, en qué estado, con qué transformaciones, qué código y qué parámetros. La parte de datos es la más subestimada: sin versionado de los conjuntos y de las transformaciones, una diferencia entre dos entrenamientos queda sin explicación y un incidente en producción queda sin diagnóstico.

Artefactos, versiones y despliegue

Un modelo en producción es un artefacto fechado, ligado a una versión de código, a un conjunto de datos, a un entorno de ejecución y a un contrato de interfaz. El despliegue plantea entonces preguntas clásicas en versión adaptada: cómo pasar a una nueva versión sin interrumpir el servicio, cómo comparar la anterior y la nueva con tráfico real, y cómo volver atrás rápido. La capacidad de volver atrás es a menudo lo que permite a un equipo avanzar deprisa.

Pruebas, monitorización y deriva

Probar un sistema de ML no se limita a las pruebas unitarias del código. También se comprueba la calidad de los datos de entrada, la coherencia de las transformaciones entre entrenamiento y servicio, la estabilidad de las salidas sobre una muestra de referencia y el comportamiento ante valores ausentes o anómalos.

• Monitorización técnica: disponibilidad, latencia, tasa de errores, saturación. Necesaria, insuficiente.
• Monitorización de entradas: cómo evoluciona la distribución de los datos recibidos respecto a los de entrenamiento.
• Monitorización de salidas: distribución de las predicciones, tasa de abstención, casos límite, diferencias entre segmentos de usuarios.
• Calidad real: cuando la verdad de campo llega más tarde — a veces semanas —, hace falta un mecanismo para vincularla a las predicciones pasadas.
• Alerta y decisión: un indicador que se degrada debe disparar algo definido; si no, la monitorización solo sirve para constatar a posteriori.

Seguridad, costes y gobernanza

Acceso a los datos de entrenamiento y a los registros, datos personales, separación de entornos, secretos, trazabilidad de las decisiones automatizadas, conservación de lo necesario para explicar una decisión pasada: no son formalidades administrativas, a menudo determinan qué se puede poner en producción. Los costes también se pilotan: entrenamiento, inferencia, almacenamiento y conservación de trazas son arbitrajes recurrentes.

Estas responsabilidades no siempre recaen en la misma persona. En una estructura pequeña una sola las cubre parcialmente; en una grande se reparten entre equipos con fronteras propias de la organización. Describir lo que has sostenido de verdad es más útil que reclamar un perímetro teórico.

Qué cambian los sistemas GenAI

Cuando el modelo se invoca a través de una API externa, parte del trabajo clásico desaparece — sin entrenamiento, sin gestión de GPU — y aparece otro. La responsabilidad se desplaza a lo que rodea al modelo.

• Dependencia del proveedor: versiones de modelos que evolucionan o se retiran, comportamientos que cambian sin que toques nada, límites de caudal, caídas. Prever un plan alternativo es una decisión de arquitectura, no un detalle.
• Prompts y configuraciones: son artefactos versionados, probados y desplegados como código, no cadenas que se editan en producción.
• Evaluación: en lugar de una métrica única, series de casos repetidas en cada cambio, incluidos los fallos conocidos.
• Trazas: consulta, contexto entregado, salida, coste, latencia. Sin ellas no hay análisis de incidentes posible, y conservarlas plantea a su vez cuestiones de confidencialidad.
• Salvaguardas: filtrado de entradas y salidas, restricción de las acciones permitidas, comportamiento alternativo cuando un control bloquea una respuesta.
• Coste y latencia: pasan a ser indicadores de producción de pleno derecho, vigilados por caso de uso y no solo en agregado.

Lo que se mantiene del ML clásico es la disciplina: medir, versionar, vigilar, poder volver atrás. Lo que cambia son los objetos vigilados y el hecho de que parte del sistema está fuera de tu control.

DevOps, ML Engineering, MLOps, operaciones GenAI

Estos términos se solapan y las fronteras varían según la empresa. Las distinciones siguientes son referencias útiles para una conversación, no definiciones oficiales.

1. 1

   DevOps

   referencia

   Cadena de entrega, infraestructura, fiabilidad, observabilidad aplicativa. El objeto determinante es el código y su ejecución. Los datos no son una preocupación de primer plano.

2. 2

   ML Engineering

   referencia

   Diseñar e industrializar la parte de modelo: preparación de datos, entrenamiento, optimización, puesta en servicio. El acento está en construir el sistema, con un componente de software fuerte.

3. 3

   MLOps

   referencia

   Hacer y mantener explotables esos sistemas: reproducibilidad, versionado de datos y modelos, despliegue, monitorización, deriva, rollback, costes, cumplimiento. El acento está en la vida del sistema, no solo en su lanzamiento.

4. 4

   LLMOps / operaciones GenAI

   referencia

   La misma disciplina aplicada a sistemas apoyados en modelos a menudo externos: versionado de prompts y configuraciones, evaluación por series de casos, trazas, salvaguardas, gestión de la dependencia del proveedor, coste por consulta.

En la práctica muchas ofertas usan un título para una realidad distinta. Razón de más para hacer preguntas precisas en entrevista: quién despliega, a quién se llama en un incidente, quién decide un rollback, quién vigila la calidad y con qué frecuencia.

¿Competencia complementaria o trayectoria de carrera?

Ambas existen de verdad y la cuestión no se zanja en abstracto. En un equipo pequeño, MLOps es una competencia complementaria que sostienen personas con otro título: la capacidad de llegar a producción marca entonces la diferencia entre un proyecto que se entrega y uno que se queda en demostración. En una organización con varios sistemas en paralelo, la función se convierte en un puesto propio, con responsabilidad de plataforma y varios interlocutores.

Dos señales indican si se está convirtiendo en trayectoria: ¿el trabajo apunta a un sistema o a los medios comunes de varios sistemas? y ¿el rol consiste en entregar o en decidir cómo se entrega? Pasar de lo primero a lo segundo es lo que convierte una competencia en trayectoria.

Lo que un perfil MLOps debe saber explicar en entrevista

En lugar de una lista de tecnologías, estas son las preguntas que hay que poder responder desde una experiencia real. Una buena respuesta describe un contexto, una decisión y una consecuencia.

• ¿Cómo reproduces un resultado obtenido hace seis meses? ¿Qué necesitas para ello?
• ¿Qué vigilas una vez el sistema está en servicio y qué dispara una acción?
• ¿Cómo sabes que un modelo se degrada cuando la verdad de campo llega tarde, o nunca?
• ¿Cómo despliegas una nueva versión y cuánto tarda un rollback?
• ¿Qué se ha roto en producción y qué cambiaste después?
• ¿Cómo evitas que una transformación difiera entre entrenamiento y servicio?
• ¿Cuánto cuesta tu sistema y qué partida domina?
• En un sistema GenAI: ¿cómo pruebas un cambio de prompt o de versión de modelo antes de desplegarlo?
• ¿Qué datos se conservan en tus trazas y durante cuánto tiempo?

Ninguna exige conocer una herramienta concreta. Comprueban que has ejercido una responsabilidad sostenida en el tiempo, que es exactamente de lo que trata el oficio.

• MLOps
• Producción
• Evaluación