Qué aporta una ontología a la inteligencia artificial empresarial

Una taxonomía ordena conceptos. Una ontología explica cómo funcionan. Y esa
diferencia es la que separa un glosario que un humano lee de una
representación sobre la que un agente puede razonar.

Introducción

Ayer dejamos la semántica a medio camino: un glosario es el mínimo viable,
un modelo semántico formal es el destino. Hoy caminamos hacia ese destino.
Por el camino, hay una palabra que aparece en cada conversación de IA
empresarial, usada a menudo como sinónimo de «modelo de datos» o «lista de
categorías», y que casi nunca se define: ontología.

Vale la pena definirla una vez, con rigor, porque el resto de la serie la
supone.

El problema

Una empresa de seguros lleva dos años con su «modelo de datos de
seguros»: tablas bien nombradas, un glosario de 40 términos, y un data
mart. Cuando llegó el proyecto de IA, el equipo construyó un RAG sobre los
documentos y un agente sobre el data mart. En las preguntas simples
funcionaba. En las preguntas reales se caía:

• «¿Qué pasa con esta póliza si el siniestro tiene más de un año?» — el
  agente no sabía que la cobertura de un tipo de riesgo caduca a los 12
  meses y la de otro no.
• «¿Este siniestro está dentro del límite agregado?» — no sabía que los
  límites se aplican por línea de negocio, no por póliza individual.
• «¿Puedo endosar esta póliza si hay un siniestro abierto?» — no sabía que
  un endoso depende del estado del siniestro y del tipo de cobertura.

El glosario definía «póliza», «siniestro» y «endoso» por separado. Pero las
preguntas reales no van sobre definiciones: van sobre cómo se relacionan
las cosas y qué reglas gobiernan esas relaciones. Y eso, el glosario no lo
decía.

El concepto

La definición canónica, de Tom Gruber (1993), sigue siendo la mejor:

Una ontología es una especificación explícita de una conceptualización
compartida.

Desglosemos las cuatro palabras que importan:

• Especificación. No es intuición: es una representación formal, con
  reglas, que un sistema puede procesar.
• Explícita. Los conceptos, las relaciones y las restricciones están
  escritos, no implícitos en el código de una aplicación o en la cabeza de un
  analista.
• Conceptualización. No describe tablas: describe el dominio — las
  clases de cosas que existen (póliza, siniestro, asegurado, endoso), sus
  atributos, y cómo se relacionan.
• Compartida. Es un acuerdo: varias aplicaciones, varios sistemas y, hoy,
  varios agentes, la usan como referencia común.

Una ontología empresarial, en la práctica, tiene cinco piezas:

1. Clases. Las categorías del dominio: Póliza, Siniestro,
   Asegurado, Endoso, Proveedor.
2. Instancias. Los objetos concretos: la póliza P-2024-118, el siniestro
   S-2026-007.
3. Atributos. Las propiedades de cada clase: una póliza tiene fecha de
   inicio, prima, línea de negocio.
4. Relaciones. Cómo se conectan: póliza → tiene → siniestro,
   siniestro → afecta → póliza, endoso → modifica → póliza.
5. Restricciones y reglas. Lo que el dominio permite o exige: un
   siniestro debe estar asociado a exactamente una póliza; un endoso no es
   válido si hay un siniestro abierto en la línea afectada; los límites se
   aplican por línea de negocio.

Ahora, la diferenciación que la mayoría de las conversaciones confunde, y
que es el corazón de este artículo:

Cuatro cosas distintas, cuatro trabajos distintos. Una taxonomía de
productos es útil para ordenar el catálogo; no te dice nada sobre qué
sucede cuando un producto sale de stock. Una base de datos te almacena
siniestros; no te dice que un endoso con siniestro abierto es inválido. Una
ontología te da las reglas del dominio; un knowledge graph te da los hechos
concretos del negocio, conectados. La ontología es el esqueleto de
significado; el grafo es el cuerpo de hechos. (El grafo lo vamos a
desarrollar en su día.)

La aportación decisiva de la ontología a la IA es la restricción
verificable. Un LLM puede decir «un endoso no debería aplicarse si hay un
siniestro abierto», pero no lo sabe: lo está adivinando a partir de lo que
leíste. Si esa regla está en una ontología, el sistema puede verificar que
un endoso propuesto la respeta, antes de que el modelo genere una sola
palabra. Esa es la diferencia entre un agente que parece entender el
dominio y uno sobre el que la organización puede confiar una decisión.

Arquitectura

En el diagrama de la serie, la ontología se sitúa dentro de la columna de
conocimiento, como la especificación formal de la semántica:

                KNOWLEDGE
                     ↑
          ┌──────────┴──────────┐
          ↓                     ↓
      ONTOLOGY             (instancias, hechos,
   (clases, relaciones,     relaciones concretas →
    restricciones)          KNOWLEDGE GRAPH, día 6-7)
          ↓
       SEMANTICS
          ↓
        DATA

La ontología es la capa donde la semántica de ayer deja de ser «un acuerdo
escrito en un documento» y pasa a ser «una representación que un sistema
puede comprobar». Es, en términos de la serie, el punto en que la
infraestructura cognitiva empieza a ser verificable, y no solo legible.

Caso de uso

La aseguradora, con su dominio de underwriting. Descomponemos:

1. Problema. Los ajustadores pierden tiempo comprobando manualmente si
   un siniestro o un endoso respeta las reglas de la póliza, y las
   incoherencias se detectan tarde, a veces después de pagar.
2. Decisión. Aceptar o rechazar un endoso propuesto sobre una póliza
   concreta.
3. Conocimiento necesario. Qué reglas gobiernan un endoso; qué es un
   siniestro abierto; qué líneas de negocio existen y sus límites; qué
   cobertura caduca y cuándo.
4. Datos. Pólizas, siniestros, endosos, asegurados, líneas de negocio en
   el core de seguros; condiciones en documentos PDF.
5. Relaciones. Póliza → línea de negocio; póliza → siniestros; siniestro
   → estado (abierto/cerrado); endoso → póliza; cobertura → plazo de
   caducidad.
6. Contexto. El endoso se solicita el día 30 del periodo; la póliza
   tiene dos siniestros, uno abierto en la línea afectada.
7. Memoria. Un endoso similar se rechazó en 2025 por la misma regla; la
   decisión y su justificación están en el historial del ajustador.
8. Razonamiento. Aplicar la restricción: endoso inválido si
siniestro_abierto en línea afectada → el endoso propuesto es inválido;
   proponer la alternativa (esperar a cerrar el siniestro o aplicar la
   cláusula de excepciones, si existe).
9. Acción. Rechazar el endoso con la regla citada, o encolar la
   alternativa para aprobación.
10. Infraestructura. La ontología del dominio (clases, relaciones,
    restricciones) + los hechos del grafo (esta póliza, este siniestro, su
    estado) + el razonamiento que cruza ambos. Sin ontología, el agente
    «averigua» la regla; con ontología, la verifica.

El caso muestra el valor exacto de la ontología: no es que el agente sepa
más, es que el sistema puede comprobar que el agente respeta el dominio.

Trade-offs

• Coste. Formalizar una ontología de dominio es caro: requiere expertos
  de negocio y tiempo, y el primer modelo siempre sale incompleto.
• Complejidad. Una ontología muy rica (OWL completo, con inferencia
  pesada) puede ser sobreingeniería para muchos casos. La regla práctica:
  empezar con RDFS (clases y propiedades, sin lógica compleja) y añadir
  restricciones solo donde el negocio las exija.
• Mantenimiento. El dominio cambia: una nueva línea de negocio, una
  regla modificada por el regulador. La ontología tiene un dueño y un
  proceso de cambio, o se convierte en un mapa desactualizado que da
  confianza falsa.
• Latencia. La inferencia sobre ontologías grandes añade tiempo. En la
  práctica, las verificaciones que importan son selectivas y baratas; lo que
  no se puede verificar todo el tiempo es un grafo de millones de
  instancias, pero eso es problema del grafo (días 6-7), no de la ontología.
• Adopción. Una ontología que no consumen ni las aplicaciones ni los
  agentes es un documento muerto. Su valor nace del día en que un sistema la
  usa para verificar.
• Limitación honesta: la ontología captura las reglas explicitables.
  El criterio del subdirector que dice «este siniestro se ve raro» no entra
  en la ontología. La ontología formaliza el dominio; no lo reemplaza.

Implicación para la empresa

Para el CDO, la ontología es el activo semántico ejecutable de la
organización: el glosario es para humanos, la ontología es para sistemas. Y
como es un acuerdo compartido, necesita un dueño con autoridad de negocio,
no solo técnica.

Para el equipo de IA, la ontología cambia el tipo de confianza que puedes
pedir a un agente: de «da respuestas plausibles» a «respeta reglas que el
sistema puede comprobar». Eso es lo que convierte un piloto en algo que
puede soportar decisiones.

Para la alta dirección, el mensaje es económico: cada regla de negocio que
hoy vive en la cabeza de un experto y en un PDF, y que un agente puede
violar sin que nadie lo note, es un riesgo latente. La ontología no lo
elimina, pero lo hace visible y verificable.

Conclusión

Una ontología es una especificación explícita de una conceptualización
compartida: clases, relaciones, atributos y restricciones que hacen el
dominio verificable. No es una taxonomía (que solo clasifica), no es un
knowledge graph (que almacena hechos), y no es una base de datos (que
almacena y consulta). Es el esqueleto de significado sobre el que todo lo
resto de la serie se va a apoyar.

Pero una ontología nos dice qué clase de cosa es una póliza o un
siniestro. Y ahí aparece la siguiente pregunta, la más práctica de todas:
si sabemos qué clase de cosa es cada registro, ¿sabemos qué entidad
concreta representa? Porque en la empresa real, la misma entidad aparece
con diez nombres distintos.

Siguiente artículo

Mañana: Antes de razonar hay que saber quién es quién. Veremos qué es
la entity resolution, por qué es la condición previa del conocimiento
empresarial fiable, y qué pasa cuando «ACME», «ACME LTD» y «Customer 49281» son, a todos los efectos, la misma empresa.

Fuentes

• Gruber, T. (1993). «A Translation Approach to Portable Ontology
  Specifications». Knowledge Acquisition, 5(2). — Definición canónica de
  ontología.
• W3C: RDF, RDFS, OWL 2. — Estándares de representación y ontologías.
• Definición de trabajo de la ICE: ver serie, Día 1.