Analítica con IA

Tan preciso como su modelo semántico. Cortex Analyst responde únicamente a través de las Semantic Views que se le entregan y muestra la consulta detrás de cada respuesta. La mayor parte de nuestro esfuerzo de implementación se concentra en ese modelo: consultas verificadas, cobertura de los términos del negocio y ciclos de revisión con los analistas del cliente hasta que las respuestas se sostienen. El Cortex Agent que lo invoca pide aclaración cuando una solicitud es ambigua y, antes de abrir el acceso a más personas, las evaluaciones de Cortex Agents miden la exactitud de las respuestas frente a las preguntas que hace el negocio.

Sí. El text-to-SQL sobre esquemas crudos tiene que adivinar qué significa "ingresos" o "cliente activo". Las Semantic Views codifican esas definiciones una sola vez, y Cortex Analyst, Cortex Agents y Snowflake CoWork responden a través de ellas. Hacemos el primer borrador durante el discovery y lo refinamos con el equipo interno en cada sprint. dbt construye y prueba las tablas que están debajo, las Semantic Views guardan las definiciones de negocio que leen los agentes, y las dos capas viven bajo control de versiones. Para un grupo de concesionarios de vehículos comerciales en México, Viewnear está construyendo los golden records dominio por dominio, con agentes de Snowflake CoWork por dominio sobre ellos.

Cortex Analyst es el servicio que convierte una pregunta en lenguaje natural en SQL sobre Semantic Views, diseñado para integrarse en aplicaciones y flujos de trabajo. Snowflake CoWork es la experiencia de agente que los usuarios de negocio abren directamente para explorar los datos y actuar. Cortex Agents conecta a los dos: un agente llama a Cortex Analyst para los datos estructurados y a Cortex Search para los documentos, Snowflake CoWork funciona sobre esos agentes, y Snowflake hoy recomienda Cortex Agents para los builds nuevos. Un build puede incluir los tres: Snowflake CoWork para las personas, Cortex Agents donde las respuestas deben aparecer dentro de un producto o un proceso, y las apps de Cortex Analyst existentes, que siguen funcionando tal como están.

Snowflake retiró los dashboards de Snowsight en 2026, y la opción Generate Streamlit app convierte cada dashboard guardado en una app de Streamlit in Snowflake. El build los clasifica: las vistas que vale la pena conservar se convierten en apps de Streamlit in Snowflake, las preguntas recurrentes pasan a Snowflake CoWork, donde un Artifact guardado mantiene viva una gráfica con los permisos propios de cada integrante del equipo, y el resto se retira. Las herramientas de BI actuales siguen funcionando después de mover los datos a Snowflake, con Snowflake como la fuente que consultan. Las Semantic Views se consultan con SQL estándar, así que esas herramientas leen las mismas métricas que los agentes. Donde importa qué filas ve cada persona, conectamos cada herramienta para que inicie sesión como la persona que la usa, y las políticas de acceso a filas siguen a esa persona.

Conviene empezar donde ya viven los datos. Si los datos del producto están en Snowflake, embeber la analítica desde ahí mantiene juntos los datos, su modelo de seguridad y los permisos de acceso. Después se modelan los datos para acceso multi-tenant, se elige el patrón de consumo (dashboards embebidos, aplicaciones con Streamlit in Snowflake o APIs hacia un front end propio) y se libera una primera vista de alto valor con clientes piloto antes de extenderla a todos los clientes. Una app de Streamlit in Snowflake carga en las propias páginas del producto mediante un iframe y un enlace temporal para embeberla, y Cortex Agents, invocados por API REST, permiten que los clientes pregunten y actúen dentro de la aplicación.

Cada cliente ve solo sus propias filas, y Snowflake lo hace cumplir en cada consulta. En la edición Enterprise de Snowflake, la seguridad a nivel de fila funciona con políticas de acceso a filas que filtran por tenant las tablas compartidas, y los tenants que requieren una separación más estricta reciben objetos propios o una cuenta propia. Las apps embebidas corren con la identidad de la persona que inició sesión, Cortex Agents reciben el tenant como un atributo de sesión inmutable y las consultas a Cortex Search llevan un filtro por tenant. Cada política se prueba por separado antes de que el primer tenant entre en producción, y nuestra página de seguridad y confianza detalla los controles que las rodean.

Snowflake factura estas dos funciones de inteligencia artificial por consumo, en AI Credits: Cortex Agents y Snowflake CoWork se cobran por los tokens que procesan, el costo se acumula entre las herramientas que invoca cada agente, y el SQL detrás de cada respuesta corre en el cómputo estándar de los warehouses. El primer sprint define presupuestos de IA por equipo o centro de costos, más cuotas por usuario que bloquean nuevas solicitudes de IA al llegar al límite, y los Resource Monitors ponen tope a los warehouses. En un producto de cara al cliente, las consultas de cada tenant llevan un query tag, así que el equipo de producto fija el precio del plan de analítica con el costo medido por cliente.

Sí. Los agentes actúan con los roles de Snowflake de la persona que pregunta, así que el acceso por roles, las políticas de acceso a filas y el enmascaramiento se aplican a cada respuesta, y un Restricted Session Scope puede mantener a un agente por debajo de lo que esos roles permiten. Las respuestas incluyen el SQL o los documentos de origen que las respaldan, el linaje va de cada tabla a la Semantic View y de ahí al agente, y AI Agent Identity registra quién autorizó cada acceso y qué agente lo ejecutó. Los modelos corren dentro del perímetro de servicio de Snowflake, los datos almacenados permanecen en la región de la cuenta y el enrutamiento entre regiones se configura según las reglas de residencia de datos.