Edge AI: assess the field operating case

OutsourcingVN is operated by Netbase JSC, which scopes and builds field and mobile software, so we have an interest in your decision. The method applies whoever builds yours. This guide is for CTOs, product leads and operations owners considering inference on phones, tablets, cameras, gateways or embedded modules in warehouses, plants, vehicles or field sites.

Where the decision favours cloud rather than device inference, Cloud Platform and DevOps Engineering builds that hosting and GPU capacity, with the reliability and incident readiness guide covering how the running service is monitored and recovered. Device credentials, remote wipe and site access raise the same questions as the data security and compliance guide works through for any outsourced system.

What this guide covers

• Why run the model on the device at all?
• Which operating pattern fits?
• What changes when the model leaves the data centre?
• How do you build a bounded field assessment?
• A worked example: connection lost mid-inspection
• What has Netbase delivered for field workflows?
• Which questions should you ask a supplier?
• What failure modes should you watch for?
• Common questions
• How this guide is sourced
• Bring the field conditions

Why run the model on the device at all?

There are four good reasons to put inference at the edge, and a proposal should name which one applies. The network is unreliable where the work happens. The answer is needed faster than a round trip allows, such as a camera rejecting a part on a moving line. The raw data should not leave the site, such as video of people. Or sending everything to the cloud would be too heavy, such as continuous high-resolution video. If none applies, a connected service with local capture is simpler to run and update; the production inference assessment covers that route.

Edge also changes what "deployment" means. A cloud model has one copy to patch. A fleet has hundreds of copies on devices of different ages, some offline for days, some in places nobody can reach quickly. Most of the cost and risk of edge AI sits in that lifecycle, not in the model.

Which operating pattern fits?

What changes when the model leaves the data centre?

The model usually has to shrink. Teams export it to a portable format such as ONNX and run it with a runtime matched to the hardware: ONNX Runtime with a hardware-specific execution provider, a vendor inference engine on a GPU module, or the phone's neural accelerator. Quantising weights to lower precision makes the model smaller and faster, and can change its answers on hard cases. ONNX Runtime's own documentation leaves validation of accuracy and performance to the user, so every conversion needs the case set rerun on the target device, not on a developer laptop.

The device class sets the limits. A phone offers a camera, an accelerator and a familiar update channel through app stores. A GPU module suits multiple camera streams but needs cooling and power. An industrial gateway sits on a site network and needs remote management. Heat, battery drain and storage also matter: a model that runs well for ten minutes can slow down once the device warms up in a hot vehicle.

A worked example: connection lost mid-inspection

A manufacturer gives quality inspectors a tablet running a defect-detection model for incoming parts. An inspector photographs a batch in a loading bay where the network drops.

The tablet keeps working: the model flags two parts as possible cracks, and each result is stored locally with the photo, timestamp, device ID and model version. The screen shows "saved offline, will sync" rather than an error. The inspector marks one flag as confirmed and leaves the other for review. When the tablet reconnects, the queue uploads in order with an idempotency key per record, so a retried upload does not create a second inspection.

On the server, a larger model rescores a sample of offline results. It disagrees on the unconfirmed flag, which lands in the quality engineer's review queue with both results side by side. The quality engineer decides; the fleet owner sees in telemetry that this tablet is two model versions behind and schedules the update. The manufacturing and field service page covers where workflows like this sit in a wider operation, and the same offline-capture and fleet-update pattern applies to substation and depot devices in energy and utilities.

Which questions should you ask a supplier?

What failure modes should you watch for?

How this guide is sourced

Statements about Netbase map to approved claims backed by attested company facts listed under Sources, in their registered wording. External guidance comes from the ONNX Runtime documentation and NIST SP 800-213, each dated below. The inspection example is illustrative and describes no client. The Dey Page field workflow above is offline capture without AI, and no launch or usage claim is made for it. This page does not replace your security owner's device assessment. See the methodology for how claims are reviewed.

Bring the field conditions

A first conversation goes furthest with a description of the sites, the devices you already own, the decision the model would support and some real inputs captured there. Submit a project with those, or read the emerging technology adoption guide, the robotics software feasibility guide and the other guides first; an AI Workflow Blueprint is the assessment route when the operating case is still open. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

Related services and solutions

Sources

• ONNX Runtime documentation
• NIST SP 800-213, IoT Device Cybersecurity Guidance for the Federal Government