---
title: "Cómo construir una ontología empresarial en 6 pasos, sin modelar toda la empresa"
description: "Cómo construir una ontología empresarial paso a paso: preguntas de competencia, vocabulario, modelo, mapeo, validación y gobierno, con plantillas y ejemplos."
url: https://addabra.com/blog/como-construir-una-ontologia-empresarial
lang: es
date: 2026-11-10
category: "Brain empresarial"
keyword: "construir una ontología empresarial"
publisher: Addabra
alternate: https://addabra.com/en/blog/how-to-build-an-enterprise-ontology
---

# Cómo construir una ontología empresarial en 6 pasos, sin modelar toda la empresa

> Cómo construir una ontología empresarial paso a paso: preguntas de competencia, vocabulario, modelo, mapeo, validación y gobierno, con plantillas y ejemplos.

El proyecto empezó con entusiasmo. Seis meses después, el equipo de datos tiene un diagrama con cientos de cajas que ocupa una pared entera, y nadie de negocio lo ha abierto. Los agentes de IA siguen sin saber qué es un cliente activo. Es la forma más común de fracasar al **construir una ontología empresarial**: empezar por modelar todo en lugar de empezar por lo que el negocio necesita saber.

Hay un método que evita ese error y no es nuevo. La academia lo usa desde los años noventa, y funciona igual de bien en una empresa con ERP, CRM y agentes de IA.

## El principio: empezar por las preguntas, no por las tablas

En 1995, Michael Grüninger y Mark Fox propusieron empezar el diseño de una ontología con **preguntas de competencia**: lo que el modelo debe ser capaz de responder. Años después, Natalya Noy y Deborah McGuinness, en Stanford, lo convirtieron en una guía práctica que sigue siendo referencia ("Ontology Development 101", 2001).

La idea es sencilla y poderosa. Las preguntas definen el alcance: lo que no ayuda a responder ninguna pregunta, no entra. Y las mismas preguntas sirven de prueba al final: si una no se puede responder, al modelo le falta algo.

## Paso 1. Escribe las preguntas de competencia

Reúne a los dueños del proceso que quieres atender primero y pídeles las preguntas que hoy les cuesta responder. Escríbelas tal como las dicen. Ejemplo ilustrativo para cobranza:

- ¿Qué clientes tienen facturas vencidas y pedidos abiertos al mismo tiempo?
- ¿Por qué está detenido el pedido de este cliente?
- ¿Quién puede autorizar una excepción de crédito y hasta qué monto?
- ¿Qué clientes pagan tarde de forma recurrente?

Prioriza. Para una primera versión, unas pocas preguntas bien elegidas valen más que cien genéricas. Elige las que, respondidas, ahorran trabajo o evitan errores caros.

## Paso 2. Extrae el vocabulario y acuerda definiciones

Subraya los sustantivos y verbos de cada pregunta: cliente, factura, vencida, pedido, abierto, autorizar, excepción. Esa es tu lista inicial de términos.

Para cada término, acuerda una definición escrita y un dueño. Aquí aparecen los desacuerdos de siempre: ¿una factura está vencida al día siguiente de su fecha o después de un periodo de gracia? Resolverlo ahora es la mitad del valor del proyecto, incluso antes de que exista un agente.

## Paso 3. Modela objetos, relaciones, reglas y acciones

Convierte el vocabulario en un modelo. Los sustantivos suelen ser objetos o propiedades; los verbos, relaciones o acciones. Una plantilla simple basta para la primera versión:

| Elemento | Nombre | Definición | Dueño |
|---|---|---|---|
| Objeto | Cliente | Empresa con al menos una compra pagada | Comercial |
| Relación | Cliente realiza Pedido | Todo pedido tiene exactamente un cliente | Comercial |
| Regla | Factura vencida | Fecha de vencimiento superada sin pago completo | Finanzas |
| Acción | Liberar crédito | Solo Finanzas; requiere cero facturas vencidas | Finanzas |

Reutiliza antes de inventar. Para conceptos genéricos como personas, organizaciones o direcciones existen vocabularios públicos, como schema.org, que te ahorran discusiones.

## Paso 4. Mapea cada objeto a sus sistemas

La ontología no mueve datos: apunta a ellos. Para cada objeto y propiedad, indica de qué sistema viene y con qué llave se reconoce:

| Objeto | Sistema | Campo | Llave común |
|---|---|---|---|
| Cliente | CRM | cuenta.nombre | RFC o ID fiscal |
| Cliente | ERP | CUST_NO | RFC o ID fiscal |
| Factura | ERP | INV_HDR | número de factura |

La llave común es el corazón del mapeo. Sin ella, el CRM y el ERP siguen hablando de clientes distintos. Si tus datos no tienen una llave confiable, ese es el primer trabajo, y está explicado en [datos listos para IA](https://addabra.com/blog/datos-listos-para-ia).

## Paso 5. Valida con las preguntas del paso 1

Toma cada pregunta de competencia y respóndela con una consulta real sobre la ontología conectada a tus datos. Marca cada una como aprobada o pendiente. Las pendientes te dicen exactamente qué falta: un objeto, una relación, una llave o una regla.

Haz que negocio revise las respuestas, no solo que la consulta corra. Una respuesta técnicamente correcta pero con la definición equivocada es el error más caro.

## Paso 6. Gobierna y haz crecer el modelo

Una ontología que no cambia se vuelve obsoleta en meses. Necesita tres cosas mínimas:

- **Dueños por concepto**, que aprueban cambios en su definición.
- **Versiones**, para saber qué cambió, cuándo y por qué, y qué agentes dependen de qué versión.
- **Un ciclo de revisión**, donde nuevas preguntas del negocio reinician el método desde el paso 1.

Este gobierno es parte del [gobierno de datos para IA](https://addabra.com/blog/data-governance-para-ia), no un proceso aparte.

## Ejemplo ilustrativo: la primera versión en cobranza

Imagina una distribuidora que quiere un agente de cobranza. Es un ejemplo ilustrativo, no un cliente real.

**Semana 1.** Dos sesiones con Finanzas y Comercial producen ocho preguntas de competencia. Se eligen cinco. Aparece el primer desacuerdo: Comercial considera vencida una factura a los 30 días; Finanzas, al día siguiente de su fecha. Se acuerda la definición de Finanzas y se agrega una propiedad "días de atraso".

**Semanas 2 y 3.** Se modelan seis objetos, ocho relaciones, tres reglas y cuatro acciones. El mapeo descubre que el CRM no guarda el ID fiscal de todos los clientes; se completa antes de seguir.

**Semana 4.** Cuatro de las cinco preguntas se responden con consultas reales. La quinta, "¿qué clientes pagan tarde de forma recurrente?", necesita historial de pagos que hoy no está en el ERP. Queda como pendiente para la siguiente versión.

El resultado no es un diagrama de pared. Es un modelo pequeño, aprobado por negocio, que un agente ya puede usar.

## Errores comunes

- **Modelar toda la empresa antes de entregar algo.** Empieza por un proceso y crece por preguntas.
- **Saltarse las definiciones porque "todos saben qué es un cliente".** Precisamente ahí están los desacuerdos.
- **Dejar fuera las acciones.** Sin acciones y permisos, la ontología no sirve para gobernar agentes.
- **No probar con preguntas reales.** Un modelo que nadie valida contra consultas reales es un dibujo.
- **Confiar en que la IA genere la ontología sola.** Los modelos ayudan a proponer términos y relaciones, pero las definiciones son decisiones de negocio que alguien debe aprobar.

## Qué hacer el lunes

Agenda una sesión de una hora con los dueños de un proceso y saca de ahí sus preguntas de competencia. Prioriza las cinco más valiosas y extrae su vocabulario. Con eso ya tienes el alcance de tu primera ontología, y puedes ver para qué la usarán tus agentes en [ontología para agentes de IA](https://addabra.com/blog/ontologia-para-agentes-de-ia).

En Addabra construimos ontologías empresariales con este método: facilitamos las sesiones con tus equipos, modelamos, mapeamos a tus sistemas y validamos con tus propias preguntas, y dejamos la ontología conectada al brain de tu empresa y a tus agentes. Puedes ver cómo en nuestro servicio de [desarrollo de company brain](https://addabra.com/company-brain-development/es).

## Preguntas frecuentes

### ¿Qué son las preguntas de competencia de una ontología?

Son las preguntas que la ontología debe poder responder, escritas en lenguaje de negocio. Definen el alcance al inicio y sirven como prueba al final: si una pregunta no se puede responder con una consulta, al modelo le falta algo.

### ¿Qué herramienta necesito para construir una ontología?

Para empezar basta una hoja de cálculo y una pizarra. La herramienta importa después, cuando la ontología se conecta a tus datos y a tus agentes; conviene que permita exportar en estándares abiertos como RDF u OWL para no quedar atado a un proveedor.

### ¿Quién debe ser dueño de la ontología?

Cada concepto necesita un dueño de negocio que decida su definición, y el modelo completo necesita un responsable técnico que mantenga la coherencia. Si solo TI es dueña, la ontología termina reflejando las tablas y no la operación.

## Sobre Addabra

Addabra es una fábrica de software AI software first que diseña y construye sistemas agénticos a la medida para empresas: un agente por proceso, una memoria del negocio compartida, orquestación, aprobación humana por rol, auditoría y control de costos. Diagnóstico sin costo: https://addabra.com/blog/como-construir-una-ontologia-empresarial#contacto