Un lakehouse productivo separa el ciclo del dato en tres capas: Bronze conserva el dato original, Silver lo valida y estandariza, y Gold lo convierte en información lista para decisiones, BI e IA. El valor no está en usar tres colores, sino en establecer trazabilidad, reglas de calidad, responsables y controles que permitan reutilizar datos sin reconstruirlos para cada proyecto.
Microsoft y Databricks documentan este enfoque como medallion architecture, un patrón para incrementar progresivamente la calidad del dato desde su ingestión hasta su consumo. Databricks lo considera una práctica recomendada, no un requisito obligatorio de todo lakehouse.
En MAIA by Scanda lo llevamos un paso más allá: la arquitectura debe reducir versiones contradictorias de una misma cifra, aumentar las fuentes integradas al catálogo y acortar el tiempo entre recibir un dato y tomar una decisión. Ésas son métricas de negocio; contar tablas no lo es.
Definiciones taxonómicas
1. Capa Bronze
Es la zona de ingestión y preservación del dato fuente. Mantiene la información con el menor número posible de modificaciones de negocio: archivos, eventos, tablas operativas, APIs, ERP, CRM, IoT o sistemas transaccionales.
Su objetivo principal es conservar trazabilidad y permitir que las capas posteriores puedan reconstruirse sin volver a consultar cada sistema origen.
Databricks recomienda persistir esta capa precisamente para poder regenerar las capas posteriores cuando sea necesario.
2. Capa Silver
Es la capa donde el dato deja de ser solamente disponible y comienza a ser confiable y reutilizable.
Aquí se ejecutan procesos como:
- validación de calidad;
- normalización de formatos;
- eliminación o tratamiento de duplicados;
- homologación de identificadores;
- integración entre fuentes;
- aplicación de reglas de negocio reutilizables;
- cuarentena de registros inválidos;
- enriquecimiento y conformación de entidades.
Microsoft describe Silver como la etapa donde se corrigen errores, se estandarizan formatos y se eliminan duplicados; Databricks la posiciona como la base refinada para analistas y científicos de datos.
3. Capa Gold
Es la capa de consumo gobernado. Contiene productos de datos preparados para una decisión, proceso o caso de uso concreto: modelos semánticos, KPIs ejecutivos, datasets analíticos, agregaciones, reporting, forecasting o entradas controladas para aplicaciones de IA.
Gold no debería ser simplemente «Silver con menos columnas». Debe expresar el lenguaje del negocio: cliente, venta, margen, inventario, producción, riesgo, rentabilidad o nivel de servicio.
Microsoft plantea Gold como la capa curada para reportes y visualización, mientras que las arquitecturas de referencia más recientes ya contemplan su consumo también desde Copilot, agentes de datos y otras experiencias de IA.
Tabla comparativa
| Variable | Bronze | Silver | Gold |
| Propósito | Preservar el dato fuente | Hacerlo confiable y reutilizable | Convertirlo en producto de datos |
| Estado del dato | Raw / source-aligned | Validado, limpio, estandarizado | Curado y orientado al negocio |
| Transformaciones | Mínimas | Calidad, joins, MDM, reglas, deduplicación | KPIs, agregaciones, modelos semánticos |
| Principal consumidor | Ingeniería de datos, auditoría | Ingeniería, analítica, data science | BI, negocio, aplicaciones e IA |
| Granularidad | Máxima | Detallada y conformada | Adaptada al caso de uso |
| Acceso | Muy restringido | Restringido por rol | Según producto y audiencia |
| Regla crítica | No perder trazabilidad | No aceptar datos sin calidad comprobada | No publicar métricas sin dueño y definición |
| Fallo típico | Alterar el dato original | Duplicar reglas de negocio | Crear «una verdad» distinta por dashboard |
| Riesgo financiero | Reingestas, reprocesos, pérdida de evidencia | Reconciliación manual y retrabajo | Decisiones basadas en cifras inconsistentes |
| Métrica ejecutiva | Completitud y frescura | Calidad y reutilización | Tiempo del dato a la decisión |
La arquitectura medallion busca precisamente que la estructura y la calidad aumenten conforme el dato avanza de Bronze a Silver y posteriormente a Gold.
Cuerpo técnico
Qué función cumple cada capa en un lakehouse en producción
Un error frecuente es interpretar Bronze, Silver y Gold como tres carpetas.
No lo son.
Son tres contratos de calidad diferentes.
En un entorno productivo, cada transición debe responder cuatro preguntas:
- ¿Qué condición debe cumplir el dato para entrar?
- ¿Qué transformaciones están permitidas?
- ¿Quién responde por su calidad?
- ¿Qué consumidores pueden utilizarlo?
Sin esas reglas, se tiene almacenamiento por capas, pero no arquitectura.
1. Diseñar primero los productos Gold, no los pipelines Bronze
Puede parecer contradictorio, pero el diseño debería comenzar preguntando:
¿Qué decisión necesita tomar el negocio?
Después se trabaja hacia atrás.
Por ejemplo, si Dirección Financiera necesita una vista consolidada de margen por unidad:
Gold
Margen por producto, unidad, cliente y periodo.
↓
Silver
Clientes homologados + productos maestros + ventas + devoluciones + costos conformados.
↓
Bronze
ERP 1 + ERP 2 + CRM + archivos comerciales + catálogo de producto.
Esta lógica evita uno de los problemas más caros de una plataforma de datos: ingerir cientos de fuentes antes de saber para qué serán utilizadas.
En MAIA by Scanda, nuestra oferta de Data Intelligence parte precisamente de integrar, gobernar y dar calidad a información procedente de múltiples fuentes para convertirla en decisiones confiables, no de acumular datos sin una pregunta de negocio detrás.
2. Construir Bronze como registro reconstruible de la realidad
Bronze debe permitir responder:
«¿Qué recibimos realmente del sistema fuente?»
Requisitos mínimos
- Conservar el dato original o una representación fiel del mismo.
- Registrar fecha y hora de ingestión.
- Identificar sistema fuente.
- Registrar batch, archivo o evento de origen.
- Mantener trazabilidad de cambios de esquema.
- Definir política de retención.
- Detectar cargas duplicadas.
- Separar errores técnicos de transformaciones de negocio.
- Restringir el acceso directo de usuarios finales.
Microsoft recomienda conservar en Bronze el dato en su formato original o utilizar formatos como Parquet o Delta, dependiendo del escenario.
¿Por qué importa financieramente?
Porque sin una capa raw confiable, corregir una regla en Silver puede obligar a:
- consultar nuevamente sistemas fuente;
- reconstruir archivos históricos;
- repetir extracciones;
- solicitar información a otras áreas;
- reconciliar nuevamente cifras;
- detener dashboards o modelos.
Eso convierte un error lógico de horas en un reproceso de días.
Bronze protege el costo de reconstrucción.
3. Convertir Silver en la verdadera fuente reutilizable
Silver suele ser la capa que determina si una plataforma escala o termina llena de pipelines duplicados.
Su función es producir entidades consistentes que distintos consumidores puedan reutilizar.
Ejemplos:
- cliente_conformado
- producto_maestro
- transaccion_validada
- orden_integrada
- inventario_normalizado
- activo_industrial
- evento_operativo
Qué debe ocurrir en Silver
- Aplicar reglas de calidad.
- Homologar unidades y formatos.
- Resolver identidades.
- Deduplicar.
- Estandarizar claves.
- Integrar fuentes.
- Manejar datos faltantes.
- Aplicar MDM cuando corresponda.
- Crear historización cuando el negocio la necesite.
- Clasificar o proteger información sensible.
- Segregar registros rechazados.
Las mejores prácticas de Databricks recomiendan aplicar en esta capa schema enforcement y controles explícitos de calidad, en lugar de permitir que cualquier dato continúe automáticamente hacia consumo.
El error caro: transformar lo mismo cinco veces
Si Finanzas, Operaciones, Comercial y Data Science construyen cuatro versiones diferentes de «cliente activo», el costo no está solamente en el cómputo.
Está en que ahora existen cuatro verdades.
La primera métrica que debería preocupar a un CIO no es cuántos terabytes tiene el lakehouse, sino:
¿Cuántas versiones de la misma cifra existen dentro de la organización?
Ésta es también una de las métricas de diagnóstico que utilizamos en MAIA by Scanda para evaluar la madurez de datos.
4. Construir Gold alrededor de decisiones, no alrededor de sistemas
Bronze puede organizarse por sistema fuente.
Silver puede organizarse por entidades.
Gold debería organizarse por resultado de negocio.
Ejemplos adecuados:
- rentabilidad por cliente;
- forecast tienda × SKU;
- OEE por línea;
- riesgo por proveedor;
- disponibilidad por operación;
- customer lifetime value;
- rotación y cobertura de inventario;
- consolidación financiera.
Ejemplos poco útiles:
- SAP_gold
- CRM_gold
- ERP_gold
Eso sigue describiendo tecnología, no negocio.
Microsoft ejemplifica Gold con estructuras como ventas diarias, customer lifetime value e inventario para forecasting.
Gold no tiene que ser una única capa física
Dependiendo de la plataforma, puede implementarse como:
- tablas Delta;
- un lakehouse;
- un warehouse;
- vistas materializadas;
- modelos semánticos;
- productos de datos por dominio.
En Microsoft Fabric, por ejemplo, existen patrones tanto con un lakehouse por capa como con Bronze y Silver en lakehouse y Gold servido desde un warehouse.
Por eso Bronze, Silver y Gold describen responsabilidades lógicas antes que productos específicos.
Cómo diseñar un lakehouse Bronze-Silver-Gold paso a paso
Paso 1. Definir los casos de consumo
Antes de crear infraestructura, documentar:
- decisión que se quiere habilitar;
- usuario que consumirá el dato;
- frecuencia requerida;
- granularidad;
- periodo histórico;
- nivel de frescura;
- datos sensibles involucrados;
- KPI de negocio relacionado.
Un lakehouse sin consumidor definido suele convertirse en almacenamiento técnicamente correcto y financieramente difícil de justificar.
Paso 2. Mapear las fuentes contra el producto de datos
Para cada producto Gold se debe identificar:
- sistemas fuente;
- propietario de cada fuente;
- frecuencia de actualización;
- volumen;
- esquema;
- calidad histórica;
- claves disponibles;
- políticas de acceso;
- dependencias.
El objetivo no es ingerir todo.
Es ingerir lo que sostiene una decisión.
Paso 3. Establecer contratos Bronze → Silver
Una carga debería avanzar únicamente cuando supera controles definidos.
Ejemplos de controles
- archivo recibido completo;
- columnas obligatorias presentes;
- formato válido;
- fechas dentro de rango;
- claves primarias válidas;
- porcentaje de nulos aceptable;
- duplicados dentro del umbral acordado;
- datos sensibles correctamente clasificados;
- volumen consistente con su comportamiento esperado.
Los registros inválidos no deberían desaparecer silenciosamente.
Se deben rechazar, poner en cuarentena o remediar con trazabilidad.
Paso 4. Establecer contratos Silver → Gold
Antes de publicar información para negocio deberían cumplirse, al menos:
- reconciliación contra fuente;
- definición formal del KPI;
- propietario de negocio;
- controles de calidad aprobados;
- modelo de seguridad;
- nivel de frescura esperado;
- trazabilidad disponible;
- prueba de rendimiento;
- política de cambio.
Gold debe ser certificable, no solamente consultable.
Paso 5. Separar seguridad por capa
No todos necesitan entrar a todas las capas.
Un patrón razonable es:
Bronze: ingeniería y operación de datos.
Silver: ingeniería, analítica y data science autorizada.
Gold: consumidores de negocio y aplicaciones según función.
Microsoft documenta patrones donde los permisos se separan por workspace, artefacto, tabla, fila y columna, y recomienda tratar gobierno, identidad, RBAC y lineage como capacidades transversales a todo el ciclo de datos.
Esto importa especialmente cuando el lakehouse comienza a alimentar agentes o aplicaciones de IA.
El modelo no corrige permisos mal diseñados: consume aquello a lo que se le da acceso.
Paso 6. Separar desarrollo, pruebas y producción
Un lakehouse empresarial no debería modificarse directamente en producción.
El ciclo necesita:
- control de versiones;
- revisión de cambios;
- pruebas de calidad;
- ambientes Dev/Test/Prod;
- variables por ambiente;
- gates de despliegue;
- rollback;
- responsables de aprobación.
Microsoft Fabric, por ejemplo, soporta integración con Git y pipelines de despliegue entre desarrollo, pruebas y producción.
Lo importante no es la herramienta específica.
Es eliminar el «cambio rápido en producción» como proceso operativo.
Qué controles necesita un lakehouse productivo
Un lakehouse entra realmente en producción cuando puede responder no solamente qué datos contiene, sino qué está ocurriendo con ellos.
Controles por dominio
Ingestión
- Freshness.
- Latencia.
- Volumen esperado vs. recibido.
- Fallos por fuente.
- Duplicidad de cargas.
- Cambios de esquema.
Calidad
- Completitud.
- Validez.
- Unicidad.
- Consistencia.
- Integridad referencial.
- Exactitud cuando exista fuente de reconciliación.
Operación
- Tiempo de pipeline.
- Reintentos.
- Backlog.
- Costo de cómputo.
- Crecimiento del almacenamiento.
- Incidentes por producto de datos.
Gobierno
- Owner técnico.
- Owner de negocio.
- Lineage.
- Clasificación.
- RBAC.
- Retención.
- Evidencia de cambios.
Consumo
- Usuarios activos.
- Consultas.
- Freshness efectiva.
- Tiempo de respuesta.
- Productos sin consumo.
- KPIs duplicados.
Las vistas materializadas de Fabric, por ejemplo, ya incorporan capacidades para dependencias, reglas de calidad, refresh y visualización del lineage de Bronze a Silver y Gold.
Cómo medir si Bronze, Silver y Gold están generando valor
En MAIA by Scanda consideramos que una arquitectura de datos no debería reportarse al comité ejecutivo con «número de pipelines» o «número de tablas».
Para nosotros, tres preguntas son mucho más útiles:
1. ¿Cuántas versiones de la misma cifra existen?
Si Comercial dice 8.2 millones y Finanzas dice 7.9 millones, todavía no existe una fuente confiable de decisión.
2. ¿Qué porcentaje de fuentes críticas está integrado al catálogo maestro?
Permite medir si el fundamento realmente cubre el negocio o sólo una fracción de éste.
3. ¿Cuánto tarda un dato en convertirse en decisión?
Un dato correcto que llega después de que terminó la ventana de decisión tiene poco valor operativo.
Estas métricas forman parte del tablero de datos e IA definido por MAIA by Scanda.
Cómo traducir la arquitectura a ROI, EBITDA y riesgo
Bronze, Silver y Gold no generan ROI por usar esos nombres.
El valor aparece cuando eliminan costos o habilitan un resultado.
Palanca 1. Reducir costo operativo
Puede medirse con:
Costo actual de datos =
horas de integración manual
- reconciliación
- corrección de errores
- reprocesamiento
- mantenimiento de pipelines duplicados
- incidentes
- infraestructura.
Una arquitectura gobernada busca reducir esas partidas.
Cuando esas reducciones afectan gasto operativo, pueden traducirse en impacto sobre EBITDA.
Palanca 2. Reducir tiempo de decisión
Ejemplo:
Reporte actual disponible: día 10 del mes.
Reporte objetivo: día 2.
La pregunta financiera no es «¿ahorramos ocho días?».
Es:
¿Qué decisión no podía hacerse antes por esos ocho días de retraso?
Puede tratarse de:
- inventario;
- forecast;
- producción;
- pricing;
- compras;
- cobranza;
- disponibilidad;
- riesgo.
El beneficio se calcula sobre esa decisión, no sobre el dashboard.
Palanca 3. Evitar costo de reproceso
Bronze permite reconstruir.
Silver permite reutilizar.
Gold evita recrear lógica por consumidor.
En conjunto, esto reduce el costo marginal de habilitar un nuevo caso de uso.
Una plataforma que exige reconstruir ingestión, limpieza y reglas cada vez que aparece un nuevo modelo de IA no es una plataforma escalable: es una colección de proyectos.
Fórmula ejecutiva
Una forma simple de evaluar el proyecto durante 12 meses es:
ROI = (Beneficio económico anual − TCO anual) / TCO anual × 100
Donde el TCO debería incluir:
- plataforma;
- almacenamiento;
- cómputo;
- ingeniería;
- gobierno;
- operación;
- observabilidad;
- soporte;
- evolución;
- gestión de datos.
Y el beneficio debe construirse con datos de la propia operación, no con un benchmark genérico. Esa es también la metodología que seguimos en MAIA by Scanda para estructurar business cases y Proofs of Value.
Errores que elevan el TCO de un lakehouse
Error 1. Transformar Bronze hasta volverlo irreconocible
Si Bronze ya incluye reglas comerciales, se pierde la posibilidad de reconstruir y auditar desde la fuente original.
Error 2. Permitir que BI consuma directamente Bronze
El resultado suele ser que cada dashboard implementa su propia limpieza y su propia definición del dato.
Error 3. Convertir Silver en un segundo data lake sin gobierno
Silver debe consolidar lógica reusable. Si todo entra y nada se certifica, sólo se cambió el lugar del problema.
Error 4. Construir Gold por aplicación
Gold debe reflejar productos de datos o decisiones, no la estructura de los sistemas fuente.
Error 5. No asignar propietarios
Toda métrica crítica necesita un responsable técnico y un responsable de negocio.
Error 6. Medir actividad en lugar de confiabilidad
«Procesamos 20 TB» no demuestra valor.
«Reducimos de cuatro versiones del indicador financiero a una» sí demuestra un cambio operativo.
Conclusión predictiva
Durante los próximos ciclos de adopción, Gold dejará de ser únicamente la capa de dashboards.
Nuestra previsión en MAIA by Scanda es que se convertirá progresivamente en la interfaz gobernada entre los datos corporativos y tres consumidores simultáneos: personas, modelos analíticos y agentes de IA.
Las arquitecturas de referencia actuales ya muestran productos Gold consumidos no sólo desde BI, sino también desde Copilot y data agents.
Eso elevará el estándar.
Ya no bastará con preguntar:
«¿El dashboard tiene el número correcto?»
También habrá que responder:
- ¿qué origen produjo ese número?;
- ¿qué reglas lo transformaron?;
- ¿quién autorizó su uso?;
- ¿qué agente puede consumirlo?;
- ¿qué versión está vigente?;
- ¿se puede reproducir?;
- ¿qué ocurre si cambia su fuente?
Por eso, la arquitectura Bronze-Silver-Gold seguirá siendo útil, pero el verdadero diferenciador no será tener tres capas.
Será gobernarlas como una cadena de confianza.
CTA final de MAIA
Convierte tu lakehouse en una plataforma para decisiones e IA, no en otro repositorio
En MAIA by Scanda partimos de una pregunta simple: ¿qué decisión necesita mejorar tu empresa y qué datos necesita para confiar en ella?
A partir de ahí evaluamos fuentes, calidad, integración, gobierno y arquitectura para determinar qué debe permanecer en Bronze, qué necesita resolverse en Silver y qué productos de datos deben llegar a Gold.
Si hoy tienes datos distribuidos entre ERP, CRM, archivos, plataformas cloud o sistemas operativos y todavía existen distintas versiones de la misma cifra, conversemos. Podemos ayudarte a definir una arquitectura de datos orientada a resultados y preparada para analítica e IA en producción.
FAQ
1. ¿Es obligatorio tener tres lakehouses separados para Bronze, Silver y Gold?
No. Bronze, Silver y Gold son principalmente capas lógicas. Pueden implementarse mediante schemas dentro de un mismo lakehouse o mediante lakehouses y warehouses separados. La decisión depende de escala, seguridad, equipo y necesidades de gobierno. En Fabric, Microsoft incluso recomienda separar capas en distintos workspaces cuando se necesita mayor control.
2. ¿Los modelos de IA deben consumir únicamente datos de Gold?
No necesariamente. Data scientists pueden trabajar con datos Silver cuando necesitan mayor granularidad, mientras que productos de IA en producción deberían consumir datasets gobernados y adecuados a su caso de uso. Databricks identifica Silver como una capa útil para data science y Gold como una capa optimizada para consumidores y productos de negocio.
3. ¿Cómo saber si un lakehouse ya está listo para producción?
Debe tener ingestión reproducible, controles automáticos de calidad, lineage, propietarios, seguridad por rol, monitoreo, ambientes de desarrollo/prueba/producción y productos Gold con definiciones de negocio verificables. Si un error no puede rastrearse desde el KPI hasta su fuente, la plataforma todavía tiene una brecha de producción.
Español 
English