Edge AI for real-time analytics runs trained AI models on devices near data sources, so systems decide locally within strict latency budgets. Cameras, sensors, machines, vehicles generate data continuously throughout normal operations. Sending every stream to a distant data centre adds network delay before any analysis begins. Local inference removes most network travel from the decision path entirely. Operators gain answers during the event itself, rather than minutes after the event ends.
Readers familiar with basic machine learning already know the prediction loop behind inference at the edge. Edge deployment changes where the trained model runs, while the model itself stays familiar. Deployment location changes latency, bandwidth demand, privacy exposure, operational risk. Understanding those trade-offs helps teams choose between edge, cloud, hybrid designs.
What Is Edge AI for Real-Time Analytics?
Edge AI for real-time analytics means running AI inference at or near the point where data gets created. A camera, gateway, machine controller, vehicle computer can host the model directly. Raw data enters the model locally, while only results, alerts, summaries travel onward. Cloud platforms still train models, store history, coordinate fleets across many sites.
Edge analytics applies the same placement idea to measurement, filtering, aggregation tasks. A vibration sensor can report a fault score instead of a raw waveform. A traffic camera can report vehicle counts instead of full video streams. Local analysis reduces backhaul volume because extracted information is far smaller than raw data. Researchers at Carnegie Mellon University described exactly that bandwidth mechanism in a 2017 paper on edge computing.
Standards bodies describe edge computing without using marketing language at all. The National Institute of Standards and Technology defined fog computing in NIST SP 500-325, published on 14 March 2018. Fog computing moves applications, management, analytics into the network itself, close to connected devices. The International Organization for Standardization describes edge computing as processing, storage placed near places where systems meet the physical world. Precise definitions matter during procurement, because vendors use edge labels very loosely.
Secondary terms help separate nearby concepts before design work begins in earnest. Edge computing is the broader placement model for compute, storage, networking near data sources. Edge AI is the narrower practice of running AI models within that placement model. Cloud AI runs models inside centralised data centres, reached over wide area networks. Real-time analytics is the workload goal, namely analysis fast enough to influence an ongoing process.
How Does Edge AI Work?
A working edge pipeline follows a repeatable sequence from sensing to action at the site. Each stage below names the component responsible for that stage of processing.

- Sensors, cameras, machines capture raw data at the point of operation continuously.
- A local gateway or device filters noise, checks quality, prepares model inputs.
- The trained model runs inference on the device or a nearby edge server.
- A rules layer converts model outputs into alerts, scores, control signals immediately.
- Site systems act on the output, for example stopping a line or flagging a transaction.
- Selected results, metadata move to cloud platforms for storage, reporting, retraining.
- Updated models travel back to devices through a controlled release process later.
Reference architecture becomes clearer when each layer carries one named responsibility for the pipeline.

| Layer | Component | Responsibility |
|---|---|---|
| Sense | Sensors, cameras | Capture raw events |
| Process | Edge device, gateway | Filter data, run inference |
| Decide | Rules engine, local application | Trigger alerts, control actions |
| Coordinate | Edge platform, orchestrator | Deploy models, monitor devices |
| Learn | Cloud platform | Train models, store history |
Streaming design decides whether the pipeline keeps up during peak load periods at busy sites. Ingestion layers need event ordering, buffering, backpressure handling for streams with sub-second targets throughout. Buffering protects the pipeline when a device produces data faster than inference can run. Time synchronisation keeps events from different sensors in a correct, comparable order. Model compression reduces model size through quantisation, pruning, compilation for target hardware. Smaller models run faster on limited hardware, although compression can reduce accuracy slightly.
Edge AI vs Cloud AI
Placement shapes every major property of an analytics system, from latency to failure behaviour. The comparison below summarises the practical differences teams evaluate during architecture reviews.

| Factor | Edge AI | Cloud AI | Hybrid Design |
|---|---|---|---|
| Processing location | Device or site server | Central data centre | Split by workload |
| Latency profile | Lowest, no wide area trip | Higher, network dependent | Tuned per task |
| Bandwidth demand | Low, results only | High, raw streams | Moderate |
| Internet dependence | Works while disconnected | Stops without connectivity | Core tasks continue |
| Compute capacity | Limited by local hardware | Very large | Large for training |
| Model training | Rarely on device | Central, at scale | Central, at scale |
| Privacy exposure | Data stays on site | Data leaves the site | Sensitive data local |
| Best fit | Urgent local decisions | Training, global reporting | Most production fleets |
Latency claims deserve careful reading, because headline figures often hide narrow test conditions. Researchers cited by Carnegie Mellon University measured an average round-trip time of 74 milliseconds to optimal cloud instances in 2017. Measurements came from 260 global vantage points, before any wireless first hop was added. Modern networks perform differently, while the distance penalty behind the figure remains physical. Light travel time alone forces compute within roughly 300 kilometres for a one-millisecond propagation budget.
Marketing around 5G creates a second common misunderstanding about latency figures in practice. The International Telecommunication Union set a one-millisecond user-plane requirement for ultra-reliable low-latency communication in Report ITU-R M.2410-0. A four-millisecond requirement applies to enhanced mobile broadband under the same 2017 report. Both figures cover the radio network only, under unloaded conditions, using small packets. Transport networks, servers, model inference sit outside those radio figures completely. Buyers should therefore ask vendors which latency segment any quoted figure actually covers.
What Latency Does an Application Actually Need?
A latency budget gives a team a concrete placement rule instead of a vague speed claim. The thresholds below come from published research targets for specific application classes.

| Application class | Latency target | Source basis | Placement implication |
|---|---|---|---|
| Demanding interactive systems | Under 10 milliseconds | Research target, 2015 | Edge placement required |
| Head-tracked virtual reality | Under 16 milliseconds | Perceptual stability target, 2017 | Edge placement required |
| Cognitive assistance | A few tens of milliseconds | Research goal, 2017 | Edge or near edge |
| General interactive tools | 60 to 70 milliseconds | Acceptable range, 2015 | Near edge or cloud |
| Reporting, trend analysis | Seconds to minutes | No urgency in process | Cloud placement suitable |
Head-tracked virtual reality needs latency under 16 milliseconds for perceptual stability, according to Carnegie Mellon University research. Cognitive assistance applications were given a goal of a few tens of milliseconds in the same research programme. Less demanding interactive applications were described as acceptable at 60 to 70 milliseconds. Workloads above those ranges rarely justify edge hardware on latency grounds alone. Teams should measure the full path, sensor to action, before committing capital spending.
Standards That Define Edge Computing
Several standards describe different layers of edge architecture, from fog models to telecom frameworks. The table below maps each document to the layer a deployment team actually uses.
| Document | Publisher | Date | Layer covered |
|---|---|---|---|
| NIST SP 500-325 | National Institute of Standards and Technology | March 2018 | Fog concepts for IoT |
| ISO/IEC TR 23188:2020 | International Organization for Standardization | February 2020 | Edge concepts, cloud relation |
| ISO/IEC TR 30164:2020 | International Organization for Standardization | April 2020 | IoT edge concepts, security |
| IEEE Std 1934-2018 | Institute of Electrical and Electronics Engineers | August 2018 | Fog reference architecture |
| ETSI GS MEC 003 | European Telecommunications Standards Institute | May 2025, version 4.1.1 | Telecom edge framework |
Telecom edge deployments follow the framework published by the European Telecommunications Standards Institute in ETSI GS MEC 003. The framework names a MEC orchestrator, MEC hosts, a MEC platform, MEC applications as separate elements. Clear component names help teams assign ownership for deployment, monitoring, failure response. Fog architecture follows IEEE Std 1934-2018, which adopted the OpenFog Reference Architecture in 2018. Architecture documents give procurement teams shared vocabulary for tenders, acceptance tests, support contracts.
Benefits of Edge AI
Local inference produces measurable operational benefits when workloads genuinely need fast local decisions. Benefits below assume suitable hardware, a maintained model, a monitored deployment process throughout.
Lower Latency for Local Decisions
Removing the wide area network from the decision path cuts response time sharply. Safety systems, control loops, fraud checks depend on responses inside tight time windows. A sub-250ms inference latency budget shows how teams allocate milliseconds across pipeline stages carefully. Latency budgets expose slow stages before production traffic exposes them in public operation.
Lower Bandwidth Costs
Local filtering sends results instead of raw streams across expensive network links at scale. Video, vibration, telemetry streams are large, while extracted events are comparatively tiny records. Lower backhaul volume reduces network load on sites with limited connectivity options available. Savings depend on stream size, retention rules, the share of data filtered locally.
Stronger Privacy Through Data Minimisation
Keeping raw data on site reduces how much personal data leaves a controlled location. Privacy law rewards minimisation directly, although local processing alone never creates compliance by itself. The European Union set the data minimisation principle in Article 5(1)(c) of Regulation (EU) 2016/679. Article 25 of the same regulation requires data protection by design, by default. Edge filtering can support both duties by limiting amount, extent, storage period, accessibility.
Healthcare deployments face a parallel minimisation duty under United States federal rules for health information. The U.S. Department of Health and Human Services explains the HIPAA minimum necessary standard in 45 CFR 164.502(b). Covered entities must limit protected health information to the minimum necessary for a purpose. Local inference sending an alert instead of a continuous raw stream can support that policy. Disclosures for treatment are an exception, so clinical workflows need individual legal review.
Reliability During Network Failure
Disconnected operation keeps local decisions running during internet outages, storms, network maintenance windows. Factories, farms, remote sites often lose connectivity for hours without losing production value locally. Local buffering stores events during an outage, while synchronisation runs after connectivity returns again. Reliability planning must still cover power loss, hardware failure, corrupted local storage scenarios.
Business teams usually connect these benefits to live forecasting, alerting, operational decision systems. Organisations exploring that commercial layer often review predictive analytics services alongside the underlying edge architecture work.
Edge AI Use Cases for Real-Time Analytics
Production use cases share one pattern, namely value created inside a short decision window. Examples below describe the workload, the local decision, the result sent onward clearly.
Manufacturing and Predictive Maintenance
Vibration, temperature, sound sensors watch motors, pumps, presses for early signs of failure. Local models score each reading, while maintenance teams receive alerts before breakdowns stop production. Consider a bottling plant running twelve filling lines across two shifts every production day. Gateway devices beside each line score vibration readings every second, flagging abnormal patterns for technicians. Technicians inspect flagged machines during planned pauses, rather than waiting for failures during full production. Only scores, timestamps, machine identifiers leave the plant, keeping raw vibration streams on local storage systems. Factories also run camera inspection at line speed, rejecting defective items during production runs. Guidance on edge and on-premise inference in manufacturing covers offline deployment on factory hardware in more detail.

Healthcare and Remote Monitoring
Wearable devices, bedside monitors produce continuous signals that need fast local interpretation every second. Local inference can flag dangerous patterns, while clinicians receive a summary instead of raw signals. Hospitals gain faster alerts during network congestion, because interpretation happens beside the patient locally. Clinical accuracy claims require regulated validation, so healthcare examples here stay deliberately general in scope.
Retail Operations
Store cameras can count footfall, detect empty shelves, flag queue growth without sending video onward. Managers act during the trading day, rather than reviewing reports on the following morning shift. Loss prevention systems can flag suspicious movement patterns for staff review within the store. Faces, identities raise separate legal duties, so many retailers process counts without identifying individuals.
Smart Cities and Transport
Traffic systems adjust signal timing from live vehicle counts measured at the junction itself. Vehicle systems detect obstacles locally, because steering, braking decisions cannot wait for network travel. Fleet operators use local alerts for harsh braking, idling, route deviation during each journey. City deployments must publish clear data policies, because public cameras affect people beyond customers.

Energy, Utilities, and Agriculture
Substation monitors detect fault signatures locally, while protection actions occur within very short windows. Cooling systems in data centres adjust airflow from local temperature readings throughout each facility hall. Farm systems trigger irrigation, pest alerts, livestock checks from sensor readings in remote fields. Remote locations benefit strongly, because connectivity there is often slow, intermittent, expensive per megabyte.
Hardware Classes for Edge Inference
Hardware choice follows model size, latency target, power supply, the physical environment at the site. The table below compares hardware classes without naming commercial products or vendor product lines.
| Hardware class | Typical role | Strength | Main limit |
|---|---|---|---|
| Microcontroller with AI acceleration | Single sensor inference | Very low power draw | Tiny models only |
| Single-board computer | Prototypes, light analytics | Low cost, flexible | Limited durability |
| Industrial gateway | Multi-sensor aggregation | Rugged, many interfaces | Moderate compute |
| Edge server with graphics acceleration | Video, multi-model workloads | High inference throughput | Power, cooling needs |
| Telecom edge host | Network-side applications | Operator managed platform | Less site control |
Environmental ratings matter as much as processor speed on factory floors, outdoor installations alike. Heat, dust, vibration, moisture destroy office-grade hardware in industrial settings within short operating periods. Power budgets matter on battery devices, solar sites, vehicles with limited electrical capacity available. Teams should test the exact model on the exact hardware before fleet purchasing decisions begin. Benchmarks from a different model, resolution, batch size rarely predict production performance with useful accuracy.
Tools and Platforms Used for Edge AI
Buyers comparing options usually meet the following names during hardware, software shortlisting for pilots.
| Name | Type | Typical role |
|---|---|---|
| NVIDIA Jetson | Edge hardware platform | Modules for vision, robotics workloads at sites |
| Google Coral | Edge TPU hardware | Low-power inference for cameras, sensors |
| Hailo-8 | AI accelerator | Vision inference inside cameras, gateways |
| TensorFlow Lite | Model runtime | Runs converted models on embedded devices |
| ONNX Runtime | Model runtime | Runs models across varied hardware targets |
| OpenVINO | Optimisation toolkit | Optimises models for Intel hardware targets |
| AWS IoT Greengrass | Edge runtime service | Local compute, messaging, sync on devices |
| Azure IoT Edge | Edge runtime service | Deploys cloud workloads to edge devices |
| EdgeX Foundry | Open edge framework | Connects devices, services through open interfaces |
Federated Learning and Small Models at the Edge
Federated learning trains models across many devices without moving raw data to one central server. Each device trains locally on local data, sharing only model updates with a coordinating server. Coordinators combine updates from many devices into an improved global model for later redistribution. Healthcare, keyboard prediction, multi-site factories suit federated patterns, because raw records stay at source sites. TinyML covers the opposite end, running very small models on low-power microcontrollers with tight memory limits. Small language models now bring summarisation, classification, voice interfaces to gateways, vehicles, offline field devices. Generative AI features at the edge usually rely on such small models, distilled from larger systems. Small models answer locally during outages, while larger cloud models still handle complex reasoning tasks centrally.

Challenges of Edge AI Deployment
Edge deployment moves complexity from one data centre to many distributed sites in the field. Challenges below appear in most fleets, regardless of industry, hardware class, model type chosen.
Limited Compute and Power
Devices at the edge offer far less compute, memory, storage than cloud servers provide daily. Large models may not fit, or may run too slowly for the latency budget set. Compression helps, while accuracy testing must follow every compression step before release approval proceeds. Thermal limits can throttle processors during heat waves, heavy workloads, poorly ventilated enclosures at sites.
Model Updates and Drift
Production data changes over time, while a deployed model keeps using older patterns learned earlier. Drift detection requires local metrics, because raw data often never reaches central systems for review. Update delivery must handle offline devices, failed installs, rollback after a bad release reaches sites. Teams usually manage that lifecycle through MLOps services for deployed models with staged release rings.
Security Across Many Sites
Each device is a physical object in a location outside a guarded data centre hall. Secure boot, signed updates, encrypted storage, unique device credentials form the baseline control set for fleets. Compromised devices need remote isolation, because a single weak device can attack wider networks internally. Physical tampering is a realistic threat for street cabinets, vehicles, unattended remote installations in public places.

Energy Accounting Without Slogans
Central inference carries a real, growing energy cost at national scale in the United States. The U.S. Department of Energy reported United States data centre use of 176 terawatt-hours in 2023. Data centres consumed about 4.4 percent of total United States electricity during 2023 alone. Projections in the same report reach 325 to 580 terawatt-hours by 2028 nationally. Edge designs add device, gateway, network energy, while no authority source totals that side completely. Honest projects therefore measure watts per inference, gateway duty cycle, backhaul volume, data centre share separately.
Data growth explains why filtering keeps gaining importance for analytics teams in many sectors. A white paper from the European Commission projected growth from 33 zettabytes in 2018 to 175 zettabytes in 2025. The 2020 white paper cited an industry forecast, so the 175 figure is a projection, not a measurement. Volume growth still supports the design point, namely raw streams outgrow cheap central processing capacity quickly.
How Much Does Edge AI Cost?
Total cost depends on device count, hardware class, connectivity, support obligations across the fleet lifecycle. The cost model below lists the categories a budget must cover before a pilot expands further.
| Cost category | What drives the cost | Cost behaviour |
|---|---|---|
| Edge hardware | Device count, hardware class | Upfront, per site |
| Model development | Data quality, accuracy target | Project based |
| Connectivity | Backhaul volume, network type | Recurring, monthly |
| Fleet operations | Updates, monitoring, spares | Recurring, per device |
| Site support | Travel distance, failure rate | Recurring, variable |
| Compliance work | Sector rules, audit scope | Project, recurring |
Cloud analytics shifts spending toward recurring network, compute, storage charges inside central platforms each month. Edge analytics shifts spending toward upfront hardware, plus recurring fleet operations across many locations afterwards. A fair comparison therefore covers three years minimum, including spares, support visits, replacement cycles realistically. Pilot budgets often miss site support, because one demonstration site hides travel, access, scheduling costs completely. Finance teams should price the fleet, not the pilot, before approving a national rollout programme. A simple budgeting method multiplies per-site hardware, installation by planned site count before adding recurring items. Recurring items include connectivity, monitoring, spares, support visits, model maintenance across the whole contract period realistically. Vendor quotations remain necessary for final figures, because hardware class, site conditions swing totals very widely.
How to Deploy Edge AI for Real-Time Analytics
A disciplined deployment sequence reduces failed pilots, unclear ownership, unsupported fleets in production environments. Each step below names one action, one owner, one output for the next stage.

- Define the local decision, the latency budget, the action triggered by model output first.
- Audit data sources at one representative site, including quality gaps, missing labels, timing issues.
- Select hardware by testing the real model under site temperature, power, load conditions directly.
- Build the ingestion pipeline with buffering, time synchronisation, local storage limits configured from the start.
- Validate accuracy on site data, comparing model output against human judgement, recorded ground truth carefully.
- Configure security controls, including secure boot, signed updates, encrypted storage, unique credentials per device.
- Release the model to a small ring of devices, monitoring accuracy, latency, failure rates daily.
- Expand release in stages, keeping a tested rollback path for every model version in production.
- Review drift metrics, energy use, support costs monthly, scheduling retraining before accuracy decays materially.
Architecture ownership should follow the component names used in recognised edge frameworks from the start. A platform team owns the orchestrator, model registry, release policy for the whole fleet centrally. Site teams own hosts, sensors, physical access, local network quality at each operating location daily. Clear ownership prevents the common failure where nobody accepts responsibility for a silent device failure. Monitoring must report device silence as an alert, because quiet devices often signal hidden failure.
Governance and Security Standards for Edge AI Fleets
Distributed fleets need governance that covers model risk, update authority, incident response across sites. The National Institute of Standards and Technology published the AI Risk Management Framework 1.0 on 26 January 2023. Four core functions structure the framework, namely Govern, Map, Measure, Manage for AI risk. Applied to a fleet, Govern assigns update authority, while Map records deployment context, failure impact locally. Measure tracks accuracy, drift on devices, while Manage covers rollback, incidents, retirement of models safely.
Formal management systems follow a different route under the International Organization for Standardization catalogue entry for ISO/IEC 42001:2023. Publication in December 2023 made the document the first AI management system standard available internationally. Requirements in the standard can support certification by an independent body, unlike voluntary framework guidance documents. Companion guidance in ISO/IEC 23894:2023, published in February 2023, explains AI risk management integration methods. Organisations can combine framework guidance for daily practice, plus a management system for formal accountability structures.
When Edge AI Is the Wrong Choice
Batch reporting, historical trend analysis, model training gain little from local inference on devices. Global questions need global data, while central platforms aggregate across sites far more efficiently overall. Small pilots with one camera, one site, slow decisions rarely repay fleet operations costs involved. Hybrid designs usually win in production, because urgent decisions stay local, while learning stays centralised globally. A clear rule helps, namely place inference at the edge only when latency, bandwidth, privacy, reliability demands it.

Conclusion
Successful programmes treat edge ai for real-time analytics as an architecture decision, not a product purchase. Latency budgets, data minimisation duties, fleet operations decide whether local inference earns the added hardware cost involved. Standards from recognised bodies give teams vocabulary, thresholds, governance structures for those decisions in procurement documents. Organisations planning a production deployment can start with one measured use case, one representative site, one rollback plan. Specialist help with custom AI software development services can then turn a proven pilot into a supported fleet.
Frequently Asked Questions
What is edge AI in simple terms?
Edge AI means running a trained AI model on a device near the data source itself. A camera or sensor analyses data locally, while a person or system receives only the result. Local placement cuts delay, because data avoids a long trip to a distant data centre.
How does edge AI differ from cloud AI?
Edge AI runs inference at the site, while cloud AI runs inference inside a central data centre. Cloud platforms remain stronger for training, storage, reporting across many sites over longer periods. Most production systems combine both placements, assigning each workload according to latency, cost, privacy needs.
Does edge AI work without an internet connection?
Local inference continues during an internet outage, provided power, hardware, local storage remain healthy on site. Alerts reach local systems immediately, while cloud reporting waits until connectivity returns to the site later. Safety functions should never depend on a remote connection for a basic protective action locally.
What hardware runs edge AI models?
Hardware ranges from microcontrollers for single sensors to edge servers for demanding video workloads at sites. Selection depends on model size, latency target, power supply, the physical environment around the device itself. Teams should benchmark the exact model on candidate hardware before ordering devices for a fleet rollout.
How much does edge AI cost for a small deployment?
Cost depends on device count, hardware class, connectivity charges, support obligations across the expected fleet life. A single site pilot costs far less than a supported fleet across many operating locations nationally. Budgets should cover hardware, development, connectivity, operations, spares over a three-year period at minimum realistically.
Is edge AI more private than cloud AI?
Local processing can reduce how much raw personal data leaves a site during normal operations each day. Privacy law still applies fully, because alerts, summaries, stored footage can remain personal data under law. Organisations need a lawful basis, retention limits, access controls, regardless of where inference actually runs today.
What is the difference between edge AI and edge analytics?
Edge analytics covers local measurement, filtering, aggregation of data at or near the source itself. Edge AI covers local inference by a trained model, for example image recognition or anomaly scoring. Many deployments combine both, because filtering reduces volume before model inference begins on the device hardware.
What role does 5G play in edge AI?
5G networks can carry data between devices, edge hosts with lower radio latency than older networks. Radio speed alone never guarantees application speed, because inference, transport, server stages still consume time afterwards.
Can small businesses use edge AI for real-time analytics?
Small businesses can start with one camera, one sensor, one narrow decision at one site. Managed gateways, subscription software reduce upfront effort, although support, connectivity costs still need a budget line.
How is edge AI used in video analytics?
Cameras running local models can count people, detect objects, flag safety events without streaming footage continuously. Footage stays on site by default, while alerts, counts, short clips move onward for human review.
How do teams get started with edge AI?
Teams get started by choosing one measurable decision, one site, one model with clear success criteria. A limited pilot exposes data quality, hardware limits before money goes into a wider fleet rollout programme.
What are the main disadvantages of edge AI?
Hardware limits, update complexity, physical security risks form the main disadvantages for most distributed edge fleets. Costs also shift from monthly cloud bills toward upfront hardware purchases, ongoing site support obligations over time.
References
- National Institute of Standards and Technology. Fog Computing Conceptual Model, NIST SP 500-325, March 2018.
- International Organization for Standardization. ISO/IEC TR 23188:2020, Edge Computing, February 2020.
- International Organization for Standardization. ISO/IEC TR 30164:2020, IoT Edge Computing, April 2020.
- Institute of Electrical and Electronics Engineers. IEEE Std 1934-2018, OpenFog Reference Architecture Adoption, August 2018.
- European Telecommunications Standards Institute. ETSI GS MEC 003, Multi-access Edge Computing Framework, Version 4.1.1, May 2025.
- International Telecommunication Union. Report ITU-R M.2410-0, IMT-2020 Technical Performance Requirements, November 2017.
- European Commission. White Paper on Artificial Intelligence, COM(2020) 65 final, February 2020.
- U.S. Department of Energy. Report on United States Data Center Energy Use, December 2024.
- National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework 1.0, NIST AI 100-1, January 2023.
- International Organization for Standardization. ISO/IEC 42001:2023, Artificial Intelligence Management System, December 2023.
- International Organization for Standardization. ISO/IEC 23894:2023, Artificial Intelligence Guidance on Risk Management, February 2023.
- U.S. Department of Health and Human Services. HIPAA Minimum Necessary Requirement, 45 CFR 164.502(b).
- European Union. Regulation (EU) 2016/679, General Data Protection Regulation, Official Journal L 119, May 2016.
- Satyanarayanan, M. The Emergence of Edge Computing, Computer, January 2017, Carnegie Mellon University.
- Satyanarayanan, M. et al. An Open Ecosystem for Mobile-Cloud Convergence, IEEE Communications Magazine, March 2015.