Edge AI processes camera data near the place where it is captured. Cloud processing sends data to a remote service for analysis. A hybrid system can combine local event detection with central reporting. The right arrangement depends on the operational decision, the network and the evidence the team needs to retain.
Start by naming the time-sensitive action. A factory reject signal has different requirements from a daily retail footfall report. Placing all processing in one location because it appears simpler can create unnecessary latency, bandwidth or support problems.
Examine the complete path
For a hypothetical warehouse doorway, the path includes image capture, decoding, detection, tracking, event rules, delivery and a dashboard. A model inference benchmark measures only one part. The business needs to know when a useful event becomes available and what happens when a component stops.
If a local rule must continue during an internet outage, cloud-only inference cannot provide that behaviour by itself. If the team only needs overnight analysis, the additional cost of always-on edge devices may be hard to justify.
Compare operating trade-offs
| Concern | Edge consideration | Cloud consideration |
|---|---|---|
| Connectivity | Can operate locally if designed for it | Depends on the remote path |
| Capacity | Limited by deployed device and thermal conditions | Capacity can be managed centrally |
| Maintenance | Devices need updates and physical support | Central services need deployment and cost control |
| Data movement | Can send events instead of full streams | Requires a defined upload and retention path |
| Failure recovery | Local buffer and device health matter | Queue, retries and regional service health matter |
None of these properties is automatic. An edge device that loses its configuration after reboot is not resilient merely because it sits inside the building.
Verify the target hardware
Model runtimes expose different execution providers for supported hardware. Compatibility and performance must be tested on the intended device, model and input shape. A laptop demonstration does not validate the production edge box.
Measure several cameras together, not one isolated frame. Include decoding overhead, event rules, storage and sustained temperature. Decide whether the system drops frames, lowers resolution or falls back to manual operation under load.
Preserve useful evidence
An event-only architecture reduces data transfer, but the event may still need a reviewable snapshot or short clip. Define what is retained locally, what leaves the site and which roles can access it. Avoid treating location alone as a privacy guarantee.
Calibration and camera placement also need operational ownership. A camera moved during maintenance can invalidate spatial rules even when the model continues running. Detect or document those changes before relying on the result.
Plan updates and outages
Use a versioned configuration and a rollback route for model or rule updates. Record which version generated an event so later reviews remain understandable. A failed update should not leave the device in an unknown state.
For offline buffering, define the maximum duration, storage limit and delivery order. When connectivity returns, repeated delivery must not create duplicate alerts. Show whether an event is live or delayed so staff interpret it appropriately.
Make the architecture decision reviewable
Ask a supplier to demonstrate the full path on representative hardware and a deliberately interrupted network. Compare event latency, missed events, recovery and support effort. The most useful design is the one whose measured behaviour matches the workflow, not the one with the most fashionable placement of compute.
Primary references
Related reading
Explore our computer vision if you need help turning these choices into a reviewable project brief.
