Durante años, la retención de datos históricos ha sido tratada como una decisión puramente técnica: más días significan más capacidad de recuperación, menos días implican menos coste. Sin embargo, la nueva capacidad de configuración del período de retención en Microsoft Fabric Data Warehouse permite abordar esta decisión desde una perspectiva mucho más interesante: alinear la retención con el valor de negocio de los productos de datos.
Microsoft Fabric permite configurar el período de retención entre 1 y 120 días, siendo 30 días el valor predeterminado. Este período determina durante cuánto tiempo pueden utilizarse capacidades como time travel queries, table clones, restore points o warehouse snapshots.
La mayoría de organizaciones verán esta funcionalidad como una simple configuración administrativa. Sin embargo, creo que representa una oportunidad para conectar directamente la arquitectura de datos con la estrategia de gobierno, la gestión del riesgo y el catálogo de productos de datos.
Dejemos de pensar en tablas. Empecemos a pensar en productos de datos.
En una organización madura, no todos los productos de datos tienen la misma importancia. Algunos alimentan informes operativos diarios, otros soportan procesos regulatorios, mientras que otros son simples datasets exploratorios utilizados por equipos analíticos.
Por ello: ¿Tiene sentido que todos ellos tengan exactamente la misma política de recuperación histórica?. Probablemente no.
La posibilidad de configurar el retention period del warehouse permite empezar a responder a preguntas como:
- ¿Cuánto tiempo necesito para recuperar datos críticos?
- ¿Qué impacto tendría una corrupción de datos descubierta semanas después?
- ¿Qué productos justifican mayores costes de almacenamiento?
- ¿Dónde puedo optimizar costes sin asumir riesgos relevantes?
La conversación deja de ser tecnológica para convertirse en una cuestión de gobierno y gestión del riesgo empresarial.
Ejemplo 1: Producto financiero estratégico
Imaginemos un producto de datos que consolida ingresos, márgenes y rentabilidad global de la compañía. Este producto es consumido por:
- Comité de Dirección.
- Finanzas.
- Auditoría Interna.
- Planificación Estratégica.
Un error en los procesos ETL podría no detectarse inmediatamente. Tal vez alguien identifique una anomalía tres semanas después durante el cierre mensual. Si el warehouse solamente conserva 15 días de historial, la capacidad de investigar o recuperar versiones anteriores puede verse seriamente limitada.
En este escenario tendría sentido definir una clasificación:
Nivel A – Crítico Corporativo
Características:
- Impacto financiero.
- Uso ejecutivo.
- Decisiones estratégicas.
- Requisitos de auditoría.
Retención recomendada:
- 90 o incluso 120 días.
De esta forma se maximiza la capacidad de realizar análisis retrospectivos y recuperar estados históricos del dato.
Ejemplo 2: Customer 360 y casos de IA
Pensemos ahora en un producto Customer 360 utilizado por:
- Marketing.
- Ventas.
- IA Generativa.
- Sistemas de recomendación.
Aunque no sea estrictamente regulatorio, cualquier degradación de calidad puede afectar múltiples experiencias digitales. Además, estos productos suelen convertirse en contexto para copilots, agentes inteligentes o asistentes conversacionales. Si una clasificación errónea aparece en miles de registros de clientes y se detecta después de varias semanas, disponer de historial suficiente puede marcar la diferencia.
Aquí podría encajar una clasificación:
Nivel B – Importancia Alta
Retención recomendada:
- 60-90 días.
Suficiente para investigar incidencias y reconstruir estados previos sin asumir los costes máximos reservados a activos más críticos.
Ejemplo 3: Sandbox analítico
Ahora imaginemos un entorno exploratorio utilizado por científicos de datos para experimentar con nuevas hipótesis.
Características:
- Datos temporales.
- Alto volumen.
- Bajo riesgo empresarial.
- Sin decisiones críticas asociadas.
¿Tiene sentido conservar historial durante 120 días?. Probablemente no.
Una política más razonable podría ser:
Nivel D – Experimental
Retención recomendada:
- 1 a 7 días.
Con ello se minimiza el consumo de almacenamiento mientras se mantiene la capacidad necesaria para depuración y validación técnica.
Una visión que encaja perfectamente con el Data Product Thinking
Lo interesante es que esta capacidad puede convertirse en un atributo más dentro del catálogo corporativo.
Además de documentar:
- Owner.
- Dominio.
- SLA.
- Calidad.
- Sensibilidad.
- Clasificación regulatoria.
Podríamos incorporar:
- Nivel de criticidad.
- Período de recuperación esperado.
- Retention Period configurado.
- Coste asociado al historial retenido.
Esto genera una relación directa entre:
Caso de uso → Producto de datos → Riesgo → Política de retención
Una trazabilidad que pocas organizaciones tienen hoy completamente definida.
Una oportunidad para FinOps del dato
Otro aspecto especialmente interesante es la conexión con iniciativas FinOps. Microsoft indica que aumentar el período de retención incrementa el almacenamiento necesario para mantener versiones históricas, mientras que reducirlo disminuye los costes asociados. Por tanto, la organización puede tomar decisiones conscientes:
| Clasificación | Caso de uso | Retención (días) |
|---|---|---|
| Crítico Corporativo | Finanzas, Riesgo, Regulatorio Reporting, ESG, Compliance | 120 |
| Estratégico | Customer 360, Supply Chain, Revenue Management, Ventas | 60-90 |
| Operacional | Reporting departamental, KPIs funcionales, procesos operativos | 30 |
| Analítico | Data Science, laboratorios analíticos, modelos en desarrollo | 7-15 |
| Experimental | PoCs, sandboxes, pruebas y prototipoa | 1-7 |
Este enfoque permite optimizar costes sin aplicar políticas uniformes a todos los dominios.
El puente hacia las plataformas agénticas
Desde mi punto de vista, el verdadero valor aparece cuando combinamos esta capacidad con el concepto de Agentic Data Platform.
Un agente de gobierno podría:
- Identificar productos críticos.
- Evaluar patrones de uso.
- Revisar requisitos regulatorios.
- Recomendar automáticamente períodos de retención.
- Detectar configuraciones inconsistentes respecto al nivel de criticidad.
Imaginemos un agente que lanza una alerta indicando:
«Este producto está clasificado como Critical Business Product, es utilizado por procesos regulatorios y tiene una retención de solo 15 días. Se recomienda ampliarla a 90 días.«
Ese es precisamente el tipo de inteligencia operativa que diferencia una plataforma moderna de una plataforma verdaderamente agéntica.
Conclusión
La nueva capacidad de configuración de retención en Microsoft Fabric Data Warehouse no debería verse únicamente como una característica de almacenamiento.
Representa una oportunidad para conectar:
- Gobierno del dato.
- Gestión del riesgo.
- FinOps.
- Catálogo de productos de datos.
- Casos de uso empresariales.
En organizaciones orientadas a productos de datos, el retention period puede convertirse en un atributo estratégico más del producto, ayudando a equilibrar coste, resiliencia y valor de negocio.
Y probablemente ahí reside su mayor potencial: dejar de gestionar históricos de datos y empezar a gestionar activos de negocio con políticas de recuperación alineadas a su importancia real para la organización.
Fuentes
Microsoft Learn, Data Retention in Fabric Data Warehouse. [learn.microsoft.com]
Microsoft Learn, How to Configure Data Retention in Fabric Data Warehouse. [learn.microsoft.com]
Ambika Jagadish, Configurable Data Retention in Microsoft Fabric Warehouse (Preview), Microsoft Fabric Community Blog. [community….rosoft.com]
Foto de portada gracias a Dapur Melodi: https://www.pexels.com/es-es/foto/denso-trafico-urbano-en-el-paisaje-urbano-de-yakarta-32487423/
Alb3rto Alonso 