Tercera y última entrega de esta serie de tres artículos. En las publicaciones anteriores analizamos las limitaciones del dato cuando carece de contexto y el papel que desempeñan elementos como el modelo semántico, la ontología, el catálogo de datos y los estándares que los sustentan.
En este último post abordamos cómo estas capacidades potencian el valor de los copilots y los agentes de IA, así como las acciones que puede emprender una organización para construir una base sólida que permita aprovechar todo su potencial.
El factor que determina el valor real de copilots y agentes
Los copilots y agentes son tan buenos como el contexto que pueden usar. Un copiloto sin contexto funciona como un consultor altamente cualificado que debe trabajar sin acceso a los sistemas, procesos y conocimiento interno de la organización: puede analizar y proponer soluciones, pero desconoce qué fuentes son oficiales, qué políticas aplican y qué excepciones deben considerarse. Un copiloto con contexto se parece más a alguien que ha recibido formación, acceso controlado y criterios de actuación.
La diferencia se nota en cuatro capacidades: entender la pregunta (mapear expresiones como "clientes buenos" o "riesgo alto" a conceptos aprobados), elegir fuentes adecuadas, aplicar reglas (respetar fórmulas, filtros y permisos) y explicar el resultado, no solo darlo. Esto cambia la conversación de "qué modelo usamos" a "qué contexto le damos y cómo lo gobernamos". Sin ese contexto, el riesgo no es que la IA no responda: es que responda demasiado bien a la pregunta equivocada.
La primera ola de analítica conversacional se centró en “text-to-SQL”: el usuario pregunta y el sistema genera una consulta. Es valioso, pero limitado si se usa solo, porque entre el lenguaje natural y el SQL debe existir un contrato de significado, modelos semánticos, ontologías, catálogos, reglas, que evite que una consulta sintácticamente correcta responda a una interpretación equivocada. Los agentes, además, van más allá de una consulta: planifican pasos, piden aclaraciones cuando una pregunta es ambigua, y deberían elegir la métrica certificada cuando existen varias versiones. La métrica de éxito no debería ser solo "el agente respondió", sino su precisión, consistencia con las definiciones y trazabilidad de fuentes.
Aquí aparece otro concepto relevante: MCP (Model Context Protocol), un protocolo abierto que estandariza cómo las aplicaciones de IA se conectan a sistemas externos, su propia documentación lo compara con un puerto USB-C para aplicaciones de IA. MCP resuelve cómo conectar agentes y herramientas de forma estandarizada, pero conectar no es entender: un servidor MCP puede exponer una base de datos o una API, y si lo que expone no lleva contexto semántico, el agente tendrá acceso pero no necesariamente criterio. La combinación potente es MCP más semántica gobernada: MCP como interfaz técnica, y el modelo semántico, la ontología y el catálogo diciéndole al agente qué métricas son oficiales, qué relaciones existen y qué fuentes son certificadas.
¿Por qué el contexto cambia la utilidad de copilots y agentes?
Sin semántica, el agente improvisa; con contexto, opera con contrato de significado, permisos y validaciones.
De la estrategia a la práctica: construir contexto con propósito
La pregunta difícil no es si el contexto semántico es deseable, sino cómo empezar sin crear un programa interminable. Hay que resistir dos tentaciones: modelar toda la empresa antes de entregar valor (acaba en un repositorio elegante y poco usado), o resolver cada caso de uso de forma aislada (entrega rápido, pero acumula deuda semántica). El camino sano combina negocio, arquitectura y operación en cuatro pasos.
- Elegir un dominio con impacto y ambigüedad. No el más fácil, sino uno donde la ambigüedad genere coste real: cliente, ventas, riesgo, producto. "Cliente" suele ser un buen punto de partida porque cruza muchas áreas que, aun usando la misma palabra, no siempre significan lo mismo. El entregable de este paso no es una ontología completa, sino un backlog semántico priorizado: conceptos, métricas y reglas críticas, con responsables y casos de uso.
- Convertir métricas en productos semánticos. Una métrica crítica no es solo una fórmula: es un activo con nombre, definición, propietario, versión, granularidad, reglas de cálculo y ejemplos de uso. Se puede empezar con una ficha mínima y llevarla después a la tecnología adecuada, una Semantic View en Snowflake, una Metric View en Databricks, un semantic model en Power BI, evitando que la misma métrica se defina, sin gobierno, en varios sitios a la vez.
- Validar con SHACL, gobernar con catálogo y desplegar con plataforma. Validar semántica significa crear pruebas sobre significado: si un "contrato activo" debe tener fecha de inicio, estado válido y cliente asociado, eso puede comprobarse. El catálogo orquesta qué activos son oficiales y qué consumidores dependen de cada uno, y todo el conjunto, modelos, ontologías, reglas, debería tratarse como código: versionado, probado y promovido entre entornos, igual que cualquier pipeline crítico.
- Medir la mejora en decisiones, no solo en consultas. Si el programa se evalúa por número de términos en el glosario, se incentiva volumen, no utilidad. Conviene medir cosas como el tiempo de reconciliación entre áreas, el porcentaje de preguntas del agente respondidas con fuentes certificadas, o la reducción de incidencias por interpretación, y cerrar el ciclo: cada fallo del agente por un sinónimo no entendido o una regla no formalizada debería alimentar de vuelta al modelo semántico.
Una arquitectura de referencia: roles y errores más frecuentes
Toda esta capacidad puede ordenarse en seis capas: las fuentes (sistemas transaccionales, lakehouses, APIs), la integración y preparación (ingesta, calidad técnica), la capa de significado (modelos semánticos, ontologías, reglas y shapes), el gobierno (catálogo, linaje, permisos, certificación), las interfaces de consumo (BI, copilots, agentes) y la evaluación (pruebas, benchmarks, métricas de impacto). Lo importante es que estas capas no sean compartimentos estancos: el agente consume modelos semánticos y catálogo, las validaciones alimentan indicadores de confianza, y las preguntas de los usuarios generan mejoras en las definiciones.
Esta capacidad tampoco puede desarrollarse ni mantenerse de forma autónoma; requiere un modelo de gobierno con responsabilidades claramente definidas. En él participan el responsable de negocio de cada concepto o métrica, el Data Product Owner, los equipos de arquitectura, gobierno del dato y seguridad, así como los equipos de IA, que utilizan este contexto para construir soluciones y aportan retroalimentación continua para su mejora y evolución. Cada vez es más relevante también el traductor semántico, data steward, analytics engineer, ontologist, que convierte lenguaje de negocio en estructuras formales sin perder matices. Muchas discusiones semánticas son en el fondo discusiones de poder ("¿quién define cliente?"), y la tecnología no las resuelve sola: las hace visibles.
Los errores más frecuentes al construir esta capacidad son: confundir documentación con contexto operativo (si la definición no se usa en consultas o agentes, su impacto es limitado); empezar demasiado grande, con una ontología corporativa total en lugar de avanzar por dominios; delegar todo en la herramienta, cuando la plataforma implementa pero es la organización la que acuerda qué significa margen o cliente; olvidar las excepciones; no versionar las definiciones; medir la adopción por cantidad de términos en lugar de por reducción real de fricción; y exponer agentes con acceso amplio antes de tener límites, permisos y trazabilidad claros.
El contexto como ventaja competitiva
La empresa que quiera aprovechar de verdad la IA no puede limitarse a acumular datos y conectar modelos. Necesita construir contexto: para que las personas compartan lenguaje, para que las métricas no se contradigan, para que los agentes no improvisen reglas, para que el gobierno no sea un freno sino una garantía.
Hoja de ruta para una organización real
Un enfoque incremental evita el “big bang semántico” y conecta arquitectura con resultados de negocio.
Los modelos semánticos, las ontologías y los catálogos no son modas aisladas, sino piezas complementarias de una misma necesidad: hacer explícito el significado. Estándares como OWL, OWL 2 RL, SWRL y SHACL aportan formas de representar conocimiento, inferencias y validaciones, y fabricantes como Snowflake, Databricks y Microsoft están llevando esa conversación al producto porque el mercado ya ha entendido que la IA empresarial necesita algo más que prompts.
La buena noticia es que no hace falta resolverlo todo a la vez. Se puede empezar por un dominio, unas métricas críticas y una experiencia de consumo concreta, e ir convirtiendo conocimiento tribal en definiciones gobernadas, paso a paso, hasta que el contexto deje de ser una idea abstracta y se convierta en arquitectura. Más datos pueden alimentar más informes. Más contexto puede alimentar mejores decisiones. Esa es la diferencia.
