Gobernar el subsuelo de datos que nadie ve

En una reunión de dirección de Northstar Consumer Group, el caso ficticio de esta serie, alguien pregunta cuál fue el margen del trimestre y recibe tres respuestas. Gobernar el subsuelo de datos es darle a esa pregunta una sola definición con dueño, linaje, reglas de calidad y política de acceso, y conectar a ella por rutas controladas cada aplicación que la responde. El subsuelo, en el marco de Urbanización del Mundo Digital (DWU) que propongo, es el conjunto de sistemas de datos y conocimiento de los que dependen las aplicaciones visibles.

Finanzas trae la cifra de su cierre, el dashboard comercial muestra otra y la aplicación de uno de los países, una tercera. Nadie en la sala miente. Cada cifra es correcta según la regla con la que se calculó, y ninguna de esas reglas está escrita en un lugar que las otras dos puedan consultar.

Por qué Northstar tiene tres márgenes

Cada cifra se construyó para un propósito legítimo, con los datos que había a mano. Para el ejemplo supongo lo siguiente.

Finanzas calcula el margen al cierre, con las notas de crédito aplicadas y el costo ya ajustado. Su cifra es la más confiable y también la que llega más tarde. El dashboard comercial se construyó para mirar el mes mientras ocurre; la herramienta de BI que lo alimenta consulta tablas del ERP directamente, con la fórmula que alguien del equipo comercial escribió cuando lo armó. La aplicación del país también lee tablas del ERP y suma un componente de costo que solo existe en esa jurisdicción. Son tres propósitos y tres fórmulas, y ninguna está registrada en un lugar común.

Lo que describe esa escena es un subsuelo que nadie construyó a propósito. Los datos de Northstar son lo que queda de sus aplicaciones, el escape que producen al operar, y cada equipo que necesita una respuesta perfora por su cuenta hasta dar con la tabla que le sirve.

Leavell (2026) llama deuda interpretativa a los compromisos de interpretación que se acumulan en capas y restringen el cambio. Las tres fórmulas son eso. Cada una sostiene reportes, hábitos y decisiones, y unificarlas más tarde obliga a explicarle a cada audiencia por qué su número histórico se mueve.

La consulta directa de la herramienta de BI a las tablas del ERP es, por otra parte, una de las carreteras improvisadas que describí en el post sobre integraciones punto a punto. Entra al subsuelo por donde puede, sin contrato y sin que el dueño del registro sepa que alguien depende de esa columna.

Viví una versión real de esta escena, a otra escala, en el proyecto que conté en La Brújula Comercial y el número único. Cuando Finanzas y Comercial llegan con cifras distintas, la reunión deja de discutir el negocio y empieza a discutir el origen de los números.

El subsuelo como infraestructura cívica

Ese conjunto incluye registros operativos, productos de datos analíticos, metadatos, linaje, controles de calidad, modelos semánticos, índices vectoriales, bases de conocimiento y el contexto que se entrega a los modelos. Las aplicaciones y los dashboards que se apoyan en él son los edificios, y las personas, servicios y agentes que lo consumen son los habitantes. De los doce textos de la serie, este es el que más se acerca a lo que en la práctica se llama gobierno de datos.

Dos propiedades

El marco le atribuye al subsuelo dos propiedades, y las dos aparecen en la reunión de Northstar.

La primera es que sus fallas se propagan hacia edificios que en apariencia no tienen relación entre sí. Una tabla de costos mal cargada aparece a la vez en el dashboard comercial, en la aplicación del país y en cualquier agente que haya recibido ese dato como contexto. Cada equipo la investiga por separado, porque ninguno ve la dependencia común.

La segunda es que usarlo con responsabilidad exige cuatro cosas que ninguna aplicación aporta por sí sola. Hace falta un mapa de qué existe y de dónde viene, mantenimiento, un dueño y conexiones controladas.

La analogía urbana es el agua, la energía y las telecomunicaciones de una ciudad, invisibles para casi todos sus habitantes e indispensables para cada edificio. Se notan cuando fallan, y en ese momento la única pregunta útil es de quién es la tubería.

El diagrama muestra el estado que Northstar querría alcanzar, con una única definición de margen de la que dependen edificios y agentes. Ese estado tiene un costo que retomo más abajo, porque centralizar la definición también centraliza la falla.

El principio de infraestructura cívica

El quinto de los diez principios del marco se llama datos como infraestructura cívica. Dice que los datos, la semántica, el linaje y el conocimiento requieren propiedad explícita, niveles de servicio y políticas de acceso. Infraestructura cívica es el nombre que DWU da a los servicios compartidos que la organización trata como base común en lugar de reconstruirlos en cada proyecto, y el principio pide que una definición como el margen reciba ese trato. Bajo ese principio, los datos dejan de ser el escape sin dueño de las aplicaciones.

Lo que hereda de data mesh

Casi todo esto ya está en data mesh. Dehghani (2020) propuso propiedad de los datos orientada a dominio, datos tratados como producto, infraestructura de datos self-service y gobierno computacional federado. DWU hereda esas cuatro ideas y no pretende reemplazar data mesh.

Lo que el marco agrega es la conexión del subsuelo con el resto de la ciudad. Data mesh describe quién es dueño de un producto de datos. DWU pregunta además cómo ese producto se conecta con la autoridad del distrito, con las rutas de movilidad (las APIs, eventos, colas y contratos por los que viajan datos y comandos) y con los habitantes que lo consumen, agentes incluidos. Un distrito, en DWU, es una capacidad o dominio de negocio con dueño, y Northstar tiene cuatro (Comercial, Cadena de suministro, Finanzas y Personas).

Un catálogo bien hecho diría que el margen pertenece a Finanzas, pero no vería la consulta directa de la herramienta de BI, porque nunca pasó por él. Para DWU esa consulta es parte del mismo problema.

Declarar el margen en Northstar

Llevado a Northstar, el principio 5 produce una declaración parecida a la siguiente.

# Ilustrativo. Una forma posible de declarar la métrica; no sigue ningún estándar.
metrica: margen_bruto
version: 3
distrito_propietario: finanzas
responsable: contabilidad de costos
definicion: >
  Ventas netas del periodo menos el costo de ventas,
  por entidad legal, línea de producto y mes.
formula: ventas_netas - costo_ventas
porcentaje: margen_bruto / ventas_netas
fuentes:
  - producto: finanzas.ventas_netas
  - producto: cadena_suministro.costo_ventas   # otro distrito, interfaz explícita
linaje:
  registros_origen: [erp.facturacion, erp.notas_credito, erp.costos]
  registrado_en: catalogo_corporativo
estados: [preliminar, definitivo]
calidad:
  - regla: ventas_netas presente para cada entidad y mes
  - regla: costo_ventas disponible antes de publicar el mes
  - regla: margen conciliado contra el mayor contable al cierre
    si_falla: publicar como preliminar y avisar a los consumidores
nivel_servicio:
  preliminar: actualización diaria durante el mes
  definitivo: al cierre contable de cada entidad
acceso:
  jurisdiccion: cada entidad legal ve sus datos; el consolidado es regional
  personas: [distrito_finanzas, distrito_comercial]
  agentes: solo con perfil cívico y patrocinador registrado
variantes:
  - metrica: margen_local
    deriva_de: margen_bruto
    diferencia: agrega un costo que solo existe en una jurisdicción
    distrito_propietario: comercial
    jurisdiccion: entidad legal de un país
    consumidores: [app_pais]
consumidores: [cierre_finanzas, dashboard_comercial, base_conocimiento_compras]

El archivo obliga a tomar cuatro decisiones.

Quién puede cambiar el significado

Asignar el margen al distrito de Finanzas significa que cualquier cambio en la fórmula pasa por ese distrito y queda versionado. Finanzas sigue sin construir dashboards, y aun así es la única que puede cambiar qué significa margen.

De dónde viene cada pieza

El costo de ventas viene de un producto de datos de Cadena de suministro. El margen de Finanzas depende entonces de un activo de otro distrito, y el linaje deja esa dependencia por escrito. Si Cadena de suministro cambia su forma de calcular el costo, el catálogo sabe qué métricas y qué edificios quedan afectados antes de que alguien lo descubra en una reunión de dirección.

Cuando escribí sobre el lakehouse serverless con DuckDB, la decisión que más cuidé fue que la capa derivada nunca se confundiera con la fuente de verdad. El bloque de linaje registra esa misma distinción, esta vez declarada para cualquiera que la consulte.

Una regla de calidad que avisa

Cuando la conciliación contra el mayor contable falla, la métrica se publica como preliminar y los consumidores reciben aviso. Esa regla, junto con los dos estados de la métrica, deshace buena parte del conflicto del ejemplo, porque en Northstar la diferencia entre la cifra de Finanzas y la del dashboard comercial es sobre todo de momento. Comercial quiere ver el mes mientras ocurre. Finanzas quiere una cifra definitiva. Con una definición y dos estados, el dashboard puede mostrar el mes en curso sin escribir una fórmula propia.

La variante con nombre propio

La aplicación del país tenía un motivo para sumar su costo local, y borrar esa diferencia en nombre del número único destruiría información que esa jurisdicción necesita. La variante conserva la regla, le da un nombre distinto, declara de qué métrica deriva y en qué difiere, y le asigna dueño. La dirección puede seguir viendo dos cifras en la misma reunión, pero cada una llega con su nombre, su dueño y la diferencia declarada frente a la otra.

Cuando el subsuelo alimenta acciones

Mientras quienes consumían el subsuelo eran personas leyendo reportes, una definición equivocada producía una mala reunión. Con agentes, índices vectoriales y bases de conocimiento, el subsuelo pasa a ser insumo directo de acción.

Entre los doce agentes experimentales de Northstar hay uno de compras que prepara órdenes de compra y que hoy usa credenciales heredadas de un desarrollador. Imaginemos que, para priorizar proveedores, recupera de una base de conocimiento una política interna que fija márgenes mínimos por línea de producto y la compara con margen_bruto. Si esa base indexó una versión vieja de la política, o documentos de una entidad legal con reglas distintas, el agente prepara órdenes con un criterio equivocado, y ninguna persona revisa la cifra antes de que se use.

El agente repite esa comparación para cada proveedor y cada línea de producto. Los controles pensados para un lector humano, como el analista que contrasta una cifra con la del mes anterior antes de usarla, no tienen dónde actuar en ese circuito.

Por eso los índices vectoriales y las bases de conocimiento entran en el mismo régimen que el margen. Necesitan dueño y linaje (qué documentos, en qué versión, se indexaron y cuándo). Necesitan también reglas de calidad para el caso en que un documento fuente se retira, y una política de acceso que respete la del documento original. Un índice que mezcla documentos de las cinco entidades legales de Northstar sin sus etiquetas de jurisdicción mueve información de una entidad a otra aunque nadie lo haya decidido.

La sección acceso del YAML anticipa esto con una línea para agentes, que solo pueden consumir la métrica si tienen perfil cívico y patrocinador registrado. Qué es un perfil cívico, y por qué un agente con credenciales heredadas no lo tiene, es el tema del post sobre gobierno de agentes de IA.

El caso de Grupo Diveco

Debajo de los módulos de Portal Diveco, la plataforma descrita en el primer artículo, hay, entre otras cosas, un data lake con repositorio propio desde el 13 de mayo de 2026. Está organizado en capas Bronze, Silver y Gold (la arquitectura llamada medallón) sobre Parquet y DuckDB.

La pieza que más se parece al YAML de Northstar es la capa semántica común del lake. Es la única fuente de filtros y de definiciones como venta neta, margen o estimado contra real, y su documentación la describe como un núcleo común que no se debe redefinir por reporte. Entre los hallazgos que el portal documenta hay definiciones inconsistentes de venta neta y de margen entre capas y entre herramientas de BI. Es el análogo real de los tres márgenes de Northstar, esta vez sin suponer nada.

Alrededor del lake hay documentos de cuadres mensuales, runbooks y bases de conocimiento para los agentes. En la maqueta 3D de la plataforma, el Distrito 4 muestra ese recorrido, desde unas minas que representan las fuentes hasta una fábrica de datos y tres bodegas, Bronze, Silver y Gold.

Lo que falta es el equivalente de las secciones del YAML de Northstar que asignan dueño, linaje y reglas de calidad. El lake no expone esa información por producto de datos, y el linaje está escrito solo para casos puntuales. La maqueta hereda el mismo hueco, porque muestra por dónde fluyen los datos y no dice a quién pertenece cada bodega.

Lo que el caso muestra es que la idea se puede operar en una empresa real. No mide si reduce las conciliaciones manuales ni los datasets duplicados, que es lo que pediría la hipótesis de la sección siguiente.

Lo que esperaría observar

Si el principio 5 es correcto, una empresa que asigna dueño, linaje y reglas de calidad a sus definiciones críticas debería mostrar menos conciliaciones manuales entre áreas y menos datasets duplicados que calculan lo mismo. El marco asocia esa evidencia a su proposición P5, sobre asentamientos informales y deuda urbana.

Es una hipótesis todavía sin validación empírica. Un patrocinio ejecutivo más fuerte, que el marco incluye entre sus explicaciones rivales, podría producir la misma mejora por sí solo, y un estudio que quisiera poner a prueba el principio tendría que separar un efecto del otro.

Poder, cuellos de botella y un punto único de falla

El YAML de arriba se escribe en una tarde. Lo caro es acordar que la cifra del dashboard comercial se llama ahora margen preliminar, y que el número histórico de la aplicación del país es una variante con otro nombre. Cada área llega a esa conversación defendiendo la cifra con la que la han evaluado.

En los proyectos de datos en que he trabajado, la parte técnica rara vez fue la que más tardó. Lo lento fue la conversación semántica, y debajo de ella había poder, porque decidir qué significa un número con el que se evalúa a otros es una forma de autoridad. El preprint reconoce entre sus limitaciones que las relaciones de poder podrían ser un constructo ausente del marco. El principio 5 dice que una definición necesita dueño, pero no dice cómo se negocia esa propiedad entre áreas con poder desigual.

El segundo costo es más serio. Asignar cada definición a un dueño puede convertir al distrito de Finanzas en una ventanilla por la que pasa todo análisis nuevo. El principio 7 del marco, subsidiariedad con federación, pide decidir en el nivel de dominio competente más bajo, y un catálogo semántico mal administrado produce lo contrario. Lo que esperaría ver si cada variante local necesitara la aprobación de un comité corporativo es que los países dejen de declarar sus variantes y vuelvan a calcular por su cuenta, esta vez fuera del catálogo. Formalizar habría creado el asentamiento informal que pretendía evitar.

El tercero está en el primer diagrama. Una definición compartida reduce la duplicación y concentra la falla. Si la versión 4 de margen_bruto sale con un error, lo heredan al mismo tiempo cada edificio y cada agente que la consumen. DWU registra esta tensión para toda infraestructura compartida (menos duplicación a cambio de cuellos de botella y riesgo de concentración) y no la resuelve; propone tratarla como moderador que se debe medir.

Hay además un límite que el YAML no toca. Una definición correcta no garantiza que la gente la use. En cómo hice que confiaran en nuestros datos conté que cerrar la brecha de credibilidad de una unidad de datos fue un problema de confianza y de estatus, y un catálogo semántico no resuelve ninguno de los dos.

Empezar por el dueño

Si tuviera que elegir una sola intervención para empezar, sería la línea distrito_propietario. Antes del catálogo, del YAML y de cualquier herramienta de linaje, alguien tiene que poder decir «esta definición es mía, la mantengo y respondo cuando falla». Para saber si ese dueño existe alcanza con preguntar, sobre la métrica que más se discute en la organización, quién podría cambiar su fórmula mañana. Si la respuesta es «nadie», «el que armó el reporte» o un silencio, ahí empieza el gobierno de datos.

El YAML deja una decisión sin tomar. La variante del país puede seguir como variante reconocida, integrarse a la definición corporativa si su costo local resulta relevante para toda la región, o retirarse. Son tres de las cuatro respuestas que el marco propone para los asentamientos informales, y el siguiente post explica cuándo conviene cada una.

Este artículo es parte de la serie Urbanización digital, basada en el preprint Toward a Theory of Digital-World Urbanization (Rodas López, 2026), un marco conceptual cuyas ideas apliqué y refiné en la plataforma corporativa de Grupo Diveco, aunque sus seis proposiciones todavía no tienen validación empírica. Anterior: Las integraciones punto a punto son carreteras improvisadas. Siguiente: Shadow IT como asentamiento informal: primero el mapa.