La transformación del Machine Learning en BBVA: de plataforma de datos a ML escalable

En los últimos años, el crecimiento del número de soluciones de inteligencia artificial y machine learning desarrolladas dentro del banco, junto con la diversificación de los casos de uso, ha hecho necesario apoyarse en una sólida plataforma en la nube que permita mayores niveles de flexibilidad, escalabilidad y automatización.

Una vez completado su despliegue global en BBVA, la plataforma ADA sigue creciendo y actualmente presta servicio a más de 6.500 usuarios en el banco, proporcionando acceso centralizado a entornos de desarrollo, activos de datos compartidos y capacidades de despliegue en producción. Ahora, además, ofrece pipelines de ML estandarizados y reutilizables, que los equipos técnicos utilizan para crear y desplegar modelos de forma consistente entre distintas áreas de negocio, al tiempo que habilitan una experimentación y una entrega más rápidas.

Para implementar esta evolución del marco de trabajo o framework de MLOps, BBVA aprovecha tecnologías de AWS que proporcionan la base técnica, al mismo tiempo que respaldan los altos estándares del banco en gobernanza, gestión del riesgo y auditabilidad.

En este artículo, analizaremos las principales novedades de la arquitectura de ADA que están impulsando esta transformación, como los flujos de desarrollo efímeros y un modelo de gobernanza integrado y orientado a eventos.

El reto: industrializar MLOps manteniendo una estricta gobernanza

Los ML workflows de ADA se construyeron sobre una base sólida que permitía una rápida experimentación mediante scaffolding estandarizado y workflows basados en notebooks. Sin embargo, a medida que aumentó la adopción de la IA, el foco pasó a mejorar la modularidad, incrementar la reutilización de código y reforzar las prácticas de reproducibilidad y control de versiones en todos los equipos. Alinear los patrones de desarrollo entre distintas áreas de negocio se convirtió en un paso natural para asegurar la consistencia y la sostenibilidad a largo plazo.

Al mismo tiempo, necesitábamos una solución que pudiera ofrecer a los profesionales en ciencia de datos una mayor autonomía para experimentar e iterar, sin comprometer la estabilidad de la plataforma ni sus estándares de gobernanza.

Desde una perspectiva operativa, los procesos de desarrollo y de gobernanza estaban claramente definidos y funcionaban bien, pero operaban como flujos de trabajo separados. Como resultado, optimizar la gestión del ciclo de vida mediante una mayor automatización e integración pasó a ser una prioridad. En particular, consolidar los activos relacionados —pipelines de entrenamiento, modelos y pipelines de inferencia— en estructuras de proyecto unificadas, y automatizar los procesos de aprobación y auditoría, reduciría la carga de coordinación y mejoraría la trazabilidad.

Para resolverlo, pasamos de un enfoque monolítico a un flujo de trabajo de desarrollo de ML flexible, desacoplado y completamente automatizado, basado en Amazon SageMaker AI. Al proporcionar componentes estandarizados y capacidades de autoservicio, los equipos pueden centrarse ahora en generar impacto en el negocio en lugar de gestionar la orquestación de la infraestructura.

En qué consiste la solución técnica

La arquitectura de MLOps proporciona la infraestructura y las herramientas necesarias para que los profesionales de ciencia de datos e ingeniería de ML construyan pipelines para entrenamiento, inferencia en batch y monitorización, manteniendo al mismo tiempo la gobernanza y la trazabilidad.

Dentro de la plataforma ADA, un usuario selecciona una plantilla de MLOps de un catálogo e inicia la creación de un nuevo proyecto. Este despliegue recopila metadatos regulatorios importantes, como la descripción del modelo, el responsable de negocio y la clasificación del modelo. Cada proyecto aprovisiona automáticamente un repositorio GitHub dedicado con un código base estandarizado para entrenar modelos y registrarlos junto con métricas y metadatos.

La plataforma permite un flujo de trabajo de desarrollo de ML completamente automatizado, en el que bloques de construcción estandarizados y capacidades de autoservicio permiten a los equipos desarrollar, probar y desplegar soluciones de ML de forma independiente, apoyándose en una base compartida y lista para producción. Esto permite a los equipos centrarse en aportar valor al negocio, en lugar de gestionar la complejidad de la infraestructura y la orquestación. En lugar de implementar la lógica de principio a fin en un solo paso, los usuarios pueden componer componentes reutilizables, parametrizarlos e iterar con mayor eficiencia.

Además, para reducir el tiempo de testeo, la solución despliega flujos de desarrollo efímeros dedicados para probar nuevas funcionalidades antes de que se integren en la rama principal.

La transición entre los entornos de desarrollo y producción se gestiona mediante GitHub Actions, que están vinculados a las ramas del repositorio asociadas en cada entorno. Amazon EventBridge y AWS Lambda, por su parte, siguen un workflow de aprobación de modelos y registran los modelos en el entorno de producción una vez aprobados. Puedes ver el flujo de trabajo de principio a fin para implementar modelos de ML en este artículo del blog de AWS.

Flujos de desarrollo efímeros

Una de las innovaciones más transformadoras en la evolución de MLOps de BBVA ha sido la introducción de flujos de desarrollo efímeros. Este enfoque redefine la forma en que el equipo técnico valida e itera sobre su trabajo, pasando de una validación basada en uniones (merges) a un modelo basado en ramas que permite una experimentación más rápida sin renunciar a los estándares de calidad.

Antes de implementar los flujos efímeros, validar cambios requería fusionar el código en ramas compartidas (main branch), lo que introducía fricción y riesgos potenciales en el ciclo de desarrollo. Además, provocaba la proliferación de pipelines no utilizados debido a un enfoque de versionado secuencial.

La implementación del workflow efímero aprovecha GitHub Actions y AWS SageMaker para crear recursos aislados y temporales para cada Pull Request. Cuando un desarrollador abre una Pull Request (PR), la plataforma CI/CD aprovisiona automáticamente un conjunto completo de recursos —incluidos pipelines de entrenamiento y paquetes de modelos— dentro de un entorno de prueba dedicado. Estos entornos aislados utilizan una convención de nombres estándar, lo que permite que varios equipos y usuarios trabajen simultáneamente en diferentes funcionalidades sin interferir con los recursos compartidos.

Versionado de pipelines y gestión de recursos

Es fundamental destacar que esta flexibilidad que hemos mencionado no genera desperdicio de recursos en la nube. Nuestro sistema de flujos efímeros implementa una rigurosa limpieza automatizada de recursos. Cuando una PR se cierra o se fusiona, la plataforma CI/CD ejecuta un proceso de destrucción en varias etapas: detiene las ejecuciones en curso, elimina versiones de modelos, suprime definiciones de pipeline y limpia los grupos de paquetes de modelos. Esta gestión automatizada del ciclo de vida se ha convertido en una disciplina operativa clave en BBVA, contribuyendo directamente a una reducción de costes del 40% al 55% en casos de uso piloto.

Además, optimizamos el versionado de pipelines para que las nuevas versiones solo se generen de forma nativa cuando la definición del pipeline o el código subyacente cambian realmente, reduciendo el número total de recursos utilizados y mejorando la trazabilidad. Esta consolidación mejora la gestión de cuotas, ayudando a los equipos a reducir su consumo y habilitando capacidades precisas de rollback y comparison.

Desarrollo en paralelo e integración corporativa

Un elemento clave de la evolución de BBVA es que los workflows de MLOps están integrados en el marco de trabajo corporativo de validación del banco. Estos workflows específicos de MLOps se han incorporado al repositorio centralizado de GitHub Actions de BBVA, lo que los hace fácilmente reutilizables en todos los proyectos de MLOps del banco y garantiza una calidad homogénea, al tiempo que reduce el esfuerzo necesario para los nuevos proyectos.

Esta capacidad de desarrollo en paralelo ha sido el principal motor de la reducción del 20% al 75% en los tiempos de desarrollo observada en los casos de uso piloto. Ahora los desarrolladores pueden iterar rápidamente, experimentar con libertad y probar escenarios complejos con total confianza.

Marco de gobierno de modelos

El gobierno está integrado por diseño dentro de la plataforma, en lugar de introducirse como una capa de control separada. Las reglas de aprobación, la separación de funciones, la promoción basada en el nivel de riesgo del modelo y la auditabilidad ya no se gestionan como pasos manuales desconectados, sino como parte del propio flujo de trabajo de la plataforma. SageMaker Model Registry se integra con el marco de gobierno de modelos del banco para hacer cumplir estas reglas de forma programática, manteniendo al mismo tiempo una experiencia ágil y controlada para los científicos de datos.

El marco de trabajo aborda tres retos principales:

• Garantizar que ningún científicos de datos pueda aprobar su propio modelo (prevención de autoaprobación).
• Automatizar las decisiones de promoción en función del nivel de riesgo del modelo.
• Mantener una auditoría centralizada de cada evento del ciclo de vida del modelo.

Estos controles garantizan que todas las transiciones del ciclo de vida del modelo sean trazables, auditables y estén alineadas con las políticas internas de gestión de riesgos de BBVA.

Flujos de aprobación

Los modelos registrados en SageMaker Model Registry avanzan por cuatro etapas: Development, QA, PreProduction y Production. Cada etapa, junto con un estado específico (InProgress, PendingApproval, Approved o Rejected), determina las transiciones permitidas y el rol responsable de cada acción.

Para gestionar estas transiciones de forma segura sin frenar la innovación, el marco de gobierno implementa distintos flujos de aprobación, cada uno orientado a una preocupación concreta de gobierno:

• Flujo de autoaprobación: Como los modelos en producción requieren reentrenamiento con frecuencia, exigir un ciclo de aprobación completo en cada ocasión impediría a los equipos mantener los modelos actualizados. Para resolverlo, una vía de autoaprobación promociona automáticamente nuevas versiones del modelo si el modelo ya había sido aprobado para producción y el pipeline de entrenamiento subyacente no ha cambiado de forma material. Si la definición del pipeline sí cambia, el modelo debe pasar por el ciclo completo de revisión.
• Flujo de aprobación manual: Cuando no se cumplen las condiciones de autopromoción, un científico de datos solicita la aprobación de QA actualizando el ciclo de vida del modelo de Development/InProgress a QA/PendingApproval. Otro científico de datos revisa el modelo y lo promueve a la siguiente etapa o lo rechaza. Una vez que un modelo alcanza la etapa PreProduction, el sistema evalúa automáticamente si se puede omitir el paso de aprobación del responsable de negocio en función del nivel de riesgo del modelo. Los modelos de menor riesgo omiten este paso y se promocionan automáticamente a Production, mientras que los modelos de mayor riesgo requieren revisiones manuales rigurosas por parte de otro científico de datos.
• Notificaciones a lo largo del ciclo de vida del modelo: Una de las mejoras de proceso más importantes es la integración más estrecha entre ADA y la plataforma Model Risk Management. Al notificar automáticamente al portal de riesgos eventos clave del ciclo de vida —como la inicialización de un proyecto o la promoción a producción—, el sistema elimina transferencias manuales, mejora la trazabilidad a lo largo de todo el ciclo de vida del modelo y mantiene ambas plataformas perfectamente alineadas.

Conclusión

La transformación de MLOps de BBVA demuestra cómo la modernización de las prácticas de ML puede generar valor empresarial tangible cuando se aplica a casos de uso reales. En cuatro iniciativas piloto, los equipos lograron una reducción del 20% al 75% en el tiempo de desarrollo y una reducción del 40% al 55% en los costes, en función del caso de uso y del nivel inicial de madurez de MLOps.

Estas mejoras fueron impulsadas por un nuevo modelo operativo de MLOps dentro de BBVA: la creación estandarizada de proyectos, los entornos de validación efímeros y los flujos de trabajo automatizados de CI/CD permiten a los equipos moverse más rápido sin renunciar al nivel de control que exige un entorno bancario regulado.

Más allá de las ganancias de eficiencia, la plataforma, basada en tecnologías de AWS, integra gobierno, cumplimiento normativo y trazabilidad por diseño. El gobierno centralizado y los flujos de aprobación automatizados reducen el riesgo operativo al tiempo que garantizan la alineación con los requisitos regulatorios.

Esta transformación representa un cambio hacia el tratamiento del Machine Learning como una disciplina de ingeniería de primer nivel dentro de BBVA, respaldada por capacidades de plataforma que permiten escala, consistencia e innovación continua.

Autores

Natalia Sampietro, Leticia García Martín (BBVA Tech), Itziar Molina Fernandez (AWS Professional Services), Juan Asensio Sánchez (AWS Professional Services), Néstor Durán (AWS Professional Services)