翻訳待ち：Building Trustworthy Snowflake AI Agents with Semantic Governance

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

--> Governing AI Agents: Deploying Semantic Views on Snowflake India's Most Futuristic AI Conference Is Back – Bigger, Sharper, Bolder d : h : m : s Career GenAI Prompt Engg ChatGPT LLM Langchain RAG AI Agents Machine Learning Deep Learning GenAI Tools LLMOps Python NLP SQL AIML Projects Reading list How to Become a Data Analyst in 2025: A Complete RoadMap A Comprehensive Learning Path to Tableau in 2025 A Comprehensive NLP Learning Path 2025 Learning Path to Become a Data Scientist in 2025 Step-by-Step Roadmap to Become a Data Engineer in 2025 A Comprehensive MLOps Learning Path: 2025 Edition Roadmap to Become an AI Engineer in 2025 A Comprehensive Learning Path to Master Computer Vision in 2025 Best Roadmap to Learn Generative AI in 2025 GenAI Roadmap for Enterprises Large Language Models Demystified: A Beginner’s Roadmap Learning Path to Become a Prompt Engineering Specialist Building Trustworthy Snowflake AI Agents with Semantic Governance Analytics Vidhya Last Updated : 08 Aug, 2026 13 min read This year, many data teams have added AI agents to their roadmaps. The excitement is real: an agent that turns a two-day analysis into a two-minute conversation can change how analysts and business teams work together. But agents are only as reliable as the data foundation beneath them. Point them at raw tables or outdated metadata, and they may sound convincing while being wrong. This article outlines a practical framework for generating and deploying governed semantic views on Snowflake. Table of contents Why Agent Quality Breaks Down What a Semantic Layer Actually Does Where This Lives in Snowflake The Two Governance Pillars Behind Every Certified Metric The Framework: A Governance Harness for Semantic View Generation Why This Differs From Snowflake’s Native Tooling BI Tools: Where Consumption Stands Today A Certification Rubric, So “Human in the Loop” Isn’t a Slogan From Deployment to Answer: Cortex Analyst and Agents Conclusion Why Agent Quality Breaks Down Three failure patterns show up repeatedly once agents move from demo to production: Governance gets traded for speed. Teams under pressure to ship skip questions about data integrity and access control until an agent is already answering questions for the business. Duplication proliferates. Without a shared process, different teams build overlapping agents that answer the same question in subtly different – and inconsistent – ways. Answers are non-deterministic. The same question, asked twice, returns two different numbers. That’s worse than being reliably wrong, because nobody knows when to distrust the answer. All three trace back to one root cause: there’s no standardized, enforced process governing how a semantic definition gets created, reviewed, versioned, and promoted. Tooling that helps you author semantic views faster doesn’t solve this by itself – speed and governance are different axes, and an organization can have plenty of one and very little of the other. What a Semantic Layer Actually Does Ask five teams “what is the total number of active members in Q1 2026?” without a shared semantic layer, and you may get five different numbers. Each team applies its own filters, joins its own tables, and defines “active” differently – and an LLM asked the same question with no grounding will hallucinate a sixth answer that sounds just as confident as the other five. A semantic layer solves this by sitting between the raw warehouse and every consumer – dashboards, spreadsheets, and now AI agents – and answering three questions the same way, every time: which tables hold this data, what filters apply, and what’s the aggregation logic and grain. Snowflake’s own documentation frames this as addressing the mismatch between how business users describe data and how it’s actually stored in database schemas – for example, defining “net revenue” once, consistently, as SUM(gross_revenue * (1 - discount)), rather than leaving the calculation to be reinvented in every report. Where This Lives in Snowflake In Snowflake, the semantic layer is implemented as a semantic view, a schema-level object stored directly in the database that defines business metrics and models entities and their relationships, which Cortex Analyst – Snowflake’s text-to-SQL tool, can then query in natural language. Cortex Agent is the AI orchestrator that holds one or more semantic views, alongside search services and custom tools, and decides which resource answers a given question – the same architecture underpinning Snowflake CoWork(formerly Snowflake Intelligence). Here’s what that specification looks like filled in with a real example. Below is a semantic view over a SaaS billing dataset – two logical tables (billing and customers), joined on customer ID, with three certified revenue metrics defined once: name: SAAS_BILLING description: Combines customer records with subscription billing details to support certified MRR, net MRR, and churned revenue metrics. tables: - name: BILLING base_table: { database: FINANCE, schema: ANALYTICS, table: FCT_SAAS_BILLING } dimensions: - name: BILLING_DATE expr: BILLING_DATE data_type: DATE - name: PLAN_TYPE expr: PLAN_TYPE data_type: VARCHAR(20) facts: - name: MRR_AMOUNT expr: MRR_AMOUNT data_type: NUMBER(10,2) metrics: - name: TOTAL_MRR expr: SUM(billing.MRR_AMOUNT) - name: NET_MRR expr: SUM(billing.MRR_AMOUNT) - SUM(billing.DISCOUNT_AMOUNT) - name: CHURNED_REVENUE expr: SUM(IFF(billing.IS_ACTIVE = FALSE, billing.MRR_AMOUNT, 0)) primary_key: { columns: [BILLING_ID] } - name: CUSTOMERS base_table: { database: FINANCE, schema: ANALYTICS, table: DIM_CUSTOMERS } dimensions: - name: COMPANY_NAME expr: COMPANY_NAME data_type: VARCHAR(100) - name: INDUSTRY expr: INDUSTRY data_type: VARCHAR(50) primary_key: { columns: [CUSTOMER_ID] } relationships: - name: CUSTOMER_BILLING left_table: BILLING right_table: CUSTOMERS relationship_columns: - { left_column: CUSTOMER_ID, right_column: CUSTOMER_ID } (Trimmed for readability – the full generated file includes every column comment and access modifier. Repo has the full semantic definition ) What’s not in question is that this object works. What is in question is: how does a semantic view like this get created in the first place? The Two Governance Pillars Behind Every Certified Metric Before the pipeline itself, it’s worth being precise about the two governed inputs it depends on. The Data Catalog: One authoritative source for business descriptions, data types, sensitivity tags (PII/PHI), sample values, and certification status for every column and table. In this implementation that’s Snowflake Horizon – tags are set at the column level or table level. The catalog contains the data type, description, synonyms, sample values etc., and a dynamic masking policy can restrict who ever sees a flagged column. A certification_status = 'Certified' tag is the green light for th at column’s metadata to be used in a semantic view at all. The Metric Inventory: A single governed home for every metric formula, with a description, business owner, source table, domain, sensitivity classification, and critically a certification status. The operative rule: each metric is defined once and reused everywhere, and “once” is gated behind an actual sign-off from a domain owner or data steward. This is what is going to solve the problem that the same metric can be answered 6 different ways across teams. The Framework: A Governance Harness for Semantic View Generation The core idea is simple to state: treat semantic view generation as a governed software release, not a one-off modeling exercise. In practice that means five components, each enforcing a rule that an informal process typically leaves optional. Before walking through each one, it helps to see the whole pipeline end to end, and then how that pipeline fits into the wider Snowflake architecture – the two diagrams below cover exactly that. Governance Framework Flow Diagram Zooming out one level: this pipeline is only the build-time half of the picture. Figure 2 shows how it fits alongside the systems that actually consume its output – Cortex Analyst, Cortex Agents, Snowflake Cowork, and the BI tools discussed later in this article. System architecture The full code for the below components breakdown is here. Component 1 – Context Extraction An orchestration script connects to Horizon and the metric inventory and pulls, for a given domain, only certified metric formulas and tagged schema. This step is deterministic – it retrieves already-approved facts, it doesn’t infer anything: cursor.execute(f""" SELECT metric_name, description, expression, base_table FROM GOVERNANCE_DB.SEMANTICS.METRIC_INVENTORY WHERE certification_status = 'Certified' AND base_table IN ({table_list}) """) metrics = [ {"metric_name": r[0], "description": r[1], "expression": r[2], "table": r[3]} for r in cursor.fetchall() ] The process pulls schema and tag context directly from Horizon tag references. catalog_query = f""" WITH physical_schema AS ( SELECT table_schema, table_name, column_name, data_type, comment AS column_description FROM {database}.INFORMATION_SCHEMA.COLUMNS WHERE table_schema IN ({schema_list}) AND table_name IN ({table_list}) ), horizon_tags AS ( {real_time_tags_cte} ) SELECT p.table_name, p.column_name, p.data_type, p.column_description, t.tag_value AS privacy_tag FROM physical_schema p LEFT JOIN horizon_tags t ON p.table_name = t.table_name AND p.column_name = t.column_name """ This is the first structural difference from usage-inference approaches worth stating plainly: this pipeline only ever proposes definitions that trace back to a pre-approved source, rather than a definition surfaced because it was the most common pattern in someone’s query history. Popularity is a useful discovery signal; it isn’t the same claim as governance sign-off. Component 2 – Constrained Generation An LLM of choice (Claude, GPT, Qwen, GLM etc) converts the extracted context into a strictly formatted dbt model using the dbt_semantic_view package syntax. The key control is constraint: the system prompt fixes the output schema and clause order and requires every generated field to map to a catalog or inventory entry instead of the model’s own judgment. A trimmed version of the actual system prompt used in this pipeline: SYSTEM_PROMPT = """You are an expert Data Engineer building dbt semantic models for Snowflake. You will receive a JSON context payload with: - metrics: certified metric definitions (metric_name, expression, table) - catalog: physical columns per table (table, column, data_type, description, tag) - table_descriptions: [{ table, description }] source table in Snowflake Produce ONE valid dbt model file using the Snowflake-Labs dbt_semantic_view package. Output ONLY the raw file contents. No prose, no markdown fences, no preamble. Required clauses, in this exact order, separated by newlines: {{ config(materialized='semantic_view') }} TABLES ( AS {{ source('', '') }} [ PRIMARY KEY () ] [ COMMENT = '' ] ) RELATIONSHIPS ( AS () REFERENCES ) FACTS ( . AS [ COMMENT = '...' ] [, ...] ) DIMENSIONS ( . AS [ COMMENT = '...' ] [, ...] ) METRICS ( . AS [ COMMENT = '...' ] [, ...] ) COMMENT = '' PII handling: any column whose tag contains 'PII' (case-insensitive) MUST be excluded from FACTS, DIMENSIONS, and METRICS. """ Because the extracted context includes the PII tag, the model automatically omits or masks flagged columns instead of making case-by-case judgments. Beyond PII filtering, two controls enforce governance: Predictable output: Restrict the model to a strict, non-conversational format so reviewers can verify the generated code consistently and efficiently. Data Integrity: The model must only use the specific data provided in the input, which prevents it from “hallucinating” or inventing its own columns and formulas. By applying this s [truncated for AI cost control]