La ontología como contexto del agente

Respuesta rápida:

Dar a un agente acceso a la base de datos no es darle contexto. Es darle un idioma que no habla y pedirle que adivine el resto.

Cuando un agente falla en una tarea de negocio, el diagnóstico habitual es «el modelo no es lo bastante bueno». Casi nunca es eso. El modelo no sabe qué es un cliente en esta empresa, qué diferencia hay entre un pedido y un albarán, ni quién puede aprobar una devolución. Y eso no está en ninguna tabla.

El cuello de botella no es el modelo

Un esquema de base de datos describe cómo se almacena la información: tablas, columnas, claves. No describe qué significa. cust_id_2 puede ser el cliente que factura o el que recibe; el esquema no lo dice y el agente tampoco lo adivina.

La salida habitual es meter esa explicación en el prompt. Funciona con cinco tablas. Con doscientas, el contexto no cabe, cambia cada semana y nadie sabe quién lo mantiene. Es deuda técnica disfrazada de texto.

Qué aporta una ontología

Una ontología describe el negocio en los términos del negocio. Tiene tres cosas que un esquema no tiene:

Objetos con nombre propio

Cliente, pedido, instalación, póliza, orden de trabajo. No tablas: conceptos, con sus propiedades y su definición acordada. Cuando dos departamentos discrepan sobre qué es un cliente activo, la ontología es donde se resuelve la discusión y queda escrita.

Relaciones explícitas

Un pedido pertenece a un cliente, contiene líneas, se sirve desde un almacén y genera una factura. Esas relaciones están declaradas, no deducidas de nombres de columna parecidos. El agente puede recorrerlas sin inventárselas.

Acciones con permisos

Aquí está la diferencia que importa para un agente que actúa. La ontología no solo dice qué es un pedido: dice qué se le puede hacer —cancelar, reprogramar, aplicar descuento—, con qué reglas y quién tiene permiso. Sin esa capa, cada acción se implementa a mano y los permisos acaban viviendo en el código de cada integración.

Es exactamente lo que explicamos al hablar de la Ontología de Palantir desde el gobierno del dato: el valor no está en el grafo bonito, está en que las acciones lleven sus reglas pegadas.

Tabla frente a objeto: un ejemplo

Sin ontología, un agente que debe responder «¿podemos servir este pedido esta semana?» necesita saber qué tablas unir, qué estados significan «confirmado», qué almacén corresponde y qué columna indica el compromiso de entrega. Todo eso hay que escribírselo.

Con ontología, el agente recorre pedido → líneas → disponibilidad → almacén, porque esas relaciones existen como tales, y consulta la regla de compromiso donde está definida. El razonamiento deja de ser adivinanza y pasa a ser recorrido.

Cómo se construye, y cómo no

Como no: modelando toda la empresa antes de entregar nada. Es el proyecto de dieciocho meses que muere en el mes doce con un diccionario precioso que no usa ningún sistema.

Como sí, en cuatro pasos:

1. Partir de un caso de uso con dueño. Una pregunta concreta que alguien necesita responder o una acción concreta que alguien necesita ejecutar.
2. Modelar solo los objetos que ese caso toca. Suelen ser entre cuatro y ocho.
3. Declarar las acciones y sus permisos junto con los objetos, no después.
4. Ampliar cuando llegue el siguiente caso, reutilizando lo modelado.

En nuestra experiencia con MVP60™, la ontología mínima de un primer caso de uso se construye en semanas, no en trimestres, precisamente porque se acota a lo que el caso necesita.

Errores frecuentes

• Copiar el esquema y renombrarlo. Si los objetos se llaman igual que las tablas, no se ha modelado nada.
• Modelar sin las acciones. Queda un diccionario, no una capa operativa.
• Dejarla fuera del gobierno. Una ontología sin dueño se desactualiza y vuelve al prompt.
• Confundirla con un catálogo. El catálogo dice dónde está el dato; la ontología dice qué significa y qué se puede hacer con él.

Cómo puede ayudar Galde

Diseñamos ontologías acotadas a casos de uso reales, con sus acciones y sus permisos, sobre la Ontology de Palantir Foundry. El criterio es el mismo de siempre: el modelo lo mantiene el equipo interno cuando nos vamos.

Conclusión

Los proveedores están coincidiendo en el diagnóstico: lo que frena a los agentes es el contexto de negocio, no la capacidad del modelo. La conclusión práctica es menos vistosa que un modelo nuevo, pero más rentable: antes de pedirle a un agente que actúe, hay que enseñarle de qué está hecha la empresa.

Y eso se enseña una vez, en un sitio, con dueño. No en cada prompt.