Última actualización: 2026-11-14

Contenido de esta página

• ¿Qué es MLOps?
• ¿Para qué sirve MLOps?
• El ciclo de vida de MLOps: qué produce cada etapa
• Los niveles de madurez de MLOps según Google Cloud
• ¿Qué hay que versionar en MLOps?
• Roles y herramientas de MLOps
• La deuda técnica oculta del machine learning
• MLOps y AIOps: ¿son lo mismo?
• MLOps en Colombia: lo que pide la política de inteligencia artificial
• Lo que se paga después

Historia real, contada en un artículo científico. En 2015, diez ingenieros de Google publicaron un trabajo en las actas de NeurIPS, un congreso académico de inteligencia artificial [1]. El título era una advertencia: Hidden Technical Debt in Machine Learning Systems, la deuda técnica oculta en los sistemas de machine learning [1]. Machine learning es la rama de la inteligencia artificial en la que un programa aprende una tarea a partir de ejemplos.

Su tesis cabe en una frase. Los autores, que abrevian machine learning como ML, escriben que «desarrollar y desplegar sistemas de ML es relativamente rápido y barato, pero mantenerlos en el tiempo es difícil y costoso» [1]. Las citas en inglés de esta página son traducción propia.

Para mostrar lo caro que sale el código olvidado, el artículo trae un caso ajeno a Google. El sistema de Knight Capital perdió 465 millones de dólares en 45 minutos, «aparentemente» por el comportamiento inesperado de rutas de código experimental que ya no se usaban [1]. Los autores toman el dato de un comunicado de la comisión de valores de Estados Unidos [1].

Según ese relato, el problema estaba en código viejo que seguía ahí.

Esa zona tiene nombre propio: MLOps. Son las prácticas para que un modelo llegue a trabajar con datos reales y siga trabajando bien meses después, cuando el mundo que aprendió ya cambió.

¿Qué es MLOps?

MLOps, sigla en inglés de operaciones de machine learning, es una forma de trabajar que une dos tareas que suelen ir separadas. Una es construir un modelo; la otra, mantenerlo funcionando en un servicio real. Un modelo es la fórmula que el programa saca de los datos para hacer predicciones. «En producción» quiere decir que ese modelo ya responde a usuarios o procesos reales, no a una prueba de laboratorio.

Google Cloud, en su guía de arquitectura sobre el tema, lo define como una cultura y una práctica de ingeniería de machine learning [3]. Su meta, según esa guía, es unificar el desarrollo del sistema y su operación [3]. Practicarlo significa defender la automatización y el monitoreo en todos los pasos de construcción del sistema, entre ellos la integración, las pruebas, el lanzamiento, el despliegue y el manejo de la infraestructura [3].

Microsoft lo describe desde otro ángulo en la documentación de Azure Machine Learning, su servicio en la nube para entrenar modelos. Allí dice que el MLOps se basa en principios y prácticas de DevOps, la forma de trabajo que junta a quienes escriben software con quienes lo operan [4]. Según esa documentación, aplicar esos principios al ciclo de vida del machine learning da tres resultados [4]:

1. Experimentación y desarrollo de modelos más rápidos.
2. Despliegue más rápido de los modelos a producción.
3. Mejor control de calidad y rastreo del linaje de punta a punta, es decir, saber de dónde salió cada pieza.

¿De dónde sale el término MLOps?

La guía de Google lo presenta como la aplicación de los principios de DevOps a los sistemas de machine learning [3]. Ni esa guía ni la de Microsoft le ponen fecha o autor al término, y esta página tampoco lo hace.

Lo que sí tiene fecha es el problema que el MLOps intenta resolver. La primera versión del diagnóstico de Google se presentó en 2014, en un taller del congreso NIPS (hoy NeurIPS) sobre ingeniería de software para machine learning [2]. Se llamaba Machine Learning: The High Interest Credit Card of Technical Debt [2]. La versión larga es el artículo de 2015 [1]. La propia guía de Google Cloud remite a ambos textos para explicar las trampas de operar estos sistemas [3].

¿Para qué sirve MLOps?

El MLOps sirve para que un modelo no se quede en una demostración. La guía de Google lo plantea sin rodeos. Un científico de datos puede entrenar un modelo que rinde bien con datos de prueba [3]. El verdadero reto, dice, es construir un sistema integrado y operarlo de forma continua en producción [3].

La razón es que un modelo puede empeorar sin que nadie toque su código. Según la misma guía, puede perder desempeño no solo por código deficiente, sino también porque los perfiles de los datos cambian todo el tiempo [3]. Un programa normal hace lo mismo hasta que alguien lo modifica. Un modelo, en cambio, depende de que el mundo se siga pareciendo a sus datos de entrenamiento.

En la práctica, Microsoft enumera lo que estas prácticas permiten hacer [4]:

1. Armar cadenas de pasos reproducibles para preparar datos, entrenar y calificar.
2. Crear entornos de software reutilizables para entrenar y desplegar.
3. Registrar, empaquetar y desplegar modelos, con los metadatos necesarios para usarlos. Los metadatos son los datos que describen otro dato: quién lo creó, cuándo y con qué.
4. Guardar el linaje para el gobierno del ciclo de vida: quién publicó un modelo, por qué cambió y cuándo se desplegó.
5. Avisar de eventos como el fin de un experimento, el registro de un modelo o un cambio en los datos.
6. Vigilar problemas de operación y del propio modelo.
7. Automatizar el ciclo completo para probar, actualizar y lanzar modelos nuevos de forma continua.

Ese cuarto punto toca otra disciplina. Decidir quién responde por cada dato y cada modelo es tarea del gobierno de datos; el MLOps aporta el registro que hace posible esa rendición de cuentas.

El ciclo de vida de MLOps: qué produce cada etapa

Un proyecto de machine learning pasa por pasos conocidos: extraer y preparar datos, entrenar, evaluar, validar, desplegar y vigilar [3]. El MLOps mira esos pasos con otra pregunta: qué queda guardado al final de cada uno, para que otra persona pueda repetirlo o deshacerlo.

La guía de Google describe así las etapas cuando todo el ciclo está automatizado. Cada fila nombra el resultado que la propia guía atribuye a la etapa [3]. Un pipeline es una cadena de pasos que corre sola, de principio a fin.

Un artefacto, en este oficio, es cualquier archivo que deja un paso: un conjunto de datos preparado, un modelo, un reporte de métricas.

Etapa	Qué se hace	Qué produce
Desarrollo y experimentación	Se prueban algoritmos y formas de modelar, con los pasos del experimento ya orquestados	El código fuente de los pasos del pipeline, guardado en un repositorio
Integración continua del pipeline	Se construye el código y se le corren pruebas	Componentes listos para desplegar: paquetes, ejecutables y artefactos
Entrega continua del pipeline	Esos componentes se instalan en el entorno de destino	Un pipeline desplegado con la nueva versión del modelo
Disparo automático	El pipeline corre en producción según un horario o ante un evento	Un modelo entrenado, guardado en el registro de modelos
Entrega continua del modelo	El modelo entrenado se pone a servir predicciones	Un servicio de predicción desplegado
Monitoreo	Se recogen estadísticas del desempeño con datos reales	Una señal para volver a correr el pipeline o abrir otro experimento

Fuente: Google Cloud, guía de MLOps, sección del nivel 2 [3].

Una aclaración de la misma guía: el análisis de datos sigue siendo manual antes de cada nueva vuelta, y el análisis del modelo también [3].

Quedan dos temas que merecen guía aparte. Uno es cómo se instala el modelo en un servidor; el otro, cómo se vigila su deriva, que es la pérdida de ajuste entre el modelo y los datos nuevos. Aquí basta saber que ambos cierran el ciclo.

Los niveles de madurez de MLOps según Google Cloud

Google Cloud ordena el MLOps en tres niveles, según cuánto del ciclo está automatizado [3]. No es un estándar universal: es el marco de un proveedor, pensado sobre todo para la inteligencia artificial predictiva, la que estima un valor o una categoría [3]. Para leer la tabla sirven tres siglas. La integración continua (CI) prueba cada cambio de código apenas se guarda. La entrega continua (CD) lo deja listo para instalar sin pasos a mano. El entrenamiento continuo (CT) vuelve a entrenar el modelo con datos nuevos de forma automática.

Nivel	Nombre en la guía	Qué cambia	Qué se despliega
0	Proceso manual	Cada paso se corre a mano, por lo general en cuadernos interactivos (documentos donde se escribe y se corre código por partes); quien entrena le entrega el modelo a quien lo instala	Solo el modelo, como servicio de predicción
1	Automatización del pipeline de ML	El entrenamiento se repite solo con datos frescos; entran validaciones automáticas de datos y de modelo	Todo el pipeline de entrenamiento, que corre de forma recurrente
2	Automatización del pipeline de CI/CD	Además, cada cambio al pipeline se construye, se prueba y se instala de forma automática	El pipeline y sus nuevas versiones, con registro de modelos y almacén de metadatos

Fuente: Google Cloud, guía de MLOps [3].

La guía advierte que el nivel 0 es común en muchas empresas que empiezan a aplicar machine learning [3]. En ese nivel, una versión nueva del modelo sale apenas un par de veces al año [3]. Puede bastar cuando los modelos casi no cambian. El problema, dice la misma guía, es que en la práctica los modelos a menudo se rompen cuando llegan al mundo real [3].

El paso al nivel 1 resuelve el reentrenamiento, pero no la llegada de ideas nuevas. Si un equipo maneja muchos pipelines y necesita probar cambios seguido, la guía indica que hace falta el nivel 2 [3]. Tampoco exige saltar de golpe: dice que las prácticas se pueden implantar de forma gradual [3].

¿Y los cinco niveles de Microsoft?

Microsoft usa otro mapa. Su modelo de madurez de MLOps tiene cinco niveles, del 0 al 4 [5]:

1. Nivel 0, sin MLOps. Compilaciones, pruebas y entrenamientos manuales.
2. Nivel 1, DevOps sin MLOps. El código ya tiene control de versiones y la aplicación, pruebas automáticas, pero los resultados del modelo siguen siendo difíciles de rastrear y reproducir.
3. Nivel 2, entrenamiento automatizado. El entrenamiento se automatiza, el modelo es fácil de reproducir y el desempeño del entrenamiento se sigue en un solo lugar.
4. Nivel 3, despliegue automatizado del modelo. Los lanzamientos son automáticos y hay trazabilidad completa hasta los datos originales.
5. Nivel 4, operación totalmente automatizada. Las señales de deriva o de retroceso del desempeño disparan el reentrenamiento automático.

Microsoft añade una advertencia que vale para cualquier escala. Una organización suele mostrar rasgos de más de un nivel a la vez, así que conviene leer el avance como un continuo y no como escalones aislados [5]. Por eso no conviene traducir una escala en la otra. La de Google mide cuánto del ciclo está automatizado [3]; la de Microsoft evalúa también personas, procesos y tecnología [5].

¿Qué hay que versionar en MLOps?

Versionar es guardar cada estado de algo con un identificador, para poder volver a él. En software normal basta con versionar el código. En machine learning el resultado depende también de los datos, de la configuración y del entorno, así que cada una de esas piezas necesita su propio registro.

Una característica, en esta tabla, es cada variable de entrada que el modelo usa para predecir, como la edad de un cliente o el historial de compras.

Qué se versiona	Por qué	Qué dice la fuente
Datos	Si los datos cambian, el mismo código produce otro modelo	Azure Machine Learning permite rastrear, perfilar y versionar datos [4]; Sculley y su equipo proponen una copia versionada de una señal inestable [1]
Código	Para saber qué instrucciones entrenaron cada modelo	En el nivel 2 de Microsoft, el código de entrenamiento y los modelos están ambos bajo control de versiones [5]
Modelo	Para poder volver al anterior si el nuevo falla	El registro de modelos los identifica por nombre y versión; si se registra uno con el mismo nombre, sube el número de versión [4]
Características	Para que el modelo use en producción las mismas variables con que se entrenó	Un almacén de características estandariza su definición, almacenamiento y acceso para entrenar y para servir [3]
Configuración	Un ajuste mal puesto rompe el sistema sin tocar el código	Las configuraciones deberían pasar revisión completa y guardarse en un repositorio [1]
Entorno de software	Las librerías y sus versiones cambian los resultados	Los entornos de Azure rastrean y reproducen las dependencias de pip y conda (dos gestores de paquetes de Python) [4]
Metadatos de cada ejecución	Para comparar corridas, depurar errores y reanudar un paso fallido	El almacén de metadatos guarda versiones, fechas, parámetros, punteros a artefactos y métricas de cada corrida [3]

El riesgo de no versionar las características tiene nombre en la guía de Google. Se llama sesgo entre entrenamiento y servicio: el modelo aprendió con unas variables y en producción recibe otras, calculadas de otra manera [3].

Un registro mínimo de entrenamiento en Python

Las plataformas grandes hacen esto por usted, pero la idea cabe en un script de la librería estándar de Python, sin instalar nada. El ejemplo entrena una recta con datos sintéticos de área y precio de apartamentos y la evalúa con dos filas apartadas. Al final guarda un archivo JSON (un formato de texto que guarda datos como pares de nombre y valor) con lo que hace falta para repetir la corrida.

# Registro mínimo de un entrenamiento: datos, código, configuración, modelo y métrica
import hashlib
import json
import statistics
import sys

# 1. Datos sintéticos: área de un apartamento (m²) y precio (millones de pesos)
datos = [(40, 95), (55, 120), (60, 138), (72, 160), (85, 190), (90, 205), (110, 240)]
config = {"modelo": "regresion_lineal_simple", "prueba": "las 2 últimas filas"}

entreno, prueba = datos[:-2], datos[-2:]

# 2. Entrenar: recta que mejor ajusta precio contra área
x = [area for area, _ in entreno]
y = [precio for _, precio in entreno]
pendiente, intercepto = statistics.linear_regression(x, y)

# 3. Evaluar: error absoluto medio en las filas de prueba
errores = [abs(pendiente * area + intercepto - precio) for area, precio in prueba]
error_medio = statistics.fmean(errores)

# 4. Registrar: huellas de datos y código, versión de Python, configuración y resultado
def huella(contenido: bytes) -> str:
    return hashlib.sha256(contenido).hexdigest()[:12]

with open(__file__, "rb") as f:
    huella_codigo = huella(f.read())

registro = {
    "huella_datos": huella(json.dumps(datos).encode()),
    "huella_codigo": huella_codigo,
    "python": sys.version.split()[0],
    "config": config,
    "modelo": {"pendiente": round(pendiente, 4), "intercepto": round(intercepto, 4)},
    "metricas": {"error_absoluto_medio": round(error_medio, 2)},
}

with open("registro_entrenamiento.json", "w", encoding="utf-8") as f:
    json.dump(registro, f, ensure_ascii=False, indent=2)

print(json.dumps(registro, ensure_ascii=False, indent=2))

Corrido con Python 3.11.15, el script imprime esto y deja el mismo contenido en el archivo registro_entrenamiento.json:

{
  "huella_datos": "29350b7831dd",
  "huella_codigo": "4aaccc8ba6ae",
  "python": "3.11.15",
  "config": {
    "modelo": "regresion_lineal_simple",
    "prueba": "las 2 últimas filas"
  },
  "modelo": {
    "pendiente": 2.1308,
    "intercepto": 7.6385
  },
  "metricas": {
    "error_absoluto_medio": 3.81
  }
}

Las huellas son el comienzo de un resumen SHA-256, un cálculo cuyo resultado cambia si cambia un solo byte de la entrada. En una prueba, bastó subir en uno el último precio para que la huella de los datos pasara a «98fa103642fb». La huella del código también cambia con cualquier carácter, así que en su copia del script saldrá distinta.

La función que calcula la recta, «statistics.linear_regression», existe desde la versión 3.10 de Python [11]. Este registro no reemplaza un control de versiones: le dice qué datos, qué código y qué ajustes produjeron cada número.

Roles y herramientas de MLOps

¿Quién trabaja en MLOps?

La guía de Google está dirigida a científicos de datos e ingenieros de machine learning que quieren aplicar principios de DevOps a sus sistemas [3]. El modelo de madurez de Microsoft nombra tres perfiles y describe cómo cambia su relación según el nivel [5]:

1. Científicos de datos. Construyen y prueban los modelos. En los niveles altos convierten su código de experimento en guiones repetibles, junto con los ingenieros de datos.
2. Ingenieros de datos. Preparan y mueven los datos que alimentan el entrenamiento. Microsoft anota que, en los niveles 0 y 1, los ingenieros de datos «(si existen)» trabajan aislados [5].
3. Ingenieros de software. Integran el modelo en la aplicación. En el nivel más alto automatizan esa integración y miden el modelo ya instalado.

La diferencia entre el nivel 0 y el 4 no es solo tecnológica. En el 0 los tres perfiles trabajan aislados; en el 4 trabajan juntos [5]. Qué estudiar para llegar al puesto de ingeniero de machine learning se trata en las rutas de aprendizaje de ciencia de datos.

Las piezas del stack de MLOps

Para el nivel 2, la guía de Google lista los componentes de la instalación [3]:

1. Control de código fuente, para guardar el historial del código.
2. Servicios de construcción y prueba.
3. Servicios de despliegue.
4. Registro de modelos, el catálogo de versiones entrenadas.
5. Almacén de características.
6. Almacén de metadatos de machine learning.
7. Orquestador de pipelines, el programa que decide qué paso corre y cuándo.

Tres proyectos abiertos cubren buena parte de esa lista. Se nombran como ejemplos, sin orden de preferencia:

• MLflow. Su módulo de seguimiento es una API (la puerta por la que un programa le pide algo a otro) con una interfaz gráfica. Sirve para registrar parámetros, versiones de código, métricas y archivos de salida de cada corrida [6].
• Kubeflow. Se presenta como un conjunto de proyectos modulares de código abierto para cargas de datos e inteligencia artificial sobre Kubernetes, un sistema que reparte programas entre muchas máquinas [7]. Según su documentación, empezó como una forma abierta de correr TensorFlow (una biblioteca de Google para entrenar modelos) como lo hacía Google por dentro [7].
• TFX (TensorFlow Extended). Google lo describe como una plataforma de machine learning de escala de producción basada en TensorFlow, con componentes para definir, lanzar y vigilar el sistema [8].

Las herramientas de base que corren por debajo, como Airflow para orquestar tareas o Docker y Kubernetes para empaquetar y repartir programas, son materia de la ingeniería de datos.

La deuda técnica oculta del machine learning

La deuda técnica es el costo futuro de tomar un atajo hoy. El artículo de Sculley y su equipo recuerda que la metáfora la introdujo Ward Cunningham en 1992, para el software en general [1]. Su aporte fue mostrar que los sistemas de machine learning tienen todos los problemas del código tradicional y además unos propios [1]. Y esa deuda puede costar verla porque vive en el sistema, no en una línea de código [1].

La tabla resume los tipos que nombra el artículo, con sus palabras y ejemplos. Es un texto de 2015 escrito desde la experiencia de Google, no un censo de la industria.

Tipo de deuda	En qué consiste	Ejemplo o regla del artículo
Erosión de límites	Las piezas del modelo dejan de poder cambiarse por separado	Principio CACE: «cambiar cualquier cosa cambia todo» [1]
Cascadas de corrección	Se entrena un modelo encima de otro para corregir un caso parecido	Mejorar el modelo de base puede empeorar el sistema completo [1]
Consumidores no declarados	Otros sistemas usan la salida del modelo sin avisar	Cualquier cambio al modelo los afecta de formas no previstas [1]
Dependencias de datos inestables o poco usadas	Entradas que cambian solas o que casi no aportan	Se conservan dos numeraciones de productos; un año después se borra el código que llenaba la vieja y el modelo que aún dependía de ella sufre [1]
Bucles de retroalimentación	El modelo influye en los datos con que se volverá a entrenar	Dos sistemas de una misma página web que se afectan a través de los clics [1]
Código pegamento y junglas de pipelines	Mucho código solo para meter y sacar datos de paquetes genéricos	Un sistema maduro podría terminar con «a lo sumo» 5 % de código de machine learning [1]
Rutas experimentales muertas	Ramas de prueba que se quedan en el código de producción	El caso de Knight Capital [1]
Deuda de configuración	Ajustes que a menudo se tratan como algo secundario y que, en un sistema maduro, pueden ocupar más líneas que el código	Las configuraciones deberían revisarse y guardarse en un repositorio [1]
Cambios en el mundo externo	Umbrales fijos en un entorno que se mueve	Un umbral puesto a mano puede dejar de servir cuando el modelo se actualiza con datos nuevos [1]
Otras deudas	Pruebas de datos, reproducibilidad, gestión de muchos modelos y cultura del equipo	Premiar borrar características y simplificar tanto como subir la precisión [1]

Fuente: Sculley y otros, NeurIPS 2015 [1].

El dato del 5 % lleva su cautela original: el artículo dice que un sistema maduro «podría» terminar así, no que todos lo hagan [1]. Lo mismo vale para la cifra de Knight Capital, que los autores atribuyen a un comunicado oficial y matizan con un «aparentemente» [1].

MLOps y AIOps: ¿son lo mismo?

No. El AIOps, sigla en inglés de inteligencia artificial para operaciones de tecnología, usa la inteligencia artificial para cuidar la infraestructura informática. Una revisión académica de 2023 lo describe como combinar la inteligencia artificial con los datos que generan las operaciones de TI (tecnologías de la información), sobre todo en la nube [9]. Su meta principal, según esa revisión, es maximizar la disponibilidad [9]. Sus tareas clave, según esa revisión, son detectar incidentes, predecir fallas, encontrar la causa raíz y automatizar respuestas [9].

La diferencia está en el objeto. El MLOps cuida modelos. El AIOps usa modelos para cuidar servidores, redes y servicios.

Hay un tercer término en circulación. Para la IA generativa, la que produce textos o imágenes, Microsoft habla de GenAIOps. Aclara que complementa los niveles de madurez del MLOps en vez de reemplazarlos [5]. Entre otras capacidades, suma el ciclo de vida de las instrucciones que recibe el modelo. También suma el control del costo de los tokens, los fragmentos de texto que el modelo procesa [5].

MLOps en Colombia: lo que pide la política de inteligencia artificial

En Colombia, la política nacional de inteligencia artificial no usa la palabra MLOps, pero la idea aparece. El 14 de febrero de 2025 se aprobó la Política Nacional de Inteligencia Artificial [10]. Es el documento CONPES 4144, del Consejo Nacional de Política Económica y Social, que aprueba los grandes planes del Gobierno. Ese documento recoge los lineamientos que el Gobierno dio a las entidades públicas en una directiva presidencial de 2021 y un decreto de 2022 [10].

Entre esos lineamientos, según el documento, está «documentar los procesos y decisiones adoptadas durante el ciclo de vida» de la inteligencia artificial [10]. Eso se parece, en lenguaje de política, a lo que un almacén de metadatos hace en lenguaje técnico.

El mismo CONPES nombra el cuello de botella. Uno de sus diagnósticos es la escasez de capital humano para el diseño, desarrollo, despliegue, uso, monitoreo y evaluación de sistemas de inteligencia artificial [10]. Le dedica una línea de acción completa [10]. La lista no se detiene en diseñar y desarrollar: incluye desplegar, usar, monitorear y evaluar.

Lo que se paga después

Leo el artículo de 2015 como la mejor explicación de por qué el MLOps no es un lujo de empresas grandes. Su argumento central no depende del tamaño. Un equipo pequeño que entrena un modelo en un cuaderno y lo entrega por correo también está tomando un crédito.

Por eso empezaría por lo barato y no por la plataforma. Un registro de qué datos, qué código y qué ajustes produjeron cada modelo cuesta un script. La orquestación completa puede esperar. Lo que no puede esperar es el rastro de cómo se hizo el primer modelo en producción. Sin él empieza la deuda que, según Sculley y su equipo, se acumula en silencio [1].

Preguntas frecuentes

¿MLOps es una herramienta o una metodología?

Es una forma de trabajar, no un programa que se instala. Google Cloud la define como una cultura y una práctica de ingeniería. Las herramientas, como MLflow o Kubeflow, ayudan a aplicarla, pero tener una instalada no equivale a practicarla. Un equipo puede usar MLflow y seguir entregando modelos a mano, sin pruebas ni registro de datos.

¿Cuál es el primer paso para implantar MLOps en un equipo pequeño?

Registrar cada entrenamiento: qué versión de los datos, qué código, qué configuración y qué métricas. Con eso se puede repetir un resultado y volver a un modelo anterior. Google Cloud aclara que no hace falta mover todos los procesos de un nivel a otro de inmediato, así que automatizar puede venir después.

¿Hace falta la nube para hacer MLOps?

No. Las guías de Google y Microsoft describen servicios de sus nubes, pero las prácticas de fondo, como versionar, probar y registrar, se pueden aplicar en un solo computador. MLflow, por ejemplo, guarda por defecto sus registros en una carpeta local llamada «mlruns» si no se le configura un servidor.

¿Qué es el entrenamiento continuo en MLOps?

Es volver a entrenar el modelo de forma automática con datos nuevos. Google Cloud lo llama una propiedad propia de los sistemas de machine learning. Según su guía, el reentrenamiento puede dispararse a pedido, con un horario, cuando llegan datos nuevos, cuando baja el desempeño o cuando cambia mucho la distribución de los datos.

¿Qué es un registro de modelos?

Es el catálogo donde se guardan los modelos entrenados con su nombre, su número de versión y sus metadatos. En Azure Machine Learning, por ejemplo, registrar un modelo con un nombre que ya existe sube el número de versión. Y no se puede borrar un modelo que esté en uso en un despliegue activo.

Referencias

1. Sculley, D.; Holt, G.; Golovin, D.; Davydov, E.; Phillips, T.; Ebner, D.; Chaudhary, V.; Young, M.; Crespo, J.-F. y Dennison, D. Hidden Technical Debt in Machine Learning Systems, Advances in Neural Information Processing Systems 28 (NIPS 2015) — desarrollar y desplegar es relativamente rápido y barato, mantener es difícil y costoso; metáfora de Cunningham (1992); tipos de deuda (erosión de límites, CACE, cascadas de corrección, consumidores no declarados, dependencias de datos, bucles de retroalimentación, antipatrones, configuración, mundo externo, otras); copia versionada de señales; principios de configuración; sistema maduro «a lo sumo» 5 % de código de ML; Knight Capital, 465 millones de dólares en 45 minutos, «aparentemente» por rutas experimentales obsoletas (fuente citada por el artículo: comunicado de la SEC de 2013); versión corta presentada en el taller SE4ML de 2014. NeurIPS Proceedings: Hidden Technical Debt in Machine Learning Systems (PDF) — Consultada: 2026-11-14.
2. Sculley, D. y otros. Machine Learning: The High Interest Credit Card of Technical Debt, SE4ML: Software Engineering for Machine Learning (NIPS 2014 Workshop) — primera versión del diagnóstico sobre deuda técnica en sistemas de machine learning. Google Research: The High Interest Credit Card of Technical Debt — Consultada: 2026-11-14.
3. Google Cloud. MLOps: Continuous delivery and automation pipelines in machine learning, Cloud Architecture Center (última revisión: 28 de agosto de 2024) — definición de MLOps como cultura y práctica de ingeniería de ML; aplica sobre todo a la IA predictiva; el reto es operar el sistema integrado; degradación por perfiles de datos cambiantes; pasos de ciencia de datos; niveles 0, 1 y 2 con sus características; nivel 0 común en muchas empresas, versiones un par de veces al año; almacén de características, almacén de metadatos y disparadores; etapas del nivel 2 con su salida; componentes del nivel 2; implantación gradual. Google Cloud: MLOps, continuous delivery and automation pipelines — Consultada: 2026-11-14.
4. Microsoft. MLOps model management with Azure Machine Learning, Microsoft Learn (fecha del artículo: 6 de octubre de 2025) — MLOps basado en principios de DevOps; tres resultados; capacidades (pipelines reproducibles, entornos reutilizables, registro y despliegue, linaje, alertas, monitoreo, automatización); registro de modelos por nombre y versión; versionado de datos; entornos de pip y conda; no se borra un modelo en un despliegue activo. Microsoft Learn: MLOps model management with Azure Machine Learning — Consultada: 2026-11-14.
5. Microsoft. MLOps maturity model, Azure Architecture Center, Microsoft Learn (fecha del artículo: 3 de junio de 2026) — cinco niveles (0 a 4) con nombre y rasgos; personas, procesos y tecnología; una organización suele mostrar rasgos de más de un nivel; roles de científicos de datos, ingenieros de datos (si existen) e ingenieros de software por nivel; GenAIOps complementa los niveles de MLOps. Microsoft Learn: MLOps maturity model — Consultada: 2026-11-14.
6. MLflow. MLflow Tracking, documentación oficial (versión «latest», MLflow 3) — API e interfaz para registrar parámetros, versiones de código, métricas y archivos de salida; por defecto registra en la carpeta local mlruns. MLflow: documentación de MLflow Tracking — Consultada: 2026-11-14.
7. Kubeflow. Introduction, documentación oficial — proyectos modulares de código abierto para cargas de datos e IA sobre Kubernetes; empezó como la apertura de la forma en que Google corría TensorFlow internamente, a partir de TensorFlow Extended. Kubeflow: introducción — Consultada: 2026-11-14.
8. TensorFlow. The TFX User Guide, documentación oficial — plataforma de ML de escala de producción de Google basada en TensorFlow, para definir, lanzar y vigilar el sistema. TensorFlow: guía de TFX — Consultada: 2026-11-14.
9. Cheng, Q.; Sahoo, D.; Saha, A. y otros. AI for IT Operations (AIOps) on Cloud Platforms: Reviews, Opportunities and Challenges, arXiv:2304.04661 (2023) — AIOps combina la IA con los datos de las operaciones de TI, en especial en la nube, con la meta principal de maximizar la disponibilidad; tareas: detección de incidentes, predicción de fallas, análisis de causa raíz y acciones automáticas. arXiv: AI for IT Operations (AIOps) on Cloud Platforms — Consultada: 2026-11-14.
10. Departamento Nacional de Planeación. Documento CONPES 4144: Política Nacional de Inteligencia Artificial (14 de febrero de 2025) — lineamientos de la Directiva Presidencial 03 de 2021 reiterados en el Decreto 1263 de 2022, entre ellos documentar los procesos y decisiones adoptadas durante el ciclo de vida (p. 32); diagnóstico 4.4.3 y línea de acción 4.3 sobre capital humano para el diseño, desarrollo, despliegue, uso, monitoreo y evaluación de sistemas de IA. DNP: Documento CONPES 4144 (PDF) — Consultada: 2026-11-14.
11. Python Software Foundation. statistics — Mathematical statistics functions, documentación de Python 3 — «linear_regression» devuelve pendiente e intercepto por mínimos cuadrados ordinarios; añadida en la versión 3.10. Python: documentación del módulo statistics — Consultada: 2026-11-14.

Cómo investigamos esta página

• Pregunta que responde: Qué es el MLOps, qué etapas y niveles describen las guías oficiales y qué deuda técnica busca evitar.
• Fuentes: identificadas 15 → incluidas 11 (guías de Google Cloud y Microsoft, el artículo de NeurIPS 2015 y su versión de 2014, documentación de MLflow, Kubeflow, TFX y Python, una revisión de arXiv y el CONPES 4144).
• Criterios de inclusión: solo documentación oficial, actas académicas y documentos públicos leídos en texto completo; sin cifras virales sin fuente primaria.
• Fecha de corte de los datos: 2026-11-14