Why "ask your data" breaks in production
Every major cloud data platform now offers some version of a conversational BI interface. The demos look compelling: a business user types a question in plain English, the system runs a SQL query, and a clean chart appears. Then the team tries to deploy it, and the chart stops being clean.
The failure almost never lives in the LLM. It lives in the layer between natural language and your actual tables—the semantic model. A production conversational BI system on Snowflake Cortex Analyst is not a chatbot bolted onto a warehouse. It is a five-layer stack, and three of those layers require deliberate engineering work before the AI can be useful.
| # | Layer | What lives here |
|---|---|---|
| 1 | Data layer | Snowflake tables, views, Iceberg tables |
| 2 | Semantic model | YAML semantic view or stage file defining business terms, metrics, joins |
| 3 | Cortex Analyst API | Snowflake-managed LLM that translates natural language → SQL |
| 4 | Application interface | Streamlit app, REST integration, or custom frontend |
| 5 | Access control | Snowflake RBAC, row-level security, column masking policies |
Layer 1: The data layer
Cortex Analyst queries your existing Snowflake tables. There is no separate data store to maintain. What matters is that the tables are query-ready: columns have clear names, null rates are low where the business cares, and fact-dimension joins are consistent. A warehouse built for ETL pipelines often needs a modeling pass before it can serve conversational queries reliably.
The recommended starting point is a narrow set of tables—three to five—that answer the questions your business users actually ask. Expanding scope is straightforward once the semantic model is solid. Starting with forty tables means forty sources of ambiguity for the model to resolve on every query.
Layer 2: The semantic model (where the real work is)
This is the layer that determines whether a production deployment works. The semantic model is a YAML file—stored on a Snowflake internal stage or defined as a semantic view—that tells Cortex Analyst what your tables mean in business terms. It maps column names to concepts: order_ts becomes "order date," net_amt_usd becomes "revenue." It defines measures, dimensions, verified queries, and the relationships between tables.
Without a well-authored semantic model, the LLM has to infer intent from raw column names. It will occasionally succeed and occasionally return a plausible-looking result that is quietly wrong. That kind of intermittent failure is harder to catch than a clear error, and it erodes trust in the tool faster than anything else.
Snowflake's Cortex Analyst documentation recommends using semantic views for new implementations rather than stage-stored YAML files. Semantic views are first-class Snowflake objects, version-controlled like any other schema change, and benefit from Snowflake's AI-assisted authoring tools that can suggest definitions based on column metadata and sample data.
Layer 3: Cortex Analyst API
Once the semantic model is in place, Cortex Analyst handles the translation. A business user asks a question through your application. The application sends that question—along with a reference to the semantic model—to the Cortex Analyst REST endpoint. Cortex Analyst generates a SQL query, runs it against your Snowflake tables, and returns both the result set and the SQL it produced.
The fact that the generated SQL is always visible is architecturally significant. Your data team can review every query, verify correctness, and identify gaps in the semantic model that are causing misinterpretation. This feedback loop is what allows a conversational BI deployment to improve over time rather than drift.
Cortex Analyst is a fully managed service. There is no model to host, no inference infrastructure to maintain, and no API key to a third-party LLM provider. Pricing follows Snowflake's standard compute model—the same credit system you are already using for your queries. If you are evaluating Snowflake's cost behavior at scale, the analysis in how Snowflake costs behave under heavy query loads is directly applicable here.
Layer 4: The application interface
Cortex Analyst does not come with a built-in UI. You connect it to an interface your users already have access to. The three common paths are:
- Streamlit in Snowflake: The fastest path from semantic model to working chat interface. Runs inside your Snowflake account, inherits existing permissions, no separate deployment.
- REST integration: If your team already has a BI tool or internal portal, Cortex Analyst exposes a REST API that any web application can call. The response includes the SQL and the result set in a structured format.
- Custom application: For teams that need a specific UX—embedded analytics, a dedicated analyst workspace, a Slack integration—the API gives full control over how results are displayed and how conversations are stored.
The choice of interface does not affect what Cortex Analyst can do. It affects adoption. A conversational BI layer that requires users to open a new tool they do not already trust gets low usage regardless of how accurate the underlying model is.
Layer 5: Access control and governance
Cortex Analyst respects the Snowflake RBAC of the user or service account making the request. If a sales analyst's role can only see their region's data, Cortex Analyst will only return results from that data. Row-level security policies, column masking policies, and object-level permissions all apply at query execution time, not at the semantic model level.
This is the access control model most data teams already have. The practical implication is that you can expose the same semantic model to different user groups with different permissions and get correctly scoped results without building separate models per role. Whether your data infrastructure is ready for this kind of deployment is worth reviewing before starting—the readiness criteria for a first AI project cover the data governance checks that apply here.
Production readiness checklist
- Source tables are modeled and documented (column names describe business concepts, not ETL internals)
- Fact-dimension join keys are consistent and validated
- A semantic model covers the top 10–15 questions users actually ask
- Verified queries are defined in the semantic model for the most common analytical patterns
- RBAC is applied at the table level and tested with representative user roles
- A feedback mechanism is in place: users can flag incorrect answers, and the data team reviews generated SQL weekly
- The application interface is embedded in a tool users already open daily
If any of these are missing, the deployment will work in controlled conditions and degrade in practice. The semantic model and the feedback loop are the two that teams most often skip, and they are the two that matter most for long-term accuracy.
What to do if the semantic model is the bottleneck
For most mid-market data teams, building the first semantic model for Cortex Analyst takes two to four weeks of focused work: understanding what questions the business actually asks, mapping those questions to the right tables and metrics, and iterating on the verified queries until accuracy is consistent. This is not a one-time effort—the semantic model is a living artifact that needs updates as the data model changes and as users ask questions the initial version did not anticipate.
Teams that have already shipped a Snowflake environment but have not yet built the semantic layer are closest to a working deployment. If your warehouse needs structural modeling work before a semantic model can be built on top of it, that step comes first. The data and AI consulting work we do typically starts with that diagnostic—understanding what the data looks like today and what it needs to look like before any AI layer is useful.
Frequently asked questions
- Does Cortex Analyst work with Iceberg tables?
- Yes. Cortex Analyst queries any table type available in Snowflake, including Apache Iceberg tables managed through Snowflake. The semantic model references the table by name; the storage format is abstracted.
- How does Cortex Analyst handle ambiguous questions?
- When a question maps to more than one valid interpretation, Cortex Analyst returns the SQL it used along with clarifying questions for the user. The quality of those clarifying questions depends on how well the semantic model documents the ambiguous dimensions.
- Can Cortex Analyst write to tables or only read?
- Cortex Analyst only generates SELECT statements. It does not write to, modify, or delete data. The query runs under the permissions of the calling user or service account.
- What is the difference between Cortex Analyst and Cortex Copilot?
- Cortex Analyst is designed for structured, analytical queries against defined tables via a semantic model. Cortex Copilot is a general-purpose assistant for Snowflake tasks—writing SQL, explaining query results, navigating the platform. They serve different use cases and can be used alongside each other.
- How many tables can a semantic model cover?
- There is no hard limit. Snowflake's best-practice guidance recommends starting with a focused set of three to five tables, validating accuracy, and expanding from there. Large, loosely defined models tend to produce more ambiguous queries than focused ones.
