Cómo construimos la ontología de una empresa

Seis capas, unas reglas y un procedimiento: el modelo que escribimos antes de encender ningún agente. Y el momento en que a un cliente le decimos que le basta con algo mucho más barato.

El agente que una empresa quiere de verdad hace trabajo. Procesa el pedido que entró por correo. Bloquea el envío que no debe salir. Prepara el abono y busca a alguien que lo firme.

Para hacer eso sin riesgo, el software necesita algo que casi ninguna empresa tiene por escrito: un modelo de cómo funciona su negocio.

Nosotros construimos ese modelo antes de construir ningún agente. Lo llamamos la ontología: el modelo operativo de la empresa puesto por escrito. Qué cosas existen, qué funciones calculan sobre ellas, qué acciones pueden cambiarlas y quién firma cada una.

Qué llamamos ontología, y de dónde viene la palabra

La palabra es prestada. Todas las plataformas de datos venden ya algo parecido: la capa semántica, que es un diccionario de métricas. Cada una se define una vez y así todas las herramientas calculan la misma cifra.

Viene de la arquitectura que Palantir construyó para gobiernos y multinacionales, cuya documentación insiste en un punto: una ontología integra datos, lógica, acción y seguridad. Nosotros la aplicamos en otro sitio. Una empresa mediana no tiene departamento de datos ni tres años por delante. Tiene un ERP, que es donde viven pedidos, facturas y stock. Tiene un CRM, donde viven clientes y reclamaciones. Tiene una hoja que alguien mantiene a mano. Y tiene a una persona que ya sabe cómo debería funcionar todo.

Construir sobre eso es otro método, y es el nuestro.

La capa semántica cumple lo que promete: todos leen los mismos números. Lo que no lleva dentro es autoridad para cambiar ninguno de ellos. Y a nuestros agentes se les contrata precisamente para eso.

Un diccionario de métricas describe. Una ontología, además, autoriza.

Las seis capas que construimos, y en qué orden

La conversación es la única capa que la gente nota. Debajo hay cinco más. Cada una funciona solo porque funciona la de abajo.

Abajo del todo conectamos, cada sistema por su vía. Encima modelamos, que es poner el negocio por escrito para que lo entienda una máquina. Después replicamos en un gemelo lo que haya que cruzar: una copia espejo donde dos tablas que nunca se han visto pueden por fin ponerse una al lado de la otra.

Sobre esas tres viven las otras. Los agentes ejecutan. El gobierno retiene cada escritura hasta que alguien la firma. Y la conversación es por donde pregunta la gente.

La pila es valiosa antes de estar terminada, y eso le ahorra dinero al cliente: un modelo con funciones contesta el crédito disponible de un cliente mucho antes de que ningún agente escriba nada.

Cómo autorizamos cada cambio en los sistemas del cliente

Una regla gobierna todo el lado de escritura: nada escribe en un sistema del cliente salvo a través de una acción tipada.

Una acción tipada es un cambio declarado antes de que ningún agente pueda ejecutarlo. Su definición lleva todo lo que hace falta para que sea seguro: parámetros, validaciones, quién puede ejecutarla, si alguien tiene que firmar, cuánto tiempo se puede deshacer y una clave de idempotencia.

Esa clave es una huella que hace que una operación repetida se ejecute una sola vez. Se entiende con un ejemplo aburrido. Llega un pedido por correo, el agente lo procesa, y el servidor de correo entrega el mensaje dos veces. Sin la clave, el pedido se crea dos veces. Con ella, el segundo intento muere en silencio.

Un pedido duplicado hace más daño a la confianza que un mes de paneles equivocados.

Quién calcula las cifras, y por qué nunca el modelo

Un total improvisado es la forma más rápida de perder a una directora financiera. Los modelos de lenguaje leen bien la intención y calculan mal, y está medido: en 2023 acertaban el 55 y el 59 por ciento de las multiplicaciones de tres cifras, y en 2024 una frase de más en el enunciado provocaba caídas de acierto de hasta 65 puntos. Los de hoy puntúan mejor; el error sigue apareciendo cuando el problema se complica.

De ahí la segunda regla: un modelo de lenguaje nunca calcula una cifra.

Cada número que ve una persona sale de una función determinista, que con los mismos datos devuelve siempre el mismo resultado. El modelo solo lo presenta.

Las preguntas llegan a dos niveles y nuestras funciones también. Una función base lee una cosa: las facturas impagadas, el límite de crédito. Una función de alto nivel compone varias y devuelve la respuesta con su desglose.

Pide el crédito disponible de un cliente y ves el límite, menos las impagadas, menos los pedidos pendientes. Con cada sumando delante. El cliente quiere ver la resta, y el día que alguien discute la cifra, discute una factura.

Cifras de ejemplo de diseño, no de un cliente: enseñan la forma del desglose, que es lo que se discute cuando alguien discute.

Partir las funciones así parte también las respuestas. La lista de pedidos pendientes es dato y vuelve tal cual. «Cuál de estos pinta peor» necesita al modelo, y esa parte va marcada como lectura suya, junto a cifras que él no ha calculado.

Cómo cruzamos datos de sistemas que no se hablan entre sí

Las preguntas difíciles del día a día cruzan dos sistemas que nunca se han visto. Qué clientes con facturas impagadas abrieron una reclamación este mes. El CRM sabe de reclamaciones. El ERP sabe de facturas. Y no hay ningún sitio donde esas dos tablas se puedan cruzar.

Nuestra respuesta es un gemelo: una base espejo con copias de solo las tablas que el modelo necesita. Cada copia declara su cadencia, porque la frescura tiene precio. Los saldos, cada treinta minutos. El catálogo, una vez al día.

Lo que tiene que estar al segundo se consulta en vivo en el origen. El estado de un pedido hecho esta mañana, por ejemplo. Los documentos ya funcionan así en nuestro producto: los manuales y las páginas web entran en un índice consultable que responde citando su fuente.

La conexión es la parte menos vistosa. Cuando el ERP de un cliente no tiene API, ponemos un ordenador pequeño en su oficina con un servidor MCP privado, que es un conector que expone las consultas acordadas. Llega a la base de datos en local y alimenta el gemelo por un túnel cifrado.

El gemelo es de solo lectura para todos los agentes. Lo que esté mal en una réplica se arregla en el sistema de origen, con una acción, nunca en la copia.

Dónde vive es la primera pregunta de cualquier equipo legal. Cada cliente tiene su propia base de datos, aislada del resto, en nuestra infraestructura dentro de la Unión Europea. El gemelo es un esquema aparte dentro de esa misma base, lo bastante cerca para cruzarlo en una consulta.

Las credenciales no se guardan ahí. Viven en un almacén separado, así que un volcado completo de la base de un cliente no expone ni una contraseña.

Y cuando una fuente deja de sincronizar, el gemelo lo dice. La respuesta llega sellada: este saldo es de las 05:12, el ERP lleva tres horas sin sincronizar.

Qué parte de la empresa se modela primero, y cómo

Modelar toda la empresa primero es la forma más común de fracasar, y el fracaso está contado: Gartner espera que más del 40 por ciento de los proyectos de IA agéntica se cancelen antes de que acabe 2027. Lo hemos medido sobre un ERP libre, para poder enseñar el número: un Odoo 19 recién instalado tiene 134 tablas, y con ocho módulos de un ERP corriente encima (ventas, compras, almacén, contabilidad, fabricación, CRM, personal y proyectos) sube a 644. Un modelo que las refleje todas tarda tanto que, cuando está listo, ya nadie se acuerda de para qué era.

Construimos en la dirección contraria. El procedimiento cabe en seis pasos.

Ese procedimiento lo ejecuta un generador, y las personas deciden. Confirman lo que acierta, corrigen lo que malinterpreta y dicen qué se queda fuera.

El modelo se cambia como se cambia el código: en una rama que alguien revisa antes de fusionarla. Nadie edita a pelo el modelo vivo de una empresa que está funcionando con él.

Las tres clases de agente que construimos encima

La ontología existe para que los agentes se apoyen en ella. Construimos tres clases.

Los que responden, citando de dónde sale cada afirmación. Los que vigilan, disparados por reloj o por evento, y abren un caso cuando algo se desvía. Y los que actúan, que ejecutan trabajo de punta a punta y se paran a pedir firma donde una regla lo exige.

Cada clase se gana la siguiente. Primero responder. Luego vigilar. Luego actuar.

Cómo se corrige a un agente, y qué guardamos de cada sector

Cuando una persona corrige a un agente dos veces sobre lo mismo, eso se convierte en un hecho declarado, pegado al cliente al que pertenece. Ese cliente quiere la entrega en obra y no en su oficina.

El hecho lleva de dónde salió, caduca en una fecha, y cualquiera puede leerlo o borrarlo desde la ficha de ese cliente. Un agente que aprende en privado es un agente al que nadie puede corregir.

Los agentes verticales trabajan con el vocabulario y las reglas de un sector. Uno que procesa pedidos de un distribuidor industrial tiene que saber qué es una tarifa pactada. Uno de una aseguradora, qué es el apetito de riesgo.

Ese conocimiento del sector es la barrera y lo guardamos. Guardamos la forma, nunca el contenido: los datos de cada cliente viven en su propia base y sus nombres, sus clientes y sus cifras no salen de ahí. El segundo distribuidor industrial empieza con el mapa del sector, no con la empresa del primero.

Los cinco controles de la capa de gobierno

A una empresa grande le preocupa poco el software que contesta mal. Le preocupa el que actúa mal, y no es una manía suya: entre las empresas europeas que se plantearon usar IA y no la adoptaron, en la última encuesta de Eurostat, el 71 por ciento alegó falta de conocimientos propios, el 52 por ciento falta de claridad sobre las consecuencias legales y el 49 por ciento la protección de datos. Que la tecnología no les sirviera quedó el último, con un 21 por ciento.

La capa de gobierno decide si el resto merece confianza, y sus frenos actúan en un orden.

El primero es el que más se salta, y el que sale más caro: medir y congelar lo que cuesta hoy la tarea. La intuición no lo sustituye, y está medido: en un ensayo con dieciséis desarrolladores experimentados, creyeron que la IA les había hecho un 20 por ciento más rápidos y habían tardado un 19 por ciento más.

Ensayar sobre datos viejos sale más barato que las semanas en sombra, pero esos registros llegan incompletos. Una comparación hecha esta semana la comprueba cualquiera.

Las instantáneas van encadenadas por hash, o sea que cada una lleva la huella de la anterior. Meses después se audita un pedido de agosto con los números de agosto.

Y deja de ser una preferencia nuestra en cuanto el caso entra en el anexo de alto riesgo del Reglamento europeo de IA, que se aplica desde agosto de 2026.

Las demás reglas están en el informe: la ventana para deshacer, el menú cerrado de rechazos, el modelo exportable desde el primer día y el trato del contenido externo, que es dato y nunca una orden. Esa última no sobra: la inyección de instrucciones es el riesgo número uno de la lista de OWASP, y lo seguía siendo en agosto de 2026. El silencio tampoco firma: un caso que caduca sin respuesta no se ejecuta.

Cuatro sistemas nuestros funcionando hoy, con sus límites

Lo de arriba no es un plan. Hay tres modelos de estos en marcha y uno abierto al público, cada uno con sus cifras y su límite declarado, y cada uno está en un peldaño distinto de la escalera.

El de logística vigila un almacén automático en tiempo real, con veinticuatro reglas sobre los datos en vivo del gestor de almacén y del ERP: más de treinta millones de operaciones registradas y 460.000 ubicaciones. Los umbrales salen de medir esos mismos datos. Su límite está escrito y es el de un agente que vigila: detecta, explica y avisa, y no mueve una orden ni cambia una prioridad.

El de venta B2B recalcula cada noche la salud de 29.000 clientes sobre más de catorce millones de líneas de venta, y avisa al vendedor cuando una cuenta rompe su ritmo. El ritmo es el propio de cada cliente, medido sobre sus dos últimos años. Esa decisión es justo lo que se escribe en el modelo y no en la consulta de un informe: un umbral igual para todos habría dado por dormido a medio fichero de clientes.

El de soporte sube un peldaño y ya prepara respuestas. Cada tipo de asunto lleva su nivel de autonomía, del borrador sugerido a la respuesta verificada, y los niveles suben solo con aprobación y bajan solos si la calidad cae. Un tono negativo o una mención legal pasan siempre por una persona.

Y hay uno de cara al público: el asistente de una tienda especializada contesta sobre catálogo y condiciones, y arranca gestiones definidas contra el ERP de la tienda, una devolución entre ellas.

Los tres internos comparten el mismo primer paso, que es el que describe este texto: poner por escrito qué datos hay, qué procesos los mueven y qué reglas los gobiernan.

Tres errores nuestros y lo que cambiaron del método

Todo lo de arriba está escrito después de equivocarnos. Tres de esas equivocaciones explican por qué el procedimiento tiene los pasos que tiene.

El saludo en el idioma equivocado. Un asistente de cara al público contestaba el primer mensaje en español aunque el visitante hubiera escrito en otro idioma, y solo acertaba a partir del segundo. La causa no era la traducción: el idioma estaba tratado como una propiedad de cada mensaje y no del visitante. Ahora es estado de la sesión con una precedencia escrita, y esa precedencia se prueba con casos antes de encender.

El buzón que nadie puso en copia. Un agente de soporte se diseñó para leer un buzón corporativo al que las personas debían poner en copia. Durante semanas apenas entró correo. El sistema funcionaba perfectamente y no tenía nada que leer, porque dependía de un gesto humano nuevo, y un gesto nuevo no es un dato: es un supuesto. Desde entonces, cuando una fase depende de que alguien cambie una costumbre, eso se escribe como riesgo antes de empezar.

La clave que era de contabilidad. En un fabricante que vende a través de filiales, el campo que parecía identificar al cliente identificaba a quién se le factura, no quién compra. La distinción que su equipo comercial usa todos los días no estaba grabada en ninguna parte. Ese es el fallo que más veces hemos visto, y es la razón entera del segundo paso del procedimiento: leer una muestra real de registros antes de ponerle nombre a nada. Los nombres de columna mienten.

Cuándo le decimos a un cliente que no necesita una ontología

A muchas de las empresas que nos piden agentes les basta con la pieza barata, y se lo decimos en la primera conversación. Cuando el dolor son dos paneles que no cuadran sobre el último trimestre, una capa semántica cierra el caso con mucha menos maquinaria.

La pregunta que decide es otra. ¿Tiene el software que preparar o ejecutar alguna de las decisiones que la empresa toma cada día? Si la respuesta es sí aunque sea en una, las herramientas de informes se quedan cortas.

Hay una objeción justa a esa frontera, y nos la hacen clientes bien informados: los proveedores de capas semánticas están añadiendo agentes y escrituras, así que la línea se mueve cada año. Se mueve.

Lo que sobrevive es la lista de comprobación. Cuando una capa semántica gana acciones tipadas, funciones deterministas, firmas humanas y un registro que no se puede alterar sin que se note, se ha convertido en una ontología, la llame como la llame su página de precios.

Las cuatro fases, y qué se lleva el cliente en cada una

Empieza con una fuente conectada y leída. Eso solo ya contesta preguntas que hoy le cuestan a alguien una tarde de hoja de cálculo, y pasa antes de que se le haya puesto nombre a una sola entidad.

Después se escribe el modelo alrededor de los primeros agentes, de diez a veinticinco entidades. Las mismas preguntas empiezan a contestarse con las palabras de la empresa en vez de con nombres de tablas.

El primer agente solo responde, citando de dónde salió cada cifra: nadie ha firmado nada y no se ha escrito en ningún sitio. La primera acción tipada llega después, con quien la firma, su ventana para deshacer y su presupuesto.

En cada uno de esos pasos el modelo es exportable y está documentado. Si paramos en el paso dos, la empresa se queda con el mapa de sí misma que antes no tenía. Ese mapa vale lo mismo lo construyamos nosotros o lo construya otro.

Un ejercicio de una tarde, sin software

El primer ejercicio que hacemos con cada cliente cuesta una tarde y cero software.

Apunta las cinco decisiones que tu empresa ejecuta cada día. Levantar el bloqueo a un cliente. Aprobar un descuento. Reponer stock. Al lado de cada una, escribe cómo se ejecuta hoy: qué pantalla, qué persona, qué firma.

La mayoría de las empresas convivirán años con las dos capas, la que explica el negocio y la que puede tocarlo.

Esa lista, en lenguaje llano, es el primer borrador de una ontología.