Snowflake Business Ontology: compartir significado sin borrar diferencias

Una empresa puede tener perfectamente definido qué es un cliente y seguir sin poder responder a una pregunta aparentemente sencilla: «¿Qué clientes corremos el riesgo de perder?». Comercial piensa en grupos empresariales; Facturación, en sociedades que reciben una factura; Soporte, en organizaciones con contratos de servicio. La dificultad aparece al relacionar esas perspectivas: perder un contrato no siempre equivale a perder una sociedad, y perder una sociedad no siempre significa perder el grupo.

El anuncio de Business Ontology de Snowflake merece atención porque lleva esa relación entre conceptos al terreno del contexto que consumen los agentes de IA. Su interés profesional va más allá de mejorar descripciones: abre una decisión de arquitectura sobre qué significado compartimos, quién responde por sus correspondencias y qué diferencias debemos conservar.

La tesis de este artículo es que una ontología empresarial aporta valor cuando permite traducir entre dominios sin destruir las distinciones que hacen útiles sus modelos. Esa traducción debe poder examinarse. Una relación imprecisa, convertida en conocimiento oficial, puede extender un error con más eficacia que una definición dispersa.

Qué ha anunciado Snowflake y qué sigue pendiente

Snowflake presentó Business Ontology el 3 de noviembre de 2026 dentro de Horizon Context, en Horizon Catalog. El comunicado oficial de Expedition 2026 sitúa su vista previa pública como próxima. El anuncio acredita una propuesta de producto; todavía no permite tratarla como disponibilidad general ni como una implantación comprobada en cualquier cuenta.

Según la presentación técnica de Business Ontology, los equipos podrán definir conceptos, relaciones y métricas, asignar responsables, aprobar definiciones y vincularlas con los datos y modelos que las implementan. También contempla variantes por dominio y la asociación de métricas equivalentes de distintas vistas semánticas. Las sugerencias de IA y las importaciones quedan sujetas a aprobación; una definición aprobada prevalece sobre una inferencia contradictoria de Cortex Sense.

Es una separación de responsabilidades prometedora. Su eficacia habrá que comprobarla en recorridos concretos: qué definición recibe cada consumidor, cómo se resuelve una ambigüedad y qué ocurre al cambiar una relación. El análisis que sigue propone criterios para esa evaluación; no atribuye al producto funciones que el anuncio no demuestra.

Glosario, ontología y cálculo resuelven problemas distintos

Un glosario permite consultar qué significa un término. Una ontología hace explícitos, además, los conceptos y sus relaciones. Un modelo semántico ejecutable concreta cómo obtener una medida desde los datos. Estas fronteras pueden solaparse en una plataforma, pero conviene distinguirlas al exigir resultados.

«Una sociedad pertenece a un grupo» describe una relación de negocio. «Este identificador de nuestro CRM corresponde a aquella sociedad» resuelve una identidad entre sistemas. «Los ingresos del grupo se agregan a partir de estas operaciones» introduce una regla de cálculo. Ninguna de las tres afirmaciones demuestra automáticamente las otras dos.

La documentación de Semantic Views describe objetos con tablas lógicas, relaciones, dimensiones, hechos y métricas. Pueden consultarse desde SQL y utilizarse con agentes. Esto aporta una representación ejecutable del modelo; no convierte por sí mismo la etiqueta «cliente» en una identidad universal.

De ahí una consecuencia práctica: aprobar el concepto no valida todas sus implementaciones. Y vincularlo a una implementación correcta no garantiza que un consumidor externo vaya a consultarla. Un catálogo bien mantenido puede convivir con una exportación antigua, una fórmula local o un agente que siga utilizando otra ruta. La adopción debe demostrarse en los consumidores que sostienen la decisión.

El significado compartido necesita fronteras

La tentación de construir un modelo único de toda la empresa es comprensible: si todos usan las mismas palabras, parece razonable exigir las mismas entidades. Pero una organización puede necesitar varias representaciones legítimas del mismo mundo.

El diseño guiado por el dominio lleva tiempo trabajando esta dificultad. En su explicación de Bounded Context, publicada en 2014, Martin Fowler describe modelos coherentes dentro de límites explícitos y relaciones entre esos contextos. Es un antecedente conceptual, no una novedad de la IA: la consistencia interna de cada modelo y la integración entre modelos son problemas relacionados, pero distintos.

Aplicado a una ontología, propondría conservar el dominio como parte de la identidad del concepto. «Cliente de facturación» y «cuenta comercial» pueden estar relacionados sin ser intercambiables. Si los fusionamos demasiado pronto, cada excepción posterior acabará escondida en filtros, instrucciones al agente o reglas que solo recuerda una persona.

Compartir una referencia permite coordinar equipos. Obligar a que todas sus decisiones encajen en una sola entidad puede trasladar la complejidad a lugares menos visibles. La prueba de calidad consiste en poder expresar una diferencia legítima sin convertirla en un defecto del sistema.

Un grupo, dos sociedades y tres contratos

Imagina un grupo empresarial con dos sociedades, Norte y Sur. Norte tiene dos contratos de servicio; Sur tiene uno. Comercial gestiona una cuenta para el grupo, Facturación mantiene dos entidades y Soporte atiende tres contratos. Si los tres sistemas llaman «cliente» a su unidad de trabajo, obtendremos uno, dos o tres clientes según dónde preguntemos.

Renombrar las unidades ayuda, pero el valor de una ontología aparece cuando necesitamos atravesar sus relaciones. Supongamos que vence uno de los contratos de Norte. La pregunta comercial es si peligra la relación con el grupo; la operativa, qué servicio deja de estar cubierto. Para responder necesitamos saber qué contrato vence, qué sociedad lo firmó, qué servicio cubre y cómo se relaciona esa sociedad con la cuenta comercial.

Si copiamos el estado del contrato sobre la sociedad y después sobre el grupo, habremos convertido una relación de pertenencia en una regla de propagación. «Tiene un contrato que vence» se habrá transformado en «es un cliente perdido». Esa conclusión no procede de los datos originales: la hemos introducido al recorrer el modelo.

La solución depende de la decisión. Para priorizar una llamada puede bastar con señalar que el grupo contiene una relación próxima a vencer. Para dar de baja servicios necesitamos la cobertura contractual concreta. Y para medir pérdida comercial debemos acordar si hablamos de contratos, sociedades o grupos sin relación activa. La misma estructura de entidades puede sostener las tres preguntas si conserva sus diferencias.

Hay otro límite: la ontología puede explicar que una sociedad pertenece a un grupo, pero alguien debe resolver qué registros representan esa sociedad. Si dos sistemas la identifican de forma distinta, necesitamos correspondencias contrastadas y tratamiento de casos dudosos. Definir bien una clase de entidad no elimina los duplicados ni identifica automáticamente sus instancias.

Una matriz para decidir qué podemos compartir

Propongo esta matriz de correspondencias como herramienta de diseño. Se aplica a cada relación entre conceptos, antes de permitir que un consumidor sustituya uno por otro. No describe una función específica de Snowflake.

Equivalencia

Qué permite: Reutilizar el significado dentro del ámbito acordado.

Evidencia necesaria: Misma población, unidad, granularidad y reglas temporales; diferencias de implementación contrastadas.

Especialización

Qué permite: Pasar de una categoría restringida a otra más amplia cuando el uso lo admita.

Evidencia necesaria: Criterio de inclusión explícito; conservar lo que se pierde al ampliar.

Agregación o pertenencia

Qué permite: Relacionar unidades de distinto nivel, como contrato, sociedad y grupo.

Evidencia necesaria: Cardinalidad, vigencia y regla de agregación; ningún estado se propaga por defecto.

Correspondencia condicionada

Qué permite: Traducir solo cuando se cumple una condición conocida.

Evidencia necesaria: Condición comprobable y conducta definida si falta o deja de cumplirse.

Relación sin sustitución

Qué permite: Encontrar contexto relacionado manteniendo separados los conceptos.

Evidencia necesaria: Motivo del vínculo y prohibición de inferir equivalencia solo por proximidad.

En el ejemplo, contrato, sociedad y grupo mantienen relaciones de pertenencia. «Sociedad con contrato vigente» es una especialización de sociedad. Dos identificadores pueden representar la misma sociedad, pero esa correspondencia entre registros necesita su propia evidencia. Ninguna de esas relaciones autoriza a convertir tres contratos en tres grupos.

La distinción entre semejanza y equivalencia tiene un precedente formal útil. La recomendación SKOS del W3C, de 2009, diferencia correspondencias próximas y exactas. Las próximas no se declaran transitivas, para evitar que una cadena de aproximaciones produzca equivalencias indebidas. Es una referencia conceptual: no significa que Business Ontology implemente SKOS ni que sus relaciones tengan idéntica semántica.

La lección para arquitectura es sencilla: si A se parece a B y B se parece a C, no podemos asumir que A sustituye a C. Cada paso puede perder información. Un agente capaz de recorrer muchas relaciones necesita conocer también cuáles no permiten continuar una inferencia.

La equivalencia necesita un ámbito y una fecha

Incluso una correspondencia correcta puede dejar de serlo. Una sociedad cambia de grupo, un contrato se transfiere o un área redefine su unidad comercial. El catálogo debe permitir entender qué relación se considera válida; el sistema que produce la respuesta necesita aplicar la adecuada al periodo consultado.

Conviene distinguir dos preguntas temporales: qué era válido en el negocio y qué sabía el sistema cuando respondió. Si la transferencia de una sociedad tenía efectos desde octubre, pero se registró en noviembre, reconstruir una decisión tomada en octubre exige conservar esa diferencia. Consultar el organigrama actual puede explicar el presente y falsear el razonamiento histórico.

Por eso, en una evaluación de producto exigiría poder reconstruir la cadena concreta: concepto y versión, correspondencia aplicada, modelo utilizado, corte de datos y consumidor. Un historial de edición es una pieza de esa evidencia; no demuestra por sí solo qué versión utilizó una respuesta anterior.

Esta exigencia no obliga a empezar con una infraestructura temporal completa para toda la organización. En un análisis exploratorio puede bastar una advertencia sobre el alcance histórico. En un proceso que determina bajas, cobertura o compromisos contractuales, esa incertidumbre cambia la decisión de automatizar.

Qué debería demostrar un piloto serio

Elegiría un recorrido que atraviese dos dominios y termine en una decisión concreta. El ejemplo de contratos y grupos sirve mejor que importar miles de términos: obliga a comprobar relaciones, identidad y uso. El objetivo sería demostrar que el consumidor conserva el significado al cruzar la frontera.

Prepararía casos que separen comportamientos: una sociedad con varios contratos, un contrato transferido, dos registros candidatos a representar la misma entidad y una relación todavía sin aprobar. Para cada caso fijaría la respuesta esperada y el motivo. A veces será una cifra; otras, una distinción entre ámbitos o la necesidad de resolver una correspondencia pendiente.

Además comprobaría una discrepancia deliberada entre definición e implementación. Snowflake documenta reglas de validación para Semantic Views sobre estructura, relaciones y expresiones. Esas comprobaciones técnicas son necesarias. La aceptación del negocio exige demostrar también que las relaciones representan los hechos y que las operaciones conservan la unidad de análisis elegida.

Mediría la proporción de respuestas correctas que cruzan dominios sobre el conjunto de casos revisados, separando errores de identidad, correspondencia y cálculo. Registraría también cuántas solicitudes quedan pendientes de aclaración y cuánto cuesta resolverlas. Son métricas propuestas para el piloto, no resultados observados ni promesas de mejora del producto.

La cobertura del catálogo necesita otro denominador: de los consumidores incluidos en el alcance, cuántos utilizan realmente la referencia aprobada. Tener cien términos bien documentados y un consumidor crítico fuera del circuito puede importar más que duplicar el número de definiciones.

Cuándo compensa centralizar y cuándo conviene esperar

La inversión resulta más defendible cuando varias herramientas y equipos reconstruyen las mismas relaciones, los cambios provocan reconciliaciones recurrentes y existe una autoridad capaz de mantener las correspondencias. En ese contexto, centralizar conocimiento reutilizable puede reducir traducciones duplicadas y hacer visible dónde sigue habiendo desacuerdo.

Si un equipo pequeño utiliza un solo modelo estable, empezar por una capa semántica bien mantenida y un glosario acotado puede resolver la necesidad con menos coordinación. Si la organización ya tiene un catálogo reconocido, introducir otro centro de aprobación exige decidir cuál manda y cómo se sincronizan. Dos repositorios oficiales sin precedencia clara añaden una nueva frontera al problema.

La alternativa federada conserva la autoridad en cada dominio y comparte identificadores y correspondencias entre ellos. Su coste aparece en la negociación y el mantenimiento de esas relaciones. La alternativa central facilita una política común, pero puede crear una cola de aprobación que empuje a los equipos a trabajar fuera del sistema. La elección depende de quién puede sostener el cambio, además de dónde se almacena el modelo.

También pediría una demostración concreta de portabilidad. Exportar nombres y descripciones no equivale a trasladar ámbitos, relaciones, aprobaciones, historial y vínculos ejecutables. Antes de convertir una plataforma en memoria institucional, conviene saber qué conocimiento podremos conservar y qué habrá que reconstruir al salir.

El valor está en conservar lo que permite decidir

En el análisis sobre dashboards y definición de métricas la cuestión era delimitar qué representa cada cifra. Business Ontology permite abrir la siguiente: cómo conectar modelos que ya tienen sentido por separado para que personas y agentes trabajen entre ellos.

El avance merece atención. Una organización puede convertir conocimiento disperso en una referencia compartida, con responsables y vínculos utilizables. Pero el criterio de éxito debería ser exigente: atravesar esos vínculos sin perder la diferencia entre un contrato, una sociedad y un grupo, y poder explicar después por qué se aplicó una correspondencia concreta.

La mejor ontología empresarial conserva las diferencias que necesitamos para decidir y hace explícitas las relaciones que permiten trabajar juntos. Si consigue eso, el catálogo deja de ser un lugar donde guardar definiciones y se convierte en una infraestructura de coordinación. Ese es el valor que merece comprobarse cuando Business Ontology llegue a nuestras manos.