AI applied to industrial IoT: the four patterns that actually work in production (and the ones that promise and don't deliver)

If your operation already captures telemetry and already has dashboards and analytics, the next logical step is to ask: what can AI predict or automate on top of this data? This is where the conversation gets confusing, because the word “AI” in 2026 covers everything from a 200-line isolation forest to an autonomous agent wired to three LLMs.

This post is honest about the four patterns that do deliver ROI in industrial IoT operations — the ones we’ve put in production — and the ones that promise a lot but don’t deliver for this kind of client.

Before AI: have clean data

If you jumped straight here without basic analytics in place, go back. Predictive models over dirty data learn noise instead of signal. Before any serious AI pilot, make sure you have:

• 6+ months of consistent telemetry captured.
• A historical analytics layer where data is already normalized.
• An operations team that can interpret current dashboards.

We cover that foundation in industrial data analytics. If you don’t have it yet, that’s the first project, not this one.

The four patterns that actually work

1. Predictive maintenance over time series

What people believe: that a deep neural network with millions of parameters is needed.

What works in reality: classic anomaly detection (isolation forest, simple autoencoder, even rolling statistics) over vibration, temperature, current or consumption.

The typical case: an HVAC unit, motor or transformer with continuous telemetry. The model learns “normal” behavior over 60-90 days, and from then on flags deviations. It does not predict failures weeks in advance — that’s sold by consultants who never measured it — but it does pull detection 2 to 7 days ahead vs the current method (visual inspection or sudden failure).

Stack: scikit-learn (IsolationForest, OneClassSVM), PyOD for something richer. PyTorch only if you have massive volume and complex patterns.

When NOT to use it: if telemetry arrives every 5 minutes on equipment whose failures develop in seconds (some bearing vibrations), you won’t predict anything. Sampling frequency rules.

2. Computer vision on the CCTV you already have

What people believe: that you need certified industrial cameras and an USD 80k vision project.

What works in reality: the IP cameras you already have + an NVIDIA Jetson Orin (USD 500-1,500) running YOLO fine-tuned for your case. Detect:

• PPE (helmet, vest, glasses) in worksite or plant zones.
• People counting at access points, queues, cafeterias.
• Intrusion in restricted areas after hours.
• Defects on production lines (end of conveyor, before packaging).
• Loading patterns at logistics docks.

Inference runs on the Jetson, not in the cloud. Only relevant events upload (“person without helmet at 14:23 on camera 3, photo attached”). This is critical at sites with limited bandwidth — direct link with multi-Starlink connectivity.

Stack: YOLO (v8 or v11 depending on hardware), OpenCV for pre/post-processing, Jetson Orin Nano or Coral TPU as accelerator, MQTT to push events to the backend.

The hard part: labeling the initial dataset (200-1,000 images per class). You have to invest a real operator’s time, no shortcut.

3. Anti-fraud with isolation forest (real case)

This one we already put in production. In the fleet telemetry case we extended the system with an isolation forest model over historical fueling and consumption patterns. The model learns each vehicle’s normal behavior (expected consumption given route, time, load) and flags deviations for human review.

Measured results:

• Fraud detection scaled to the whole fleet without hard rules.
• False positives cut by around 60% vs the initial fixed thresholds.
• Hourly inference on the backend; no GPU needed.

The same pattern works for fuel anti-fraud at gas stations (reconciliation between customer fueling and actual tank level drop) and for anomalous shrinkage in cold chain.

Stack: scikit-learn, PostgreSQL for features, a Python microservice that runs hourly via cron or Airflow.

When NOT to use it: if you only have 30 days of history, the model won’t learn enough. Wait until you have at least 6 months.

4. LLM + RAG over manuals and runbooks

This is the newest pattern and the one that deserves more skepticism, because it’s where the most is promised and the least is delivered.

What does work:

• Field operational assistant: the tech asks “what is the purge procedure for heat exchanger HX-202?” and gets the answer pulled from the manufacturer’s manual. Without waiting on support.
• Historical log query: “when was the last time cell 4 reported a high-pressure alarm?” and the system answers with citations.
• Incident documentation: the operator describes the symptom, the system suggests the closest runbook.

Stack: an LLM (Claude, GPT, or an open-source model like Llama 3 when on-prem is required) + LangChain or LlamaIndex + vector store (Postgres pgvector is enough to start) over your manuals, logs and internal wikis.

What does NOT work:

• Autonomous agents that execute critical actions without supervision.
• “Chat with the plant” in natural language without prior data modeling work.
• LLMs deciding process control parameters.

The LLM speeds up documentation lookup; it doesn’t replace the process engineer.

Edge vs cloud: when each one

Scenario	Edge wins	Cloud wins
Rural site with limited BW	✅	❌
Inference latency < 100 ms	✅	❌
Massive dataset, monthly retraining	❌	✅
Regulated sector (sensitive data)	✅	depends
Complex model (>1GB, dedicated GPU)	expensive	✅
Many homogeneous sites	hybrid	✅

Practical rule: inference on edge, training in cloud. The Jetson or Coral at the site runs the model; monthly retraining happens in cloud with consolidated data.

And if your site depends on satellite connectivity, edge is not optional — it is the difference between a system that works and one that drops every time it rains. Covered in Multi-Starlink Bonding.

What we DON’T do

A deliberate choice for technical honesty:

• We don’t sell “digital transformation with AI” or 3-year corporate roadmaps. We sell concrete models attached to concrete equipment.
• We don’t build customer-service chatbots. Other agencies do this better than us.
• We don’t build autonomous agents that make critical decisions without a human in the loop.
• We don’t promise “100% accuracy” or “eliminate manual inspections”. We typically cut manual inspections 40-60% per plant, with false positives to manage.
• We don’t use closed models when on-prem is required. In regulated sectors, we offer self-hosted open-source models (Llama, Mistral, etc.).

Real limitations we mention in every proposal

1. Data drift. Models degrade over time as operations change. Retrain every 3-6 months depending on case.
2. Need for human labeling in computer vision. No way around this. Typical cost: 1-2 weeks of operator time for a first usable dataset.
3. Edge GPU cost. A Jetson Orin Nano costs USD 500-1,500 per site; plan capex from day one.
4. Validation time. Before acting on predictions, you need 2-4 weeks of “observer mode” to measure false positives in your real operation.

Checklist before an AI pilot

• Do you have 6+ months of clean data captured?
• What is the specific decision the model will automate or suggest?
• What is the cost of a false positive? And of a false negative?
• Who will validate the first weeks of predictions?
• Do you have supervised labeling available (if computer vision)?
• Do you need on-prem inference or is cloud fine?
• Budget for a 6-10 week pilot
• Who will maintain and retrain the model in production?

If half of these don’t have an answer, it’s not pilot time yet. Start with basic analytics.

What’s next

If you have data captured and a concrete case (not “we want to do something with AI”), write to info@col0.com or via WhatsApp with the idea. In the first meeting we’ll look at whether an AI pilot makes sense now or whether to reinforce analytics first.

More service detail at AI applied to IoT, and if you don’t have the analytics foundation yet, start with Industrial data analytics.