Generative AI in Manufacturing: Practical Use Cases Grounded in Plant Data

Generative AI in manufacturing is most valuable when it works on top of real plant data rather than general knowledge. This article walks through use cases that hold up on a real shop floor, the data plumbing they need, and the guardrails that keep a language model useful instead of risky. By the end you will know which project to start with and how to feed it live machine data over MQTT.

Why Generative AI Manufacturing Projects Stall

Most early experiments look impressive in a demo and then fade. The pattern is familiar: someone pastes a few alarm codes into a chat window, gets a plausible explanation, and the team concludes that the model "knows" the machines. A week later it confidently explains an alarm that does not exist on that controller.

The underlying problem is grounding. A large language model has broad knowledge about CNC machines, PLCs and quality methods, but it knows nothing about your line 3, your recipe for part 4711 or the fact that the furnace on the night shift always runs ten degrees hot. Without that context it fills the gap with guesses.

So the useful question is not "what can generative AI do?" but "which tasks are mostly about turning existing data and documents into text, and where can we give the model that data reliably?" That reframing points to a short list of use cases that work.

Use Cases That Work Today

Shift Reports and Downtime Summaries

This is the easiest win. Every plant has someone who spends the last half hour of a shift compiling what happened: which machines stopped, why, how many parts were produced and what the next shift should watch. The data already exists as machine states and counters. A small service can collect the shift's events, build a structured summary (numbers computed in code, not by the model) and ask the language model to turn it into readable prose.

The important design choice is to let the model write, not calculate. Compute OEE, downtime minutes and part counts in Python or SQL, pass them as facts, and instruct the model to use only those values. If you want a deeper walkthrough of that pattern, see LLM sensor data summaries.

Troubleshooting Assistants

When a machine alarms at 3 a.m., the technician needs the manual page, the last similar incident and the current state of related signals. A troubleshooting assistant retrieves those pieces and presents them together with a suggested checklist. Retrieval over manuals and past tickets is the core, which is why this use case usually builds on retrieval-augmented generation for industrial data.

The live part matters as much as the documents. An assistant that sees "spindle temperature rising for 20 minutes, coolant flow dropped at 02:41" gives far better suggestions than one that only sees the alarm number.

Code and Integration Help

Engineers spend a surprising amount of time writing glue: a Node-RED function to reshape a payload, a Python subscriber, a SQL query for a report. Language models are good at drafting this when they see real examples. Give the model a sample MQTT payload and your topic convention and it can draft a parser in seconds. Treat the output like code from a new colleague: review it, test it against the public test broker, then promote it.

Industrial Copilots

Combine the three above and you get what vendors call an industrial AI copilot: one interface where an operator asks questions, gets summaries and drafts actions. Start with read-only access. Writing setpoints or commands from a model is a separate, much harder problem with its own safeguards.

The Data Foundation: Streaming Plant Data over MQTT

Every use case above depends on fresh, structured data. MQTT is a natural fit because machines, gateways and edge devices already publish to it, and any number of consumers can subscribe without touching the machines.

A practical topic layout follows ISA-95 levels so that both people and models can read it:

connectmq/factory1/production/line1/cnc1/telemetry
connectmq/factory1/production/line1/cnc1/state
connectmq/factory1/production/line1/cnc1/alarms

A typical telemetry payload:

{
  "ts": "2026-10-16T02:41:12Z",
  "spindleTempC": 61.4,
  "coolantFlowLpm": 8.2,
  "spindleLoadPct": 74,
  "partCount": 1532
}

Readable topic names do double duty: they help humans in a topic explorer and they give the model context for free. A model that sees line1/cnc1/alarms does not need to be told what the data is.

A Minimal Shift Collector in Python

The service below subscribes to a whole site, keeps the latest state per machine and counts alarms. At the end of the shift it would hand this structured summary to whichever LLM you use. It uses the public test area of broker.connectmq.com, so keep the data synthetic.

import json
import time
import uuid
from collections import defaultdict

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/genai-7f3a"
latest = {}
alarm_counts = defaultdict(int)


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"{PREFIX}/factory1/production/+/+/#", qos=1)


def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    machine = "/".join(parts[-3:-1])  # e.g. line1/cnc1
    kind = parts[-1]
    try:
        payload = json.loads(msg.payload)
    except json.JSONDecodeError:
        return
    if kind == "alarms":
        alarm_counts[machine] += 1
    else:
        latest.setdefault(machine, {}).update(payload)


def build_summary():
    return {
        "machines": latest,
        "alarmCounts": dict(alarm_counts),
        "generatedAt": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
    }


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"shift-collector-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()

try:
    while True:
        time.sleep(60)
        summary = build_summary()
        print(json.dumps(summary, indent=2))
        # Pass `summary` to your LLM with a prompt such as:
        # "Write a shift report using ONLY these facts. Do not invent numbers."
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Note that the broker does not do any AI work here. ConnectMQ moves the data reliably; the collector and the model are your own services connecting as ordinary MQTT clients. That separation is healthy: you can swap models without touching the machines.

Guardrails That Keep Generative AI Useful

A numbered checklist worth applying to every generative AI manufacturing pilot:

1. Facts in, prose out. Compute all numbers outside the model and tell it to use only the provided values.
2. Cite the source. Ask the model to name the topic, document or ticket each claim comes from, and show that to the user.
3. Read-only first. No command topics in the model's reach until the read-only version has earned trust.
4. Human approval for actions. If the model drafts a work order or a setpoint change, a person approves it. See safe AI control of IoT devices for the command-side patterns.
5. Log prompts and answers. You will need them to debug wrong answers and to improve prompts.
6. Keep sensitive data private. Use a private broker with credentials for real plant data, never a public test area.
7. Measure usefulness. Ask operators whether the summary saved them time; drop use cases that do not.

Choosing Where the Model Runs

Hosted LLM APIs are the fastest way to start and are fine for summaries of non-sensitive data. Plants with strict data policies often run open models locally; an on-premises server running a local model runtime and subscribing to the plant broker can do this without any data leaving the site. Either way the data path is the same: machines publish to the broker, a subscriber builds context, the model writes text, and the result goes back to a topic, a ticket system or an email.

If you are mapping out the wider architecture of models, edge devices and brokers, the AI and IoT guide covers where each type of model belongs.

Getting the Infrastructure Right

The broker becomes a shared dependency once several services read the same plant data, so it should not be a forgotten virtual machine under someone's desk. A managed MQTT broker gives you TLS, credentials and monitoring without operating the server yourself. ConnectMQ also detects ISA-95 and Unified Namespace topics and can republish Sparkplug B data into readable ISA-95 topics, which is exactly the kind of structure that makes plant data easier for both people and models to consume.

For prototyping, the public MQTT test broker at broker.connectmq.com lets you build the collector and prompts with simulated data before anything touches production.

Start Your Plant Data Pipeline on ConnectMQ

Generative AI is only as good as the data you give it. Create a private broker on the free Serverless plan at app.connectmq.com, no credit card needed, connect a gateway or simulator, and watch the topics arrive in the live topic explorer. Once the data is flowing, your first shift report generator is an afternoon of work.

Frequently Asked Questions

What is the best first generative AI project in a factory?

Automated shift or downtime summaries. The data already exists, the output is easy to verify, and a wrong sentence costs little because a person reads it before acting.

Can a language model control machines directly?

It should not, at least not without strict limits and human approval. Start with read-only assistants and add command paths only with validation, allow-lists and confirmation steps.

Does ConnectMQ include AI features?

No. ConnectMQ is the MQTT broker that carries the plant data; your LLM application connects to it as a normal MQTT client, which keeps you free to choose any model.

How do I stop the model from inventing numbers?

Calculate every metric in code, pass the results as structured facts, and instruct the model to use only those values. Reviewing outputs against the source data during the pilot catches remaining issues.