Qué es MLOps y en qué se diferencia de DevOps

MLOps es la forma de trabajar que lleva un modelo de machine learning del notebook a producción y lo mantiene funcionando: automatiza el entrenamiento, versiona datos y modelos, registra cada experimento y vigila el modelo cuando está sirviendo predicciones. Parte de DevOps, pero añade algo que el software normal no tiene: el modelo se degrada aunque nadie toque el código.

Entrenar un modelo que acierta en tu portátil es la parte fácil. Lo difícil es que siga acertando dentro de seis meses, que otra persona pueda repetir tu entrenamiento y que sepas qué versión está respondiendo a los usuarios. De eso va MLOps, y por eso aparece en casi cualquier descripción del trabajo de un AI engineer.

Qué es MLOps y por qué hace falta

MLOps (machine learning operations) es el conjunto de prácticas para construir, desplegar y operar sistemas de machine learning en producción de forma continua y repetible. Google Cloud la define como «una práctica y cultura de la ingeniería de AA, cuyo fin es unificar el desarrollo (Dev) y las operaciones (Ops) del sistema de AA».

La frase que mejor explica por qué existe está en esa misma guía de Google Cloud: «el verdadero desafío no consiste en compilar un modelo de AA, sino un sistema de AA integrado, y operarlo en la producción de forma continua» (Google Cloud, MLOps: canalizaciones de automatización y entrega continua en el aprendizaje automático). El modelo es una pieza pequeña. Alrededor hay extracción de datos, validación, entrenamiento, despliegue, supervisión y la infraestructura que lo sostiene.

Microsoft lo cuenta desde el resultado. En su documentación de Azure Machine Learning explica que MLOps se basa en los principios de DevOps y que aplicarlos al ciclo de vida del aprendizaje automático da como resultado una experimentación más rápida, una implementación más rápida de los modelos en producción y un mejor «control de calidad y seguimiento de linaje de un extremo a otro» (Microsoft Learn, Administración de modelos de MLOps con Azure Machine Learning). Linaje significa poder responder, para cualquier modelo en producción, con qué datos, qué código y qué parámetros se entrenó.

Si todavía te bailan los conceptos de base, repasa antes la diferencia entre machine learning y deep learning. MLOps se apoya en los dos.

MLOps vs DevOps: qué comparten y qué añade MLOps

MLOps hereda de DevOps la integración continua (CI) y la entrega continua (CD), y añade una tercera práctica que el software clásico no necesita: el entrenamiento continuo (CT). La razón es que un sistema de machine learning depende de datos que cambian, así que puede empeorar sin que nadie modifique una sola línea de código.

Google Cloud lo resume en tres cambios concretos frente a DevOps:

• La CI ya no prueba solo código. También tiene que «probar y validar datos, esquemas de datos y modelos».

• La CD ya no entrega un único paquete. Entrega una canalización de entrenamiento que, a su vez, despliega otro servicio: el que sirve las predicciones del modelo.

• El CT es nuevo. Es «una propiedad nueva, exclusiva de los sistemas de AA, que se ocupa de volver a entrenar y entregar los modelos de forma automática».

La misma guía añade diferencias de equipo y de producción. En un proyecto de machine learning suele haber científicos de datos que no son ingenieros de software, el desarrollo es experimental por naturaleza y los modelos «pueden decaer en formas más variadas» que el software convencional, porque los datos de entrada evolucionan.

Si la parte de CI/CD te suena a chino, tenemos una guía de CI/CD explicado con un ejemplo en GitHub Actions que cubre justo eso. Y si vienes del lado de la seguridad, DevSecOps es otra extensión de DevOps con un foco distinto: proteger el software, no mantener vivo un modelo.

El ciclo de vida de un modelo, paso a paso

El ciclo de vida de un modelo de machine learning va desde que eliges los datos hasta que lo vigilas en producción, y vuelve a empezar cuando el modelo pierde calidad. Google Cloud lo describe en ocho pasos que se pueden hacer a mano o automatizar con una canalización. MLOps consiste, en buena parte, en decidir cuáles automatizas y cómo.

1. Extracción de datos. Seleccionas e integras los datos relevantes de varias fuentes.

2. Análisis de datos. Análisis exploratorio para entender el esquema y decidir qué preparación e ingeniería de atributos hacen falta.

3. Preparación de datos. Limpieza, división en entrenamiento, validación y prueba, y transformaciones.

4. Entrenamiento. Pruebas con distintos algoritmos y ajuste de hiperparámetros. Sale un modelo entrenado.

5. Evaluación. Mides la calidad del modelo sobre un conjunto de prueba que no ha visto.

6. Validación. Confirmas que es apto para desplegar si su rendimiento supera al de un modelo de referencia.

7. Entrega. Lo despliegas: como microservicio con API REST, dentro de un dispositivo o en un sistema de predicción por lotes.

8. Supervisión. Vigilas su rendimiento predictivo para lanzar, si hace falta, una nueva iteración.

El paso 6 es el que más se salta la gente que empieza. «Funciona» no basta: hay que demostrar que funciona mejor que lo que ya está en producción, o que una referencia simple. Sin esa comparación, desplegar un modelo nuevo es una apuesta.

Los tres niveles de madurez de MLOps

Google Cloud clasifica la madurez de MLOps en tres niveles según cuánto de ese ciclo está automatizado: nivel 0, todo manual; nivel 1, la canalización de entrenamiento se ejecuta sola; nivel 2, además, los cambios en esa canalización se prueban y despliegan con CI/CD. Saber en qué nivel estás te dice qué automatizar a continuación.

Nivel 0: proceso manual

Cada paso se ejecuta a mano, normalmente en notebooks, hasta que sale un modelo viable. Quien entrena el modelo se lo pasa como artefacto a quien lo despliega, no hay CI ni CD y, según Google Cloud, falta la supervisión activa del rendimiento. Es el punto de partida habitual de los equipos que empiezan a aplicar machine learning, y puede servir cuando el modelo se reentrena pocas veces.

Nivel 1: canalización de entrenamiento automatizada

El objetivo es el entrenamiento continuo: la canalización completa se despliega y se ejecuta sola con datos nuevos. Se puede activar a demanda, con un calendario, cuando llegan datos nuevos, cuando cae el rendimiento del modelo o cuando cambia de forma significativa la distribución de los datos. Aquí aparecen la validación automática de datos y de modelos y la administración de metadatos de cada ejecución.

Nivel 2: CI/CD de la canalización

Ya no solo se automatiza el entrenamiento: también se prueba y se despliega automáticamente cada cambio en el código de la canalización. Google Cloud enumera los componentes de este nivel: control de la fuente, servicios de compilación y prueba, servicios de implementación, registro de modelos, almacén de atributos (la guía en español lo llama «tienda de funciones»), almacén de metadatos y organizador de canalizaciones.

Mi recomendación si estás aprendiendo: no intentes montar el nivel 2 el primer día. Un nivel 0 ordenado (código en Git, cada experimento registrado, el modelo guardado con su versión) ya te separa de la mayoría de proyectos de notebook. Para lo primero, te sirve nuestra guía de Git y GitHub desde cero; lo segundo lo resuelve MLflow, como verás más abajo.

De registrar experimentos a operar un sistema en producción

Construye, despliega y opera sistemas de IA en producción. En el máster AI Engineer automatizas pipelines y el ciclo de vida del modelo con ZenML y MLflow. Descarga el dossier y conoce el programa completo.

Descargar dossier →

Las piezas de una plataforma MLOps

Una plataforma de MLOps no es una herramienta, sino varias piezas que responden a preguntas distintas: qué he probado, qué modelo está en producción, con qué datos se entrenó, quién ejecuta el proceso y cómo sé si el modelo empeora. Conocer el nombre de cada pieza te ahorra mucha confusión al leer documentación y ofertas de empleo.

Seguimiento de experimentos

Registra cada entrenamiento con sus parámetros, métricas y archivos de salida para poder compararlos después. En MLflow, la unidad es la ejecución o run, y cada una guarda métricas, parámetros, horas de inicio y fin, y artefactos como los pesos del modelo o imágenes (MLflow Tracking).

Registro de modelos

Es el almacén central de modelos con versiones. El de MLflow guarda el linaje de cada versión (qué experimento y qué ejecución la produjo), numera las versiones automáticamente y permite alias como @champion para señalar la que debe recibir el tráfico de producción (MLflow Model Registry). Microsoft describe lo mismo en Azure: registras un modelo con el mismo nombre y el número de versión sube solo.

Almacén de atributos (feature store)

Guarda las variables que usa el modelo con una definición única. Google Cloud lo justifica por un problema concreto: evitar el sesgo entre entrenamiento y entrega, es decir, que el modelo se entrene con un cálculo de una variable y en producción reciba otro distinto.

Almacén de metadatos

Anota cada ejecución de la canalización: versiones de cada componente, fechas y duración, parámetros, dónde quedaron los datos intermedios, el modelo anterior por si hay que volver atrás y las métricas de evaluación. Sirve para reproducir, comparar y depurar.

Orquestador de canalizaciones

Coordina qué paso se ejecuta y cuándo, respetando las dependencias entre ellos. En ZenML es un componente de la stack, y por defecto viene uno local para que puedas probar sin alquilar nada en la nube (ZenML, Core Concepts).

Supervisión y desviación de datos

Vigila el modelo en producción. Microsoft incluye entre las funcionalidades de MLOps avisar de eventos como la detección de desfase de datos, y Google Cloud propone reentrenar cuando la distribución de las variables cambia de forma significativa. Es la pieza que convierte un despliegue en un sistema que se mantiene solo.

MLflow y ZenML: qué resuelve cada uno

MLflow y ZenML son dos herramientas de código abierto que se usan juntas a menudo, porque cubren partes distintas del trabajo. MLflow responde a «qué he probado y qué modelo tengo»: seguimiento de experimentos y registro de modelos. ZenML responde a «cómo se ejecuta el proceso y dónde»: canalizaciones de pasos y la infraestructura que las corre.

MLflow se organiza en torno a experimentos y ejecuciones. Un experimento agrupa las ejecuciones de una misma tarea, y dentro de cada ejecución llamas a funciones como mlflow.log_param() y mlflow.log_metric(); también existe mlflow.autolog() para registrar sin escribir cada llamada. Su registro de modelos añade versiones, alias, etiquetas y linaje.

ZenML se describe en su documentación como el framework de MLOps de su ecosistema: canalizaciones portables para cargas de machine learning y de LLM, con artefactos versionados, caché e infraestructura abstraída en stacks. Sus conceptos básicos son pocos:

• Paso (step): una función de Python con el decorador @step.

• Canalización (pipeline): una serie de pasos, donde uno puede usar la salida del anterior.

• Artefactos: los datos que entran y salen de cada paso, que ZenML guarda y versiona en el almacén de artefactos.

• Stack: el conjunto de componentes donde se ejecuta la canalización. Toda stack necesita al menos un orquestador y un almacén de artefactos.

Y se combinan: ZenML tiene una integración que usa MLflow como experiment tracker para registrar modelos, parámetros y métricas de los pasos de una canalización (ZenML, MLflow Experiment Tracker). Mi consejo es aprender en este orden: primero MLflow, porque lo usarás desde el primer experimento; después ZenML, cuando tengas un proceso que merezca la pena automatizar.

Ejemplo: tu primer experimento registrado con MLflow

La forma más rápida de entender MLOps es registrar un experimento. Este ejemplo entrena dos versiones de un clasificador sobre el conjunto Iris, que viene dentro de scikit-learn, guarda el parámetro y la métrica de cada una con MLflow y las compara. Lo ejecutamos el 5 de noviembre de 2026 con Python 3.13, MLflow 3.18.0 y scikit-learn 1.9.1.

Primero, en un entorno virtual:

pip install mlflow scikit-learn

pip install mlflow scikit-learn

pip install mlflow scikit-learn

Después, guarda esto como mlflow_minimo.py:

import mlflow
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split

X, y = load_iris(return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

mlflow.set_experiment("iris-clasificador")

for C in [0.01, 1.0]:
    with mlflow.start_run(run_name=f"logreg-C{C}"):
        modelo = LogisticRegression(C=C, max_iter=500)
        modelo.fit(X_train, y_train)
        accuracy = modelo.score(X_test, y_test)

        mlflow.log_param("C", C)
        mlflow.log_metric("accuracy", accuracy)
        print(f"C={C} -> accuracy={accuracy:.3f}")

runs = mlflow.search_runs(experiment_names=["iris-clasificador"])
print(runs[["tags.mlflow.runName", "params.C", "metrics.accuracy"]])

import mlflow
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split

X, y = load_iris(return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

mlflow.set_experiment("iris-clasificador")

for C in [0.01, 1.0]:
    with mlflow.start_run(run_name=f"logreg-C{C}"):
        modelo = LogisticRegression(C=C, max_iter=500)
        modelo.fit(X_train, y_train)
        accuracy = modelo.score(X_test, y_test)

        mlflow.log_param("C", C)
        mlflow.log_metric("accuracy", accuracy)
        print(f"C={C} -> accuracy={accuracy:.3f}")

runs = mlflow.search_runs(experiment_names=["iris-clasificador"])
print(runs[["tags.mlflow.runName", "params.C", "metrics.accuracy"]])

import mlflow
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split

X, y = load_iris(return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

mlflow.set_experiment("iris-clasificador")

for C in [0.01, 1.0]:
    with mlflow.start_run(run_name=f"logreg-C{C}"):
        modelo = LogisticRegression(C=C, max_iter=500)
        modelo.fit(X_train, y_train)
        accuracy = modelo.score(X_test, y_test)

        mlflow.log_param("C", C)
        mlflow.log_metric("accuracy", accuracy)
        print(f"C={C} -> accuracy={accuracy:.3f}")

runs = mlflow.search_runs(experiment_names=["iris-clasificador"])
print(runs[["tags.mlflow.runName", "params.C", "metrics.accuracy"]])

Al ejecutarlo con python mlflow_minimo.py, esta es la salida que obtuvimos (sin las líneas de log):

C=0.01 -> accuracy=0.822
C=1.0 -> accuracy=1.000
  tags.mlflow.runName params.C  metrics.accuracy
0         logreg-C1.0      1.0          1.000000
1        logreg-C0.01     0.01          0.822222

C=0.01 -> accuracy=0.822
C=1.0 -> accuracy=1.000
  tags.mlflow.runName params.C  metrics.accuracy
0         logreg-C1.0      1.0          1.000000
1        logreg-C0.01     0.01          0.822222

C=0.01 -> accuracy=0.822
C=1.0 -> accuracy=1.000
  tags.mlflow.runName params.C  metrics.accuracy
0         logreg-C1.0      1.0          1.000000
1        logreg-C0.01     0.01          0.822222

Tres cosas que conviene mirar:

• Dónde se guarda. En nuestra prueba, MLflow creó un archivo mlflow.db (SQLite) en la carpeta desde la que lo lanzamos, y la ayuda de mlflow ui confirma que ese es el almacén por defecto. Para verlo en el navegador, ejecuta mlflow ui en la misma carpeta y abre la dirección que te indique.

• Qué te da. Las dos ejecuciones quedan comparables por parámetro y métrica, sin copiar números a mano en una hoja de cálculo. Eso, multiplicado por cien experimentos, es la diferencia entre saber qué funcionó y creer que lo sabes.

• Cómo leer el resultado. Un 100 % de acierto en Iris no significa que tengas un gran modelo. Es un conjunto pequeño y muy separable, con 45 casos de prueba. En un proyecto real, una métrica perfecta es motivo para revisar si hay fuga de datos, no para celebrar.

Desde aquí, el siguiente paso natural es guardar el modelo con mlflow.sklearn.log_model(), registrarlo en el Model Registry y asignarle un alias. La guía rápida de MLflow Tracking lo recorre paso a paso.

Siguiente paso: llevar un sistema completo a producción

Registrar experimentos es el primer ladrillo. El trabajo completo de MLOps consiste en encadenar datos, entrenamiento, despliegue y supervisión en un sistema que funcione sin ti, y eso se aprende mejor con un proyecto real que crece por fases que con piezas sueltas. Y los mismos principios se aplican hoy a sistemas construidos sobre modelos de lenguaje.

Si te interesa esa parte, nuestra guía sobre fine-tuning de un modelo de IA explica qué ajusta y qué datos pide, y el artículo sobre el nuevo máster en AI Engineer cuenta cómo está planteado el programa.

En el máster AI Engineer de ThePower Tech School, según su ficha consultada el 5-11-2026, aprendes a construir sistemas de IA de producción «sobre un único proyecto que evoluciona: de un chatbot simple a un sistema con RAG, fine-tuning y MLOps, desplegado en AWS». Entre lo que trabajas está automatizar «pipelines y el ciclo de vida del modelo con ZenML y MLflow» y el «CI/CD con GitHub Actions y despliegue en AWS».

La mayoría aprende IA.
Pocos saben aplicarla.

El máster definitivo para pasar de prototipos con LLMs a arquitecturas de IA desplegadas en producción.

Descubre AI Engineer →

La mayoría aprende IA.
Pocos saben aplicarla.

El máster definitivo para pasar de prototipos con LLMs a arquitecturas de IA desplegadas en producción.

Descubre AI Engineer →

Preguntas frecuentes sobre MLOps

¿MLOps es lo mismo que DevOps?

No. MLOps aplica los principios de DevOps, como la integración y la entrega continuas, a sistemas de machine learning, y añade el entrenamiento continuo. Sus pruebas, por otra parte, no se limitan al código: validan datos, esquemas y modelos, porque un modelo puede perder calidad en producción aunque nadie haya cambiado el software que lo ejecuta.

¿Qué es MLflow y para qué sirve?

MLflow es una plataforma de código abierto para gestionar el ciclo de vida de los modelos. Con MLflow Tracking registras parámetros, métricas y archivos de cada entrenamiento para compararlos, y con su Model Registry guardas versiones de los modelos, su linaje y alias como «champion» para marcar la versión que debe ir a producción.

¿Qué diferencia hay entre MLflow y ZenML?

MLflow se centra en registrar experimentos y gestionar versiones de modelos. ZenML se centra en definir canalizaciones de pasos y en la infraestructura donde se ejecutan, como el orquestador y el almacén de artefactos. No compiten: ZenML puede usar MLflow como experiment tracker dentro de sus canalizaciones, y muchos equipos combinan ambas herramientas.

¿Qué es el entrenamiento continuo en MLOps?

Es volver a entrenar y desplegar el modelo de forma automática con datos nuevos. Google Cloud lo considera la práctica exclusiva de los sistemas de machine learning. La canalización puede activarse con un calendario, cuando llegan datos nuevos, cuando cae el rendimiento del modelo o cuando cambia de forma significativa la distribución de los datos de entrada.

¿Qué necesito saber para empezar con MLOps?

Python, lo básico de machine learning con scikit-learn y control de versiones con Git son una base suficiente para empezar. Con eso ya puedes registrar experimentos en MLflow, como en el ejemplo de este artículo. Contenedores, CI/CD y la nube llegan después, cuando quieras automatizar el despliegue. Se aprende por capas, sin necesidad de dominarlo todo de golpe.

¿Cuáles son los niveles de madurez de MLOps?

Google Cloud describe tres. En el nivel 0 todo el proceso es manual, normalmente en notebooks. En el nivel 1 la canalización de entrenamiento se ejecuta sola con datos nuevos, lo que permite el entrenamiento continuo. En el nivel 2, además, cada cambio en el código de la canalización se prueba y se despliega automáticamente con CI/CD.