Tras analizar en el primer artículo las limitaciones del dato sin semántica y el verdadero significado del contexto en las organizaciones, en esta ocasión profundizamos en los componentes tecnológicos que permiten convertir ese contexto en una arquitectura de conocimiento estructurada, gobernable y preparada para la inteligencia artificial.
Tu empresa no necesita solo más datos: necesita más contexto
Cuando una organización decide tomarse en serio el contexto, aparecen tres términos que conviene ordenar: modelo semántico, ontología y catálogo. Se parecen, se relacionan y a veces se solapan, pero no resuelven exactamente el mismo problema. Entender sus diferencias evita discusiones circulares y ayuda a diseñar una arquitectura más limpia.
Junto a ellos aparecen estándares como OWL, OWL 2 RL, SWRL, SHACL, que llevan años resolviendo problemas de representación de conocimiento e inferencia, y que las plataformas de datos (Snowflake, Databricks, Microsoft) están empezando a llevar al centro de sus productos.
Modelo semántico, ontología y catálogo: ¿qué nos aporta cada pieza?
El modelo semántico suele estar cerca del consumo analítico. Traduce estructuras físicas en conceptos de negocio consultables: define métricas, dimensiones, jerarquías y agregaciones, para que personas y herramientas puedan preguntar por ventas, clientes o márgenes sin conocer todas las tablas y joins. Es un contrato para medir.
La ontología va un nivel más profundo. Describe conceptos, relaciones y restricciones de un dominio de forma explícita: que un cliente puede tener contratos, que un contrato pertenece a una línea de producto, que ciertos eventos cambian el estado de una entidad. Es un mapa del mundo empresarial que puede ser leído por máquinas, y permite inferir conocimiento implícito: si una turbina es un activo crítico y todo activo crítico requiere inspección periódica, se puede inferir que esa turbina la requiere sin que nadie lo escriba de forma explícita.
El catálogo organiza activos: ayuda a encontrar datos, entender propietarios, consultar calidad y linaje, y conectar consumidores con productores. Un catálogo sin semántica se parece a una biblioteca donde los libros están ordenados, pero nadie sabe qué tesis defienden; enriquecido con semántica puede responder preguntas como "¿qué informes usan una definición antigua de cliente activo?" o "¿qué datos sensibles podría consultar este agente?".
La arquitectura madura no elige una pieza y descarta las otras: las combina. El modelo semántico hace que el consumo sea consistente, la ontología hace que el significado sea explícito, y el catálogo hace que todo sea descubrible y gobernable. Imaginemos la pregunta "¿qué clientes premium tienen riesgo de abandono y un contrato que vence en 60 días?". El catálogo identifica fuentes certificadas; la ontología define qué es cliente, contrato y premium; el modelo semántico aporta métricas de valor y uso; las reglas determinan umbrales; el agente responde dentro de sus permisos.
Para que esta convivencia funcione conviene fijar algunos principios: las definiciones críticas tienen propietario, las métricas oficiales se versionan, las reglas de calidad semántica se prueban, los agentes solo consumen activos certificados para decisiones relevantes, y el catálogo actúa como interfaz de gobierno, no como cementerio documental.
Stack semántico empresarial
Cada pieza aporta una responsabilidad diferente: medir, relacionar, gobernar, validar y consumir.
La capa semántica no reemplaza al catálogo, la ontología o la calidad; los coordina para que negocio y tecnología hablen en mismo idioma.
Estándares que convierten el contexto en arquitectura
No hace falta inventar un lenguaje desde cero: hay estándares del mundo de la web semántica que resuelven exactamente los problemas que ahora aparecen en la empresa, cómo representar conceptos sin ambigüedad, cómo derivar conocimiento implícito o cómo validar que un conjunto de datos cumple condiciones. Conviene ser precisos sobre su estatus: OWL y SHACL son recomendaciones consolidadas del W3C; SWRL, en cambio, fue presentado como una propuesta (Member Submission) para combinar OWL con reglas tipo Horn, nunca llegó a ser una recomendación final.
OWL permite definir ontologías, clases, propiedades, individuos y restricciones, es decir, enseñar a las máquinas el vocabulario del negocio y algunas reglas sobre cómo se organiza. OWL 2 RL es especialmente interesante para entornos empresariales porque está pensado para razonamiento escalable: ciertos problemas pueden resolverse en tiempo polinómico, lo que en lenguaje de negocio significa que no todo razonamiento semántico tiene que ser inviable a escala. Encaja bien cuando queremos materializar inferencias mediante reglas: si "cliente estratégico" se define por pertenecer a ciertos segmentos y nivel de facturación, esa clasificación puede inferirse de forma consistente. OWL no sustituye a los sistemas transaccionales ni al SQL; su papel es representar conocimiento compartido, y es especialmente útil para la desambiguación cuando distintos sistemas usan la misma palabra ("cuenta") para cosas distintas.
SWRL permite escribir reglas del tipo "si se cumplen ciertas condiciones, entonces se infiere esto": si un cliente supera cierto volumen de facturación, pertenece a una región prioritaria y ha tenido incidencias críticas, se marca para seguimiento. Aunque no sea una recomendación W3C final, su enfoque sigue siendo útil como patrón para separar reglas explícitas de lógica escondida en código, y para discutir con negocio en un formato claro: condición, inferencia, consecuencia. El riesgo de no explicitar reglas es que se dupliquen en varias aplicaciones sin que nadie sepa cuál manda cuando se contradicen. Para agentes de IA esto es clave: un agente no debería inventar una regla de negocio porque suena razonable, debe consultar reglas aprobadas.
SHACL (Shapes Constraint Language) cumple otro papel: validar. Es una recomendación W3C para comprobar que los grafos RDF cumplen condiciones expresadas como shapes, cardinalidades, tipos esperados, rangos, relaciones obligatorias. Esto es potente porque la calidad de datos tradicional no siempre captura errores de significado: un campo puede no ser nulo y tener el tipo correcto, y aun así un contrato puede tener fecha de fin anterior a la de inicio, o una incidencia crítica puede no tener activo asociado. SHACL introduce una idea muy sana: la semántica también se prueba. Un catálogo puede mostrar que un conjunto de datos supera ciertas shapes, y un agente puede preferir fuentes validadas.
Cómo los estándares convierten contexto en arquitectura
OWL modela significado, SWRL expresa reglas de negocio y SHACL valida que los datos cumplan las formas esperadas.
La apuesta de Snowflake, Databricks y Microsoft
Los grandes fabricantes se mueven en la misma dirección: acercar la semántica al lugar donde se consultan, gobiernan y automatizan los datos. El patrón común es claro, un LLM conectado a tablas sin contexto genera consultas plausibles y respuestas débiles; conectado a una capa semántica gobernada, tiene muchas más posibilidades de ser útil. Y confirma una transición: la capa semántica, antes una preocupación del BI, se está convirtiendo en interfaz de IA.
Snowflake ha situado las “Semantic Views” como objetos nativos de esquema, que permiten almacenar conceptos de negocio directamente en la base de datos: métricas, entidades, relaciones y metadatos como sinónimos y ejemplos verificados. “Cortex Analyst” utiliza esas vistas para generar consultas SQL más precisas a partir de lenguaje natural, y Snowflake las recomienda frente a los antiguos modelos YAML por su integración nativa, RBAC, compartición y gobierno. También permite instrucciones personalizadas para orientar cómo el agente interpreta preguntas ambiguas.
Databricks empuja la semántica desde Unity Catalog, con las “Business Semantics” como plataforma centralizada para definir métricas y KPIs. Las “Metric Views” son el núcleo: separan las medidas de los campos usados para agrupar y filtrar, de modo que una métrica se define una vez y se consulta en tiempo de ejecución. Incorporan además “agent metadata”, sinónimos, nombres de visualización, reglas de formato, para que los agentes mapeen mejor el lenguaje coloquial de los usuarios. En el plano de consumo, “AI/BI” y “Genie Spaces” permiten curar espacios con datasets, consultas de ejemplo y expresiones semánticas de negocio adaptadas a la terminología de cada organización.
Microsoft parte de una posición fuerte en BI con el semantic model de Power BI, y advierte con claridad: para usar Copilot con modelos semánticos hay que preparar antes los datos, el modelo y los usuarios, o Copilot puede producir salidas inexactas o engañosas. El Fabric data agent procesa preguntas en lenguaje natural, identifica la fuente más relevante, lakehouse, warehouse, dataset de Power BI, una ontología e invoca la herramienta adecuada. Y “Fabric IQ” conecta modelos semánticos con ontologías empresariales, junto a funciones como *Prep for AI* e instrucciones de IA. Para empresas ya invertidas en Power BI, esto abre una vía pragmática: no hace falta abandonar los modelos existentes, sino elevar su calidad semántica.
Tres piezas, un mismo objetivo
Modelo semántico, ontología y catálogo no son tres nombres para lo mismo: cada uno resuelve un problema distinto: medir, entender y gobernar. La arquitectura madura los combina en lugar de elegir uno. Estándares como OWL, OWL 2 RL, SWRL y SHACL aportan formas probadas de representar ese conocimiento, inferirlo y validarlo, y los grandes fabricantes de plataformas de datos ya están llevando esa lógica al corazón de sus productos porque han entendido que la IA empresarial necesita algo más que prompts.
