Skip to content

Library · Data Practice OS

AI on Snowflake: Cortex

Reference guide · Published · Source reviewed

Snowflake Cortex AI is the case for doing AI where the data already lives. Models run inside Snowflake's security boundary, use the same roles and policies as your tables, and bill as credits. There are no API keys to hand out and no data to copy to a separate vector database.

Pick the service by the job

Job Service Notes
Classify, extract, summarise or translate rows and documents in a pipeline Cortex AI SQL functions (AI_COMPLETE, AI_CLASSIFY, AI_EXTRACT, AI_AGG, AI_PARSE_DOCUMENT) Batch LLM functions in SQL. Run it in dbt or Dynamic Tables on new rows only
"Ask our policies and procedures" Cortex Search Managed hybrid search, the retrieval half of Retrieval-augmented generation
"Ask the data" in plain English Cortex Analyst over a semantic view Text-to-SQL grounded in the Semantic layer
An assistant that does both and calls tools Cortex Agents and Snowflake Intelligence with Snowflake Intelligence as the front end Orchestrates Analyst, Search and custom tools
Custom models, fine-tuned or open-weight Snowflake ML and Snowpark Container Services GPU compute pools. Use it when managed models cannot do the job
An AI front end for a business team Streamlit in Snowflake Runs under the caller's role

Anthropic Claude models are available in Cortex alongside others, but not natively in Sydney. The Sydney (AWS AP Southeast 2) region runs only a small native set (some Llama and Mistral models, embeddings and the task functions such as AI_EXTRACT, AI_CLASSIFY and AI_AGG). Current Claude models (for example claude-opus-5-5, claude-sonnet-5-5, claude-haiku-5-5) are reached through cross-region inference with Australian routing. See model availability and regional availability.

Keep it in Australia

Cortex routing is set by one account parameter, CORTEX_ENABLED_CROSS_REGION. Four kinds of value: ANY_REGION (any cloud, anywhere), cloud-wide (AWS_GLOBAL), geography (AWS_AU, AWS_APJ, AWS_EU and others) and DISABLED (home region only). The inference payload is transient in the processing region and not stored there.

Do not rely on the default. Accounts in new organisations created after 9 March 2026 default to ANY_REGION. Under the 2026_06 behaviour change, other unset Sydney accounts default to AWS_AU, but government, finance and healthcare accounts are excluded and the Azure and Google Australian regions are unchanged (BCR 2376). Set it explicitly:

-- Australian processing only, with access to current Claude models
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'AWS_AU';
SHOW PARAMETERS LIKE 'CORTEX_ENABLED_CROSS_REGION' IN ACCOUNT;

-- AI functions are granted to PUBLIC by default: restrict them
REVOKE USE AI FUNCTIONS ON ACCOUNT FROM ROLE PUBLIC;
GRANT  USE AI FUNCTIONS ON ACCOUNT TO ROLE ai_builder;
GRANT  DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE ai_builder;

-- Allow specific models per role (model RBAC replaces CORTEX_MODELS_ALLOWLIST).
-- PUBLIC inherits every model through CORTEX-MODEL-ROLE-ALL by default: remove that first
CALL SNOWFLAKE.LOCAL.REVOKE_FROM_PUBLIC_APPLICATION_ROLE('APP_ROLE', 'CORTEX-MODEL-ROLE-ALL');
ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'None';
CALL SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH();
GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-CLAUDE-SONNET-5-5" TO ROLE ai_builder;

AWS_AU keeps prompts in Australia, which is the practice default for SENSITIVE data. DISABLED is stricter, but leaves Sydney accounts without Claude. Any wider routing (AWS_APJ, ANY_REGION) is a recorded decision for OFFICIAL, non-personal workloads only, not a toggle. The account-level CORTEX_MODELS_ALLOWLIST parameter can only be set to 'None' since August 2026 and will be removed later in 2026, so use model RBAC instead. Access is granted if either mechanism permits it, and ACCOUNTADMIN always reaches every model, so test with another role (check the exact model role names with SHOW APPLICATION ROLES LIKE 'CORTEX-MODEL%' IN APPLICATION SNOWFLAKE). See cross-region inference, model access, ADR-005: Governed model access through an AI gateway and Data residency.

Patterns that work

1. Enrich in the pipeline, not at query time. Classify each new record once, store the result, and let BI and agents read a plain column.

CREATE OR REPLACE DYNAMIC TABLE silver.crash_narrative_enriched
  TARGET_LAG = '1 hour' WAREHOUSE = wh_ai AS
SELECT crash_id,
       narrative,
       AI_CLASSIFY(narrative,
         ['speed', 'fatigue', 'distraction', 'alcohol_drugs', 'road_condition', 'other']
       ):labels[0]::string AS primary_factor
FROM bronze.crash_reports;

2. Search over curated text, not raw dumps. Chunk the documents, attach attributes for filtering (business unit, document type, classification), and index only what the audience may read.

CREATE CORTEX SEARCH SERVICE gold.policy_search
  ON chunk_text
  ATTRIBUTES doc_type, business_unit
  WAREHOUSE = wh_ai
  TARGET_LAG = '1 day'
AS SELECT chunk_text, doc_type, business_unit, source_url
   FROM silver.policy_chunks
   WHERE classification = 'OFFICIAL';

3. Analyst only on a semantic view. Cortex Analyst is only as good as the semantic model behind it. Define metrics, synonyms and verified queries once (see The semantic layer), and keep them in git next to the dbt models.

4. Agents with narrow tools. Give a Cortex Agent one Analyst tool per domain and one Search tool per corpus, not "everything". Snowflake's managed Model Context Protocol server can expose the same tools to external assistants under the same roles.

When not to use Cortex

  • Very large batch inference. Millions of long documents can be cheaper on provisioned throughput elsewhere. Do a cost test first (Cost control on Snowflake).
  • Complex multi-agent systems with many bespoke tools, custom memory and heavy evaluation loops. That work is better supported on Databricks Agent Bricks or a dedicated agent runtime.
  • When the model you need is not in-region. Do not quietly turn on cross-region inference to get it.

Pitfalls

  • Running AI_COMPLETE over a full table in an ad-hoc query. It costs tokens per row; always filter and sample first.
  • Skipping evaluation. Keep a fixed question set with expected answers for every Analyst semantic view and every Search service, and rerun it on every change. See Evaluating AI systems.
  • Treating classification output as fact. AI-derived columns need a _ai suffix or a tag, a model version, and Human in the loop review before they inform decisions about people.

Worked example

The Customer Service Centre knowledge assistant indexes procedure manuals in Cortex Search. A Cortex Analyst semantic view over the registrations gold layer answers counts and trends. One Cortex Agent combines the two, so a staff member can ask "what's the process for a transferred interstate registration, and how many did we do last month in the Metro North region?" and get a cited answer. Personal information never enters the search index, and the Analyst view runs under the staff member's own masked role.