Edge AI: Processing Data Near Where It Is Produced
Edge AI places model inference near the sensors, machines or users producing data, using endpoints, local gateways, on-premises servers or network-edge infrastructure.
Timeline
- 2014: ETSI launched its industry work on what became Multi-access Edge Computing.
- 2021-07-13: AWS published a reference architecture for machine-learning inference on cameras and other connected-home edge devices.
- 2026-06: ETSI published updated Phase 4 terminology and edge-computing resource reports.
- 2026-10-12: Current ETSI and AWS edge-computing documentation was reviewed for this guide.
Edge AI runs machine-learning inference close to the place where data is produced or an action is needed. The “edge” can be the sensor or camera itself, a nearby industrial gateway, a server inside a store or factory, or computing infrastructure within an access network. This makes edge AI an architectural category broader than on-device AI. A phone model that works entirely locally is one edge case; a group of cameras sending video to a building gateway for analysis is another, even though inference is not running inside each camera. [1][2]
Proximity is valuable when delay matters. A factory safety system, vehicle, drone, augmented-reality service or video-analytics pipeline may need a response before a distant cloud round trip is dependable. ETSI describes multi-access edge computing as cloud-style computing at the network edge with low latency, high bandwidth and access to network information, and lists IoT, vehicles, drones, gaming and video analytics among its uses. Real latency still includes sensing, preprocessing, inference, networking and actuation, so an edge label alone does not guarantee a deadline. [1]
A common architecture divides work across tiers. Endpoints collect signals; an edge runtime filters, aggregates or formats them; a local model produces a prediction; and software turns that result into an alert or action. Selected events, metrics or samples may then flow to a central service for monitoring, storage and model improvement. AWS Greengrass documentation describes devices acting locally on generated data, running predictions and exporting chosen IoT data to the cloud. The design can reduce raw-data transfers without eliminating cloud coordination. [2][4]
Edge AI can lower bandwidth use by sending conclusions or exceptions instead of continuous high-volume streams. A camera might upload an alarm and a short clip rather than every frame, while a machine monitor might report anomalies instead of all vibration readings. Local processing can also preserve essential behavior during intermittent connectivity. These advantages depend on the fallback design: an edge node may keep inference running offline yet still lose fleet dashboards, remote commands, updated models or cross-site context until communication returns. [2][4]
The deployed system contains more than a model file. It needs a compatible runtime, preprocessing and post-processing code, dependencies, configuration and a secure way to deliver versions. AWS documents separate model, runtime and inference components for edge machine learning, along with dependencies on supported operating systems and runtime releases. Hardware fleets are heterogeneous, so operators must test processor instructions, accelerators, memory, storage, temperature, power supply and sensor formats on actual devices rather than assume that a cloud-tested model will behave identically everywhere. [3][4]
Fleet management is the operational challenge that distinguishes many edge deployments from a single offline device. Teams need inventories, device identities, signed software, staged rollouts, health checks, rollback, log collection and plans for nodes that miss an update. They must track both application and model versions because a changed preprocessor can alter predictions even when weights stay constant. AWS’s edge tooling illustrates this split by deploying inference agents and collecting model metrics or selected sample data, which also shows why edge processing can still generate cloud traffic. [3][5]
Security and privacy require an end-to-end review. Processing locally can keep raw video, audio or industrial measurements within a site, but gateways can be physically exposed, credentials can be stolen and remote-management channels can be attacked. Local logs and model inputs may also contain personal or commercially sensitive data. Use least-privilege identities, encrypted communication, verified boot or trusted hardware where available, signed updates, network segmentation and retention limits. Document exactly which telemetry and samples leave each node instead of equating “edge” with “private.” [2][4][5]
A good edge-AI evaluation measures the complete service under realistic conditions: end-to-end response time and jitter, prediction quality, bandwidth saved, energy use, storage pressure, temperature, recovery after disconnection and the success rate of fleet updates. It should test sensor drift, damaged inputs, clock errors and safe behavior when the model or network fails. Edge AI can make systems faster and more resilient by placing computation near events, while central services remain useful for training, coordination and oversight. The placement decision should follow measured requirements rather than the appeal of the label. [1][2][3][4]
Sources
- ETSI — Multi-access Edge Computing
- AWS Documentation — What Is AWS IoT Greengrass?
- AWS Documentation — Machine Learning Components for IoT Greengrass
- AWS Documentation — IoT Greengrass V2 Tutorials
- AWS Documentation — The SageMaker AI Edge Manager Agent