Ontología para IA empresarial: por qué la definición y el runtime deben ser abiertos

En resumen: este artículo sostuvo en junio de 2026 que tanto la definición tipada de la aplicación como el runtime que la ejecuta deberían ser abiertos. Desde entonces, el sector ha concedido por su cuenta parte de ese argumento. Ontology MCP de Palantir pasó a disponibilidad general la semana del 16 de junio de 2026 —cuatro días después de publicarse este texto—, haciendo que los objetos y las acciones de una ontología sean invocables por cualquier agent a través de un protocolo abierto; en agosto, Palantir empezó a mover las definiciones de ontología a un repositorio versionado. La portabilidad la deciden tres capas —interfaz, definición, runtime— y 2026 abrió la primera, empezó a abrir la segunda y dejó la tercera exactamente donde estaba. El runtime es la última capa cerrada, y es la mitad de este argumento que todavía merece discutirse.

Empecemos con una historia que probablemente haya visto suceder.

Una empresa lanza un proyecto de «asistente de IA». Primera semana: la demo es deslumbrante. Alguien exporta una copia de los datos de clientes, se la pasa a un modelo, y este realmente puede responder «¿qué cuentas de la región Este tienen riesgo de no renovar?». La dirección lo ve y aprueba de inmediato un piloto más grande.

Mes tres: toca conectar los datos de producción. Entra el equipo de seguridad y hace tres preguntas:

• ¿Qué datos puede ver la IA? Si el comercial A pregunta por el «ranking de rendimiento de toda la empresa», ¿leerá en voz alta las comisiones de los demás?
• Va a ejecutar acciones — cambiar un descuento, enviar un contrato. ¿Con los permisos de quién? Cuando algo salga mal, ¿quién responde?
• Cuando auditoría pregunte «quién aprobó este descuento», ¿dónde está el registro de la parte que hizo la IA?

El equipo del proyecto no tiene respuestas. No por dejadez, sino porque la arquitectura no contiene ninguna capa capaz de responder esas preguntas. Los datos están repartidos en una docena de sistemas. Los permisos viven dentro del código de cada aplicación. La regla de «aprobación de descuentos» existe sobre todo en la cabeza de un empleado veterano. La IA está mirando tablas crudas y endpoints crudos, y ninguna inteligencia puede leer las reglas de una empresa de un lugar donde nunca se escribieron.

Mes nueve: el piloto termina en silencio. El modelo no perdió por capacidad. Perdió porque nadie estuvo dispuesto a firmar.

La industria tiene un nombre para lo que faltaba: una ontología — una capa semántica estructurada y legible por máquinas que define explícitamente qué objetos de negocio existen, cómo se relacionan, quién puede hacer qué con ellos y dónde queda registrada cada acción.

Lo que Palantir vio correctamente

La empresa que convirtió la ontología de concepto de investigación en hecho comercial es Palantir. Merece la pena mirar con honestidad por qué tuvo éxito: cuanto más justa la mirada, más afilada la pregunta que viene después.

Palantir Foundry hace dos cosas esenciales. Primero, integra los datos dispersos de una empresa en una capa de ontología unificada: clientes, equipos y pedidos dejan de ser docenas de tablas y se convierten en objetos de negocio tipados, con relaciones y propiedades. Segundo, canaliza toda operación de escritura a través de Actions gobernadas — cada una validada, con permisos y completamente auditada. A partir de 2023, AIP apuntó esta arquitectura directamente a los grandes modelos de lenguaje: el LLM nunca toca la base de datos; solo puede invocar herramientas gobernadas expuestas por la capa de ontología. Los modelos se pueden cambiar. La frontera permanece.

¿Por qué es caro? Porque el problema que resuelve es genuinamente caro. Desenredar veinte años de sistemas heredados acumulados en una ontología limpia exige que los Forward Deployed Engineers de Palantir trabajen sistema por sistema, conciliando conceptos uno a uno: ingeniería intensiva en trabajo humano en el sentido más literal. Sus clientes son gobiernos, defensa, banca y energía, para quienes «cada paso de la IA dentro de los permisos, cada paso registrado» es un requisito duro con presupuesto a la altura. Los contratos empiezan en millones, y los clientes renuevan, porque responde de verdad a las tres preguntas que más le importan a un CISO. Las mismas tres de la historia inicial.

Así que la capitalización de Palantir no demuestra una máquina de ventas. Demuestra un juicio de arquitectura: para que la IA entre en la empresa, primero tiene que existir una capa semántica de negocio gobernada. Ese juicio ya no necesita defensa.

Lo que hay que repensar es la siguiente pregunta: ¿qué forma debe tener esta capa? Porque algunas cosas están cambiando.

El software lo escribe cada vez más la IA

El primer cambio es el más visible: las propias aplicaciones las escribe cada vez más la IA.

«Construir un sistema a medida de aprobación de gastos para un equipo de 50 personas» era económicamente absurdo: el coste de desarrollo superaba el dolor. Hoy un agent de IA lo entrega en una tarde. El software de negocio a medida está pasando de bien escaso a producto corriente, y la demanda total va a explotar.

Fíjese en dónde explota: en la cola larga. En equipos que jamás aparecerán en la lista de prospectos de ningún proveedor enterprise — sin proceso de compras, sin presupuesto de implantación, sin comités de POC. Simplemente le dicen a un agent «construye algo que funcione» y empiezan a usarlo el mismo día.

Un modelo que funciona con ingenieros desplegados y contratos millonarios no puede llegar estructuralmente a este mercado. No es una crítica; sencillamente son dos mercados distintos. Pero cada sistema de este nuevo mercado chocará contra las mismas tres preguntas de seguridad del principio — solo que, cuando ocurra, no habrá ningún ingeniero desplegado al lado.

El próximo que elige la tecnología es un agent

El segundo cambio es más silencioso pero más profundo: el propio acto de elegir tecnología está pasando de los humanos a la IA.

Pídale hoy a un agent que «construya un sistema de gestión de clientes» y lo más probable es que eche mano de Next.js y Postgres. ¿Por qué? Nadie compró anuncios en su cabeza. Esas tecnologías son abiertas, están exhaustivamente documentadas y tienen presencia masiva en sus datos de entrenamiento. El agent ha visto cientos de miles de usos y sabe dónde está cada bache.

Esto crea algo que antes no existía: para la tecnología orientada a desarrolladores, el texto público del protocolo y el código abierto son ahora el propio canal de distribución. Cuanto más abierto es un protocolo — cuanto más se discute, cuanto más código hay para aprender —, mejor lo entiende la siguiente generación de modelos y más agents lo eligen por defecto. El bucle se alimenta solo.

Una plataforma cerrada tiene dos salidas. La cara: abrir el formato en sí, para que los modelos lo aprendan y los agents lo elijan sin que nadie se lo sugiera. La barata: mantener el formato cerrado y adoptar un protocolo abierto en el borde; los agents pueden entonces invocar la plataforma aunque sigan sin poder aprenderla.

Cuando este artículo se publicó, afirmaba que una plataforma cerrada sencillamente no podía entrar en el bucle. En menos de una semana quedó claro que era demasiado fuerte: los incumbentes tomaron la salida barata, y funcionó. Lo que sobrevive es la afirmación más estrecha, y es la que importa: una interfaz que un agent puede invocar no es una definición de la que un agent pueda aprender, y ninguna de las dos es un runtime que puedas llevarte. Lo que los incumbentes hicieron al respecto —y lo único que no hicieron— está más abajo.

Un momento: ¿no han ganado antes las plataformas cerradas?

A estas alturas debería haber surgido una objeción inteligente: lo abierto no siempre gana. La era de la nube la ganó AWS. El móvil lo ganó el iPhone. Ambos cerrados.

La objeción merece una respuesta seria, porque responderla expone el patrón real.

Mire cómo gana dinero AWS: aloja Linux, Kubernetes, Postgres — estándares abiertos de arriba abajo. El iPhone es cerrado, pero cada paquete que envía viaja sobre TCP/IP y HTTP. Vaya más atrás: los proveedores de bases de datos se mataron entre sí mientras SQL, el lenguaje en sí, seguía siendo público; las guerras de orquestación de contenedores terminaron con todos corriendo sobre el mismo formato abierto de imágenes OCI.

El patrón es notablemente consistente: la base portable de la que depende todo un ecosistema tiende a acabar abierta — tanto la definición como el runtime básico que la interpreta. Los proveedores siguen obteniendo ingresos recurrentes, pero de la experiencia de producción operada: hosting, actualizaciones, seguridad, rendimiento, soporte y responsabilidad. AWS es la mayor prueba: Linux, Kubernetes y Postgres siguen abiertos; AWS cobra por operarlos con fiabilidad.

Una capa semántica de negocio es exactamente esa base. Sus aplicaciones, agents y sistemas de auditoría dependerán del modelo de objetos, las reglas de permisos, los flujos de aprobación y la semántica del runtime que los aplica. Cuantas más cosas dependan de ella, menos debería vivir cualquiera de las dos mitades dentro de la plataforma de un proveedor. Las definiciones deben ser archivos legibles y versionados en su repositorio; un runtime compatible debe poder autohospedarse y sustituirse. Un archivo abierto que solo ejecuta un motor de pago no es realmente portable.

Las empresas pasaron veinte años liberando sus datos de un sistema cerrado tras otro. No deberían pasar la era de la IA encerrando de nuevo algo aún más fundamental: la definición del propio negocio.

Ontology MCP abrió la interfaz. El runtime siguió cerrado.

Ese patrón se puso a prueba casi de inmediato, y el resultado es mejor evidencia de lo que fue la predicción.

Cuatro días después de publicarse este artículo, Ontology MCP de Palantir pasó a disponibilidad general en los enrollments de Foundry, a partir de la semana del 16 de junio de 2026 (documentación de Palantir). Los tipos de objeto, los tipos de acción y las funciones se proyectan como herramientas del Model Context Protocol, de modo que cualquier agent compatible con MCP puede leer la ontología y poner en marcha sus flujos sin escribir código de integración por cada framework. Microsoft está previsualizando la misma interfaz en Fabric IQ.

Después, en agosto, Palantir lanzó en beta la ontología como código: tipos de objeto, enlaces, interfaces y acciones declarados en TypeScript dentro de un monorepo, siendo esas definiciones de código la fuente de verdad.

Junta los dos movimientos y el argumento del sustrato de la sección anterior se sostiene, pero no por la razón con la que se escribió. El sustrato se está abriendo. Se está abriendo porque los incumbentes lo abrieron ellos mismos, en el orden que menos les costaba:

Capa	Qué es	Dónde la dejó 2026
Interfaz	Cómo invoca un agent la ontología	Abierta. MCP, adoptado por los propios proveedores
Definición	Los objetos, las acciones y los permisos	Abriéndose en la forma. Declarada como código en un repositorio; sigue materializándose sobre la plataforma de un proveedor
Runtime	Lo que ejecuta una acción y aplica las reglas	Sin moverse. Ningún proveedor entregó uno que puedas ejecutar en otro sitio

Lee despacio la tercera fila, porque ahí está el argumento entero.

Una interfaz abierta hace que una ontología sea invocable. Las definiciones en un repositorio la hacen legible y revisable. Ninguna de las dos la hace ejecutable en otro sitio. La portabilidad de la definición no es la portabilidad del sistema: un monorepo lleno de código de ontología sigue materializándose sobre un enrollment de Foundry. Y como la superficie de herramientas se proyecta desde la definición, quien ejecuta la proyección decide cuáles son las herramientas. Un archivo de definición no ejecuta nada por sí solo.

Ese es el número sobre el que gira esta actualización. Aplica la regla de proyección documentada de Palantir a una aplicación mediana —12 tipos de objeto, 30 tipos de acción, 6 funciones expuestas— y obtienes 37 herramientas MCP que hablan un protocolo abierto, y exactamente un motor debajo capaz de responder a cualquiera de ellas. La interfaz se volvió portable. La dependencia no se movió ni un centímetro.

La objeción más fuerte, planteada con justicia: casi todo lo que un equipo quiere de la portabilidad ya está sobre la mesa. Puedes leer tu modelo, revisarlo como un diff, apuntar cualquier agent hacia él y —para la semántica analítica— intercambiarlo mediante una especificación neutral que llegó al Apache Incubator en 2026. Si tu ontología solo responde preguntas, eso se acerca bastante a ser suficiente, y este artículo sería deshonesto si fingiera lo contrario.

La respuesta es la misma línea que separa a una capa semántica de una ontología desde el principio: se sostiene justo hasta que algo tiene que ocurrir. En el momento en que una acción expuesta cambia un registro, todo lo que de verdad te importa —la comprobación de permisos, la transacción, la aprobación por encima de un umbral, la línea de auditoría— es una propiedad del motor, no del archivo ni del protocolo. Puedes exportar la frase. No puedes exportar la aplicación de la regla.

Llama a ese hueco la última capa cerrada. No es una acusación; es una descripción de dónde se detuvo la categoría. Dos de las tres capas se abrieron en nueve meses, en buena medida por su propia inercia. La tercera no se movió en absoluto, porque es la única capa que un negocio de plataforma no puede abrir sin cambiar lo que vende.

Cómo es esta «definición» en la práctica

Basta de abstracción. Aquí hay un objeto de oportunidad de venta en la definición tipada de aplicaciones ObjectStack, abreviado de un ejemplo real:

export const Opportunity = ObjectSchema.create({
  name: 'crm_opportunity',
  label: 'Oportunidad',
  fields: {
    name: Field.text({ label: 'Nombre', required: true }),
    account: Field.lookup('crm_account', { label: 'Cuenta', required: true }),
    amount: Field.currency({ label: 'Importe', min: 0 }),
    probability: Field.percent({ label: 'Probabilidad', defaultValue: 50 }),
    expected_revenue: Field.formula({
      label: 'Ingreso esperado',
      expression: cel`amount * probability / 100`,
    }),
    discount_percent: Field.percent({ label: 'Descuento %', max: 100 }),
  },
});

// Los permisos se declaran igual: ventas puede leer y escribir, nunca borrar
export const SalesUser: Security.PermissionSet = {
  name: 'crm_sales_user',
  objects: {
    crm_opportunity: { allowRead: true, allowCreate: true, allowEdit: true, allowDelete: false },
  },
};

La clave no es la sintaxis. La clave es que estas pocas docenas de líneas son el sistema. El runtime open source de ObjectStack lee la definición y deriva las tablas, la API REST, la interfaz de administración y las herramientas MCP, además de aplicar permisos y auditoría. ¿Los descuentos superiores al 30 % necesitan aprobación de finanzas? Eso es una definición de flujo asociada al objeto: igual de declarativa, igual de versionada. ObjectOS añade alrededor de la misma app la experiencia comercial de producción — Build y Ask en el navegador, revisión y aprobación en equipo, operación en nube gestionada o despliegue privado, SSO y soporte — sin volver propietarios la definición ni el motor.

De ahí se siguen directamente tres consecuencias:

1. Las tres preguntas de seguridad del principio obtienen respuestas estructurales. Qué puede ver la IA — está escrito en el conjunto de permisos. Con qué permisos actúa — actúa como el usuario que ha iniciado sesión, lo aplica el runtime de ObjectStack, no se suplica en el prompt. Dónde está el registro de auditoría — humanos y agents escriben en el mismo libro: quién, qué, cuándo, por qué. Cumplimiento lee un solo registro, no dos.
2. El cambio de negocio se convierte en revisión de código. ¿La IA quiere añadir un recordatorio de renovación? Lo que envía es un diff de metadatos: qué campos cambian, qué permisos se mueven, todo visible de un vistazo. Y como las definiciones están versionadas, los errores se revierten.
3. El sistema entero cabe en la ventana de contexto de un agent. Un módulo enterprise típico se condensa de decenas de miles de líneas de CRUD y pegamento a unos cientos de líneas de declaraciones — lo bastante pequeño para que una IA lea cada dependencia de principio a fin y luego refactorice con seguridad a través de datos, API, interfaz y permisos en un solo cambio. Esa es la línea entre «IA como co-mantenedora» e «IA como autocompletado».

La definición y el runtime portable pertenecen a la comunidad; la operación es el negocio

Ahora el argumento se cierra sobre sí mismo.

El juicio de la ontología es correcto — Palantir lo demostró para toda la industria. Cuando este artículo se publicó, «definición abierta, motor exclusivo de pago» era un modo de fallo que valía la pena advertir por adelantado. Nueve meses después ya no es una advertencia: es una descripción justa de dónde acabó asentándose la categoría, alcanzada una decisión razonable tras otra por proveedores que abrieron todo salvo aquello que venden. Eso hace más fácil, no más difícil, enunciar la alternativa: la definición tipada de negocio y un runtime gobernado portable pertenecen al ecosistema abierto; el producto de pago es la experiencia de producción operada que los rodea.

Esa es exactamente la división del trabajo entre ObjectStack y ObjectOS:

• ObjectStack es una ontología de negocio abierta (open business ontology): la definición tipada de la aplicación junto con el runtime open source que la ejecuta (Apache 2.0). Objetos, relaciones, permisos, flujos, APIs, UI y herramientas de IA se definen una vez en el repositorio; el runtime deriva la base de datos, la API REST, la UI renderizada y el servidor MCP, y aplica permisos y auditoría en cada llamada. Tanto la definición como el motor son versionables, autohospedables y portables — y esa segunda mitad es justo la que el resto de la categoría dejó cerrada.
• ObjectOS es la plataforma comercial de producción alrededor de esas mismas apps ObjectStack. Vende Build y Ask en el navegador, revisión y aprobación en equipo, operación en nube gestionada o despliegue privado, SSO, controles enterprise y soporte. No es un motor de ejecución cerrado que vuelva a quitarle la ontología.

A un lado: una definición de aplicación y un runtime portable que cualquier equipo o agent puede entender, autohospedar y llevarse. Al otro: la experiencia de producción por la que las empresas pagan de verdad — autoría colaborativa, aprobaciones, hosting, despliegue privado, SSO, soporte, actualizaciones y responsabilidad operativa. La aplicación y su runtime base son suyos. Operarlos de forma fiable para un equipo es el negocio.

Cierre

Aquel piloto de IA que murió en el mes nueve nunca perdió contra la capacidad del modelo. Perdió contra la ausencia de una capa semántica que un equipo de seguridad pudiera firmar. El trabajo de los grandes proveedores ha demostrado cuánto vale esa capa, y 2026 dedicó nueve meses a demostrar algo más estrecho y más útil: las partes que salían baratas de abrir ya están abiertas. La interfaz es un protocolo público. La definición es un archivo que puedes leer. Lo que queda es el motor que convierte lo segundo en lo primero y aplica las reglas mientras lo hace — y en esa capa no se abrió nada.

Así que la pregunta que este artículo hizo en junio tiene ahora una forma más afilada. Ya no es «¿debería ser abierta la ontología?» — eso está resuelto, y lo resolvieron los proveedores. Es: cuando la última capa cerrada es precisamente la que ejecuta tus reglas de negocio, ¿de quién quieres que sea ese motor?

Si quiere comprobar si algo de esto es real:

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

En cinco minutos, defina su primer objeto de negocio y vea cómo el runtime abierto de ObjectStack lo convierte en una tabla, una API, una interfaz de administración y una herramienta que una IA puede invocar con seguridad. Cada llamada lleva permisos y queda registrada. Si su equipo quiere Build y Ask en el navegador, revisión y aprobaciones compartidas, nube gestionada o despliegue privado, SSO y soporte, ObjectOS opera esa misma app ObjectStack; no la sustituye por un formato propietario ni un motor exclusivo.