YOUR NETWORK WAS BUILT TO CARRY EMAIL AND WORK ORDERS. AI ON THE PLANT FLOOR ASKS IT TO CARRY PRODUCTION DECISIONS, CONTINUOUSLY, WITHOUT DROPPING ANY OF THEM.
The quality engineer asked for one camera. Just one, mounted above the station where the same defect keeps getting through, running a model that flags bad parts before they reach packaging. The pilot ran for three weeks and caught almost everything. Everybody signed off.
Then it went on a second line, and a third, and the picture started stuttering. Frames dropped during shift change. The model kept scoring, because models always keep scoring, but it was scoring on a feed with holes in it, and nobody could say which rejects it had missed.
Nothing was broken. The switches worked. Email worked. The network was doing exactly what it had been built to do twelve years ago, which was move office traffic around a plant, and it was being asked to do something else entirely.
This is the quiet part of AI in manufacturing. The models are getting easier. The network underneath them is not.
Because it runs constantly, and increasingly it runs inside the production loop rather than alongside it.
Office software is bursty and forgiving. Forty people check email, open a few files, and sit idle most of the day. If something takes three seconds instead of one, nobody files a ticket. The network has slack in it by design, and that slack has covered a lot of sins in a lot of plants for a lot of years.
A vision system does not get bored. It produces the same load at 2 p.m. on Tuesday and 2 a.m. on Sunday. Two hundred sensors reporting every few seconds do not pause for lunch. And when the output feeds a decision rather than a dashboard, late data and no data start to look the same to the system consuming it.
That is the shift. The network stops being the thing people complain about when it is slow, and becomes a thing production depends on.
More than most plants planned for, though the volume matters less than the shape of it.
Average utilization is a misleading number here. A plant network can sit at fifteen percent all day and still fail a vision system, because what breaks the model is not the ceiling, it is the floor. The moment the feed thins out, during a shift change, when a forklift crosses the aisle and clips the wireless path, when somebody runs a backup at the wrong hour, the data stops being continuous. Continuous is the whole requirement.
The practical version: before anyone buys a camera, somebody should be able to say what the network looks like at its worst minute of the week, not its average hour. Most plants cannot answer that, and the answer is usually available within a few days of actually watching.
No, and for anything that touches the production line, it usually should not.
If the decision has to happen before the part leaves the station, a round trip to a cloud region and back is both too slow and too fragile. It puts a single internet circuit between your line and its ability to reject a bad part. Plenty of plants have one circuit. Some have a second that nobody has tested failover on since it was installed.
So the compute moves closer to the floor. That is a reasonable answer, and it is also a network problem wearing a different hat. Edge hardware needs somewhere to live, clean power, a switch port that is not a fifteen-year-old unmanaged box under a desk, and a path back to the systems that do the training and reporting. The work does not disappear when you move it local. It just becomes yours.
Cloud still makes sense for training, long-term storage, and anything that can wait a few seconds. The useful question is not cloud or edge. It is which decisions have a deadline measured in milliseconds, and which do not.
Wireless, almost every time.
Coverage in most plants was surveyed, if it was surveyed at all, for a person holding a tablet in a walkway. Sensors on moving equipment in a building full of steel racking, metal-clad walls, and forklifts passing through the signal path are a different problem. The access point that gives a human two bars gives a sensor an intermittent connection, and intermittent is worse than absent, because absent gets noticed.
After wireless, in rough order:
Switches nobody has an inventory of. Unmanaged gear accumulates in plants. It gets added during an expansion, works fine, and disappears from institutional memory. You cannot monitor what you do not know about, and you cannot troubleshoot a data gap through a device with no management interface.
A single uplink with no tested failover. Fine when the consequence is slow email. Not fine when the consequence is a line that cannot make a quality decision.
Nobody watching whether the data arrived. This is the one that costs the most and shows up the latest. Plenty of plants monitor whether devices are up. Far fewer monitor whether the stream is complete.
Because a model learns from what reaches it, and it has no way to tell the difference between a condition that did not happen and a condition it never received.
A slow dashboard is an annoyance. A feed with holes in it produces a model that is confident about a plant it has only partly seen. Worse, the gaps are rarely random. They cluster around shift change, around the busy hours, around the moments when the floor is doing the most interesting things. Which means the periods your model understands least well are often the ones you most wanted it to help with.
This is the part that does not show up in a pilot. A three-week trial on one line, on a quiet segment, with somebody watching it daily, will look fine. Scale is where the network gets tested, and by then the project has a budget and a champion and a hard time going back to first principles.
With designed, controlled paths rather than either a flat network or an air gap. This is the hardest design decision in the room and the one most likely to get skipped when a project is behind.
The tension is real and worth naming. Good security practice says separate the shop floor from the front office, so a problem in accounting cannot reach the production line. AI projects need OT data to get to where the analytics run, which usually means somewhere on the IT side or beyond it. Those two instincts pull in opposite directions, and the answer is not to pick one.
What works is segmentation with specific, documented routes for the data that has to move, and nothing else. One direction where possible. Monitored. Written down, so that the person who inherits this in four years knows why the rule exists. It takes longer than flattening the network, and it is far more useful than an air gap that somebody has already quietly bridged with a USB stick and a laptop.
If your plan involves getting the data out and the plan for keeping everything else in has not been written yet, that is the gap, and it is better found now.
Usually it looks like a network somebody has been paying attention to for a while, for reasons that had nothing to do with AI.
All-State Industries makes custom nonmetallic components for OEMs in agriculture, construction, mining, utility, marine, and infrastructure markets, out of five North American locations. We have worked with them for 34 years. Every network component across those sites runs on Cisco Meraki and is managed by us: firewalls, switches, access points, cameras, and environmental sensors, visible from a single dashboard.
The sensors were not an AI project. After a severe winter where snow got into a makeup air unit, the pilot light went out, pipes froze, and the sprinkler system was compromised, we put Meraki sensors near every water riser and across the production floor. The point was to see the plant.
But look at what that leaves them holding. A managed, monitored, single-pane network across every location. Sensor data already flowing. Cameras already on the network. Somebody who knows what normal looks like, which is the only way to spot abnormal. If All-State decides to put a model on top of any of that, the foundation is not a project. It already exists.
That is the real lesson, and it is a slightly annoying one. The plants that will do well with AI are not the ones buying AI. They are the ones who fixed the network for ordinary reasons, years earlier, and now get to skip the part everyone else is stuck on.
You do not need an AI strategy to do the useful work here. You need to know what your network actually is, which most plants do not, because the documentation stopped being accurate around the second expansion.
Iowa manufacturers: IIoT infrastructure hardware is named on the Iowa Economic Development Authority's list of technology eligible for the Manufacturing 4.0 Technology Investment Program, and the application window is open for 2027. If a network project has been sitting on your list waiting for a budget year, it is worth checking whether you qualify.
And if the question at your plant is still a step earlier, whether this particular AI project is worth doing at all, that is a different conversation and a fair one to have first. Working out which use cases actually pay back, and what the rules are going to be for how your team uses these tools, is the kind of thing our AI Advisory Services exist for.
Nobody gets excited about switches. We understand. But we have spent 45 years in Iowa plants watching good projects stall on infrastructure nobody wanted to look at, and the pattern has not changed just because the project on top is now a model instead of an ERP module. If somebody has handed you an AI project and you are not sure what it is going to ask of your network, that is a good conversation to have before the hardware shows up. We are happy to tell you it is fine, if it is.