An OEE analytics application that took 12 weeks and a team of developers to build a year ago can now be generated in minutes. Snowflake’s Cortex AI accepts a prompt describing the industry vertical, target use case, and boundary conditions, and produces a working solution. For manufacturers sitting on thousands of plant-floor use cases that never survived the IT queue, the speed change is significant.
But Pugal Janakiraman, Manufacturing Industry Principal at Snowflake, points to a problem that faster tooling will not solve on its own: most manufacturers still cannot connect their IT and OT data in a way that reflects how their plants actually run. PLCs, SCADA systems, historians, MES, ERP, maintenance platforms, quality systems, and spreadsheets all hold pieces of the picture. The data exists. It is fragmented, inconsistent across sites, and missing the production context that would make it useful for any AI application, fast or slow.
Why Questioning the Algorithm Is Usually the Wrong First Move
When an AI application delivers weak results on the plant floor, the instinct is to troubleshoot the model. Was it trained on the right data? Was the prompt specific enough? Does the vendor understand manufacturing?
Those are reasonable questions for later. The first question is whether the data underneath is organized enough to support any model at all. Can the organization tie a temperature reading to the specific asset, product, batch, shift, and operating condition it came from? Can a maintenance event be linked to its downstream effect on throughput or quality? Can a business user query production data without calling engineering first?
If not, the AI layer is working from incomplete inputs, and no algorithm can compensate for that.
This is where the Unified Namespace enters the conversation. Janakiraman describes it as a single, semantically organized data infrastructure where IT and OT data come together in a structure that reflects how the plant actually operates. A UNS gives every data point its operational meaning: what it measures, where it sits in the process, and what business outcome it connects to. Without that layer, manufacturing AI tools have no reliable way to interpret the data they are processing.
The architecture to support this is typically hybrid. Edge infrastructure handles latency-sensitive control and production continuity. Cloud platforms like Snowflake’s AI Data Cloud for Manufacturing handle analytics, multi-site data sharing, and AI development at scale. The data needs to be in the right place and in the right structure before any AI application can use it.
Building Applications Faster Does Not Fix the Inputs
Cortex AI lets business users describe a manufacturing use case in a prompt and get a working analytics application back, something that previously required weeks of developer time and IT coordination. For organizations with long internal backlogs, that changes who can build tools and how quickly operational questions get answered.
The risk is treating that speed as a shortcut past the data problem. A dashboard generated in five minutes still relies on whatever data feeds it. If the asset history is incomplete, the OEE numbers are wrong. If process conditions are not linked to quality outcomes, the model’s recommendations are guesses. If the data schema differs between sites, multi-plant comparisons are unreliable.
Faster application development amplifies whatever is underneath it, whether that is clean, contextualized data or a disconnected patchwork of systems that were never designed to talk to each other.
Five Questions Before Selecting Any AI Tool
A practical approach gaining traction in North America compresses the proof-of-value cycle into a single week. A team identifies one business use case, scopes it to one line or one machine, works with real production data, and demonstrates a measurable outcome by Friday. The purpose is to test whether the data architecture can support the use case before committing to a broader rollout.
Most proof-of-value projects that stall do so for reasons that have nothing to do with AI. The scope was too broad. The data was synthetic. Nobody defined which specific decision the output was supposed to improve. The result could not be tied to throughput, quality, cost, or safety.
Before selecting any tool or model, a manufacturing AI project should answer:
- What decision are we trying to improve?
- Which line, machine, product, or process is in scope?
- What IT and OT data is required?
- What operational context is needed for the data to be trusted?
- What measurable result would justify scaling?
If those answers are not clear, the problem is not which AI tool to buy. The problem is upstream.
What to Fix First
The manufacturers getting results from AI are the ones building a repeatable path from plant data to operational decisions: organizing data with production context, testing on a real constraint, measuring the outcome, and scaling what works.
AI can compress development cycles and put analytics in the hands of plant experts instead of IT queues. It can help operators move from experience-based judgment to data-supported decisions. But those capabilities depend entirely on the quality of what sits underneath them.
When a manufacturing AI project underdelivers, the bottleneck is rarely the model. It is usually the data the model never had.
FAQ
1. Why do most manufacturing AI projects fail?
Most manufacturing AI projects stall because the underlying IT and OT data is fragmented, poorly contextualized, or difficult for business users to access. Organizations that skip data organization and jump to model selection face disconnected inputs that produce unreliable outputs. The data foundation, not the algorithm, is the more common bottleneck.
2. How is AI being used in manufacturing operations?
AI in manufacturing operations covers quality inspection, predictive maintenance, OEE analytics, natural-language querying of production data, and AI-assisted application development. Snowflake’s Cortex AI, for example, compresses the development of OEE accelerators from 12 weeks of engineering work to minutes of prompt-based generation, allowing plant experts to build their own analytics tools.
3. What is a Unified Namespace (UNS) in manufacturing and why does it matter for AI?
A Unified Namespace is a semantically organized data layer that brings IT and OT data together in one structure that reflects how the plant actually operates. For AI, a UNS provides the operational context that makes raw sensor data, machine events, and business records meaningful enough to act on. Without it, AI tools process fragmented inputs and produce unreliable outputs.
4. What is a good first AI use case for manufacturers?
A good first use case is narrow and tied to a specific operational decision. Reducing downtime on one bottleneck machine, improving OEE visibility on one line, or identifying the root cause of scrap on a specific product all qualify. The use case should define the decision to improve, the data required, and the measurable result that would justify expanding to other lines or sites.
5. Should manufacturing AI run at the edge or in the cloud?
Most manufacturers need both. Edge infrastructure supports latency-sensitive control, local operations, and production continuity during connectivity interruptions. Cloud infrastructure supports broader analytics, AI development, multi-site data sharing, and enterprise governance. Control stays close to the plant floor; analytics and AI development benefit from cloud scale.
This article is based on a video interview with Pugal Janakiraman, Manufacturing Industry Principal and WW Strategic Solutions Lead at Snowflake, and Lucian Fogoros of IIoT World. AI tools were used to help summarize and organize the content. Reviewed and edited by the IIoT World editorial team.
About the author
