Gobernanza más allá de la seguridad: conocimiento, contexto y ontología en el lakehouse

Si pregunta a la mayoría de las organizaciones qué significa el gobierno de datos para la AI, escuchará una respuesta relacionada con la seguridad: bloquearlos, restringir el acceso, pasar la auditoría. En el sector de la salud, la seguridad no es negociable, pero es incompleta. La seguridad le dice quién puede tocar los datos. No dice nada sobre lo que los datos significan, si se puede confiar en ellos o si un modelo de AI debería alguna vez aprender de ellos.

Nuestro Data Empowerment Program (DEP) parte de una premisa diferente: el gobierno es conocimiento, contexto y ontología; no solo controles. Los artefactos que la mayoría de los equipos consideran como una carga de cumplimiento, como las etiquetas de clasificación, las políticas de desidentificación, las tarjetas de modelo y los contratos de datos, son materia prima para la semántica de datos empresariales.

Visto de esta manera, no se trata de elegir entre gobierno y AI, sino que el gobierno ayuda a construir la AI. En la era de la AI, es necesario implementar nuevos enfoques de gobierno. La única pregunta es si hará el trabajo más tarde solo para pasar la auditoría, o ahora, para sentar las bases sobre las que se ejecuta su AI.

Nuestro objetivo es demostrar que el trabajo de seguridad y gobierno que ya realiza es la base sobre la que se ejecuta su AI. Gobierne los datos lo suficientemente bien y la AI podrá ejecutarse en modelos más económicos con mayor confianza.

El gobierno debe pensar de manera más amplia a través de cinco pilares bajo una misma perspectiva

Comience con la perspectiva de que cada artefacto de gobierno contribuye a la semántica. Cada etiqueta de clasificación es un concepto. Cada tarjeta de modelo es contexto. Cada contrato de datos es una definición compartida. Cada enlace de linaje es una relación. Leído de esa manera, la pila de seguridad que ya ejecuta es el primer borrador de su ontología, y el catálogo es donde reside.

El gobierno deja entonces de ser una sola cosa y se convierte en cinco facetas de una única disciplina: los datos en sí y cómo se controlan, la AI construida sobre ellos, las personas que necesitan entenderlos, los productos que los llevan al negocio y el contexto compartido que une a los cuatro. Es la misma perspectiva, pero desde cinco frentes.

Con el DEP, visualizamos la semántica a través de cinco pilares:

• Gobierno de datos — Catálogo, calidad, curación, linaje y con seguridad y cumplimiento integrados, como clasificación de PII, control de acceso, HIPAA/GDPR y riesgos de privacidad específicos de la AI.
• Gobierno del conocimiento (AI/ML) — Documentación de modelos, gobierno y estándares de AI responsable, como sesgo y equidad, explicabilidad, supervisión humana y preparación para la Ley de AI de la UE.
• Alfabetización de datos — Capacitación, habilitación de autoservicio, certificación de profesionales y KPIs como tasas de adopción, métricas de uso y ROI del programa.
• Gestión de datos — La arquitectura, la ingeniería de datos y los contratos de productos de datos deben incluir acuerdos de esquema, SLAs y umbrales de calidad, y obligaciones del productor/consumidor.
• Ontología — Glosario, taxonomía, grafo de conocimiento; culmina en una capa semántica de AI. Esto incluye contexto para LLMs, fundamentación de RAG y preparación para consultas por chat.

Operacionalizar la visión a través de agentes

Nuestra visión de cinco pilares se queda solo en una presentación a menos que la plataforma pueda llevarla a la práctica de forma operativa. Una vez que sus artefactos de gobierno residen como metadatos estructurados y legibles por máquina, dejan de ser solo documentación y comienzan a ser conjuntos de instrucciones para los agentes.

Cuando nos referimos a "agente", lo pensamos de dos maneras: "agentes de construcción" que ensamblan y entregan productos de datos, y "agentes analíticos" que responden preguntas de negocio sobre ellos; cada uno vinculado a un único producto de datos.

Comencemos con los agentes de construcción. Los agentes de construcción automatizan el ciclo de vida de entrega de los productos de datos, desde el mapeo de origen a través de ETL, pruebas y desidentificación hasta el lanzamiento a producción. Todo lo que necesitan reside en Unity Catalog como metadatos gobernados: mapeos de origen a destino, definiciones de negocio, niveles de clasificación, políticas de desidentificación, contratos de datos y tarjetas de modelo. La plataforma se deriva de etiquetas, comentarios, marcas de certificación, linaje y términos vinculados al glosario. El catálogo no es solo donde se documenta el gobierno; es el entorno de ejecución en el que operan los agentes.

Cada agente trabaja en un bucle. Lee instrucciones del catálogo; realiza una tarea concreta, como generar código de pipeline, ejecutar un conjunto de pruebas, producir datos desidentificados o implementar un conjunto de datos certificado; y luego escribe la evidencia de vuelta como resultados de pruebas, puntuaciones de calidad, linaje o datos de captura de cambios. Esto se repite.

En la práctica, secuenciamos primero los agentes de De-ID y de pruebas. Eliminan los mayores riesgos y el trabajo manual más pesado desde el principio. Comenzar donde el retorno es más rápido ayuda a generar impulso temprano. A medida que avanzamos en el bucle, ningún agente actúa sobre datos que el catálogo no describa.

Los catálogos modernos hacen que este enfoque sea escalable porque pueden generar automáticamente descripciones de columnas y tablas para que un administrador las apruebe, clasificar campos sensibles de forma automática y capturar el linaje a nivel de columna sin que nadie tenga que mantenerlo manualmente. El rol humano pasa de la creación de metadatos a su aprobación, que es exactamente el tipo de trabajo de juicio que los humanos deberían realizar.

El ciclo de vida de construcción de datos y AI: prueba y contexto continuo

Los agentes de construcción operan dentro de un ciclo de vida de extremo a extremo diseñado para lanzar dos activos simultáneamente: el producto de datos gobernado (mapeo, curación, pipeline) y el agente analítico que se ejecuta sobre él (capa semántica, configuraciones de prompts, conjuntos de evaluación).

Este enfoque marca un cambio fundamental de la ingeniería centrada en pipelines (mover datos del punto A al B) a la ingeniería centrada en el contexto (hacer que los datos sean comprensibles y accionables para los LLMs). En lugar de certificar únicamente la calidad del código, las puertas de este ciclo de vida validan la semántica, el contexto y la propiedad.

Dos propiedades principales distinguen a este marco de un SDLC tradicional:

• Se autodemuestra: la prueba de confiabilidad es un subproducto natural de la entrega, en lugar de un simulacro de auditoría de emergencia preparado a posteriori.
• Mejora continuamente el contexto: el comportamiento en producción alimenta un bucle de AgentOps, transformando consultas fallidas, grupos de alucinaciones y votos negativos de los usuarios en el backlog semántico del próximo sprint.

Los administradores humanos sirven como la capa de responsabilidad para ambas propiedades: los agentes proponen, las personas aprueban. Aunque gestionar cinco puertas a lo largo de dos vías pueda parecer que crea cuellos de botella prolongados, la mayoría de las puertas se pueden superar en cuestión de horas. Las aprobaciones se realizan directamente dentro de las herramientas estándar de los desarrolladores. Los conjuntos de pruebas automatizados adjuntan resultados de calidad de datos, puntuaciones de evaluación y linaje antes de que se abra un ticket. Una reunión formal de puerta es una excepción a investigar, no el procedimiento operativo estándar.

La certificación de AI es el motor detrás de las puertas

El mecanismo que hace que estas puertas sean objetivas en lugar de arbitrarias es la certificación de AI. Registrada directamente en Unity Catalog, esta certificación actúa como una tarjeta de puntuación automatizada y consultable, en lugar de una atestación legal manual. Gobierna la elegibilidad de lanzamiento a través de cuatro dimensiones principales:

• Puntuación automatizada frente a humana: las puntuaciones de gobierno, calidad y semántica se calculan automáticamente a partir de tablas del sistema consultables, resultados de pipelines y ejecuciones de evaluación. La puntuación de propiedad y el sello final de implementación requieren la firma explícita de un administrador.
• Expiración continua: la certificación es dinámica. Un cambio de esquema, una actualización de contrato o un conjunto de evaluaciones fallido revocan instantáneamente la certificación hasta que las comprobaciones se vuelvan a ejecutar y se aprueben.
• Aplicación en la capa de datos: los controles de acceso operan a través de Attribute-Based Access Control (ABAC) en la capa de datos, no en la capa de aplicación. Si un usuario no puede consultar una fila en SQL, ningún agente puede recuperarla mediante búsqueda vectorial o embeddings.
• Aislamiento estricto de límites: los entornos que no son de producción (SIT, regresión, pruebas de modelos) consumen exclusivamente datos sintéticos o desidentificados. Esto garantiza que la PHI de producción nunca salga del límite gobernado.

Cuando el agente se equivoca, ¿quién lo soluciona?

La certificación y los controles demuestran que un agente era confiable al momento de su lanzamiento. Pero la pregunta que se hacen los líderes de gobernanza no es "cómo funciona", sino "¿quién es el responsable cuando da una respuesta incorrecta?" La respuesta debe ser un nombre específico, no un comité de dirección.

Para solucionar esto, cada agente analítico (por ejemplo, un Databricks Genie Agent) se vincula a un único producto de datos gobernado con un propietario designado. Cuando un agente devuelve un resultado incorrecto porque una métrica subyacente se definió de forma errónea, el problema no pertenece al equipo de ingeniería de AI. En su lugar, va directamente al Propietario del Producto de Datos (Data Product Owner), quien corrige la definición del catálogo. Vincular un agente a un producto de datos certificado y acotado a un dominio es también la mayor palanca de precisión disponible: un agente enfocado que consulta metadatos certificados supera sistemáticamente a un modelo global que intenta adivinar en todo el patrimonio empresarial.

Fundamentalmente, esta definición de métrica compartida se aplica de forma obligatoria en lugar de simplemente documentarse. Una vez que se define una métrica certificada en el catálogo, el agente de respuestas debe realizar los cálculos directamente a partir de ella. Esto convierte la documentación estática en lógica de ejecución activa.

La responsabilidad se mantiene gracias a un límite estricto sobre lo que la AI puede hacer sin supervisión: ningún agente pasa código a producción, modifica políticas ni opera con datos no clasificados sin intervención humana. Aunque las puntuaciones de certificación se calculan automáticamente, el control de validación final siempre requiere una firma humana. Si el catálogo no describe explícitamente un activo de datos, el sistema opta por la supresión de forma predeterminada en lugar de adivinar. En el tiempo de ejecución, esta política de fallo seguro (fail-closed) impone límites claros:

• Para agentes analíticos: En lugar de especular o inferir el contexto a partir de datos brutos, el agente se niega explícitamente a responder, devolviendo un mensaje transparente (por ejemplo, "Este conjunto de datos carece de la certificación activa o del mapeo semántico necesarios para procesar su solicitud").
• Para agentes de compilación: Si se detecta un esquema no clasificado o la falta de un contrato durante el ensamblaje de la canalización (pipeline), la ejecución se detiene automáticamente antes de llegar a los entornos de pruebas (staging), registrando una alerta de activo no mapeado para la revisión del supervisor (steward).

Definir estas directrices (guardrails) sobre el papel es fácil, pero hacer que funcionen en la práctica requiere sustituir los comités de gobernanza imprecisos por cuatro roles distintos y responsables:

• Data Product Owner: Responsable de las definiciones y la calidad de un producto gobernado. Es el único punto de contacto cuando una respuesta es incorrecta.
• Ingeniero de Gobernanza de Datos y AI: Traduce las políticas en metadatos de catálogo ejecutables (clasificaciones, contratos, linaje) para que las reglas se apliquen en tiempo de ejecución en lugar de quedarse en un PDF.
• Steward: Revisa los hallazgos automatizados y aprueba los controles de validación de lanzamiento. La automatización propone; el supervisor (steward) decide.
• Seguridad / IAM: Propietario de los niveles de clasificación y los atributos de acceso que impulsan automáticamente la desidentificación y los permisos a nivel de fila.

Pruebe rigurosamente sin comprometer la seguridad

El ciclo de vida que describimos oculta un requisito indispensable: cada una de esas etapas de prueba y evaluación necesita datos realistas con los que ejecutarse y, en el sector salud, no se pueden probar datos reales de PHI. Por lo tanto, el desafío radica en la necesidad de contar con datos de prueba realistas en todas partes sin comprometer la seguridad.

La desidentificación es la forma en que mantenemos los datos seguros y útiles para el análisis. ¿De dónde obtiene su conocimiento el agente de desidentificación? No de una hoja de cálculo mantenida manualmente. Funciona a partir de las políticas de seguridad que las herramientas empresariales ya generan. El flujo consta de tres pasos:

• Descubrir - Los escáneres de descubrimiento automatizados y los motores de políticas de InfoSec clasifican las columnas y los archivos confidenciales.
• Curar - Las clasificaciones llegan al catálogo como metadatos de políticas curados; el agente lee esa curación y la ejecuta.
• Ejecutar - Ingiere metadatos y produce datos sintéticos o archivos de origen desidentificados. Cumple con el estándar Safe Harbor de HIPAA, mantiene la integridad referencial y es apto para el análisis.

Para el equipo de seguridad e IAM, esta es una calle de doble sentido. Las políticas de InfoSec dejan de ser PDFs y se vuelven ejecutables: los niveles de clasificación y las reglas de retención impulsan la desidentificación de forma automática. A cambio, el equipo de seguridad obtiene una vista continuamente actualizada de los datos confidenciales, protección de fallo seguro para cualquier elemento recién descubierto y escaneos residuales que generan pruebas de auditoría en cada ejecución. El modelo de acceso sigue siendo el mismo de principio a fin. Dado que cualquier recuperación de datos por parte del agente hereda los permisos de catálogo del usuario que realiza la consulta, los enfoques de RAG no pueden mostrar un embedding de una fila que el usuario no tenga derecho a ver. Las mismas reglas de ABAC abarcan tanto SQL como la búsqueda vectorial, y los agentes actúan con los permisos del usuario que realiza la consulta, no con una cuenta de servicio privilegiada. Cada prompt del agente se registra con el linaje utilizado para responderlo, bajo la misma gobernanza que los propios datos.

Ese es el verdadero avance: un único modelo de permisos para los datos, los modelos, los embeddings y la pista de auditoría, en lugar de un catálogo de datos conectado a un registro de modelos independiente, conectado a su vez a un almacén de vectores independiente. El trabajo de gobernanza se convierte en la base de la AI en lugar de ser un proyecto paralelo.

Capture métricas, demuestre resultados y gane confianza

Observe lo que ha estado haciendo el ciclo de vida todo este tiempo: cada etapa, cada control de validación y cada certificación ha estado produciendo métricas. Agrupe las cuatro dimensiones de certificación en una única puntuación de preparación para AI por conjunto de datos, y haga que sea operativa, no aspiracional. La semántica alcanza el 100% solo cuando cada columna incluye una definición vinculada al glosario y la tabla tiene un contrato de datos firmado; la propiedad (Ownership) alcanza el 100% solo cuando un propietario designado responde a los problemas.

El resultado que sigue a la puntuación es el caso de negocio para todo el programa DEP: las métricas demuestran los resultados de la AI, las pruebas ganan confianza y la confianza es lo que convierte un piloto en uso diario. Ningún usuario de negocio adopta un agente porque el diagrama de arquitectura sea elegante. Lo adoptan porque los números fueron correctos la semana pasada y alguien responsable los corrigió cuando no lo fueron. La puntuación explica por qué los números salen bien en primer lugar: cuanto mayor sea la puntuación, menos tendrá que adivinar el modelo. No está infiriendo el significado de una columna, compensando duplicados ni alucinando uniones (joins), porque el catálogo ya se lo ha indicado.

No persiga los titulares sobre modelos. Persiga la rentabilidad de los modelos.

Cada semana trae un modelo más grande y costoso. Esto es lo que pasa por alto el ciclo de expectativas (hype cycle): cuando el catálogo ya proporciona el significado, la calidad y el contexto, el modelo no tiene que hacerlo. Los modelos más pequeños o de pesos abiertos (open-weights) cubren la mayoría de las necesidades de informes y análisis sobre datos gobernados.

Los modelos de frontera (frontier models) se utilizan a menudo para enmascarar brechas de metadatos subyacentes. Cuando los esquemas y las reglas de negocio están catalogados explícitamente, los modelos más pequeños específicos de un dominio ofrecen una precisión idéntica a una fracción del costo de los tokens.

Esta es una elección de costo-calidad, no un límite de calidad. Adapte el tamaño del trabajo diario y reserve el gasto en modelos de frontera para los problemas que realmente lo necesitan, y el costo nunca obligará a pausar la AI. Corrija los datos. Adapte el tamaño del modelo. Mantenga la precisión. Eso es lo que las raíces de la gobernanza aportan a una estrategia de AI: no una AI más barata, sino una AI imparable.

Póngase en acción: comience con un solo producto de datos

No intente una reforma en toda la empresa a la vez. Pruebe el modelo llevando un producto de datos a través de todo el ciclo de vida:

1. Escanear: Habilite el escaneo de descubrimiento automatizado en un único esquema de destino.
2. Definir: Establezca umbrales de certificación explícitos en Unity Catalog para la integridad, la semántica y la calidad.
3. Vincular: Conecte un agente analítico al conjunto de datos junto con un conjunto de evaluación dedicado y una ruta de prueba desidentificada.
4. Asignar: Designe a un único Propietario del Producto de Datos (Data Product Owner) responsable de las definiciones y la resolución de problemas.

Una vez que el bucle esté en funcionamiento, repite el proceso con un producto de datos certificado a la vez. La seguridad te dice quién puede acceder a tus datos, pero la gobernanza te dice qué significan y si una AI puede confiar en ellos.

La gobernanza no es la puerta frente a una organización impulsada por datos. Si se hace bien, es el suelo bajo ella.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original