Snowflake + ERP + AI
AI for Snowflake in Manufacturing: Questions Across ERP, MES and Quality Data
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.
- ERP
- Snowflake
- Industries
- Manufacturing, Aerospace, Electronics
- Written for
- Data Platform Lead
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.
What usually gets in the way
The problems we hear most from data platform lead teams running Snowflake.
Raw ERP tables are not business-ready
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
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
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
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
Snowflake runs on public cloud infrastructure. Export-controlled technical data or contract-restricted records may not be allowed to land there at all.
Where AI earns its place in Snowflake
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Natural-language analytics over ERP marts
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.
Touches: 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
When plants run different ERPs, the layer works over the harmonized model to compare scrap, lead time and supplier performance with consistent definitions.
Touches: Conformed dimensions for item, supplier, plant and calendar
Outcome: Comparable numbers across plants without manual reconciliation each month.
Quality and MES correlation
Questions link nonconformances, SPC results and machine events with ERP lots and suppliers, which no single source system holds.
Touches: 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
The assistant profiles tables, proposes descriptions, synonyms and measure definitions for the semantic model, for a data engineer to review and approve.
Touches: Information schema, column samples, dbt models
Outcome: Cuts the slow first pass of documenting hundreds of ERP columns.
Pipeline and freshness explanation
When a number looks stale, the assistant reads load history and task state to say when each source last landed and what failed.
Touches: 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
The layer applies limits (row caps, date filters, dedicated small warehouse) and reports which questions drive spend.
Touches: Query history, warehouse usage, resource monitors
Outcome: Predictable cost for open-ended access.
Document plus data answers
Supplier contracts, quality procedures and the warehouse tables are combined, so a question about a late supplier cites both delivery data and contract terms.
Touches: Supplier and receipt tables, contract documents, quality procedures
Outcome: Answers that cite data and the governing document together.
Reference architecture
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.
- 1
Warehouse connector
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.
- 2
Semantic layer
Business definitions as a YAML semantic model or dbt metrics, covering measures, joins, synonyms and verified queries for common questions.
- 3
Model serving
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.
- 4
Retrieval
Cortex Search or a private vector index for documents, joined with structured answers when a question needs both.
- 5
Governance and audit
Every question, SQL statement and result is logged by user, with query tags for cost attribution and approval for any non-read action.
Integration notes for your ERP team
- 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.
Deployment options
Inside Snowflake with Cortex
Teams whose data policy allows Snowflake and who want the shortest path.
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
Companies that keep Snowflake but need the language model outside a hosted service.
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
Plants whose restricted data cannot be in a public-cloud warehouse.
The same semantic approach over an on-prem database or lakehouse, with Snowflake used only for non-restricted data.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
Role-based access, masking and row access policies
Queries run under mapped Snowflake roles so masking and row access policies apply to AI answers.
ITAR and EAR technical data
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.
Data residency and regional regulation
Account region selection and a private model deployment help the customer meet residency requirements it has defined.
Audit and financial controls
Query tags and logs let finance reproduce any figure cited in an answer.
How an engagement runs
Phase 1 . 2-4 weeks
Discovery
- -Review of ERP ingestion, marts and roles
- -Data classification and placement check
- -Ranked question list
- -Cortex versus private layer recommendation
Phase 2 . 6-8 weeks
Pilot
- -Semantic model for one domain
- -Read-only role and masking review
- -3-5 question patterns live
- -Accuracy and cost review
Phase 3 . 4-6 weeks
Production
- -Role mapping and audit logging
- -Cost guardrails
- -Runbook for extending the semantic model
- -Handoff to the data team
Phase 4 . Ongoing
Scale
- -More domains and plants
- -Document retrieval
- -Quarterly accuracy review
- -Model refresh
Questions to ask any vendor, including us
A short list that separates real Snowflake AI work from a chatbot demo.
- 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?
Frequently asked questions
Should we just use Snowflake Cortex?
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?
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?
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?
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?
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?
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?
Not directly. It can draft recommendations or emails. Changes to ERP records go through the ERP's own workflow with a person approving them.
Related guides
Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English
See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.
RAG + SQL + permissionsA Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
Databricks + ERP + AIAI for Databricks in Manufacturing: Lakehouse Data From ERP, MES and the Line
Use Databricks lakehouse data from ERP, MES and sensors for grounded AI, with Unity Catalog governance, and see when Genie fits versus a private on-prem layer.
ERP migration + on-prem AIAI-assisted data migration for ERP implementations
AI speeds ERP data migration by profiling legacy data, proposing field mappings, and flagging cleansing issues before cutover, with a human validating every rule.
Agents + approval gatesAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
ERP AI readinessIs Your ERP Ready for AI? A Readiness Assessment Checklist
Is your ERP actually ready for AI? A practical checklist covering master data quality, access and permissions, GPU sizing, and governance before you fund a pilot.
Plan it with numbers
ERP AI Maturity Assessment
Benchmark how deeply AI and automation are embedded in your ERP operations, from data foundations to autonomous agents, across four maturity levels.
Free ToolERP Integration Complexity Calculator
Estimate the hours, cost, and elapsed time of your ERP integration workstream from interface count, integration patterns, and middleware maturity.
Free ToolOn-Prem AI ROI Calculator
Turn hours saved per employee into annual net benefit, payback months, and 3-year ROI for an on-prem AI investment.
GuideSyteLine Data Warehouse: ETL Design, Star Schema & Historical Analytics
Design a data warehouse for Infor SyteLine ERP data. Build ETL pipelines, star schema models, and historical analytics from SL tables for manufacturing BI.
GuideERP Data Governance Framework: Policies, Roles & Tools
Establish an ERP data governance framework with defined policies, stewardship roles, and quality metrics. Maintain data integrity across the ERP lifecycle.
GuideNatural Language ERP Query Interface
Query your ERP using natural language. Transform plain English questions into SQL/API calls with LLM-powered interfaces that democratize ERP data access.
Talk it through with an engineer who knows Snowflake
Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.