La transformación del Machine Learning en BBVA: cómo generar valor de negocio más rápido

Al diseñar nuestra nueva arquitectura de MLOps, sabíamos que construir un marco teórico no sería suficiente. Para asegurarnos de que nuestras decisiones de arquitectura respondieran desde el principio a requisitos reales de producción, desarrollamos nuestra base de MLOps en paralelo con cuatro unidades de negocio distintas. Estos primeros pilotos abarcaron dominios muy diversos —desde modelización de riesgo y optimización de precios hasta recomendaciones personalizadas y previsión financiera—, con distintas escalas de datos, necesidades de computación y niveles de madurez de los equipos.

A pesar de operar en geografías y dominios distintos, descubrimos que los equipos compartían oportunidades comunes para desarrollar y estandarizar sus prácticas de entrega de ML. Aunque ya utilizaban repositorios de código, tracking de experimentos y capacidades de ciclo de vida de modelos, los patrones de implementación habían evolucionado de forma independiente con el tiempo, lo que reducía la reutilización entre equipos y aumentaba el esfuerzo de incorporación en nuevos proyectos con bases técnicas similares.

Además, los procesos operativos en torno a la promoción de modelos y la gestión de pipelines también combinaban actividades automatizadas y manuales, lo que generaba margen para mejorar la escalabilidad a medida que crecía el número de casos de uso. La ausencia de entornos de testeo aislados hacía que validar cambios en los pipelines requiriera fusionar código en ramas compartidas, ralentizando los ciclos de feedback. Del mismo modo, aunque los equipos contaban con capacidades esenciales de gobernanza —como el registro y la monitorización de modelos—, sus enfoques variaban ampliamente.

La oportunidad era clara: acelerar e industrializar la entrega de ML mediante la estandarización de patrones comunes en plantillas reutilizables, la simplificación de los flujos operativos y la incorporación directa de la gobernanza y la trazabilidad en la experiencia de desarrollo.

Método: alinear personas, procesos y tecnología

Modernizar los flujos de trabajo de Machine Learning en una gran organización requiere más que introducir nuevas herramientas; exige definir un enfoque escalable que alinee personas, procesos, gobierno y tecnología. Para lograrlo, combinamos el conocimiento de negocio de BBVA con la experiencia de AWS y llevamos a cabo una serie de sesiones de ideación y evaluación con varias unidades de negocio.

Comenzamos con sesiones estructuradas de ideación en cada una de las cuatro unidades de negocio que aceptaron ser pioneros de la solución. Cada unidad aportó casos de uso técnicos de ML distintos (desde regresión con XGBoost hasta Deep Neural Networks), diferentes niveles de madurez en desarrollo y distintas restricciones operativas. En lugar de prescribir un único camino, utilizamos estas sesiones para mapear esos flujos de trabajo diversos e identificar patrones comunes, retos y divergencias.

Este enfoque de doble vía fue crucial para alinear las necesidades reales del negocio con la plataforma general de MLOps que estábamos diseñando. El resultado fue una comprensión compartida de qué significaba “hacerlo bien” en toda la organización, basada en datos reales.

Los hallazgos de estas sesiones de ideación alimentaron directamente el diseño de plantillas reutilizables de MLOps y flujos operativos estandarizados. El marco técnico resultante equilibró la estandarización en cuatro dimensiones: guiar a las personas en la transición del trabajo individual en notebooks a pipelines colaborativos y versionados; establecer procesos estandarizados para revisión de código, testeo y despliegue; incorporar la gobernanza para asegurar la alineación regulatoria y reducir la supervisión manual; y aprovechar la tecnología integrando las plantillas de MLOps directamente en ADA, la plataforma global de Data and AI de BBVA, de modo que cada nuevo proyecto parta de una base lista para producción.

Resumen de la solución

El núcleo de este enfoque industrializado comienza en la consola de ADA. Cuando los usuarios seleccionan un MLOps asset, el sistema aprovisiona automáticamente un nuevo proyecto con un repositorio GitHub dedicado y un código base estandarizado. Este scaffold proporciona una configuración de principio a fin para el ciclo de vida del Machine Learning, incluyendo Amazon SageMaker Pipelines reutilizables para entrenamiento, inferencia y monitorización, lo que permite a los equipos personalizar flujos concretos mientras heredan la gobernanza, tracking de experimentos y capacidades de integración continua ya incorporadas.

Los pipelines de entrenamiento están diseñados de forma intencionadamente modular. La plantilla por defecto estructura el proceso de construcción en pasos discretos: procesamiento de datos, entrenamiento, evaluación, comprobaciones condicionales basadas en el rendimiento, validaciones de calidad y registro en SageMaker Model Registry. Este diseño modular permite almacenamiento en caché paso por paso, omitiendo aquellos pasos no modificados durante el desarrollo iterativo para reducir el tiempo de ejecución y los costes de computación. Una estrategia de computación CPU-first garantiza que los recursos más costosos se utilicen solo cuando sea estrictamente necesario.

Además, la plantilla promueve un enfoque Python-first que sustituye PySpark cuando es posible, simplificando la experiencia de desarrollo en casos de uso que no requieren computación distribuida, al tiempo que permite a los equipos integrar pasos de PySpark apoyados en EMR cuando es necesaria una preparación de datos a gran escala.

Los modelos solo se registran de forma condicional si cumplen umbrales de rendimiento predefinidos, mientras que herramientas como MLflow capturan hiperparámetros, métricas y artefactos para mantener un registro centralizado de tracking asociado a la versión correspondiente en Model Registry.

Amazon SageMaker AI Pipelines registra métricas de experimentos mediante la librería MLflow en cada ejecución. Los científicos de datos visualizan estos valores en una interfaz de usuario proporcionada por el MLflow Server, integrado de forma nativa en Amazon SageMaker AI Studio. MLflow muestra estas métricas en forma de gráficos, plots, valores en bruto o informes HTML completos.

Del mismo modo, los pipelines de inferencia se estructuran para minimizar la coordinación manual. Incorporan un mecanismo automatizado de recuperación que utiliza un paso de AWS Lambda para resolver sin fricción los artefactos de la última versión aprobada del modelo, eliminando la necesidad de gestionar rutas manualmente. Cuando un modelo reentrenado completa el flujo automatizado de aprobación sin cambios materiales en el pipeline de entrenamiento subyacente, la configuración de inferencia recupera automáticamente la última versión aprobada. Esta capacidad mantiene actualizadas las predicciones en producción sin requerir un nuevo despliegue ni una nueva aprobación del propio pipeline de inferencia.

Extensión de la plantilla de MLOps para cargas de trabajo complejas

Aunque la plantilla por defecto cubre con éxito los patrones estándar de desarrollo de Machine Learning, distintos dominios de negocio suelen introducir requisitos técnicos y operativos muy especializados. En lugar de crear flujos de trabajo aislados y a medida, la base reutilizable de la plantilla se amplió para dar soporte a cargas de trabajo especializadas sin desviarse de la estructura estandarizada del pipeline.

Por ejemplo, cuando las unidades de negocio necesitan entrenar en paralelo redes neuronales profundas de alta demanda computacional para seleccionar el candidato con mejor rendimiento, el pipeline se adapta sin problemas para utilizar familias de instancias optimizadas para GPU. El entorno de contenedores cambia a una imagen de framework habilitada para CUDA, mientras que la orquestación general y la lógica de registro condicional permanecen completamente inalteradas. De forma importante, esta computación de alto rendimiento se aplica exclusivamente al paso de entrenamiento, mientras que el procesamiento de datos y la evaluación siguen ejecutándose en instancias CPU rentables para preservar la estrategia central de optimización de costes. Del mismo modo, para dominios que gestionan conjuntos de datos masivos y requieren procesamiento distribuido, se implementó un modelo de ejecución híbrido.

El principio fundamental en todas estas extensiones es la consistencia. La orquestación, la lógica condicional y las capas de gobernanza permanecen completamente desacopladas del framework de ejecución. Cada ejecución de pipeline, ya sea ejecutando PyTorch en GPU o Scikit-Learn en CPU, registra resultados en el mismo sistema de tracking, registra modelos a través del mismo flujo de gobernanza y se integra sin fricciones con la automatización de CI/CD. Esto confirma que la arquitectura de la plantilla puede absorber una enorme diversidad técnica sin fragmentarse en soluciones específicas para cada equipo. Puedes encontrar más información sobre esta solución y las plantillas extendidas de ML en este artículo del blog de AWS.

Lecciones aprendidas y buenas prácticas

La fase piloto aportó aprendizajes claros sobre cómo un marco de MLOps estandarizado pero flexible puede acelerar el desarrollo, mejorar la eficiencia y reforzar la gobernanza. Las principales buenas prácticas identificadas incluyen:

• Empezar por casos de uso reales: Construir la estandarización de MLOps a partir de casos de uso reales en producción ayudó a identificar patrones verdaderamente comunes, preservando al mismo tiempo la flexibilidad necesaria para distintos volúmenes de datos, arquitecturas de modelos y necesidades de computación.
• Tratar las plantillas como aceleradores, no como restricciones: Una plantilla genérica de MLOps proporciona una base lista para producción para pipelines de entrenamiento, inferencia, monitorización de datos y del modelo, con CI/CD, tracking de experimentos, registro de modelos y capacidades de gobernanza ya integradas. Los equipos pueden ampliar estos pipelines cuando lo necesiten, manteniendo al mismo tiempo un modelo de ciclo de vida coherente.
• Habilitar entornos de validación efímeros: Mejorar la experiencia del desarrollador es esencial. Los entornos efímeros basados en Pull Requests permiten a los equipos validar cambios de forma segura antes de fusionarlos en ramas compartidas. Combinado con tests automatizados y controles de seguridad, este enfoque de desarrollo en paralelo permite ciclos de feedback más rápidos, mejor colaboración y mayor calidad de código.
• Optimizar los recursos del pipeline a nivel de paso: Tratar un pipeline entero como un único requerimiento de computación es ineficiente. Asignando los recursos adecuados a cada etapa, usando caching y combinando cargas de trabajo PySpark, Python, CPU y GPU cuando corresponde, los equipos pudieron reducir los tiempos de ejecución y mejorar la eficiencia de costes.
• Incorporar la gobernanza directamente en el ciclo de vida de ML: El flujo de trabajo estándar gestiona el versionado de modelos, los flujos de aprobación, la integración con la gestión de riesgos de modelos (MRM), la monitorización y la trazabilidad. Esto reduce el esfuerzo manual y garantiza que el cumplimiento normativo forme parte del proceso de desarrollo de forma natural.

Conclusión

Partiendo de casos de uso reales en producción, hemos definido una base común de MLOps que acelera la entrega sin perder la flexibilidad necesaria para distintos dominios de negocio, patrones técnicos y requisitos regulatorios. En BBVA, seguiremos mejorando estas capacidades y ampliando su adopción a más equipos, geografías y proyectos de Machine Learning.

Esta nueva forma de trabajar ya está ayudando a nuestros equipos a reducir la fragmentación, mejorar la reutilización y reforzar la forma en que controlan, monitorizan y operan soluciones de ML en producción, logrando mejoras en los tiempos de entrega de hasta un 75%. Y, lo más importante, nos permite desarrollar AI de forma más eficiente, con el objetivo de ofrecer a nuestros clientes un servicio bancario más inteligente, proactivo y personalizado.

Autores

Margarita García García, Oscar García Ramos, Andrea Perez Isla (AWS Professional Services), Carlos Guerra (BBVA Tech), Raúl Díaz García (AWS Professional Services).