Unity Catalog y Gobernanza de Datos Empresariales para Plataformas Listas para IA

La gobernanza en la ingeniería de datos se trata a menudo como una actividad de cumplimiento normativo: algo que se aplica después de que la plataforma está construida para satisfacer los requisitos de auditoría. Este orden es incorrecto, particularmente para las plataformas destinadas a soportar cargas de trabajo de IA. Los sistemas de IA amplían los fallos de gobernanza: un modelo entrenado con datos con controles de acceso incorrectos puede filtrar información de identificación personal a través de los límites de las unidades de negocio; un pipeline de características sin seguimiento de linaje hace imposible identificar y remediar el impacto de un incidente de calidad de datos upstream.

El enfoque de gobernanza primero requiere herramientas que hagan del control de acceso, el linaje y la descubribilidad capacidades de plataforma de primera clase en lugar de reflexiones tardías. Unity Catalog proporciona esta base para el Lakehouse de Databricks, ofreciendo una única superficie de gobernanza en todos los tipos de espacios de trabajo: almacenes SQL, notebooks, pipelines de Delta Live Tables y tiempos de ejecución de ML.

Bajo el Artículo 25 del GDPR, los datos personales deben procesarse con controles de acceso apropiados y minimización de datos por defecto, no como un paso de remediación aplicado después de una brecha. Las capacidades de enmascaramiento a nivel de columna y filtros de filas de Unity Catalog proporcionan el mecanismo de aplicación técnica: los analistas e ingenieros de ML reciben solo los datos que están autorizados a procesar, independientemente de cómo construyan sus consultas. Para las organizaciones sujetas al Artículo 10 de la Ley de IA de la UE, que requiere documentación de la gobernanza de los datos de entrenamiento para los sistemas de IA de alto riesgo, el seguimiento de linaje de Unity Catalog puede proporcionar un registro auditable de dónde se originan los datos de entrenamiento y las transformaciones que se les aplican.

El linaje automatizado de Unity Catalog captura las dependencias tabla a tabla y columna a columna en ejecuciones de notebooks, consultas SQL, pipelines de Delta Live Tables y trabajos de Databricks. Este linaje se captura pasivamente —no requiere que los desarrolladores de pipelines anoten su código— lo que significa que se acumula con el tiempo a medida que ocurre la actividad normal de la plataforma en lugar de requerir un proyecto de instrumentación de linaje dedicado.

El linaje a nivel de columna es particularmente valioso para la gobernanza de IA. Cuando una característica utilizada en un modelo de producción se puede rastrear hasta una columna específica en una tabla Plata, y esa columna contiene datos de un sistema fuente que experimenta un incidente de calidad, Unity Catalog hace posible responder a la pregunta '¿qué modelos necesitan ser reentrenados?' en minutos en lugar de días.

La descubribilidad se proporciona a través de la búsqueda del espacio de trabajo de Databricks y la interfaz de usuario del explorador de catálogos, con la capacidad de agregar descripciones, etiquetas y metadatos de propietario a los activos. Para las organizaciones que requieren gobernanza que abarque múltiples plataformas —Unity Catalog para Databricks, Azure Purview para Azure SQL y Blob Storage, Collibra o Alation para el glosario empresarial y la administración de datos— el formato de linaje abierto de Unity Catalog permite que los eventos de linaje sean exportados y consumidos por herramientas de catálogo externas, habilitando una vista unificada del patrimonio de datos sin duplicar la carga de gestión de metadatos.

El espacio de nombres de tres niveles (catálogo → esquema → tabla) se mapea de forma natural a los patrones comunes de diseño de productos de datos. Un catálogo puede representar un dominio de datos (finanzas, operaciones, clientes), un esquema representa un producto de datos o área temática dentro de ese dominio, y las tablas representan los activos individuales expuestos por ese producto. Este mapeo convierte el espacio de nombres de Unity Catalog en una superficie natural para implementar los principios de propiedad del data mesh.

Las consultas entre catálogos son completamente compatibles, lo que significa que una tabla Oro en el catálogo de analítica puede unirse directamente con una tabla de referencia en el catálogo compartido sin requerir copias de datos ni proxies de vistas. Esto es una mejora significativa respecto al modelo anterior con ámbito de espacio de trabajo, donde el intercambio de datos entre espacios de trabajo requería una ubicación de almacenamiento externo compartida con permisos gestionados manualmente o Databricks Delta Sharing.

La proliferación de catálogos es un riesgo de gobernanza real: si cada equipo crea su propio catálogo sin coordinación, el espacio de nombres de tres niveles se fragmenta rápidamente tanto como el estado previo a Unity Catalog, solo con una apariencia más estructurada. Una restricción práctica es limitar la autoridad de creación de catálogos al equipo central de plataforma, mientras se concede a los equipos de dominio plena autonomía a nivel de esquema dentro de su catálogo asignado. Esta única decisión de política tiene un efecto desproporcionado en la coherencia de la gobernanza a largo plazo y vale la pena establecerla formalmente antes de que la plataforma llegue a más de un puñado de equipos de productos de datos.

En un entorno empresarial de múltiples equipos, la gobernanza de Unity Catalog es más efectiva cuando la configura y mantiene un equipo central de plataforma de datos en lugar de equipos individuales de productos de datos. Esto no significa el control central del contenido de datos —los equipos de productos de datos retienen la propiedad de sus esquemas y tablas— pero sí significa la gestión centralizada de catálogos, estructuras de permisos de nivel superior y configuración de registro de auditoría.

Un patrón de gobernanza práctico es la separación del catálogo de plataforma (que contiene conjuntos de datos de infraestructura compartida —calendarios de festivos, tipos de cambio, datos de referencia geográfica) de los catálogos de dominio (que contienen productos de datos propiedad de los equipos de dominio). El catálogo de plataforma es mantenido por el equipo central; los catálogos de dominio se conceden a los equipos de dominio con privilegios CREATE y USAGE a nivel de esquema. Esta separación previene el antipatrón de gobernanza de los equipos de dominio creando objetos en espacios de nombres compartidos.

Las tablas del sistema de Unity Catalog —disponibles bajo el esquema system.access— registran todos los eventos de acceso a datos, cambios de permisos e historiales de consultas en tablas Delta consultables. Las consultas SQL estándar contra estas tablas pueden producir la evidencia de auditoría que requieren la mayoría de los marcos de cumplimiento: qué principales accedieron a una tabla determinada en los últimos 30 días, qué cuentas de servicio tienen permisos que nunca se ejercieron, qué tablas no tienen propietario documentado. Ejecutar estas consultas de forma programada y enrutar las anomalías a un panel de gobernanza cuesta poco construirlo y puede detectar la deriva de permisos antes de que se convierta en un problema de cumplimiento.

¿Cómo interactúa el modelo de permisos de Unity Catalog con los clústeres de Databricks que se ejecutan en VNets gestionadas por el cliente, donde los controles de acceso a nivel de red pueden entrar en conflicto con los permisos a nivel de catálogo? ¿Cuál es el modelo operativo para rotar las credenciales de principales de servicio utilizadas por los pipelines automatizados cuando esos principales tienen permisos concedidos en docenas de catálogos y esquemas?

La pregunta del formato de tabla abierto tiene el mayor peso estratégico. Unity Catalog ahora admite tablas Apache Iceberg y Apache Hudi junto con Delta, posicionándolo como una posible capa de gobernanza entre formatos en lugar de una solución solo para Delta. Si esta ampliación se extiende eventualmente a los temas de Kafka, los artefactos de modelos de ML y los activos de BI —actualmente fuera del alcance de Unity Catalog— determinará si puede servir como la única superficie de gobernanza para un patrimonio de datos y IA completamente unificado, o si las organizaciones continuarán gestionando múltiples herramientas de gobernanza superpuestas en el futuro previsible.