Una definición empresarial aprobada necesita una prueba que demuestre que un agente realmente la usó. Snowflake anunció Business Ontology el 3 de noviembre y señaló que su vista previa pública estaría disponible próximamente. Para los equipos de datos empresariales que la estén evaluando, la cuestión de gobernanza es cómo conectar el dominio, la aprobación y la versión de una definición con la respuesta que produce un agente, en particular después de que esa definición cambie.
El anuncio del producto describe un lugar para definir y aprobar conceptos empresariales y conectarlos con los datos y cálculos que los implementan. Un significado compartido puede reducir las interpretaciones conflictivas, pero los equipos todavía necesitan establecer qué significado se aplicó a una tarea concreta. El análisis de Maetra que aparece más abajo propone una pequeña prueba de aceptación para esa dependencia. No afirma que Maetra haya probado la vista previa ni que cada campo de evidencia propuesto sea una función integrada de Snowflake.
El anuncio separa el significado del cálculo
Snowflake describe Business Ontology como parte de Horizon Context dentro de Horizon Catalog. Distingue el significado empresarial aprobado de los cálculos en Semantic Views y del contexto inferido que proporciona Cortex Sense. Sus ejemplos permiten diferencias intencionales por dominio o marca, con propietarios que aprueban las definiciones pertinentes. Estas son descripciones del proveedor sobre la arquitectura prevista, no mediciones independientes de exactitud.
El anuncio general de Snowflake sitúa la ontología junto con los controles de Cortex AI Gateway. Esos anuncios abarcan distintas etapas de disponibilidad. La vista previa pública prevista para Business Ontology no debe confundirse con la disponibilidad general de otras capacidades del gateway.
La cobertura de Constellation Research informa de manera independiente sobre el anuncio y subraya el trabajo continuo de propiedad, mapeos y pruebas de cambios. No establece que el producto garantice respuestas correctas. Los compradores deberían confirmar su acceso real y el comportamiento admitido antes de hacer un plan de producción que dependa de la capacidad anunciada.
Una pregunta sobre ingresos puede ocultar varios significados autorizados
Considera un agente hipotético al que se le pide explicar los ingresos netos trimestrales para un equipo regional de finanzas. Finanzas ha aprobado una definición que incluye un tratamiento concreto de los reembolsos. Un análisis de ventas usa un concepto diferente, también aprobado por separado. Ambas definiciones pueden ser legítimas en sus propios dominios.
La tarea está incompleta si solo dice «usa ingresos aprobados». Necesita el período del informe, el dominio organizativo, la definición pertinente y el tratamiento previsto de la ambigüedad. Un agente que sustituya el concepto de ventas podría producir una respuesta verosímil y, aun así, fallar en la tarea de finanzas.
El mismo problema puede aparecer después de un cambio. Una definición puede aprobarse hoy para informes futuros, mientras que el informe de ayer debe seguir siendo interpretable según su base original. Actualizar una definición compartida sin conservar el contexto de la respuesta puede dificultar una comparación posterior. Por eso Maetra recomienda conservar una referencia a la definición utilizada, con una fecha de vigencia o una versión cuando la implementación lo admita.
Esta recomendación se refiere al significado empresarial asociado a una tarea. No implica que la aprobación de la ontología autorice toda operación posterior. Enviar un informe al exterior o cambiar un registro financiero puede requerir decisiones de acceso y política por separado.
Ejecuta tres casos de aceptación antes de confiar en un término compartido
Usa un conjunto de datos pequeño y conocido, y resultados esperados acordados por el propietario del negocio. Mantén cada prueba acotada para que un revisor pueda distinguir entre la selección del significado, el cálculo y la entrega.
Primero, prueba el dominio previsto. Formula la pregunta de finanzas usando una definición que el propietario haya aprobado para ese contexto. Conserva el concepto seleccionado, las referencias de datos pertinentes, la referencia del cálculo y el resultado. Si el agente no puede revelar qué definición usó, deja constancia de que falta esa información para verificarlo.
Segundo, introduce un conflicto intencional. Da a la prueba acceso a dos definiciones legítimas con alcances diferentes. Haz una pregunta ambigua. Acuerda de antemano si el comportamiento esperado es una aclaración, una elección claramente etiquetada o una negativa a producir una cifra definitiva. Evalúa frente a esa expectativa, en lugar de premiar una respuesta segura.
Tercero, cambia la definición y repite la tarea. En una configuración de prueba segura, actualiza el significado aprobado o su mapeo. Comprueba si una nueva respuesta usa la revisión prevista y si la respuesta anterior todavía puede explicarse. Cuando no haya referencias de versión disponibles, conserva una instantánea controlada y registra esa limitación.
Estos son casos de evaluación sugeridos, no promesas sobre el comportamiento de la vista previa. Un resultado satisfactorio demuestra la configuración probada sobre los datos seleccionados. No justifica una afirmación amplia sobre cada dominio empresarial, agente o actualización futura.
Incluye la dependencia en el registro de la tarea
El propietario de los datos debería poder identificar la definición y su alcance. El responsable de ingeniería debería poder identificar la ruta desde esa definición hasta el cálculo. La persona que acepta la salida del agente debería poder ver si el resultado cumple las condiciones acordadas de la tarea.
Conserva esas referencias junto con la tarea y su resultado observable. Si cambia un mapeo, marca las pruebas afectadas para revisión en lugar de suponer que la aprobación de la redacción cubre la implementación. Un cálculo correcto del concepto equivocado sigue siendo una respuesta inadecuada.
El análisis de alineación de tareas de Maetra explica la diferencia entre satisfacer un objetivo asignado y obtener autorización para una acción. Task Guard cubre la alineación, los cambios de alcance y la verificación de efectos; Audit proporciona un historial inspeccionable. Para un flujo de trabajo analítico, usa la documentación de Task Guard para definir el significado y el resultado esperados antes de evaluar la respuesta de un agente.
Fuentes
- Snowflake, Business Ontology, 3 de noviembre de 2026. Anuncio principal del producto; vista previa pública próxima.
- Snowflake, Anuncio de Expedition, 3 de noviembre de 2026. Fuente principal del conjunto de anuncios y de las salvedades sobre su disponibilidad.
- Constellation Research, Cobertura sobre contexto y gobernanza de Snowflake, 3 de noviembre de 2026. Información y análisis independientes del anuncio.