Put IoT devices and AI services on deliberate networks

Here's the rule: every IoT device gets its own VLAN, and the AI controller gets a short, named list of flows to reach exactly what it needs, nothing else. That's it. What follows is the argument for why.

It matters even off a cloud network: a compromised camera or a cheap smart plug is still a foothold inside the house, whether or not any of that traffic ever reaches a cloud provider. The typical setup is an SBC controller, a few cameras, a speaker, some sensors, and an inference server, all sitting on one flat network where everything can already see everything, and that default is the real vulnerability, not whichever model you picked to run.

Name the job before you touch a breadboard

Write the event, the input, the output, and the deadline in four lines before you order anything. "Add AI to the camera" is not a job. "When a parcel sits in the porch zone for twenty seconds, send one local notification with a thumbnail" is testable, and writing it that specifically usually shows which parts don't need a model at all.

The VLANs, the firewall flows, the DNS, the update path, and a recovery procedure you can actually follow belong in that first experiment, not bolted on once the model already works. A minimal version of the controller-to-camera rule:

# controller (vlan 10) -> camera (vlan 20), one port, no return path
allow  vlan10  vlan20  tcp/8554
deny   vlan10  vlan20  any
deny   vlan20  vlan10  any

Test against data from the actual room: the real camera angle, the real microphone, the real network. Edge deployments amplify ordinary variation in a way a lab bench hides; evening light, a warm cabinet, a slow home-automation database can move your result more than swapping model versions will.

Keep a short field record: board, OS, power, cooling; model and runtime version; real input set and expected action; cold and warm latency; memory, temperature, wall power; false action, missed action, and how you recover from either.

Accuracy alone isn't the finish line for something people now depend on. Check whether it double-fires, survives a reboot, reconnects once the network returns, and fails safely when the inference server isn't there. Give it visible state and a manual override; nobody in the kitchen should need to know which container crashed to turn on a light.

The model doesn't get to hold the deadbolt (networksecurity)

The failure I see most is isolating everything so hard that the one path the controller genuinely needs becomes a blanket exception, wide open because narrowing it properly felt like too much router work. It's the same trap as sandboxing a coding agent: wall it off too tightly, and the hatch you eventually punch through ends up wider than if you'd scoped it honestly from the start.

Generative output is fine at interpreting a request, summarizing history, ranking options. It should not be the only thing standing between a bad output and a lock, a heater, an alarm, a valve, or a person in the room. Ranges, permissions, timeouts, and interlocks belong in deterministic code, not in whatever the model felt like saying. Camera text, calendar entries, scraped webpages, MQTT payloads, voice transcripts: treat all of it as untrusted data, not instructions, which is exactly where guardrails and output validation stop being optional.

Local inference just moves where the copies end up

Running the model on your own hardware kills exactly one upload. It does nothing to the recordings, the event logs, the thumbnails, or the backups, and any one of those can quietly hold a copy of something you assumed stayed local.

Decide, on paper, what actually gets collected, how long it sits around, and who can pull it up. The most private frame is the one the camera never takes. The next best is the one thrown away the moment a bounded decision gets made from it.

It has to survive you forgetting it exists

Run it under a real service manager or a small, pinned container, not a screen session somebody forgot was open. Keep configuration separate from the model files you'll swap out later, and write a health check that proves the thing does its job, not just that some process is squatting on a port. Back up the controller state, record the model hashes running, and keep a known-good image for any node you don't want to visit twice.

Power and heat belong in the acceptance test, not a footnote. Run it until the enclosure reaches equilibrium and measure at the wall with the real peripherals plugged in. If it throttles, swaps, corrupts storage, or hogs the box your home automation also depends on, it isn't ready, no matter how good the last inference result looked.

Named flows, tested from every zone: that's the whole point restated. When the model goes away, the automation underneath it should get dumber, not stop. The win was never proving a cheap board can run a model; it was one small capability that still works once the benchmark window closes and the device goes quiet in a cupboard.

None of this is worth doing for a single smart bulb and a camera app you already trust. VLANs are real router configuration with real failure modes of their own, and a fat-fingered rule can lock you out of your own porch light as fast as a compromised device could have gotten in. If your whole setup is one Home Assistant box and nothing touching a physical lock, a flat network and a decent password is the honest answer, and everything above is weight you'd be carrying for a threat you don't have yet.