Un data lake se convierte en data swamp cuando acumula información sin catálogo, dueño, controles de calidad, linaje, permisos ni ciclo de vida. Para evitarlo se requieren seis controles operativos: ownership, metadatos, calidad por capas, trazabilidad, seguridad y gestión económica. El objetivo no es almacenar más datos, sino mantener datos confiables, encontrables y utilizables para analítica e IA.
Definiciones taxonómicas
1. Data lake
Repositorio diseñado para almacenar grandes volúmenes de información estructurada, semiestructurada y no estructurada, normalmente conservando datos en formatos cercanos a su estado original. Su flexibilidad permite integrar múltiples fuentes para analítica, ciencia de datos e inteligencia artificial.
2. Data swamp
Es un data lake que perdió gobernabilidad: los usuarios ya no saben con certeza qué contiene, de dónde viene cada dato, cuál versión es válida, quién es responsable o si puede utilizarse. Google Cloud identifica explícitamente este riesgo cuando los datos cargados en un lake no están correctamente catalogados, administrados y gobernados.
3. Data lineage
Registro de dónde nace un dato, cómo se transforma, por qué sistemas pasa y dónde termina siendo utilizado. Microsoft señala que el linaje permite apoyar análisis de calidad, cumplimiento, diagnóstico de fallas e impacto de cambios.
Tabla comparativa
| Variable | Data lake gobernado | Data swamp | Impacto de negocio |
| Descubrimiento | Los datasets están catalogados y son buscables | Los datos existen, pero nadie sabe dónde | Horas de analistas e ingenieros perdidas buscando información |
| Ownership | Cada activo tiene responsable | Los datasets quedan “huérfanos” | Problemas sin dueño y mayor tiempo de resolución |
| Calidad | Reglas automáticas antes del consumo | La calidad se descubre en el reporte | Retrabajo, decisiones erróneas y menor confianza |
| Linaje | Se conoce fuente, transformación y consumidor | El origen de una cifra requiere investigación manual | Auditorías lentas y cambios de mayor riesgo |
| Seguridad | Clasificación y mínimo privilegio | Permisos heredados y acceso excesivo | Exposición de información y riesgo regulatorio |
| Ciclo de vida | Retención, archivo y eliminación definidos | Todo se conserva “por si algún día sirve” | Crecimiento continuo de almacenamiento y superficie de riesgo |
| Economía | Se mide costo por producto/caso de uso | Sólo se conoce la factura total de plataforma | ROI difícil de defender ante Finanzas |
| Consumo | Hay datasets certificados para negocio | Cada área crea su propia versión | Distintas cifras para la misma pregunta |
Cuerpo técnico
¿Qué convierte a un data lake en un data swamp?
El problema rara vez comienza con la tecnología. Comienza con una premisa aparentemente inocente:
“Guardemos todo ahora; después veremos para qué sirve.”
Al inicio funciona. El almacenamiento es relativamente económico y sumar una nueva fuente parece sencillo. El problema aparece cuando el número de sistemas, tablas, archivos, usuarios y transformaciones aumenta.
Entonces empiezan las preguntas incómodas:
- ¿Cuál de estas cinco tablas de clientes es la correcta?
- ¿Quién es responsable de actualizar este dataset?
- ¿Esta cifra viene del ERP o fue modificada después?
- ¿Qué significa exactamente este campo?
- ¿Cuándo fue actualizado por última vez?
- ¿Contiene información personal?
- ¿Qué dashboards dejarían de funcionar si cambiamos la estructura?
- ¿Por qué seguimos pagando almacenamiento y procesamiento por datos que nadie consulta?
Ese es el punto en que el data lake deja de reducir fricción y comienza a generarla.
En MaIA by Scanda abordamos ese problema dentro de Data Intelligence: no tratamos el repositorio de datos como un proyecto aislado de almacenamiento, sino como una capacidad que debe integrar MDM, gobierno, calidad, múltiples fuentes y analítica para producir decisiones confiables.
Google Cloud resume bien la causa técnica: cargar información sin catalogarla, administrarla y gobernarla puede transformar un data lake en un data swamp donde los datos resultan difíciles de encontrar, confiar y utilizar.
La diferencia, por tanto, no está en cuántos terabytes caben. Está en cuánto del dato almacenado puede convertirse en una decisión confiable.
Control 1: ningún dato entra sin dueño, propósito y contrato
La primera defensa contra el data swamp ocurre antes de almacenar el dato.
Cada nueva fuente debería ingresar mediante un contrato mínimo de incorporación que identifique:
- dueño de negocio;
- dueño técnico;
- sistema de origen;
- propósito de negocio;
- dominio al que pertenece;
- estructura o esquema esperado;
- frecuencia de actualización;
- nivel de sensibilidad;
- consumidores previstos;
- política de retención;
- reglas mínimas de calidad;
- SLA o expectativa de disponibilidad.
La regla operativa
Dato sin propietario no es un activo: es deuda futura.
Un archivo puede existir físicamente durante años sin que nadie quiera asumir responsabilidad por su semántica, actualización o calidad. Cuando eso ocurre, cada nuevo proyecto debe volver a investigar el dato desde cero.
Impacto financiero
Sin ownership, el costo aparece en forma de:
- horas de ingeniería para entender datasets existentes;
- pipelines duplicados;
- conciliaciones manuales;
- retrasos en proyectos de BI e IA;
- retrabajo de modelos;
- decisiones construidas sobre fuentes distintas.
Ese gasto rara vez aparece como una línea llamada “data swamp”. Aparece repartido entre nómina, consultoría, cloud y proyectos retrasados. Por eso termina afectando el ROI de datos e IA y, eventualmente, el EBITDA.
Control 2: catálogo y metadatos desde la ingesta
Guardar un archivo no equivale a saber que existe.
Un data lake gobernado necesita un catálogo que describa sus activos de información. Como mínimo, cada dataset productivo debería incorporar:
- nombre comprensible;
- descripción de negocio;
- propietario;
- sistema fuente;
- dominio;
- esquema;
- fecha de última actualización;
- sensibilidad;
- política de acceso;
- frecuencia esperada;
- consumidores;
- relaciones con otros datasets;
- linaje.
AWS utiliza precisamente el catálogo como pieza central para almacenar y administrar metadatos de un data lake y vincularlos con los controles de acceso.
El catálogo debe ser operativo, no documental
Un error frecuente es construir un catálogo como proyecto independiente y pedir después a los equipos que lo mantengan manualmente.
Eso envejece rápido.
La alternativa es capturar metadatos durante la propia ingesta y transformación. Cuando aparece un dataset nuevo, también deben aparecer automáticamente su esquema, ubicación, fecha, origen y relaciones técnicas.
Después se añade la capa humana: significado de negocio, propietario y reglas de uso.
Indicador que recomendamos vigilar
En nuestro modelo de diagnóstico también observamos el número de versiones de una misma cifra, el porcentaje de fuentes integradas y el tiempo que tarda un dato en convertirse en decisión. Son señales muy directas de si la arquitectura está reduciendo o aumentando fricción.
Si Finanzas, Comercial y Operaciones presentan tres valores distintos de “ventas netas”, el problema no es el dashboard. El problema está más abajo.
Control 3: calidad de datos por capas, no al final
La calidad no debería validarse cuando el CFO abre el reporte.
Debe verificarse mientras el dato avanza por la arquitectura.
Una práctica ampliamente utilizada es separar las capas según su grado de preparación:
Bronze: conservar el dato original
La capa Bronze recibe información prácticamente como llega desde la fuente.
Debe servir para:
- preservar historia;
- permitir reprocesamiento;
- mantener evidencia del dato original;
- auditar cambios posteriores.
No debería ser la fuente oficial de indicadores de negocio.
Silver: limpiar, validar y estandarizar
Aquí deben ocurrir controles como:
- validación de esquema;
- tratamiento de valores nulos;
- deduplicación;
- normalización;
- estandarización de unidades;
- reglas referenciales;
- resolución de registros tardíos;
- cuarentena de registros inválidos.
Databricks recomienda precisamente una arquitectura en la que el dato evoluciona de Bronze —raw— a Silver —validado— y Gold —listo para negocio—, incrementando progresivamente su calidad y confiabilidad.
Gold: publicar productos confiables de negocio
Aquí deberían existir los datos preparados para:
- dashboards ejecutivos;
- indicadores financieros;
- modelos analíticos;
- aplicaciones;
- casos de IA;
- decisiones operativas.
La regla es sencilla:
Raw no significa malo; significa no certificado para consumo de negocio.
El error ocurre cuando una organización permite que cualquier aplicación o usuario consulte cualquier capa sin distinguir entre dato recibido, validado y certificado.
Control 4: linaje y observabilidad de extremo a extremo
Si cambia un campo del ERP, el equipo de datos debería saber antes de hacerlo:
- qué pipelines dependen de él;
- qué tablas cambiarán;
- qué indicadores lo consumen;
- qué modelos de IA utilizan esa información;
- qué reportes ejecutivos podrían verse afectados.
Eso requiere linaje.
Microsoft describe el linaje como el ciclo que permite seguir el dato desde su origen y comprender cómo se mueve y transforma, utilizándolo para análisis de causa raíz, calidad, cumplimiento e impacto.
Pero el linaje por sí solo no basta
También hay que observar el comportamiento del dato.
Un control serio debería vigilar:
- última actualización;
- retraso contra la frecuencia esperada;
- volumen recibido;
- cambios de esquema;
- porcentaje de registros rechazados;
- duplicados;
- valores fuera de rango;
- fallas de pipelines;
- degradación de calidad;
- datasets sin consumo.
Ejemplo
Supongamos que el promedio histórico de ventas diarias es de 150,000 registros.
De pronto llegan 18,000.
El pipeline técnicamente puede haber terminado con estado “success”.
Desde infraestructura, todo funcionó.
Desde negocio, probablemente no.
La observabilidad de datos debe detectar esa diferencia. Un proceso exitoso no garantiza un dato confiable.
Control 5: clasificación y acceso con mínimo privilegio
Un data swamp no sólo genera problemas analíticos. También amplía la superficie de exposición.
La organización necesita conocer:
- qué datos son públicos;
- cuáles son internos;
- cuáles son confidenciales;
- cuáles contienen información personal;
- qué información requiere protección adicional;
- quién puede consultar cada categoría;
- quién puede modificarla;
- quién puede exportarla.
AWS Lake Formation, por ejemplo, permite separar permisos sobre metadatos y sobre el dato subyacente, además de aplicar acceso granular a bases, tablas, columnas, filas y celdas.
El error de permisos heredados
El patrón peligroso es:
“Dale acceso al bucket completo porque necesita una tabla.”
Con el tiempo, aparecen decenas de excepciones, cuentas privilegiadas y permisos cuyo motivo original nadie recuerda.
El control correcto es:
- mínimo privilegio;
- accesos basados en rol o atributos;
- clasificación de sensibilidad;
- revisiones periódicas;
- trazabilidad de accesos;
- revocación automática cuando desaparece la necesidad.
En nuestro marco, preparar información para IA incluye precisamente inventariar información sensible, corregir permisos heredados, revisar privilegios y mapear fuentes antes de habilitar nuevos casos de uso.
Impacto financiero
La mala clasificación aumenta:
- riesgo regulatorio;
- costo de auditoría;
- costo de investigación ante incidentes;
- alcance potencial de una filtración;
- tiempo requerido para desplegar nuevos casos de IA.
Cuando Seguridad no confía en el repositorio, cada iniciativa tarda más en aprobarse. Ese retraso también tiene costo.
Control 6: ciclo de vida y economía del dato
“Almacenar es barato” puede ser una pésima política de gobierno.
El problema no es sólo cuánto cuesta guardar un terabyte. También hay que pagar por:
- copias;
- respaldos;
- procesamiento;
- consultas;
- movimiento;
- catalogación;
- protección;
- auditoría;
- mantenimiento;
- ingeniería.
Por eso cada categoría de información necesita una política de ciclo de vida.
Definir desde el inicio
- cuánto tiempo permanece activa;
- cuándo pasa a almacenamiento de menor costo;
- cuánto tiempo debe conservarse;
- cuándo se elimina;
- qué regulación obliga a retenerla;
- qué evento permite destruirla;
- quién autoriza excepciones.
AWS S3 permite automatizar transiciones a clases de almacenamiento de menor costo y eliminar objetos expirados mediante políticas de ciclo de vida. Microsoft también recomienda alinear niveles de almacenamiento y políticas de retención con los patrones reales de acceso para controlar el costo.
No medir solamente almacenamiento
El KPI más útil no es:
“Tenemos 300 TB.”
Es preguntar:
- ¿cuánto cuesta mantener cada producto de datos?
- ¿cuánto cuesta procesarlo cada mes?
- ¿cuántos consumidores activos tiene?
- ¿cuándo se consultó por última vez?
- ¿qué resultado soporta?
- ¿cuántas copias existen?
- ¿qué parte puede archivarse o retirarse?
Un dataset que nadie usa pero que se procesa todas las noches es un pequeño cargo recurrente. Miles de ellos ya son una decisión financiera.
Cómo medir si el data lake sigue bajo control
En MaIA by Scanda consideramos que un buen gobierno debe poder medirse. Nuestro modelo de Data Intelligence está orientado a convertir datos gobernados en decisiones confiables, integrando calidad, gobierno, MDM y fuentes múltiples.
Un tablero ejecutivo del data lake debería concentrarse en indicadores como:
| KPI | Qué revela |
| % de datasets productivos con owner | Si existe responsabilidad real |
| % de activos con metadatos obligatorios completos | Si el catálogo puede utilizarse |
| % de fuentes críticas con linaje | Si pueden hacerse análisis de impacto |
| Tasa de cumplimiento de reglas de calidad | Si los datos llegan confiables |
| Freshness contra SLA | Si llegan cuando todavía sirven |
| Número de versiones de la misma métrica | Si existe una fuente de verdad |
| % de datasets sin consumo | Cuánta deuda de datos existe |
| Costo por producto de datos | Si la arquitectura escala económicamente |
| Tiempo dato → decisión | Si el dato realmente mejora velocidad de negocio |
| % de información sensible clasificada | Si el riesgo está bajo control |
AWS recomienda establecer umbrales de calidad, evaluarlos continuamente, integrar alertas y hacer visibles las métricas de calidad para los consumidores de cada activo.
La señal más peligrosa no es una métrica mala.
Es no tener la métrica.
Conclusión predictiva
El data swamp será un problema mayor con la adopción de IA generativa y agentes corporativos.
Antes, un dato mal documentado podía quedar enterrado durante años en una carpeta. Ahora, los sistemas de IA pueden encontrar, resumir, combinar y utilizar información a una velocidad mucho mayor.
Eso cambia el riesgo.
Un dato incorrecto puede alimentar un modelo. Un permiso excesivo puede exponer información. Una definición contradictoria puede llegar a un agente que posteriormente ejecute una acción.
Por eso el gobierno del data lake está dejando de ser una disciplina de almacenamiento para convertirse en infraestructura de confianza para la IA. Google Cloud, de hecho, ya plantea sus capacidades de catálogo alrededor de metadata, calidad, linaje y contexto empresarial para aplicaciones analíticas y agentes de IA.
En MaIA by Scanda trabajamos bajo una premisa: no tiene sentido acelerar IA sobre un fundamento de datos que nadie puede explicar. Nuestro CoE contempla una plataforma de datos gobernada, calidad, seguridad y gobierno como capacidades transversales; no como actividades que se agregan al final del proyecto.
La pregunta para un CIO ya no debería ser:
“¿Cuánto almacenamiento tenemos disponible?”
La pregunta correcta es:
“¿Qué porcentaje de nuestros datos puede ser encontrado, entendido, confiado, auditado y utilizado hoy sin intervención manual?”
Ese porcentaje será cada vez más cercano al porcentaje de datos que realmente pueden generar retorno.
CTA final de MaIA
Tus datos no necesitan otro repositorio. Necesitan control.
Si tus equipos todavía concilian cifras manualmente, desconocen qué fuentes son oficiales o tienen proyectos de IA detenidos por problemas de calidad, el siguiente paso no es incorporar más tecnología.
En MaIA by Scanda podemos evaluar la arquitectura, calidad, catálogo, gobierno y flujo de tus datos para identificar qué está frenando su uso en analítica e inteligencia artificial.
Convirtamos tu data lake en una plataforma de datos confiable para decisiones e IA, antes de que seguir acumulando información aumente el costo del problema.
Agenda una sesión de Data Intelligence con MaIA by Scanda.
FAQ
1. ¿Cómo sé si mi data lake ya se convirtió en un data swamp?
Hay cinco señales especialmente claras: existen múltiples versiones de la misma información, los usuarios no saben qué dataset utilizar, faltan propietarios, los análisis requieren conciliación manual y nadie puede explicar fácilmente el origen de una cifra.
Una prueba práctica consiste en pedir al equipo que encuentre el dataset oficial de clientes, identifique su owner, explique su origen y muestre su última actualización. Si requiere varias llamadas y mensajes para responder, el problema ya existe.
2. ¿Necesito reemplazar mi data lake para corregir un data swamp?
No necesariamente.
En muchos casos el problema no es la plataforma sino la falta de controles. Puede corregirse incorporando catálogo, linaje, ownership, clasificación, reglas de calidad, arquitectura por capas y lifecycle management sobre la infraestructura existente.
En MaIA by Scanda preferimos diagnosticar primero el fundamento. Cambiar de plataforma sin corregir las prácticas de gobierno suele trasladar el mismo problema a una infraestructura nueva.
3. ¿Cómo se justifica financieramente invertir en gobierno de datos?
El business case debe construirse contra costos observables:
- horas empleadas conciliando información;
- duplicación de pipelines;
- reportes retrasados;
- infraestructura sin consumo;
- fallas producidas por calidad;
- proyectos de IA detenidos por datos;
- tiempo dedicado a auditorías;
- riesgo asociado a información sensible;
- decisiones tomadas con cifras inconsistentes.
La discusión con Finanzas no debería ser “cuánto cuesta gobernar los datos”, sino cuánto cuesta hoy no poder confiar en ellos.
Español 
English