Hay una pregunta que cualquier equipo de datos acaba haciéndose en algún momento: ¿cómo organizamos los datos dentro del lakehouse para que sean fiables, mantenibles y útiles tanto para analítica como para machine learning? La arquitectura Medallion es la respuesta que se ha impuesto como estándar en la industria. No porque sea la única forma de estructurar un lakehouse, sino porque resuelve un problema concreto de forma sistemática: que los datos mejoren progresivamente en calidad a medida que avanzan por el sistema, con responsabilidades claras en cada etapa y sin que nadie tenga que reconstruir desde cero cuando algo falla.
Este artículo explica qué es, cómo funciona cada capa, qué decisiones de diseño hay que tomar antes de implementarla y qué errores llevan a equipos experimentados a acabar con una arquitectura Medallion que no funciona como debería.
Qué es la arquitectura Medallion
La arquitectura Medallion es un patrón de diseño de datos que se utiliza para organizar los datos de forma lógica en un lakehouse, con el objetivo de mejorar de forma incremental y progresiva la estructura y la calidad de los datos a medida que fluyen por cada capa de la arquitectura (de las tablas de la capa Bronze ⇒ Silver ⇒ Gold).
El nombre viene de las medallas: bronce, plata y oro. Cada capa representa un nivel de refinamiento superior al anterior. Los datos entran en bruto, se procesan y validan en plata, y salen listos para el consumo en oro. A las arquitecturas Medallion a veces también se las denomina arquitecturas «multi-hop», cada capa es un salto que añade calidad y estructura.
Lo que hace a este patrón especialmente valioso no es su simplicidad, sino lo que resuelve a nivel organizativo: establece un contrato entre los equipos de datos sobre quién es responsable de qué. Los ingenieros de datos son responsables de que Bronze tenga todos los datos de las fuentes. El equipo de data engineering es responsable de que Silver sea fiable para análisis. Los propietarios de dominio son responsables de que Gold responda a los requisitos del negocio. Sin esa claridad de responsabilidades, los problemas de calidad de datos se enquistan porque nadie sabe exactamente en qué punto del flujo ocurrieron.
Databricks propuso el patrón en su documentación oficial y desde entonces se ha convertido en el estándar de facto tanto para implementaciones en Databricks como en Microsoft Fabric, donde Microsoft ha adoptado el mismo modelo con la misma nomenclatura.
Las tres capas: Bronze, Silver y Gold
Capa Bronze: la fuente de verdad inmutable
La capa Bronze actúa como zona de aterrizaje inicial para todos los datos sin procesar entrantes. Los datos llegan exactamente como vienen de las fuentes: sin transformaciones, sin limpieza, sin validaciones. Un registro que llega duplicado desde el ERP se almacena duplicado en Bronze. Un valor NULL que viene del sistema de ventas se guarda como NULL. Un campo con formato de fecha inconsistente entre dos fuentes se almacena con esa inconsistencia.
Eso no es un fallo del diseño: es precisamente el objetivo. Bronze es la capa que garantiza que siempre puedes volver al origen. Si una transformación posterior resulta ser incorrecta, porque la lógica de negocio era errónea, porque el equipo malinterpretó un requisito, porque los datos fuente cambiaron de formato, puedes reprocesar desde Bronze sin tener que volver a los sistemas de origen. Esa capacidad de reproducción es la que convierte a Bronze en la fuente de verdad del sistema, no en un almacén de basura.
Lo que sí se añade en Bronze son metadatos de ingesta: marca de tiempo de carga, identificador de la fuente, identificador del lote o del evento. Esa información es la que permite después rastrear el linaje de cualquier dato hasta su origen exacto.
Capa Silver: datos limpios, confiables y conformados
Silver es la capa donde ocurre el trabajo de transformación sustancial. La capa Silver reúne los datos de diferentes fuentes en una vista empresarial y habilita el análisis de autoservicio para informes ad hoc, análisis avanzados y ML.
En la práctica, Silver es donde se resuelven los problemas que Bronze dejó visibles: se eliminan duplicados, se normalizan formatos, se validan rangos y tipos, se aplican las reglas de negocio básicas y se consolidan entidades que aparecen bajo distintos identificadores en diferentes sistemas fuente. Un cliente que tiene tres IDs distintos en CRM, ERP y plataforma e-commerce se unifica aquí en un único registro canónico.
En el paradigma de ingeniería de datos del lakehouse, normalmente se sigue la metodología ELT en lugar de ETL, lo que significa que solo se aplican transformaciones mínimas o suficientes mientras se carga la capa Silver. Se prioriza la velocidad y la agilidad para incorporar y entregar datos. Eso tiene una implicación práctica importante: Silver no es el lugar para las agregaciones de negocio ni para los modelos dimensionales. Es el lugar donde los datos son fiables y consistentes, no donde están optimizados para un caso de uso específico.
Capa Gold: datos listos para el consumo
La capa Gold genera agregados a nivel empresarial, modelos de esquema en estrella y tablas de características optimizadas para casos de uso de análisis específicos, paneles de control, entrenamiento de machine learning y atención de consultas de usuarios finales con acuerdos de nivel de servicio garantizados.
Cada tabla Gold está diseñada para un consumidor concreto con unos requisitos concretos. El dashboard de ventas de dirección necesita datos agregados por semana, mercado y línea de producto. El modelo de propensión a la compra necesita una feature table con variables calculadas sobre la ventana de los últimos 90 días. El informe regulatorio necesita una vista específica con los campos y las transformaciones exactas que exige la normativa. Cada uno de estos es un producto Gold diferente, aunque todos partan de los mismos datos Silver.
Una consecuencia de este diseño es que Gold puede y debe tener múltiples tablas para distintos dominios y casos de uso. No existe «la tabla Gold» de una entidad: existen las tablas Gold que necesitan los consumidores de esa entidad, optimizadas para sus patrones de acceso específicos.
Decisiones de diseño que nadie explica
La teoría de las tres capas es sencilla. Lo que no es sencillo son las decisiones que hay que tomar antes y durante la implementación. Estas son las que más impacto tienen en si la arquitectura acaba funcionando o no.
¿Qué va en Silver y qué va en Gold?
La frontera entre Silver y Gold es la que más confusión genera. La regla práctica más útil: Silver contiene datos que son verdad para toda la organización. Gold contiene datos que son verdad para un caso de uso específico. Las reglas de negocio universales (cómo se define un cliente activo, qué constituye una transacción válida) van en Silver. Las agregaciones, los modelos dimensionales y las features de ML van en Gold.
¿Una Gold por consumidor o Gold compartidas?
Depende del nivel de divergencia entre los requisitos. Si dos equipos necesitan los mismos datos con la misma granularidad pero con filtros distintos, una tabla Gold compartida con filtros en consulta es suficiente. Si sus requisitos de agregación, de latencia o de semántica divergen significativamente, crear productos Gold separados es lo correcto. Intentar servir a consumidores con requisitos muy distintos desde una sola tabla Gold suele acabar en tablas monstruosas con decenas de columnas que nadie entiende del todo.
¿Cómo gestionar los cambios de esquema en Bronze?
Bronze almacena datos tal como llegan, lo que significa que tiene que ser tolerante a cambios de esquema en las fuentes. La solución estándar en Delta Lake y Databricks es la evolución de esquema automática con registro de versiones: cuando una fuente añade una columna nueva, Bronze la absorbe y registra en qué versión apareció. Las capas downstream (Silver y Gold) reciben los cambios de forma controlada, con tests que validan que el cambio no rompe las transformaciones existentes.
Medallion en streaming: cómo cambia el patrón con datos en tiempo real
La arquitectura Medallion se diseñó originalmente para procesamiento por lotes. Cuando una organización necesita que sus datos lleguen a Gold en segundos en lugar de en horas, el patrón se adapta pero los principios no cambian.
Con las streaming tables y las materialized views, los usuarios pueden crear pipelines de streaming construidos sobre Apache Spark Structured Streaming que se actualizan de forma incremental. En la práctica, esto significa que Bronze puede ingerir eventos en tiempo real desde Kafka o Event Hubs, Silver aplica las transformaciones de forma continua sobre el stream en lugar de sobre lotes, y Gold materializa las vistas agregadas con la latencia que el caso de uso requiere.
En Real-Time Intelligence de Microsoft Fabric, la capa Bronze puede ingerir datos mediante Eventstream o una tabla en Eventhouse. Esta capa proporciona una base para el enriquecimiento y el análisis posteriores en las capas Silver y Gold.
El punto crítico en Medallion con streaming es el mismo que en batch pero más urgente: las validaciones de calidad tienen que ocurrir en Bronze antes de que los datos lleguen a Silver. En batch, un error de calidad se descubre en la siguiente ejecución y el impacto está acotado a ese lote. En streaming, un error de calidad que no se detecta en Bronze puede contaminar Silver y Gold en cuestión de segundos antes de que alguien lo detecte.
Errores frecuentes de implementación
Conocer el patrón no es suficiente para implementarlo bien. Estos son los errores que se repiten con más frecuencia, incluso en equipos con experiencia.
- Transformar demasiado en Bronze. El error más habitual en equipos que vienen de ETL tradicional. La tentación de limpiar los datos mientras se cargan en Bronze es comprensible, pero elimina la capacidad de reprocesar desde el origen. Si transformas en Bronze y la transformación era incorrecta, no puedes recuperar el dato original sin volver a las fuentes.
- Construir Silver para un solo consumidor. Silver debería ser un activo compartido de la organización. Cuando se diseña para servir exclusivamente a un dashboard o a un modelo concreto, acaba siendo un Gold disfrazado de Silver. El problema aparece cuando un segundo equipo necesita esos datos y descubre que las transformaciones que hay en Silver responden a los requisitos del primero, no a los suyos.
- No definir propiedad de dominio. La arquitectura Medallion no es una tendencia de la última década: es cómo se hace la IA lista para producción. Las organizaciones que lo hacen bien, con control de calidad de datos en Bronze, Silver organizada por dominios que alimenta MDM, y productos Gold certificados para IA, serán las mejor posicionadas para adoptar IA agéntica a nivel de plataforma. Sin propietarios de dominio claros, las tablas Silver se convierten en tierra de nadie que nadie mantiene cuando las fuentes cambian.
- Ignorar el linaje de datos desde el principio. El linaje de datos (qué transformaciones sufrió un dato desde Bronze hasta Gold, qué versiones de las tablas fuente se usaron) es crítico para auditoría, debugging y gobierno. En Databricks con Unity Catalog, el linaje se captura automáticamente si las pipelines están bien configuradas. No habilitarlo desde el inicio significa tener que reconstruirlo retroactivamente, que es costoso y siempre incompleto.
Arquitectura Medallion y agentes de IA: el estándar de 2026
El papel de la arquitectura Medallion está evolucionando. Empezó como un patrón de organización de datos para analítica. En 2026 es la base sobre la que operan los agentes de IA empresariales.
Un agente que tiene que tomar una decisión (recomendar una acción comercial, consolidar un informe operativo, priorizar una incidencia) necesita datos que sean fiables, con linaje documentado y con semántica clara. Gold es exactamente eso. Cuando Microsoft IQ activa Fabric IQ para dar contexto a los agentes, lo que está consumiendo son las tablas Gold del lakehouse, con la semántica que Unity Catalog tiene documentada sobre ellas.
Esta capa semántica es lo que transforma una plataforma de datos de un activo tecnológico en un tejido de inteligencia operativa. También es donde los agentes de IA añaden un valor enorme: agentes que pueden atravesar el grafo de conocimiento, responder preguntas y surfar insights que las consultas estructuradas no alcanzarían.
La consecuencia práctica para cualquier organización que planea usar agentes de IA: el estado de su arquitectura Medallion determina directamente la calidad de lo que producen sus agentes. Un agente que consume tablas Gold bien diseñadas, certificadas y con linaje documentado toma decisiones correctas. Un agente que consume tablas Gold construidas sobre un data swamp sin gobernanza toma decisiones incorrectas con la misma confianza. La arquitectura Medallion no es solo una buena práctica de ingeniería de datos: es la infraestructura que hace posible que la IA funcione con fiabilidad en producción.
Cómo trabaja BertIA con la arquitectura Medallion
En BertIA, la arquitectura Medallion es el patrón de base en cualquier proyecto de datos sobre Databricks o Microsoft Fabric. No como una plantilla que se aplica mecánicamente, sino como un marco que se adapta a las particularidades de cada cliente: volumen de datos, número de fuentes, requisitos de latencia, estructura del equipo y casos de uso prioritarios.
Lo que hemos aprendido implementando este patrón en sectores como el farmacéutico, industrial y logístico es que el mayor factor de éxito no es técnico: es la claridad sobre quién posee cada dominio de datos. Antes de crear una sola tabla Bronze, los proyectos donde el despliegue funciona bien tienen definido qué equipo es responsable de cada fuente de ingesta, qué significa «dato correcto» para cada entidad de negocio y qué SLA tiene cada tabla Gold con los consumidores que dependen de ella.
La integración con Unity Catalog de Databricks es parte estándar de nuestras implementaciones: el linaje automático entre capas, el control de acceso por dominio y la documentación de metadatos son los elementos que convierten una arquitectura Medallion en un sistema auditable. Para clientes en sectores regulados, esa trazabilidad es la que hace posible responder a una auditoría sin tener que reconstruir nada manualmente. Para los proyectos de MLOps que gestionan modelos en producción sobre estos datos, Gold certificado es la garantía de que el entrenamiento y el serving parten siempre de datos con calidad verificada.
Conclusión
La arquitectura Medallion lleva años siendo el estándar para estructurar datos en un data lakehouse. En 2026, con la IA agéntica como capa que consume esos datos para tomar decisiones autónomas, su relevancia se ha multiplicado: las organizaciones que tienen una Medallion bien implementada están construyendo sobre una base que les va a servir para los próximos años. Las que la tienen mal implementada (sin propiedad de dominio, sin linaje, con transformaciones en la capa equivocada) van a tener que pagarlo en el momento en que intenten escalar sus iniciativas de IA.
Si estás diseñando o revisando tu arquitectura de datos y quieres asegurarte de que Medallion está configurada para soportar tanto la analítica actual como los casos de uso de IA que vienen, habla con nuestro equipo para revisar tu caso concreto.
