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

En resumen: la capa de definición de negocio de la que dependen tus aplicaciones, tus agents, tus auditores —y ahora también varios proveedores— no debería pertenecer a ninguna plataforma. Debería ser una capa neutral que guardas en tu propio repositorio.

Empecemos por cómo una empresa perdió un cliente justamente por esto. Los detalles están anonimizados, pero seguramente reconocerás cada paso.

Yuanfeng es un fabricante de equipos industriales, con una facturación anual de varios miles de millones y miles de clientes. En 2024 apostó su base de datos por Microsoft y montó en Fabric una ontología impecable: qué es un “cliente”, a qué “equipos” está conectado cada cliente, qué “órdenes de trabajo” cuelgan de cada “equipo”, todo definido con total claridad. Aquel año fue el caso ejemplar que se citaba una y otra vez en la conferencia anual de su proveedor.

En 2026, tres cosas le cayeron encima a Yuanfeng casi a la vez:

el equipo de ciencia de datos quiso usar Gemini para correr una tanda de predicciones de renovación, porque en ese escenario concreto era de verdad más preciso;
el área de cumplimiento recibió la notificación de que los datos de los clientes europeos debían permanecer en la UE y ya no podían entrar en la nube de EE. UU.;
se cerró una adquisición que trajo consigo toda una organización comercial montada sobre Salesforce, con miles de clientes.

Así que Yuanfeng acabó con tres “clientes”: uno en Fabric, uno en Salesforce y otro más en el entorno europeo aislado por cumplimiento.

El giro de la historia ocurre con un cliente clave llamado “Grupo H”. Un día, el director comercial le preguntó al agent: “¿Qué riesgo de no renovación tiene el Grupo H el año que viene?”. El agent respondió: “Bajo”. Estaba conectado a la ontología de Fabric, donde los pedidos recientes del Grupo H estaban sanos y las cifras pintaban bien.

Pero lo que el agent no veía era esto: en aquel registro de Salesforce (el que trajo la adquisición), el Grupo H había escalado dos quejas a la cúpula directiva en medio año; y en el entorno europeo aislado colgaba además una disputa de cobro de 90 días de retraso. Tres conjuntos de datos repartidos en tres “clientes” que no se reconocían entre sí, y ninguna capa sabía que en realidad eran el mismo Grupo H.

Un trimestre después, el Grupo H se marchó, con una pérdida anual de varios millones. La conclusión del análisis posterior fue tan punzante que dejó a todos en silencio: técnicamente el agent no se había equivocado; los datos que vio sí mostraban un riesgo bajo. El error no estaba en el modelo, sino en que la definición de “cliente” sobre la que pisaba había quedado partida en tres.

Esto no fue un descuido de Yuanfeng. Es la consecuencia inevitable de entregar “la definición del negocio” a una plataforma para que la custodie, porque cada plataforma solo custodia su propia copia.

No es un caso aislado: todos corren por esta capa

La situación de Yuanfeng es tan común porque todo el sector se está abalanzando a la vez sobre la misma capa.

Hace poco, “capa semántica de negocio / Ontology” sonaba como vocabulario especializado de unas pocas plataformas de datos. Ahora las grandes nubes, plataformas de datos y plataformas de IA se mueven en la misma dirección. La razón es sencilla: los agents no entienden bien una empresa si solo miran tablas y APIs.

¿Por qué precisamente ahora? Porque los agents destaparon el agujero. Las tuberías de datos de la última década solo se preocupaban de “a dónde fluye el dato”, no tanto de “qué significa este dato”; al fin y al cabo, al final siempre había una persona que cubría. El agent no tiene esa persona que cubra: enfrentado a decenas de tablas y a campos de “cliente” con criterios dispares, o responde mal o no se atreve a responder. Una parte importante de los pilotos que no llegan a producción muere por la ausencia de esta capa.

Así que el juicio de los tres gigantes es correcto y, además, muy coincidente: para que la IA entre de forma fiable en la empresa, primero hace falta una capa de definición de negocio legible por máquina y gobernada. Esto ya no hace falta discutirlo. Lo que de verdad hay que discutir es la siguiente pregunta: a quién debe pertenecer esta capa.

Tres direcciones correctas, tres candados distintos

Si despliegas sobre la mesa las propuestas de las tres, te topas con una coincidencia incómoda.

	Dónde se guarda la ontología	Quién la entiende	¿Puedes llevártela?
Palantir Foundry	Dentro de la plataforma de Palantir	Ingenieros residentes + herramientas de la plataforma	Atada a la plataforma; migrar = rehacer
Microsoft Fabric IQ	Dentro de OneLake / Fabric	Ecosistema de 365 y Fabric	Atada al stack de Microsoft
Grafo de conocimiento empresarial de Google	Dentro de Google Cloud	Ecosistema de Vertex y GCP	Atada al stack de Google

Hay que reconocerlo: cada una hace muy bien su trabajo en su propio terreno. La calidad del modelado de ontologías de Palantir es de verdad alta; Microsoft suelda la capa semántica a OneLake y 365, lo que para una empresa que usa Microsoft de arriba abajo resulta tan fluido que casi no hay fricción; y Google tiene músculo real en escala de datos y razonamiento sobre grafos. Todas te ayudan a ordenar tu negocio con claridad, y luego encierran esa claridad dentro de su propia plataforma.

Al llegar aquí, un veterano de TI dirá por reflejo: otra vez el bloqueo de proveedor, el problema de siempre.

Pero esta vez lo que más debería preocuparte no es el bloqueo. Esta vez hay un problema nuevo y peor. Antes de desmontarlo, hay que contar en serio el guion con el que gana la plataforma cerrada, porque no es nada débil.

Primero, el guion con el que gana la plataforma cerrada

Si solo sabes gritar “lo abierto es bueno”, eso es prédica, no análisis. La plataforma cerrada tiene cuatro cartas de verdad:

Primera, la calidad del modelado. Roer veinte años de sistemas heredados que arrastra una gran empresa hasta convertirlos en una ontología limpia y coherente es una ingeniería pesadísima. Palantir, con ingenieros residentes, alinea concepto a concepto, y esa calidad la comunidad de código abierto no la iguala a corto plazo. Una ontología mal hecha es peor que no tener ninguna.

Segunda, un responsable que responde. Cuando algo se tuerce, hay alguien que coge el teléfono, hay un SLA, hay un contrato que cubre. Para un CIO, “un único proveedor que asume la responsabilidad de toda la capa” vale dinero por sí solo: es lo que se llama one throat to choke, un único cuello que apretar.

Tercera, muchas empresas de verdad están “casi todas en una”. Si el 80% de tu negocio está en un único ecosistema, “lo mejor dentro del ecosistema” es, literalmente, lo mejor para ti, y las ventajas de la apertura simplemente no las vas a aprovechar.

Cuarta, la profundidad de integración. Dentro de un mismo ecosistema, los datos, la identidad y los permisos ya están ahí; el trabajo sucio que te ahorras se mide en meses-persona.

Estas cuatro cartas son reales. Así que la conclusión no es “las plataformas cerradas son una trampa”: para las empresas que cumplen sus premisas, a menudo son la respuesta correcta. El problema surge con empresas como Yuanfeng: sus premisas están dejando de cumplirse.

Esta vez el guion tiene un agujero nuevo: la fragmentación

Con el bloqueo de un solo proveedor, al menos la definición de tu negocio seguía siendo una copia completa; lo único es que no podías llevártela. Duele, pero está completa.

Tres gigantes construyendo ontologías cerradas a la vez fabrican otra cosa: fragmentación. El “cliente” de Yuanfeng no quedó bloqueado, quedó partido en tres, repartido en tres plataformas que no se reconocen entre sí. Esto duele mucho más que el bloqueo, y duele con razón: hay dos mecanismos que garantizan que no se cure solo.

La primera capa es el interés. Quizá pienses: ¿y no basta con que la ontología de Microsoft entienda el “cliente” de Salesforce? No, porque ninguna tiene incentivo para hacerlo. La ontología de cada una es su foso defensivo. Si Microsoft unificara por iniciativa propia la semántica de “cliente” entre ella y Salesforce, sería ayudar con sus propias manos al rival a mover sus datos con más facilidad y mercantilizarse a sí misma. Unificar es autolesionarse para todos y cada uno de los competidores. No es un descuido técnico, es una elección racional, así que esperar que cualquiera de ellas recoja la fragmentación es esperar en vano.

La segunda capa es la técnica. Aun dejando de lado el interés, la alineación semántica entre ontologías es de por sí un problema sin resolver: ¿el “cliente” del sistema A equivale a la “Account” del sistema B? Los criterios de los campos, los ciclos de vida, las reglas de deduplicación y qué cuenta como “la misma entidad” son distintos a ambos lados. Y esto la IA tampoco lo puede hacer de forma fiable y automática; al contrario, el agent se equivoca precisamente por faltarle esta capa de definición determinista. Volviendo al Grupo H: dejar que el agent adivine por su cuenta “si estos tres registros son la misma empresa”, el coste de que se equivoque son esos varios millones.

Resumido en una frase: crees que compraste tres herramientas, pero en realidad compraste tres “fuentes de la verdad” que no se reconocen entre sí. Cuantos más sistemas, más adquisiciones y más aislamientos por cumplimiento, más grave es la fragmentación, y la era de los agents ha amplificado precisamente su coste, porque el cerebro humano todavía puede alinear a duras penas tres sistemas a mano, pero el agent no: necesita una capa de definición determinista y consistente entre sistemas para poder razonar.

Para que la fragmentación no ocurra, lógicamente solo hay una salida: la definición del negocio no puede pertenecer a ninguna plataforma que compita en la carrera, tiene que ser una capa neutral, una definición que poseas tú y que las herramientas de las tres puedan leer. La plataforma cerrada, por su estructura, no puede dártelo: son competidoras de la carrera, no pueden ser árbitro al mismo tiempo.

Cómo saber si te estás fragmentando

Esto no es abstracto, tiene síntomas tempranos muy concretos. Contrasta los siguientes puntos: si cumples tres o más, la fragmentación ya está ocurriendo en tu empresa:

El mismo “cliente / pedido / equipo” tiene criterios distintos en sistemas distintos, no cuadran, y cada vez que haces un informe hay que cruzarlos a mano.
Cuando le pides al agent que responda una pregunta que cruza sistemas, o se va por las ramas o solo acierta la mitad (vio un sistema, no vio el otro).
Cada vez que conectas un sistema nuevo, tienes que volver a enseñarle a la IA “qué es esto y qué significan los campos”.
Una adquisición lleva más de un año cerrada y los datos maestros de ambas partes siguen sin unificarse de verdad; cada uno reporta por su lado.
El cumplimiento exige aislar cierto tipo de datos, así que la misma entidad acaba almacenada en varias copias que no se reconocen entre sí.

Antes de perder al Grupo H, Yuanfeng cumplía cuatro de estos cinco puntos. En su momento se trataban todos como “pendientes de gobierno de datos”, y nadie cayó en que en realidad eran una mina que un agent acabaría pisando tarde o temprano.

Primero, un jarro de agua fría: lo abierto no es la bala de plata

Llegados aquí hay que parar honestamente, o esto acaba siendo vender crecepelo.

Primero, cambiar la definición a un protocolo abierto no fusiona automáticamente los tres “clientes” de Yuanfeng en uno solo. El modelado semántico, la deduplicación y la alineación de criterios que toca hacer hay que hacerlos igual; en esa parte no hay bala de plata, y no te creas a nadie que diga lo contrario. Lo que de verdad cambia con la apertura es la propiedad de ese trabajo penoso: la definición que hoy alineas con esfuerzo queda escrita en tu propio repositorio, no sedimentada en el backend de alguna plataforma. El año que viene, cuando cambies de modelo, de nube o te adquieran, lo que rehaces son las conexiones, no la definición en sí.

Segundo, lo “abierto” tampoco garantiza por sí mismo la victoria. Históricamente, para que un estándar abierto se imponga de verdad suele hacer falta además una implementación de referencia lo bastante buena y un ecosistema activo; con solo publicar el protocolo, sin que nadie lo haga usable, también se enfría. Así que elegir lo abierto es apostar a que “alguien lo va a hacer sólido”, y eso es un juicio con riesgo de ejecución, no una victoria segura.

Pero presta atención al peso de estos dos jarros de agua fría: dicen que “lo abierto también cuesta esfuerzo y tiene riesgo”, no que “lo cerrado sea mejor”. En comparación, el riesgo a la baja de encerrar la definición del negocio en una plataforma —es decir, la fragmentación de Yuanfeng— es mucho mayor y mucho más difícil de revertir. Ningún lado es gratis; solo que uno de ellos te deja el activo más crítico en tus propias manos.

La capa de la que todos dependen acaba siempre siendo neutral

El patrón en sí no es nuevo, pero vale la pena contarlo con ejemplos nuevos, porque está ocurriendo una y otra vez.

La “capa de definición” de la que depende todo un ecosistema acaba siempre tendiendo a la neutralidad. El ejemplo más antiguo es SQL: los fabricantes de bases de datos se masacran en un océano rojo, pero el lenguaje de consulta en sí es público. Más recientes, y más reveladores, son estos dos: OpenTelemetry —la definición de datos del mundo de la observabilidad, a la que se conectan todos los proveedores de monitorización, alojada por la neutral CNCF, sin que nadie pueda monopolizarla— y LSP (Language Server Protocol), abierto por la propia Microsoft y que precisamente por ser abierto fue adoptado por todos los editores y se convirtió en estándar de facto.

El ejemplo de LSP es especialmente jugoso, porque es algo que Microsoft demostró con sus propias manos: abrir la capa de definición y ganar dinero con la mejor implementación gana más que encerrarla. La capa semántica de negocio es de la misma clase: en el futuro dependerán de ella a la vez tus aplicaciones, tus agents, tu sistema de auditoría, y además las herramientas de los tres proveedores. Una capa de la que dependen tantas partes no puede, lógicamente, ser propiedad privada de ninguna de ellas a largo plazo. O se vuelve neutral, o sigue fabricando la fragmentación de Yuanfeng.

Qué pinta tiene esa capa neutral

Después de tanto hablar, echemos un vistazo al objeto real. Lo importante no es la sintaxis, sino dónde está, si te la puedes llevar y si puede recoger la fragmentación.

Supongamos que Yuanfeng hubiera construido “cliente” como una definición neutral desde el principio: conectaría cada uno de los tres sistemas como una fuente de datos, modelaría cada uno como objetos y los alinearía en un único “cliente” gobernado mediante una clave compartida (el NIF).

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Cliente',
  fields: {
    name: Field.text({ label: 'Nombre del cliente', required: true }),
    tax_id: Field.text({ label: 'NIF' }), // clave compartida para alinear "el mismo cliente" entre sistemas
  },
});

Esta definición vive en tu repositorio de Git: se puede diff-ear, revisar y migrar. Y lo que puede hacer a continuación es lo verdaderamente clave: convertir “llevable” en una acción demostrable, no en una promesa.

git add crm/*.ts          # la definición entra en tu control de versiones: auditable, reversible
os start   # la misma definición, corriendo en tu propia infraestructura
# y luego apunta cualquier modelo a ella: Claude, GPT, Gemini, da igual; el runtime no cambia

Ahora volvamos a hacer esa pregunta crítica: “¿Qué riesgo de renovación tiene el Grupo H el año que viene?”. El agent se enfrenta a un único “cliente” unificado, con permisos y auditoría: los pedidos están sanos, pero encima hay dos quejas escaladas a la cúpula directiva y una disputa de cobro de 90 días. Responderá: “Riesgo alto, conviene intervenir cuanto antes”. El mismo modelo, la misma pregunta, y solo porque la definición de abajo ya no está fragmentada, la conclusión pasa de “perder varios millones” a “avisar con un trimestre de antelación”.

Este es el reparto de papeles entre ObjectStack y ObjectOS, y también su respuesta a esta carrera:

ObjectStack: el protocolo abierto que describe el negocio (Apache 2.0), que vive en tu repositorio y que los agents de las tres pueden leer;
ObjectOS: el runtime de esa definición, que corre en tu propia infraestructura, fuerza los permisos y registra la auditoría.

La capa de definición es neutral, la capa de ejecución hace negocio. La misma relación que entre SQL y los fabricantes de bases de datos, o entre LSP y los fabricantes de editores.

Cierre

Esto no es una cuestión ideológica de “¿qué es mejor, lo abierto o lo cerrado?”. Es una cuenta aritmética más fría: cuando tu combinación de proveedores acabe cambiando —multimodelo, multinube, adquisiciones, aislamiento por cumplimiento; va a cambiar seguro—, en ese momento, ¿quién tiene en sus manos la definición de tu negocio?

Los tres gigantes han demostrado al sector, con dinero contante y sonante, que esta capa vale la pena. Pero al mismo tiempo han puesto esta cuenta aritmética delante de cada empresa. Los tres “clientes” de Yuanfeng no fueron un accidente técnico, fueron el coste inevitable de entregar la definición; y aquel Grupo H clasificado por error como “riesgo bajo” no es más que la primera factura.

La capa de la que todos dependen nunca ha pertenecido a largo plazo, históricamente, a una sola empresa. Esta vez no hay razón para que sea distinto.

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

Define tu primer objeto de negocio, haz que sus datos vengan de dos de tus sistemas actuales y luego haz git commit en tu propio repositorio. En ese momento, la definición del negocio habrá vuelto a tus manos, y no al backend de nadie.