“Should the model run in the cloud or at the factory?” is often premature. First establish which business action must continue without external connectivity, how long its data remain usable and who restores service. This article argues for placing industrial AI along business-continuity boundaries: one application can execute locally, be managed centrally and support asynchronous analysis. The framework and scenarios are engineering analysis, not IDENIFE project results.
Recent research shows that runtime advantages are conditional
A July 13, 2026 industrial vision study compared PyTorch, ONNX Runtime, OpenVINO and TensorRT. It measured batch-one inference on specified hardware, models and software versions, excluding pre- and post-processing. The optimization advantages for CNNs did not fully carry over to the tested Grounding DINO desktop-GPU setting.[1] These are bounded experiments, not a ranking for every edge model.
For enterprises, new models and runtimes expand the candidate set, but selection still depends on the site’s business action. Image capture, transfer, preprocessing, inference, rules and downstream acknowledgement form the full path. A faster model call does not establish that the whole path meets its deadline.
Organizations with multiple lines, factories or intermittent connectivity should particularly revisit this decision. A single-site demonstration can hide central-service outages, device differences and remote-maintenance problems. Edge–cloud allocation changes failure scope and maintenance responsibilities; per-inference cost alone is insufficient.
Allocate locations by business action
First identify actions with short deadlines that cannot wait during an outage. If the local model and associated rules meet requirements, place all essential dependencies at the device or a factory-local service. Functions requiring deterministic timing or safety protection belong in the applicable control and protection systems; AI advice does not itself establish suitability for direct control.
Next consider site assistance that can wait, such as explaining maintenance documents, investigating shift-level quality or suggesting operations. These tasks may use a shared factory service or cloud services where data conditions permit. Specify how work continues without a response; do not leave production staff to improvise what “retry later” means.
Cross-site aggregation, training, quality reviews and version management can often be centralized. This is conditional design advice: restrictions on moving data, high upload costs or insufficient central support can change the choice. Here, edge includes devices and factory-local nodes; cloud means centralized services reached over external networks. A factory server can itself be a shared failure point for several workstations.
Check the entire dependency chain for offline operation
Microsoft’s IoT Edge documentation describes continued offline operation after initial synchronization, but message retention remains limited by time-to-live and disk capacity. Cloud-visible status can also be stale during disconnection.[2] Platform support for offline operation therefore does not establish indefinite continuity for the complete AI application.
Check whether model files are already downloaded, licence checks require a remote service, startup pulls an image, identity checks can run locally under allowed conditions, and rules and material information have usable snapshots. Losing connectivity while running and restarting while disconnected are different acceptance cases.
For every cached input, record its validity period and behavior after expiry. An obsolete material rule may be more consequential than temporarily unavailable AI output. Options include approved older rules, human review, reduced automation or pausing the affected action; choose according to business consequences. Offline operation must preserve identity and permission boundaries rather than replace dependency management with shared administrator accounts.
Record process health, successful inference, completed business actions and cloud observability separately. Otherwise, a dashboard’s “online” or “healthy” label can be mistaken for evidence of production continuity.
Constructed scenario: outage capacity and recovery capacity differ
Suppose a workstation produces two mandatory inspection records each second, averaging 1 MB per record including attachments, and must tolerate a two-hour external-network outage. Business records alone accumulate to approximately 14,400 MB, or 14.4 decimal GB. This excludes filesystem overhead, logs, retry copies, model files and reserve space. Every number is a constructed assumption, not a device specification.
Define when storage alerts trigger, which data may be sampled under agreed rules, which records must never be discarded and which process degrades when storage fills. Do not promise permanent retention of every image and then treat finite disk capacity as an implementation detail.
Now assume reconnection provides a sustained effective upload capacity of 5 MB per second, new records continue at 2 MB per second and no other bottleneck exists. Net backlog clearance is only 3 MB per second, requiring about 4,800 seconds, or 80 minutes. If upload capacity does not exceed continuing generation, reconnection will not automatically clear the backlog.
This simplified calculation excludes variability and protocol overhead; replace assumptions with measured effective throughput at the site. It defines two acceptance targets: duration of tolerated disconnection and time to restore complete data. Records should also contain part and event identifiers, capture time, model version and upload status so the original decision remains distinct from later analysis.
Deploy a maintainable combination
AWS Greengrass V2 distinguishes model, runtime and inference components, assembled through dependencies.[3] Drawing on that separation, this article recommends managing the model, inference code, runtime, preprocessing and business rules as one compatible combination rather than sending new weights alone to the site.
The central team should maintain verified combinations and supported configurations. The site team needs named responsibility for approving switches, handling disk failure and checking cameras and device interfaces. Remote updates cannot repair every incident. Multi-site operation also involves access windows, local-support time differences, spare parts and hardware generations.
Complete downloads and integrity checks before switching within an agreed window. Establish that the old version can restart and read the relevant older data formats. A device returning after a long outage should not automatically run heavy updates and bulk uploads simultaneously, competing for network and disk resources. These are deployment-policy recommendations, not default guarantees from every platform.
Centralized hosting may be preferable for infrequent tasks that tolerate waiting, allow data transfer and lack on-site maintenance staff. Local execution deserves validation when critical actions must survive external outages and input volumes are stable. Hybrid designs add version and data-synchronization complexity; architectural completeness alone does not justify them.
Compare observable delivery conditions
Hold business-quality requirements constant and test normal connectivity, external disconnection, offline restart, near-full storage and reconnection with queued uploads. For each condition, identify permitted actions, actions that must be rejected and the responsible fallback operator. Count model failures and stale data instead of measuring successful responses alone.
Observe the distribution of input-to-business-result latency, the on-time completion rate, the age of the oldest queued record, backlog bytes and time spent degraded. The completion-rate denominator includes every task required to finish by its deadline. Backlog age exposes long-stalled records more clearly than count alone, but both are useful.
Compare full-lifecycle costs: equipment and redundancy, deployment adaptation, network and storage, update verification, inspections and site incident handling. Unit prices are not directly comparable when outage tolerance, retention or recovery deadlines differ. For the enterprise and industrial AI work that IDENIFE focuses on, explicit delivery boundaries connect model selection, data engineering and operational responsibility without assuming one topology suits every customer.