Buy the NPU configuration only when the actual field application, model and runtime can use it on the proposed tablet—and when that execution path improves a measured constraint in the real task. An NPU number on a processor sheet is not evidence that a particular inspection or recognition app runs on that NPU. If the app has a reliable CPU or GPU path that meets the site's latency, power and offline requirements, an NPU may add cost without changing the work.
This is a procurement guide for a Windows tablet running a buyer-supplied on-device model. It is not a claim that any AIDC GO tablet includes an NPU, a particular accelerator driver, Windows ML, or a certified AI application.
Start with the field decision, not the accelerator
Name the decision the model supports: for example, classifying an inspection image for review, extracting a defect candidate for a technician, or prioritizing a queue. Define what happens if the model is unavailable. If a human must still inspect and approve the result, say so in the workflow and acceptance script.
Ask the application owner for a reproducible package: model file and version, input dimensions, preprocessing and postprocessing, runtime version, target OS build, accelerator provider, driver versions, and a CPU fallback policy. “AI-ready” and a headline TOPS figure do not identify any of those dependencies. A cloud-only model, or an app that never selects an NPU-capable provider, does not become on-device NPU inference when moved to an NPU-equipped tablet.
The field-inspection tablet guide covers keeping asset records, forms and images together. This page answers the narrower hardware question: where this model actually runs and whether its execution path justifies a different tablet configuration.
Check the complete Windows execution path
For an application using Microsoft Windows ML and ONNX Runtime, Microsoft documents CPU and DirectML providers included with the runtime and additional hardware-optimized providers that can be acquired for compatible hardware. The catalog path for those additional providers depends on Windows 11 version 24H2 (build 26100) or later, device and driver compatibility, and the application/runtime version. That is a platform example, not a universal requirement for every AI stack or a promise about a specific tablet. Microsoft's current provider list is the version-specific reference to check at quotation time.
Microsoft's provider-selection guidance shows how an app can enumerate available provider devices and select one explicitly. It also warns that the enumerated list can change when drivers or Windows ML providers update. Request a run log from the proposed OS image and app build showing the provider actually selected. Separately ask the app team which operations, if any, do not run on that provider and where they run instead. Do not infer full-model NPU execution from successful model initialization or the existence of a provider package.
If the proposed machine uses Windows on Arm, also use the Windows-on-Arm rugged-tablet compatibility guide for the unrelated question of legacy app binaries, drivers and peripherals. An AI provider working on Arm does not prove a printer, reader or VPN driver works there.
Compare configurations against one task
| Procurement question | Evidence to request | Decision consequence |
|---|---|---|
| Does the approved app invoke an on-device model? | Evidence: app build, model version and offline demonstration | Decision: if not, omit NPU from the AI requirement. |
| Is a compatible provider available on this exact image? | Evidence: OS build, runtime/provider/driver versions and enumeration log | Decision: if not, quote a supported CPU/GPU route or a different verified configuration. |
| Does the relevant model work on that provider? | Evidence: actual graph/session report, representative inputs and fallback record | Decision: a provider name alone does not establish useful acceleration. |
| Does it improve the constrained field task? | Evidence: same app and inputs on the candidate configurations; observed latency, power and operator outcome | Decision: keep the cheaper or simpler route if the NPU changes no acceptance criterion. |
| What happens after updates or provider loss? | Evidence: version-pinned deployment plan, recovery test and CPU/GPU fallback behavior | Decision: do not accept an unmaintainable single-path demonstration. |
This comparison is not a benchmark table. The supplier and app owner must provide results for the exact model and device configurations; this article offers no throughput, battery-life or temperature guarantee.
Run a fair, bounded pilot
Prepare a set of representative non-sensitive sample images or sensor records with expected human outcomes. This is a hypothetical acceptance design, not an AIDC GO test result. Use the same app build, model, inputs, screen settings and network condition for each candidate. Record inference completion, end-to-end operator time, any wrong or uncertain result, power behavior across the intended shift segment, and the provider actually used. Separately observe sustained behavior: a five-second demo does not prove an hour-long field workflow. The sustained thermal-workload guide explains why steady work and charging context matter beyond a short peak test.
Repeat with the network unavailable if offline inference is a requirement. Then remove or disable the chosen provider in a controlled test image—or use a documented unavailable-provider scenario—to confirm the app's declared fallback. Do not disturb production devices merely to create this failure. Capture the app's user-visible state and the technician's recovery action, not just a runtime log.
Fail the NPU requirement if the proposed SKU cannot expose the required provider, the model falls back without the buyer noticing, a driver update breaks the flow, or the measured benefit does not meet a pre-agreed threshold. A functioning CPU path can still be an acceptable procurement answer.
Put the evidence in the quote
Ask for the exact tablet SKU and processor option, OS image/build, app and model versions, runtime and provider versions, driver support statement, fallback behavior, tested input set and the owner of future updates. Confirm any regional or configuration differences with the supplier. If the supplier cannot show the relevant provider on the quoted machine, treat NPU support as unproven rather than transferring a platform feature to that SKU.
Explore rugged tablets and discuss the app, peripheral and OS dependencies with AIDC GO integration support. Send the shortlisted configuration and acceptance script through the contact page so the team can confirm what it can actually source and document for this project. Do not infer a catalogued NPU option from this guide.