Snowflake incorpora capacidades nativas de calidad de datos que resuelven casos de uso puntuales dentro de su plataforma, pero dejan expuestos los flancos más críticos para equipos de gobierno de datos: la cobertura cruzada entre fuentes, el data lineage end-to-end y la asignación formal de ownership sobre activos distribuidos. Para un CDO que opera en un entorno multicloud o híbrido, conocer exactamente dónde termina Snowflake y dónde empieza el problema de governance es la decisión que define la arquitectura del programa.
Qué hace bien Snowflake de forma nativa
La plataforma ofrece funciones integradas para definir métricas de calidad directamente sobre tablas y vistas mediante Data Metric Functions (DMFs), disponibles en el tier Enterprise. Estas permiten medir completitud, unicidad y freshness de forma programática, y programar ejecuciones periódicas sin necesidad de herramientas externas. Adicionalmente, el Data Quality Score de Snowflake consolida esas métricas en un indicador único por objeto, accesible desde Snowsight. Para organizaciones que tienen su data estate concentrado mayoritariamente dentro de Snowflake y cuentan con equipos de ingeniería capaces de escribir y mantener DMFs, esta capa es funcional y de bajo costo operativo.
El catálogo nativo —Snowflake Horizon— extiende estas capacidades con clasificación automática de datos sensibles, políticas de acceso basadas en etiquetas (tag-based masking) y una vista de linaje a nivel de columna dentro del ecosistema Snowflake. La integración con herramientas de la suite es directa, lo que reduce la fricción de implementación para equipos que trabajan dentro de ese perímetro.
El límite real: el data estate que vive fuera del perímetro
El problema aparece en cuanto el data estate trasciende Snowflake, algo que en la práctica ocurre en la mayoría de las organizaciones medianas y grandes de la región. Fuentes on-premises, data lakehouses en AWS S3 o Azure Data Lake, instancias de SAP, Oracle o sistemas legados que alimentan pipelines críticos quedan fuera del alcance de las DMFs y del linaje de Horizon. En esos escenarios, la calidad medida dentro de Snowflake es una foto parcial: no refleja si los datos llegaron correctos desde el origen, ni si la transformación en el pipeline introdujo degradación.
El DAMA-DMBOK v2 distingue entre calidad de datos como función operativa —medir y corregir— y governance de la calidad como función estratégica —definir estándares, asignar stewards, escalar issues y certificar activos para consumo. Las DMFs de Snowflake cubren la primera dimensión dentro del perímetro de la plataforma. La segunda requiere un programa con procesos, roles y herramientas que operen agnósticamente al stack tecnológico.
Lo que necesita el CDO para cerrar la brecha
La brecha de governance que dejan las herramientas nativas de Snowflake se cierra con tres decisiones concretas que un CDO debería tomar antes de extender el uso de la plataforma como hub analítico de la organización. Primero, mapear el data estate completo: identificar qué porcentaje de los datos críticos para el negocio —definidos por impacto regulatorio o por uso en decisiones de alto valor— reside efectivamente en Snowflake y qué porcentaje llega desde fuentes externas. Si ese segundo número supera el 30%, las métricas nativas son insuficientes como programa de calidad. Segundo, definir formalmente a los data stewards responsables de cada dominio de datos, independientemente de la plataforma donde residan. Según el Non-Invasive Data Governance de Bob Seiner, el steward no necesita un mandato formal para actuar, pero sí necesita visibilidad sobre los activos que ya administra informalmente. Las DMFs no asignan ownership: eso es una decisión de programa, no de herramienta. Tercero, evaluar si el catálogo activo cubre el linaje desde el origen hasta el consumo, incluyendo transformaciones fuera de Snowflake.
El contexto regulatorio LATAM no perdona datos de baja calidad
En América Latina, la presión regulatoria eleva el costo de una calidad de datos deficiente. Los bancos y fintechs en Brasil están obligados a reportar información de crédito al Banco Central bajo estándares del Sistema de Informações de Crédito (SCR), donde la exactitud y completitud de los datos tiene consecuencias directas en la supervisión prudencial. En Argentina, la Comunicación A 7724 del BCRA exige que las entidades financieras acrediten controles sobre la integridad de los datos utilizados en modelos de riesgo. En México, la CNBV ha alineado sus requerimientos de reportería con estándares de calidad que implican trazabilidad de origen. En todos estos casos, medir calidad solo dentro de Snowflake —sin cubrir el pipeline completo— no alcanza para acreditar cumplimiento ante el regulador.
Las organizaciones que operan en estos marcos y usan Snowflake como plataforma central de analítica deben asegurarse de que sus programas de data quality incluyan controles en la capa de ingesta, validación en el pipeline de transformación y certificación formal de los activos que alimentan reportería regulatoria. Herramientas de governance de terceros que se integran con Snowflake —y extienden cobertura a otras fuentes— son la respuesta técnica habitual para cerrar esa brecha.
Qué hacer el lunes
Si tu organización usa Snowflake como plataforma principal, el primer paso es auditar cuántas DMFs están activas hoy y sobre qué porcentaje del inventario total de tablas críticas. Ese número revela inmediatamente la cobertura real del programa de calidad. Después, revisá el catálogo de datos activo —sea Snowflake Horizon, Collibra, Alation u otro— y verificá si el linaje de al menos los diez activos más sensibles llega hasta la fuente de origen. Si la respuesta es no en ambos casos, tenés dos brechas documentables para justificar inversión en governance ante el CFO o el directorio.
Snowflake es una plataforma poderosa, pero un programa de calidad de datos no puede tener el mismo perímetro que una licencia de software.
Deja un comentario