Edge AI for decisions close to the work
Edge AI places inference near a camera, sensor or machine when latency, connectivity or data handling makes a remote round trip a poor fit. It still needs an explicit update, monitoring, recovery and ownership plan.
Start with the constraint, not the device
Edge is a placement decision. Use these questions to decide whether it belongs in the architecture alongside local, cloud or hybrid components.
What Edge AI means
Inference runs close to the source of the event, reducing the dependency on a network round trip for that decision.
Good fit
Time-sensitive inspection, intermittent connectivity, high-volume sensor streams or payloads that should stay near the site.
Not a default
A central workflow, complex data joins or a model too large for the device may favour local, cloud or a hybrid split.
Evidence first
Latency and throughput only mean something with resolution, preprocessing, stream count, model and hardware recorded.
Evidence status and review date stay attached to every claim.
Edge decision matrix — compare the whole operating boundary
No option wins every row. Compare the proposed Edge path with on-premise, cloud and hybrid alternatives against the workload and team that will operate it.
| Constraint | Edge implication | Alternative to compare | Decision question |
|---|---|---|---|
| Latency | Fast local response is possible | Cloud for central compute; Local for larger models | What is the measured budget at the required stream count? |
| Privacy | Payload can stay at the source | Hybrid for approved integrations | Which telemetry, update or support fields can leave? |
| Connectivity | Inference can tolerate an outage | Cloud when reliable central access is acceptable | What continues offline and how does recovery reconcile state? |
| Cost | Device, power and replacement are explicit | Cloud usage or Local hardware pool | Who owns the five-year TCO and upgrade path? |
| Operations | Many devices need inventory and rollout control | Central service may reduce fleet work | Who monitors, patches, backs up and rolls back each site? |
Reference architecture and boundary
A reference flow is a starting model, not a claim about every site. Mark where payload, telemetry, updates and approved support can cross the boundary.
- 01
Camera, light and sensor
Capture a representative stream with lens, lighting, sensor, PLC and environmental assumptions recorded.
- 02
Edge inference
Preprocess and run the selected model close to the source; document resolution, stream count and fallback.
- 03
Human approval and action
Route uncertain results to an operator, then an ERP/MES/workflow decision with an auditable event.
- 04
Telemetry and update path
Send only approved health fields; install signed package/model updates through a connected or offline route.
- 05
Recovery and improvement
Keep a version inventory, rollback trigger, backup owner and evaluation loop for each device fleet.
Evidence cards — status is part of the claim
The examples below are evidence structures, not performance promises. A number belongs only after its workload and review record are attached.
Internal test
Measure latency, FPS, thermals and power on a named device with resolution, preprocessing and model version.
Status: proposed · review date required
Customer pilot
Run a thin slice at the pilot site with an operator, acceptance metric and stop condition agreed in advance.
Status: tested · customer evidence required
Supported operation
Only list a device fleet as supported when patch, monitoring, replacement, backup and rollback ownership are documented.
Status: supported · scope and owner required
Device sizing and ownership assumptions
Sizing is a workload and operations decision. These assumptions belong in the assessment rather than an unverified device promise.
Compute and model
Record model, precision, preprocessing, stream count, memory headroom and measured workload.
Thermal and power
Plan enclosure, ambient temperature, duty cycle, power budget and thermal throttling behaviour.
Storage and retention
Separate payload retention from logs, model packages, evidence and recovery artefacts.
Network recovery
Define offline behaviour, queue limits, reconciliation and what happens when update or telemetry is unavailable.
Fleet operations
Name the owner for inventory, patch windows, spare devices, backup, rollback and end-of-life replacement.
Where Edge AI may be the wrong fit
- A model or retrieval workload that exceeds the device memory, thermal or power envelope
- A process that needs central joins, frequent model changes or a reliable shared data service
- An untested camera, lighting, sensor, PLC, resolution or stream-count combination
- A site without an owner for patching, monitoring, backup, rollback and spare hardware
- A requirement that assumes offline inference also covers offline updates, telemetry and support
- Latency or FPS numbers without the workload, model, hardware and review date that produced them
Edge AI questions buyers ask
Does Edge mean the system never needs a network?
No. Inference may continue during an outage, while updates, telemetry, support or workflow integration still need an approved path and recovery plan.
Is Edge cheaper than cloud?
It changes the cost shape: device, power, maintenance and replacement become explicit. Compare the workload and operating team rather than assuming a saving.
Can any camera or PLC work?
Compatibility is assessed with the actual interface, lighting, timing and data format. An example device is not proof for another site.
Who owns model updates and rollback?
The delivery inventory names the customer and service responsibilities, approval window, version evidence and rollback trigger.
What does the feasibility assessment return?
A bounded latency, connectivity and device-readiness view with assumptions, test plan and a recommendation that can also be no-go.