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

En resumen: Palantir demostró que la IA necesita una capa semántica de negocio gobernada para entrar en la empresa. Pero esa capa debe ser una definición de aplicación abierta y tipada con un runtime open source portable, no un «archivo abierto» que siga dependiendo del motor de un solo proveedor. Abre la definición y la base de ejecución; cobra por la experiencia de producción operada.

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 no puede entrar en ese bucle. Su formato de ontología, su semántica de acciones y su modelo de permisos están detrás de muros de documentación y contratos. Los modelos no pueden aprenderlo; los agents no pueden empezar por autoservicio. Puede ser seleccionada por un proceso de compras, pero no puede ser elegida por un agent. A medida que más software lo escriben agents, eso deja de ser un problema de marketing. Es ausencia del canal.

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.

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. Pero la forma sana de esta capa en la era de la IA no es «definición abierta, motor exclusivo de pago». Es esta: 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 la definición abierta y tipada de la aplicación y su runtime open source (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.
• 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. El siguiente trabajo es conseguir que deje de ser un lujo de las grandes corporaciones.

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.