Ontología empresarial abierta: quién debería poseer la capa semántica del negocio

En corto: cuando este artículo se publicó en junio de 2026 preguntaba quién sería dueño de la capa semántica del negocio. La carrera ya se corrió: cinco plataformas lanzaron una en nueve meses. Y además hicieron algo que nadie predijo: abrieron la vía de acceso a su ontología mediante MCP y se quedaron dentro con la definición. Llamémoslo protocolo abierto, definición cerrada. Hoy un agent puede leer cinco ontologías que no puede llevarse. Eso vuelve la pregunta de propiedad más afilada, no más débil, y la respuesta no cambia: la capa de definición de la que dependen a la vez tus aplicaciones, tus agents, tus auditores y tus proveedores debería ser una capa neutral que guardes en tu propio repositorio.

Empecemos por cómo una empresa perdió un cliente exactamente por esto. Los detalles están anonimizados, pero probablemente hayas visto cada paso.

Yuanfeng, el nombre que le daremos a este fabricante de equipos industriales, factura unos miles de millones al año y atiende a unos miles de clientes. En 2024 apostó su base de datos por Microsoft y construyó una ontología limpia en Fabric: qué es un «cliente», qué «equipos» se conectan a un cliente y qué «órdenes de trabajo» cuelgan de cada equipo. Ese año se convirtió en el caso modelo que se repetía en las conferencias de proveedores.

En 2026, tres cosas golpearon a Yuanfeng casi a la vez:

• El equipo de ciencia de datos quiso ejecutar un lote de predicciones de renovación en Gemini, porque en ese escenario concreto realmente era más preciso;
• Cumplimiento recibió aviso de que los datos de clientes de la UE debían quedarse en la UE y ya no podían tocar la nube estadounidense;
• Se cerró una adquisición que trajo una organización comercial entera —varios miles de clientes— funcionando sobre Salesforce.

Así que Yuanfeng pasó a tener tres «clientes»: uno en Fabric, uno en Salesforce y otro más en el entorno de la UE aislado por cumplimiento.

El punto de inflexión llegó con una cuenta clave que llamaremos Grupo H. Un día el director comercial preguntó a un agent: «¿Qué riesgo de renovación tiene el Grupo H el año que viene?». El agent respondió: «Bajo». Estaba leyendo la ontología de Fabric, donde los pedidos recientes del Grupo H se veían sanos y los números eran bonitos.

Pero lo que el agent no veía: en los registros de Salesforce (traídos por la adquisición), el Grupo H había escalado quejas a nivel directivo dos veces en seis meses; en el entorno aislado de la UE había una disputa de pago con 90 días de retraso sin resolver. Tres conjuntos de datos pertenecían a tres «clientes» que se desconocían mutuamente, y ninguna capa en ninguna parte sabía que todos eran el mismo Grupo H.

Un trimestre después el Grupo H se fue: millones de pérdida anual. La conclusión del análisis posterior fue lo bastante cruda como para dejar la sala en silencio: el agent no se había equivocado técnicamente. La porción de datos que vio mostraba realmente riesgo bajo. Lo que estaba mal no era el modelo. Era la definición de «cliente» bajo sus pies, partida en tres.

Esto no fue simplemente un error de Yuanfeng. Es el resultado previsible de entregar «la definición de tu negocio» a una plataforma para que la custodie, cuando cada plataforma solo protege y entiende su propia porción.

La carrera que este artículo nombró ya se corrió

Cuando este texto se publicó por primera vez, los participantes eran todavía un pronóstico. Ahora son un hecho registrado. Entre noviembre de 2025 y agosto de 2026, cinco plataformas lanzaron una capa semántica de negocio:

Plataforma	Qué lanzó	Cuándo
Microsoft Fabric IQ	Un elemento Ontology más una carga de trabajo de agents completa —Graph, Data Agent, Operations Agent— en vista previa pública, alcanzable por cualquier agent mediante endpoints públicos de Ontology MCP	Ignite, nov. 2025; ampliado con reglas y automatización en FabCon Atlanta, mar. 2026
Snowflake	Semantic View Autopilot, GA: redacta vistas semánticas a partir de tu histórico de consultas y tus activos de BI en lugar de pedir a un comité que defina «ingresos» desde cero	3 de feb. de 2026
Google	Looker BI Agents anclados en la capa semántica de Looker, y Dataplex renombrado como Knowledge Catalog, que convierte los metadatos del catálogo en un grafo semántico con una API de contexto para agents	Cloud Next ‘26, abr. 2026
Databricks Unity Catalog	Business Semantics, GA: vistas de métricas gobernadas y metadatos para agents definidos una sola vez en la capa de datos, con la implementación central abriéndose en Apache Spark	GA en 2026; Business Glossary y Domains en el Data + AI Summit, jun. 2026
Palantir Foundry	Ontology MCP alcanzó GA en todas las instalaciones de Foundry: tipos de objeto, tipos de acción y funciones expuestos a cualquier cliente MCP como herramientas invocables	Semana del 16 de jun. de 2026

Dos cosas sobre esa tabla merecen decirse antes de seguir con el argumento.

Este artículo no es el lugar para compararlas celda a celda. Capacidad por capacidad, con cada dato atribuido a la documentación del propio proveedor, es otro texto: Fabric IQ vs Palantir vs Unity Catalog vs Snowflake. Ahí se resuelve cuáles modelan acciones en lugar de solo describir el negocio, que es la fila que más decide. Léelo si estás eligiendo. Lee este si estás decidiendo qué poseer.

El argumento lo hacen las fechas, no las listas de funciones. Nueve meses, cinco plataformas, cinco decisiones independientes de que esa misma capa valía la pena. Ya no hace falta convencer a nadie de que la IA en la empresa exige una capa de definición de negocio legible por máquina y gobernada. Esa mitad de la pregunta está cerrada.

Queda una aclaración que pertenece aquí, porque las tres palabras en juego se usan como sinónimos y no lo son: ontology vs semantic layer vs knowledge graph fija qué puede y qué no puede responder cada una. La discusión de propiedad que sigue asume que ya decidiste a qué capa te refieres.

El giro: protocolo abierto, definición cerrada

Aquí está la parte que no salió como nadie esperaba, y es el cambio más importante desde junio.

Las plataformas no se quedaron amuralladas. Se abrieron, mediante MCP. Fabric IQ expone endpoints públicos de Ontology MCP. Palantir puso Ontology MCP en disponibilidad general en todas las instalaciones de Foundry la misma semana en que este artículo se publicó por primera vez. Snowflake ofrece un servidor MCP gestionado. Google colocó una API de contexto delante de Knowledge Catalog. De las cuatro plataformas de la comparativa enlazada, tres exponen su capa semántica a los agents mediante MCP.

A primera vista parece que la respuesta abierta llegó sola. No es así, y la distinción merece precisión:

MCP estandariza cómo un agent alcanza tu ontología. No estandariza nada sobre quién la posee.

Un endpoint MCP es una vía de lectura, no una escritura de propiedad. Tu agent obtiene una forma limpia, gobernada y neutral de preguntar a una definición que sigue viviendo en la plataforma de otro, que sigue versionándose al ritmo de sus lanzamientos y que sigue quedándose con ellos cuando tú te vas. El protocolo está abierto. La definición está cerrada. Protocolo abierto, definición cerrada.

Esto importa porque ambas cosas se confunden justo en la dirección que cuesta dinero. «Cualquier agent puede leerla» suena a portabilidad. Es lo contrario: es lo que hace cómodo no ser portable.

Por qué eso agrava la fragmentación en vez de aliviarla

Con la dependencia de un solo proveedor, al menos la definición de tu negocio sigue siendo una copia completa: simplemente no puedes moverla. Doloroso, pero entero.

Cinco plataformas sosteniendo cada una su propia ontología producen otra cosa: fragmentación. El «cliente» de Yuanfeng no solo quedó encerrado; quedó partido en tres y almacenado en tres plataformas que se ignoraban entre sí. Dos mecanismos impiden que eso se cure solo, y MCP acaba de añadir un tercero.

La primera capa son los incentivos. Podrías pensar: que la ontología de Microsoft entienda el «cliente» de Salesforce y listo. No será tan simple, porque la ontología de cada proveedor es parte de su foso defensivo. Si Microsoft unificara unilateralmente su semántica de «cliente» con la de un rival, ayudaría a ese rival a mover datos con más fluidez y reduciría su propia diferenciación. Unificar es estratégicamente poco atractivo para todos los participantes de la carrera. No es solo un descuido técnico; es comportamiento racional de plataforma.

La segunda capa es técnica. Aun dejando los incentivos de lado, alinear semánticas entre ontologías es difícil: ¿el «cliente» del sistema A equivale al «Account» del sistema B? Las definiciones de campo, los ciclos de vida, las reglas de deduplicación y los criterios de «la misma entidad» difieren entre sistemas. La IA tampoco puede inferir esto de forma fiable. Los agents se equivocan precisamente porque falta esa capa de definición determinada. Volviendo al Grupo H: deja que el agent adivine si «estos tres registros son la misma empresa», y el coste de fallar es exactamente la pérdida de la historia.

La tercera capa es nueva, y es la incómoda: MCP abarata tolerar la fragmentación. Antes, cablear un agent a cinco capas semánticas desconectadas dolía lo suficiente como para que alguien acabara escalándolo y el proyecto de conciliación consiguiera presupuesto. Ahora son cinco registros de endpoint en una tarde. El agent sostendrá tan tranquilo cinco herramientas que responden distinto a «quién es este cliente», y responderá con confianza desde la primera que alcance. Se eliminó el dolor de integración que forzaba la conciliación; la fragmentación de la que avisaba, no.

En una línea: creíste comprar cinco herramientas; en realidad compraste cinco fuentes de verdad que se desconocen entre sí, ahora cómodamente direccionables. Cuantos más sistemas, más adquisiciones y más aislamiento por cumplimiento, más grave se vuelve esta fragmentación. La era de los agents amplifica el coste, porque una persona todavía puede conciliar a mano entre sistemas, por penoso que sea, mientras que un agent necesita una capa de definición determinada y consistente entre sistemas antes de poder razonar.

Para evitar la fragmentación, la definición de tu negocio no puede pertenecer por completo a una plataforma que compite en la carrera. Necesita ser una capa neutral: una definición que sostengas tú y que puedan leer las herramientas de distintos proveedores. Las plataformas cerradas tienen dificultades estructurales para ofrecer esto, porque son competidoras de la carrera y no pueden ser a la vez árbitros neutrales.

Primero, el guion con el que ganan las plataformas cerradas

Si lo único que sabes hacer es repetir «lo abierto es bueno», eso es prédica, no análisis. Las plataformas cerradas tienen cuatro cartas reales, y los últimos nueve meses fortalecieron dos de ellas.

Primera, calidad de modelado. Convertir veinte años de complejidad empresarial acumulada en una ontología limpia y coherente consigo misma es ingeniería pesada. Palantir la alinea concepto a concepto con ingenieros en sitio, con una calidad que las comunidades de código abierto no igualan rápido. Con una ontología, construirla mal puede ser peor que no construirla. Ese modelo presencial tiene su propia economía, y viaja peor que el título del puesto: por qué copiar el modelo forward-deployed construye una consultora desarrolla qué tiene que existir debajo para que el trabajo componga.

Segunda, una única parte responsable. Cuando algo se rompe, alguien descuelga el teléfono, hay un SLA y hay un contrato detrás. Para un CIO, «un proveedor asume la responsabilidad de toda la capa» tiene valor real.

Tercera, muchas empresas de verdad están «básicamente en un solo stack». Si el 80 % de tu negocio ya vive en un ecosistema, «lo mejor dentro del ecosistema» puede ser literalmente tu mejor opción. Las ventajas de la apertura son más difíciles de aprovechar si tu negocio no cruza sistemas.

Cuarta —y esta se fortaleció— el problema del arranque en frío. El Autopilot de Snowflake redacta el modelo semántico a partir del histórico de consultas que ya tienes; Fabric IQ deja que expertos de negocio escriban la ontología en una herramienta visual sin código en lugar de esperar a los ingenieros de datos. Ambos atacan el obstáculo real, que nunca fue la tecnología sino el comité de modelado de seis meses. Un formato abierto te entrega un archivo y una página en blanco.

Las cuatro cartas son reales. Así que la conclusión no es «las plataformas cerradas son todas trampas». Para empresas que encajan cómodamente en un ecosistema, suelen ser la respuesta correcta. El problema aparece en empresas como Yuanfeng: la premisa caduca.

Cómo saber que te están fragmentando

Esto no es abstracto; tiene síntomas tempranos concretos. Contrasta con la lista siguiente. Si tres o más son ciertos, la fragmentación ya está ocurriendo dentro de tu empresa.

1. El mismo «cliente / pedido / equipo» está definido de forma distinta en cada sistema y no cuadra; cada informe exige coser a mano.
2. Le haces a un agent una pregunta que cruza sistemas y o se va por las ramas o acierta a medias (vio un sistema, se perdió el otro).
3. Cada vez que conectas un sistema nuevo tienes que volver a enseñarle a la IA «qué es esto» y «qué significan los campos».
4. Una adquisición se cerró hace más de un año y los datos maestros de ambas partes siguen sin fusionarse de verdad; cada lado reporta su propia versión.
5. Cumplimiento exige aislar una clase de datos, así que la misma entidad acaba en varias copias que no se reconocen entre sí.
6. A tu agent le han dado más de una herramienta de capa semántica y nadie ha escrito cuál manda cuando se contradicen.

Antes de que Yuanfeng perdiera al Grupo H, cuatro de los cinco primeros eran ciertos. En su momento se archivaron como «tareas pendientes de gobierno del dato», y nadie vio que eran riesgos que un agent acabaría destapando. El sexto es la incorporación de 2026, y es el que llega en silencio, porque añadir el segundo endpoint se siente como progreso.

Un poco de agua fría: lo abierto no es una bala de plata, y el campo se está estandarizando

Detengámonos aquí con honestidad, o esto se convierte en un argumentario de ventas. Hay tres contrapesos legítimos, y el tercero es nuevo.

Primero, cambiar la definición por un protocolo abierto no fusiona automáticamente los tres «clientes» de Yuanfeng en uno. El modelado semántico, la deduplicación y la alineación de definiciones siguen habiendo que hacerlos. Aquí no hay bala de plata, y no creas a quien diga que la tiene. Lo que lo abierto cambia de verdad es la titularidad de ese trabajo duro: la definición que alineas hoy queda escrita en tu propio repositorio, no enterrada en el backend de una plataforma. El año que viene, cuando cambies de modelo, de nube o te adquieran, lo que reconstruyes es la conexión, no la definición.

Segundo, «abierto» por sí solo no garantiza ganar. Históricamente, para que un estándar abierto se imponga suele hacer falta además una buena implementación de referencia y un ecosistema activo. Publicar un protocolo que nadie hace agradable de usar no basta. Elegir abierto es apostar a que alguien lo construya bien. Eso es riesgo de ejecución, no una victoria garantizada.

Tercero —y este es el argumento más fuerte contra la posición de este artículo— los proveedores están estandarizando la capa de definición ellos mismos. Snowflake cofundó Open Semantic Interchange con Salesforce, dbt Labs, BlackRock y RelationalAI; la iniciativa entró en el Apache Incubator en julio de 2026 como Apache Ossie, con más de 50 organizaciones miembro entre ellas Databricks, Oracle y Collibra. Databricks, por separado, está abriendo el código de su implementación de vistas de métricas en Apache Spark. Eso es real, y va más rápido de lo que suele lograr un esfuerzo de capa neutral; quien hoy sostenga que las plataformas cerradas nunca convergerán está discutiendo contra la evidencia.

Pero mira con cuidado dónde se detiene esa convergencia. Ossie cubre semántica analítica: métricas, dimensiones, relaciones. Acciones y permisos quedan fuera de alcance. Es decir, la mitad de tu ontología que describe el negocio se está volviendo portable, mientras que la mitad que lo cambia —las operaciones, quién puede ejecutarlas y qué se escribe en el registro de auditoría— sigue siendo propietaria. No es un resto pequeño. Es la mitad que decide si un agent puede hacer algo, y exactamente la mitad donde la fragmentación sale más cara.

Ninguno de los tres dice que lo cerrado sea mejor. Dicen que lo abierto también cuesta esfuerzo, también conlleva riesgo y está siendo parcialmente correspondido. Pon eso frente al inconveniente de encerrar la definición de tu negocio en una plataforma y luego fragmentarla entre cinco. Ningún lado es gratis; uno de ellos deja el activo central en tus manos.

Las capas de las que todos dependen acaban siendo neutrales

El patrón no es nuevo, pero merece contarse con ejemplos frescos, porque sigue repitiéndose.

La «capa de definición» de la que depende colectivamente todo un ecosistema tiende a volverse neutral. El ejemplo más antiguo es SQL: los proveedores de bases de datos compitieron con dureza, y aun así el lenguaje de consulta siguió siendo público. Dos ejemplos más recientes son OpenTelemetry, el estándar de datos de observabilidad alojado por la neutral CNCF, y LSP (el Language Server Protocol), abierto por Microsoft y adoptado por muchos editores precisamente porque era abierto.

El ejemplo de LSP es especialmente útil porque fue Microsoft quien probó el patrón: abrir la capa de definición y competir con la mejor implementación puede crear más valor que cerrarla con llave. Fíjate, eso sí, en qué abrió LSP realmente: el protocolo y la definición de lo que un servidor de lenguaje debe proporcionar. Para las ontologías, MCP ha hecho la primera mitad. Apache Ossie intenta la segunda mitad para la parte analítica. La parte que actúa no la ha hecho nadie todavía.

Una capa de la que dependen a la vez tus aplicaciones, tus agents, tus sistemas de auditoría y las herramientas de cinco proveedores no puede seguir siendo privada de uno de ellos sin continuar produciendo el tipo de fragmentación que sufrió Yuanfeng.

Qué aspecto tiene la capa neutral

Después de todo esto, mira la cosa real. El punto no es la sintaxis; es dónde vive la definición, si puedes llevártela y si puede recuperar la fragmentación.

Supón que Yuanfeng hubiera construido «cliente» desde el principio como una definición neutral: conectar los tres sistemas como orígenes de datos, modelar cada uno como objetos y luego alinearlos en un único «cliente» gobernado mediante una clave compartida (el identificador fiscal), una declaración en tu propio repositorio que es la única fuente de verdad:

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Customer',
  fields: {
    name: Field.text({ label: 'Customer name', required: true }),
    tax_id: Field.text({ label: 'Tax ID' }), // clave compartida para alinear «el mismo cliente» entre sistemas
  },
});

Esta definición vive en tu repositorio Git: diferenciable, revisable, migrable. Lo que puede hacer a continuación es el meollo: convertir «portable» en una acción demostrable, no en una promesa:

git add crm/*.ts          # La definición está en tu control de versiones: auditable, reversible
os start   # La misma definición, corriendo sobre tu propia infraestructura
# Después apunta cualquier modelo hacia ella — Claude, GPT, Gemini — el runtime no cambia

Ahora vuelve a hacer la pregunta crítica: «¿Qué riesgo de renovación tiene el Grupo H el año que viene?». El agent ve ahora un «cliente» unificado, con permisos y auditoría: pedidos sanos, superpuestos con dos quejas escaladas a dirección y una disputa de pago de 90 días. Responde: «Riesgo alto; se recomienda intervención temprana». Mismo modelo, misma pregunta. Como la definición de debajo ya no está fragmentada, la conclusión pasa de «perdimos millones» a «avisamos un trimestre entero antes».

El punto sobre MCP también aplica aquí, y en la dirección que importa: esa misma definición es la que el runtime sirve a los agents como herramientas gobernadas, de modo que la vía de lectura está abierta y la definición es tuya. Ese es el argumento que por qué la definición y el runtime deberían ser ambos abiertos desarrolla por completo.

Esta es la división de trabajo entre ObjectStack y ObjectOS, y su respuesta a esta carrera:

• ObjectStack — una open business ontology (ontología de negocio abierta): el protocolo de definición abierto y el runtime autoalojado de código abierto (Apache 2.0). La definición vive en tu repositorio, el agent de cualquier proveedor puede leerla, y el runtime la valida y la ejecuta con permisos y auditoría;
• ObjectOS — la plataforma comercial de producción opcional y la experiencia operada para esa misma aplicación ObjectStack —en la nube o autogestionada— que añade construcción con IA en el navegador, despliegue y operación, sin sustituir la definición ni el runtime abiertos de debajo.

La definición y el runtime autoalojado siguen abiertos y neutrales; la experiencia comercial de producción es donde compiten los productos. Es la misma relación que SQL tiene con los proveedores de bases de datos y LSP con los de editores.

Y siendo honestos con el intercambio: en profundidad de modelado, en arranque en frío y en semántica analítica sobre datos a escala de almacén, las plataformas de arriba van por delante, y el artículo comparativo dice en detalle dónde. Lo que aquí es distinto es más estrecho que «mejor»: la definición es un archivo corriente en tu repositorio bajo una licencia abierta, y el runtime que la hace cumplir lo alojas tú.

Cierre

Esta no es una cuestión ideológica de «lo abierto es bueno» o «lo cerrado es bueno». Es una pregunta de arquitectura más fría: cuando tu mezcla de proveedores cambie por adopción multimodelo, estrategia multinube, una adquisición o aislamiento por cumplimiento, ¿quién sostiene la definición de tu negocio?

Hace nueve meses esa pregunta era hipotética, porque el campo aún no había entregado nada. Ya entregó. Cinco plataformas demostraron que la capa vale la pena, y después la mayoría abrió una puerta principal a una casa que no es tuya. Un endpoint MCP sobre la ontología de otro es algo genuinamente útil; simplemente no es lo mismo que poseer la definición, y en el hueco entre ambas cosas se fue el Grupo H de Yuanfeng.

Una capa de la que todos dependen rara vez se queda mucho tiempo en una sola empresa. No hay razón para que esta sea distinta.

npm i -g @objectstack/cli && os start

Define tu primer objeto de negocio, haz que sus datos vengan de dos sistemas existentes y luego hazle git commit en tu propio repositorio. En ese momento, la definición de tu negocio vuelve a estar en tus manos, no en el backend de otro.