# AI for Snowflake in Manufacturing: Questions Across ERP, MES and Quality Data

> Source: https://netray.co/erp-ai/snowflake-ai-for-manufacturing
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for ERP

## Short answer

Snowflake AI for manufacturing means a language model that reads ERP, MES and quality tables landed in Snowflake and answers plain-English questions with the SQL shown, under Snowflake roles. Snowflake Cortex handles this inside the platform; a private layer is for cases where data or models must stay outside a public cloud.

## Kind

platform

## Erp Family

mfg-systems

## Erp Products

- Snowflake

## Industries

- Manufacturing
- Aerospace
- Electronics

## Region

Global

## Persona

Data Platform Lead

## Eyebrow

Snowflake + ERP + AI

## Intro

Manufacturers move ERP data into Snowflake for good reasons: the ERP database is slow for analytics, plants run different ERPs, and finance wants a single place for margin and inventory. Tools such as Fivetran, Qlik Replicate, SAP Datasphere or custom pipelines land sales orders, work orders, BOMs and receipts as raw tables, and a transformation layer in dbt or SQL shapes them into marts.

That is a good foundation, and it still leaves the usual gap. Business users cannot write SQL, and the marts only answer the questions the data team modelled. The person who knows that a SyteLine job status code of 'F' means finished, or that an M3 order line carries two quantities, is not the person asking the question.

Snowflake offers its own tools: Cortex Analyst answers natural-language questions over a semantic model defined in YAML, and Cortex Search handles unstructured text. For teams all-in on Snowflake, with data policy allowing it, these are the obvious first step. They run inside Snowflake's cloud on AWS, Azure or GCP, which is exactly where some manufacturers cannot put data.

This page covers where AI on Snowflake makes sense for manufacturers, what the data engineering must get right first, how access control carries through, and when a private, on-prem layer is the better choice, including the honest case where Snowflake is the wrong place for the data at all.

## Pain Points

### Raw ERP tables are not business-ready

**Detail:** ERP status codes, unit-of-measure conversions, multi-currency amounts and effective-dated records need transformation before anyone, human or model, can ask meaningful questions.

### The semantic layer is the real work

**Detail:** Without agreed definitions of on-time delivery, standard cost, or active item, a model will guess. Building and maintaining those definitions is slower than choosing a model.

### Latency between ERP and warehouse

**Detail:** Batch or CDC pipelines mean the warehouse trails the ERP. Questions about today's shortages need to be honest about how fresh the data is.

### Cost surprises from open-ended queries

**Detail:** Natural-language access to a consumption-priced warehouse can generate expensive scans unless warehouses are sized, resource monitors set, and queries limited.

### Cloud-only platform for restricted data

**Detail:** Snowflake runs on public cloud infrastructure. Export-controlled technical data or contract-restricted records may not be allowed to land there at all.

## Use Cases

### Natural-language analytics over ERP marts

**Description:** Planners and finance ask about backlog, margin or inventory. The layer maps the question to the semantic model, generates SQL, and returns the result with the query visible.

**Erp Objects:** Marts built from sales orders, work orders, BOMs, inventory and purchase receipts

**Outcome:** Reduces ad hoc requests to the data team for questions the marts already cover.

### Cross-plant comparison

**Description:** When plants run different ERPs, the layer works over the harmonized model to compare scrap, lead time and supplier performance with consistent definitions.

**Erp Objects:** Conformed dimensions for item, supplier, plant and calendar

**Outcome:** Comparable numbers across plants without manual reconciliation each month.

### Quality and MES correlation

**Description:** Questions link nonconformances, SPC results and machine events with ERP lots and suppliers, which no single source system holds.

**Erp Objects:** QMS records, MES event tables, ERP lot and receipt tables

**Outcome:** Faster root-cause leads, with the joins visible for an engineer to verify.

### Semantic model drafting

**Description:** The assistant profiles tables, proposes descriptions, synonyms and measure definitions for the semantic model, for a data engineer to review and approve.

**Erp Objects:** Information schema, column samples, dbt models

**Outcome:** Cuts the slow first pass of documenting hundreds of ERP columns.

### Pipeline and freshness explanation

**Description:** When a number looks stale, the assistant reads load history and task state to say when each source last landed and what failed.

**Erp Objects:** Snowpipe or connector load history, tasks, dynamic table refresh state

**Outcome:** Shorter time from 'the dashboard is wrong' to a known cause.

### Cost guardrails for natural-language queries

**Description:** The layer applies limits (row caps, date filters, dedicated small warehouse) and reports which questions drive spend.

**Erp Objects:** Query history, warehouse usage, resource monitors

**Outcome:** Predictable cost for open-ended access.

### Document plus data answers

**Description:** Supplier contracts, quality procedures and the warehouse tables are combined, so a question about a late supplier cites both delivery data and contract terms.

**Erp Objects:** Supplier and receipt tables, contract documents, quality procedures

**Outcome:** Answers that cite data and the governing document together.

## Architecture

**Overview:** Two shapes are common. Inside Snowflake, Cortex Analyst runs on a semantic model. Outside it, a private layer connects through a read-only role, uses the same semantic definitions, and runs its model on infrastructure the customer controls.

**Layers:**

#### Warehouse connector

**Detail:** Connects through the Snowflake connector or SQL API with a dedicated read-only role, using the asking user's role or a mapped role so grants, masking and row access policies apply.

#### Semantic layer

**Detail:** Business definitions as a YAML semantic model or dbt metrics, covering measures, joins, synonyms and verified queries for common questions.

#### Model serving

**Detail:** Either Cortex inside Snowflake, or an open-weight model such as Qwen, Llama or Mistral served with vLLM on customer GPUs, with only query results crossing the boundary.

#### Retrieval

**Detail:** Cortex Search or a private vector index for documents, joined with structured answers when a question needs both.

#### Governance and audit

**Detail:** Every question, SQL statement and result is logged by user, with query tags for cost attribution and approval for any non-read action.

## Deployment Options

### Inside Snowflake with Cortex

**Fit:** Teams whose data policy allows Snowflake and who want the shortest path.

**Detail:** Semantic model and queries stay in the Snowflake account. This is often the right first step, and we say so.

### Private model, Snowflake as source

**Fit:** Companies that keep Snowflake but need the language model outside a hosted service.

**Detail:** A read-only connector pulls query results to a model on customer GPUs or a private cloud, with masking policies applied before data leaves Snowflake.

### On-prem lakehouse instead

**Fit:** Plants whose restricted data cannot be in a public-cloud warehouse.

**Detail:** The same semantic approach over an on-prem database or lakehouse, with Snowflake used only for non-restricted data.

## Compliance

### Queries run under mapped Snowflake roles so masking and row access policies apply to AI answers.

**Framework:** Role-based access, masking and row access policies

### If controlled data may not reside in a public-cloud warehouse, it stays out of Snowflake; classification and data placement decisions remain the customer's.

**Framework:** ITAR and EAR technical data

### Account region selection and a private model deployment help the customer meet residency requirements it has defined.

**Framework:** Data residency and regional regulation

### Query tags and logs let finance reproduce any figure cited in an answer.

**Framework:** Audit and financial controls

## Integration Notes

- ERP ingestion paths vary: SAP via Datasphere or ODP-based tools, NetSuite through SuiteAnalytics Connect, SyteLine and LN through database replication or ION-based extracts.
- Use dbt or Snowflake dynamic tables to convert raw ERP codes into business-readable marts before exposing them.
- Cortex Analyst needs a semantic model file with tables, joins, measures and verified queries; the quality of that file determines answer quality.
- Use a dedicated small warehouse and resource monitor for AI queries to cap spend.
- Apply masking policies to sensitive columns such as cost and customer pricing before connecting any language model.
- Keep query tags on every AI-generated statement for audit and cost attribution.
- Freshness is reported with each answer, from the latest load timestamp of the underlying tables.

## Product Fit

### DataRay

**Why:** Chat with warehouse tables, file shares and documents on-prem or in a private cloud, with the SQL shown.

### Custom build

**Why:** Semantic model design, ERP pipeline work and cross-system agents for Snowflake programs are usually bespoke.

## Engagement

### Discovery

**Duration:** 2-4 weeks

**Deliverables:**

- Review of ERP ingestion, marts and roles
- Data classification and placement check
- Ranked question list
- Cortex versus private layer recommendation

### Pilot

**Duration:** 6-8 weeks

**Deliverables:**

- Semantic model for one domain
- Read-only role and masking review
- 3-5 question patterns live
- Accuracy and cost review

### Production

**Duration:** 4-6 weeks

**Deliverables:**

- Role mapping and audit logging
- Cost guardrails
- Runbook for extending the semantic model
- Handoff to the data team

### Scale

**Duration:** Ongoing

**Deliverables:**

- More domains and plants
- Document retrieval
- Quarterly accuracy review
- Model refresh

## Buyer Questions

- Do masking and row access policies apply to every AI query?
- Should we use Cortex Analyst first, and what would justify going beyond it?
- Who owns and maintains the semantic model?
- How fresh is the data and how is that shown in answers?
- How are warehouse costs capped for open-ended questions?
- Is any restricted data allowed in Snowflake at all?
- Where does the model run, and what leaves Snowflake?
- What do we keep if we stop?

## Faq

### Should we just use Snowflake Cortex?

**Answer:** If your data is already in Snowflake and policy allows it, start there. Cortex Analyst over a good semantic model is a sound first step. A private layer is for models that must run outside a hosted service, restricted data, or cross-source questions beyond the warehouse.

### What matters most for answer quality?

**Answer:** The semantic model and the transformed marts, not the language model. Clear definitions, joins, synonyms and verified queries do most of the work. Plan more effort for the data engineering than for model selection.

### Can it handle several ERPs?

**Answer:** Yes, if the data is harmonized into conformed dimensions such as item, supplier and plant. Without that, the layer can query each source but cross-plant comparisons will carry caveats, which we state rather than hide.

### How are costs controlled?

**Answer:** With a dedicated small warehouse, resource monitors, query timeouts, row limits and date filters, plus query tags to see which questions cost the most. Open-ended access without these is where surprise bills come from.

### Is Snowflake right for export-controlled data?

**Answer:** Often not. Snowflake runs on public cloud infrastructure. Whether controlled technical data may reside there is a decision for your compliance team. If not, keep that data in an environment you control and use Snowflake only for non-restricted data.

### Does data leave Snowflake to a model?

**Answer:** With Cortex, processing stays in Snowflake. With a private model, only query results cross the boundary, after masking policies apply, to a model on your own infrastructure. We document exactly what is sent.

### Can the AI write to the ERP?

**Answer:** Not directly. It can draft recommendations or emails. Changes to ERP records go through the ERP's own workflow with a person approving them.

## Search terms

Snowflake AI for manufacturing, Snowflake Cortex Analyst ERP, Snowflake ERP data, natural language query Snowflake, Snowflake manufacturing analytics, Snowflake SAP data AI, Snowflake semantic model ERP, private LLM Snowflake, chat with Snowflake data, Snowflake MES data, Snowflake data warehouse manufacturing, Snowflake alternative on-prem AI

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json