Live AI Dream Session, Vol. 3: Trustworthy AI in Practice with Sarath Kuravi and Dr. Shonraj Ballae • Nov 10 | 11:00 AM EST Reserve Your Seat Claim Free Seat

Reserve Your Seat
Intuceo
Book a Briefing

Tag: Generative AI

Generative AI in Manufacturing: Moving Beyond Chatbots to Production-Grade Automation

Posted on by Intuceo
Most plants that have experimented with generative AI (GenAI) in manufacturing started in the same place: an assistant that answers questions about manuals, standard operating procedures (SOPs), and safety documents. It is a reasonable entry point, but it rarely moves throughput, yield, or engineering lead time. Larger gains come from workflows where models draft controller logic, generate training data for inspection systems, and prepare quality and maintenance records from live plant data.
For operations and engineering leaders evaluating generative AI for production automation, the key question is which workflows can safely accept model output as an input to a controlled process. The answer depends on three things: the data behind the model, how it connects to plant systems, and who approves what it produces. This guide covers four areas:
  • the use cases with the strongest evidence behind them
  • how those use cases connect to manufacturing execution systems (MES) and enterprise resource planning (ERP)
  • the governance that keeps them in service
  • how to sequence a program that reaches production

Key Takeaways

  • The strongest GenAI gains come from drafting code, training data, and records, not from chatbots.
  • Four use cases are production-ready: PLC code generation, multi-agent engineering retrieval, synthetic defect data, and record drafting from MES and CMMS data.
  • Integration should follow ISA-95 boundaries, with narrowly defined tools for any action.
  • Governance needs authority levels, plant-data evaluation, full logging, and model change control.

What Is Generative AI in Manufacturing?

Generative AI in manufacturing is the use of models that create new content, such as PLC code, defect images, and quality records, from plant and engineering data. Production-grade systems ground every output in systems of record and route it through an existing review step before it affects the process.

What Does Production-Grade Generative AI Mean on a Plant Floor?

A chatbot only retrieves and answers. A production-grade system also drafts records and, in limited cases, takes action, and each of those steps leaves a trail that an auditor or shift supervisor can follow. Three properties define the difference:
  • Grounding in systems of record: Answers and drafts are built from MES, ERP, historian, and engineering data, with the source attached. They are not built from the model’s general training.
  • A defined output destination: Output lands somewhere specific where an existing review step already applies. Examples include a programmable logic controller (PLC) project, a nonconformance report, or a training dataset.
  • Graded authority: Each task is assigned a level of authority based on its risk: to inform, to recommend, or to execute.
These properties are what take generative AI in manufacturing beyond chatbots and simple assistants. The model becomes one component inside an engineered workflow, and the workflow carries the accountability.

Which Generative AI Use Cases in Manufacturing Are Production-Ready in 2026?

The examples below are among the clearest real-world cases of production-grade generative AI in factory operations. The strongest GenAI manufacturing use cases share a pattern: the model produces something an engineer or technician already produces by hand, in a format that existing review steps can check.

Controls Engineering: Generative AI for PLC Code and Unit Tests

Siemens and Schaeffler offer a well-documented public example of generative AI for PLC programming. Siemens Industrial Copilot connects to the Totally Integrated Automation (TIA) Portal through its open application programming interface (API). This lets Schaeffler’s automation engineers generate PLC code from natural-language instructions. Siemens also positions the copilot for two further tasks: generating unit tests of function blocks, and guiding maintenance teams through step-by-step fixes drawn from the documentation in TIA Portal [1].
The design choice worth copying is where the output goes. Generated code passes through the same engineering environment, simulation, and commissioning checks as code written by hand. The model speeds up a scarce skill without bypassing the validation that protects the line.

Engineering Knowledge: Multi-Agent Retrieval Across Domains

Toyota’s O-Beya system takes its name from the Japanese for big room, a long-standing Toyota term for collaborative teams. It uses nine specialized agents covering areas such as vibration and fuel consumption. An engineer can query several agents at once, and the system combines their answers into a single response.
The system draws on Toyota’s past design reports, current regulatory information, and handwritten notes from veteran engineers. Human experts review its responses to improve it over time. Around 800 powertrain engineers have had access since January 2024 [2].
For manufacturers losing expertise as experienced staff retire, the lesson is in how the system is organized. Separate agents for each discipline, each tuned to its own sources, give a more defensible answer than one assistant searching everything. A regulatory limit and a performance target appear side by side rather than blended together.

Quality: Synthetic Defect Data for Vision Inspection

Generative AI quality control is usually discussed as inspection itself. A more valuable role comes earlier: producing synthetic defect data, the images that inspection models need but plants rarely have. This matters most when a new part is launched and few real defects exist.
Industrial research published in April 2026 demonstrated a diffusion-based method that transfers the appearance of a defect onto new surfaces. It needed only three to five annotated reference examples. With no real defect images from the target surface, it raised detection accuracy from 65.0% to 85.1% on a private industrial dataset, measured as mean average precision (mAP) [3].
The operational benefit is timing. Computer vision inspection can be trained and validated before a new part reaches volume, rather than after enough scrap has accumulated to build a dataset.

Maintenance and Quality Records: Drafting From Live Plant Data

This use case draws less attention than the others but is often the simplest to start, because it requires no change to control systems. Large language models (LLMs) can draft shift handover notes, nonconformance reports, and corrective and preventive action (CAPA) summaries. They do this by pulling alarm history, work orders, and batch records from MES and the computerized maintenance management system (CMMS). Free-text technician logs often record recurring failure causes that sensors miss, and these logs become structured inputs to root cause analysis.
Applied this way, LLMs in manufacturing operations shorten documentation cycles without gaining authority over the process itself. A quality engineer still approves the record, while the model removes the time spent assembling it.
The table below summarizes the four use cases and the review step each one relies on.
Use case What the model produces Existing review step Public example
PLC code Controller logic and unit tests TIA Portal simulation and commissioning Siemens and Schaeffler
Engineering knowledge Combined multi-agent answers Human expert review Toyota O-Beya
Quality inspection Synthetic defect images Model validation before volume April 2026 diffusion research
Records Handover notes, NCRs, CAPA summaries Quality engineer approval General pattern, no single named example

How Does Generative AI in Manufacturing Integrate With MES and ERP Systems?

Generative AI integrates with MES and ERP through read-only grounding, draft-and-approve records, and narrowly defined tools for limited actions, never through direct writes to control systems.
The ISA-95 standard from the International Society of Automation (ISA) provides a reliable map for this work. It places MES and supervisory control and data acquisition (SCADA) systems at Level 3 and business systems such as ERP at Level 4. The standard focuses mainly on the connection between the two [4]. Generative AI in MES and ERP environments should work within those boundaries rather than create a shortcut across them.
Integration pattern What the model touches Control required
Read-only grounding Historian, MES genealogy, ERP orders, engineering documents Role-based access and source citation on every answer
Draft and submit Nonconformance reports, work orders, CAPA records Human approval in the existing workflow before commit
Limited execution Scheduling adjustments, parameter suggestions within limits Pre-approved action set, hard limits, full logging
Control-layer changes PLC logic, recipes Engineering change process only, never direct write
The Model Context Protocol (MCP) is an open protocol for connecting LLM applications to external data sources and tools. Its specification requires hosts to obtain explicit user consent before invoking any tool [5].
Rather than giving a model broad database credentials, teams can expose individual MES and CMMS functions as narrowly defined tools, each tied to a single business transaction. This is also the foundation for any AI agent on the manufacturing floor. The agent can only do what its tools allow, and every tool call can be audited.

What Governance Does Generative AI in Manufacturing Need to Run Safely?

Plant governance for GenAI covers two areas: the risks of the model, and the risks of its connections to plant systems.
On the model side, the National Institute of Standards and Technology (NIST) Generative AI Profile, NIST AI 600-1, lists 12 risks that are specific to or worsened by generative systems. Two matter most in a plant. The first is confabulation, where a system confidently presents incorrect content. The second is value chain and component integration, which covers third-party models and data entering your environment [6]. Confabulation is manageable when every output carries its source and passes through review. It becomes a material risk once a model writes directly to a system of record.
On the connection side, any GenAI service that reaches operational technology should meet the same expectations as other plant-floor software. The ISA and International Electrotechnical Commission (IEC) 62443 series addresses the security of industrial automation and control systems across their lifecycle [7]. GenAI connections to plant systems should be segmented, authenticated, and monitored on those terms.
A workable governance baseline for production automation with generative AI includes:
  • Documented authority levels: Every workflow has its authority level recorded before go-live. Execution is limited to reversible actions within pre-set limits.
  • Evaluation against plant data: Models are tested on historical cases from your own lines, against acceptance thresholds agreed with quality and engineering.
  • Traceability by default: Prompts, retrieved sources, tool calls, and approvals are logged and kept alongside the records they influenced.
  • Change control for models: A model or prompt update is treated as a software change to a validated system, with regression testing before release.

How Should Manufacturers Sequence a GenAI Program to Reach Production?

Plants that move generative AI in manufacturing past pilots usually begin with one high-volume documentation workflow, which proves grounding and integration at low process risk. Engineering assistance follows, since its outputs pass through existing validation. Limited execution comes last, once evaluation results and audit trails are in place to justify it. Each stage builds the data access and controls that the next one depends on. A GenAI readiness session with Intuceo helps teams pick that first workflow.

How Intuceo Helps Manufacturers Put GenAI Into Production

Intuceo’s PhD-led team delivers generative AI for manufacturing where models meet plant data. The firm’s work spans three areas:
  • Industrial data pipelines: consolidating PLC, SCADA, sensor, and ERP streams.
  • Root cause analysis: applying natural language processing to technician logs and maintenance reports to surface recurring causes.
  • GenAI solutions: built on Azure OpenAI, with role-based access controls and data lineage through Microsoft Purview.
Each engagement begins with an assessment of candidate use cases and data readiness. The first deployment is selected for measurable impact on downtime, quality cost, or engineering lead time, and it is governed from the start.
Find the GenAI workflow on your floor that is ready for production. Book a manufacturing GenAI readiness session with Intuceo’s engineering team.

Frequently Asked Questions

Manufacturers use generative AI in four main ways:
  • Industrial data pipelines: consolidating PLC, SCADA, sensor, and ERP streams.
  • Root cause analysis: applying natural language processing to technician logs and maintenance reports to surface recurring causes.
  • GenAI solutions: built on Azure OpenAI, with role-based access controls and data lineage through Microsoft Purview.
In each case, the output enters an existing review or validation step.
A chatbot only retrieves and answers. Production-grade generative AI also drafts records and, in limited cases, takes action. Every output is grounded in systems of record, lands in a defined review step, and carries an authority level of inform, recommend, or execute.
The most mature are documentation drafting from live plant data, controls engineering assistance, and engineering knowledge retrieval grounded in internal reports. Synthetic training data for quality inspection is close behind, with strong research results. These use cases are ready for production because their outputs can be checked by processes plants already run.
Yes, when generated code passes through the same engineering environment, simulation, and commissioning checks as hand-written code. Siemens Industrial Copilot, used by Schaeffler, generates PLC code inside TIA Portal, so existing validation stays in place.
Integration works best when it follows ISA-95 boundaries. That means read-only access for grounding, draft-and-approve patterns for records, and narrowly defined tools for any action. Protocols such as MCP let teams expose specific MES or ERP functions as auditable tools instead of granting broad system access.
Plants need four controls: documented authority levels for each use case, evaluation against their own historical data, full logging of sources and actions, and change control for model updates. NIST AI 600-1 provides a risk catalog for the model. ISA/IEC 62443 sets security expectations for how GenAI services connect to operational systems.

RAG vs Fine-Tuning: How Enterprise Teams Should Actually Decide

Posted on by Intuceo
Enterprise teams tend to treat the choice between retrieval and retraining as a purely technical question, then spend weeks debating it before a single use case. In practice, the market has already settled into a clear pattern. Across 600 enterprise technology decision-makers surveyed by Menlo Ventures, Retrieval-Augmented Generation (RAG) reached 51 percent of production deployments, while fine-tuning accounted for just 9 percent.1
That gap reflects what each method is built to do, what it costs to run, and how much control an organization keeps over its own data.
The RAG vs fine-tuning question is less about which is smarter and more about matching the method to the problem in front of you. This guide breaks down where each approach earns its place, why one of them is quietly ruled out for most closed models, and how to make the call without stalling delivery.

What is the difference between fine-tuning and RAG?

Both methods start from the same place: a pretrained Large Language Model (LLM) that is fluent in language but knows nothing specific about your business. They diverge in how they add that missing knowledge.
RAG leaves the model untouched. When a user asks a question, a retrieval system searches a connected knowledge base, usually a vector index built from your documents, pulls the most relevant passages, and places them into the model’s prompt as context. The model then answers using that supplied material. Update the documents, and the answers update with them. Nothing is retrained.
Fine-tuning takes the opposite route. It adjusts the model’s internal weights by training it further on a curated set of examples, teaching it a specific style, format, or task pattern. The knowledge becomes part of the model itself rather than something fetched when a question is asked.
So the short answer to what is the difference between fine-tuning and RAG is a question of where the knowledge lives. RAG keeps it external and current. Fine-tuning bakes it in at a fixed point in time. That single distinction drives almost every practical trade-off that follows.

What RAG is actually good at, and when it is the cheaper, faster answer

RAG’s core strength is grounding. Because the model answers from retrieved source material rather than memory, it can point to where an answer came from and stay current as that material changes. That matters most in fields where being wrong is expensive.
A 2025 study published in JMIR Cancer measured this directly. When Generative Pre-trained Transformer (GPT) models answered cancer-information questions using a curated, authoritative knowledge base through RAG, the hallucination rate fell to between 0 and 6 percent. The same models answering from memory alone, with no retrieval, produced medically harmful or incorrect information in roughly 40 percent of responses.2 The only variable that changed was whether the model was grounded in a trusted source.
RAG is also the faster and cheaper option under a specific set of conditions. It wins when your knowledge changes frequently, because refreshing an index costs far less than retraining a model. It wins when answers must be traceable to a source, which fine-tuning cannot provide. And it wins when you need to move quickly, since RAG works with the strongest available closed models straight away, with no training run required. For most enterprise knowledge tasks, internal search, policy lookup, or customer support grounded in documentation, RAG is the pragmatic default for exactly these reasons.

Why fine-tuning is only feasible for open models, and what that rules out

Here is the constraint many teams discover late. Genuine fine-tuning, the kind that changes a model’s weights and keeps the result under your control, requires access to those weights. The most capable closed models, reached only through an Application Programming Interface (API), do not hand them over.
Some closed providers offer managed fine-tuning services, but these carry conditions that matter in regulated settings. Your training data leaves your environment to reach the provider. You are limited to whichever base models that provider permits. And the tuned model still runs on their systems, not yours. For an organization bound by data residency rules or handling protected health information under the Health Insurance Portability and Accountability Act (HIPAA), that is often a non-starter.
That leaves open-weight models, such as those in the Llama or Mistral families, as the only route to fine-tuning that keeps both the data and the model inside your own environment. Choosing to fine-tune therefore carries a second, unavoidable decision: adopting and running an open model, with the infrastructure and engineering that implies. RAG imposes no such constraint, which is part of why it dominates in practice.

Using RAG and fine-tuning together

Framing this as a binary is the most common mistake. The two methods solve different problems, so the strongest systems often use both.
The pattern is straightforward. Fine-tuning shapes how a model behaves, including the tone it uses, the format it returns, and the domain-specific reasoning it applies. RAG supplies what the model needs to know right now. A model can be fine-tuned to respond in a validated regulatory style and structure, then paired with RAG so every answer is grounded in the latest approved documents.
Research supports the combination. In RAFT (Retrieval-Augmented Fine-Tuning), researchers at the University of California, Berkeley trained models to work with retrieved documents, including learning to ignore irrelevant ones, and found this improved accuracy on domain-specific tasks over either approach used alone.[3] The catch is capability. A hybrid approach needs both machine learning and data engineering skills at the same time, a combination many teams do not have in-house. That is precisely where sequencing the decision, and knowing when to bring in outside help, becomes the real work.

A simple checklist to make this decision

Many teams struggle when they pick a method first and reverse-engineer the justification. The key is to reach a confident answer by working through a handful of questions:
  • Does knowledge change often? If yes, favor RAG. Retraining a model to keep it current is slow and expensive.
  • Do answers need to cite a source? If yes, RAG. Fine-tuning cannot produce traceable citations.
  • Is the problem about what the model knows, or how it behaves? Facts point to RAG. Consistent format, tone, or task behavior points to fine-tuning.
  • Do you have labeled training examples? Fine-tuning needs them. If you do not, RAG is the faster start.
  • Must the data and the model stay inside your environment? If yes, fine-tuning means committing to an open-weight model.
  • Do you have the engineering capacity to maintain a tuned model? If not, RAG carries far less operational overhead.
Your answers to these questions will determine the RAG vs fine-tuning decision.

Where this decision gets harder in regulated industries

For organizations in pharmaceuticals, life sciences, healthcare, and the public sector, this decision rarely stops at method selection. It runs straight into data residency, compliance, and the question of how to ground a model in proprietary knowledge without ever exposing that knowledge. This is where a services partner with prior regulated experience changes the calculation.
Intuceo approaches the retrieval side of this problem with accelerators drawn from earlier engagements rather than tools installed from scratch. Intuceo-Ix™, a neural semantic search accelerator, retrieves by meaning rather than keyword across fragmented clinical, engineering, and regulatory documents. Intuceo-Dx™ adds retrieval-augmented extraction over document libraries, letting teams query dense institutional records as if consulting an expert. Both can be configured to run in air-gapped, on-premise, or private-cloud environments, so sensitive data and models stay under the organization’s control, and proprietary information is never used to train outside models. Delivery follows iPDLC™, Intuceo’s proprietary Project Development Life Cycle, with PhD-led quality gates at each step.
The upcoming AI Dream Session extends this into planning. Guided by the DARWIN framework, the session helps teams weigh the infrastructure and security implications of each path, including the hardware sizing and model-protection decisions that separate a working prototype from a production system. The result is a grounded roadmap, not a bet on the newest model.

Deciding between RAG and fine-tuning for a regulated use case?

Bring your specific problem to us and work through the method, the infrastructure, and the compliance constraints with a team that has delivered in regulated environments before.

Schedule a Consultation

Frequently Asked Questions

The difference comes down to where the knowledge lives. RAG retrieves relevant documents at query time and feeds them to the model as context, leaving the model unchanged. Fine-tuning retrains the model’s weights on examples so the knowledge or behavior becomes part of the model itself. RAG stays current as documents change; fine-tuning captures a fixed snapshot.
For most enterprise knowledge tasks, yes. Updating a retrieval index costs far less than running a training job, and RAG works immediately with strong closed models, so there is no upfront training cost. Fine-tuning becomes more efficient mainly at very high query volumes on a fixed, stable task.
Yes, and strong systems often do. Fine-tuning is used to fix a model’s tone, format, or task behavior, while RAG supplies current facts and source grounding. The main barrier is capability, since a hybrid setup requires both machine learning and data engineering skills at once.
Fine-tuning that you control requires access to the model’s weights, which access-only closed models do not provide. Managed fine-tuning services exist, but they require sending training data to the provider and running the result on the provider’s systems, which is often unacceptable for regulated data. Keeping data and the model in-house means using an open-weight model.
RAG is usually the safer starting point in regulated industries because it keeps proprietary data external to the model, supports source traceability for audit, and updates without retraining. Fine-tuning still has a role for consistent behavior and format, but in regulated settings it typically requires an open model deployed inside a controlled environment.