A desktop icon does not tell you where an AI model runs. A local-inference evidence brief separates the application interface, model storage, inference process, and network services. The goal is to establish the execution path for a specific mode, rather than treating every desktop assistant as private, offline, or locally computed.
Primary sources checked on 8 October 2026. Worked examples and sample records below are illustrative; they do not represent product tests or real customer findings.
Identify the exact application mode
Record the app version, selected model, operating system, and feature. Some applications offer both local and cloud models under the same interface. A desktop program may send prompts to a hosted API, while another loads downloaded weights into local memory. File location and inference location are different facts. A file selected from your computer can still be uploaded for processing.
Write the question narrowly: does this named mode execute inference on this machine? Keep related questions about telemetry, synchronization, licensing, and updates separate. Local generation does not automatically mean the application makes no network connections. A meaningful brief describes each relevant connection instead of using offline as an imprecise label for the entire product.
Find architectural evidence in primary documentation
Ollama’s official FAQ describes how to inspect models loaded into memory and the processor allocation reported by its running-model command. That is an example of primary documentation connecting a local service with execution evidence. It should not be generalized to unrelated desktop apps. Inspect each vendor’s own architecture, model, and privacy documentation.
Look for statements about local models, cloud model options, prompt transmission, and server endpoints. Preserve the exact product scope. A privacy page about a consumer account may not describe an enterprise deployment or a separately configured local server. If documentation says a feature uses cloud processing, retain that finding even when the program itself is installed locally.
Collect evidence from the running configuration
When authorized to inspect a machine, record the model selected, model files present, local service endpoint, and process activity during a non-sensitive request. A rise in GPU or CPU activity can support the execution story but cannot prove it by itself. Video rendering or other work may produce the same activity. Connect observations to the relevant process and request.
Use application logs or documented status commands where available. Distinguish loaded weights from cached downloads. A model file on disk may never be used by the current mode. Preserve the command or observation method and timestamp so another reviewer can reproduce the check without relying on a screenshot of an unexplained resource graph.
Design an offline check that answers one question
A controlled network-disconnected test can help establish whether a particular prepared mode works without a live service. Download required model files first, then use a synthetic prompt. Record which feature worked and what failed. Avoid disconnecting a shared production machine or interrupting other users’ work simply to test an assumption.
A successful offline response supports the tested mode, not every feature. Search, remote connectors, licensing checks, and cloud models may still require connectivity. A failed offline response also needs interpretation: missing weights or account initialization can prevent a local-capable mode from starting. Document the prepared state and error rather than immediately calling the entire app cloud-only.
Map data flows separately from compute
Create rows for prompts, attachments, generated output, telemetry, crash reports, and synchronization. For each, record the documented destination and observed evidence where available. Mark unresolved items. This prevents a local-inference finding from becoming an unsupported no-data-leaves-the-device promise. Data-flow policy and execution architecture need separate treatment.
In an illustrative comparison, a local model produces a draft without a network request while a search feature fetches remote results. The brief should state that distinction. Do not flatten it into fully offline or fully cloud. Teams choosing a confidential-document workflow need the exact feature boundary so they know which actions change the processing path.
Deliver the local-inference evidence brief
Summarize the named mode, supporting documentation, configuration evidence, offline-test status, and unresolved connections. Label tests as performed only when they actually occurred. This guide’s examples are illustrative; they do not certify any installed app. Give the reader a concrete check plan and clearly separate provider statements from observations.
Revisit the brief after an app update, model change, new connector, or cloud-mode selection. Keep a dated configuration snapshot and avoid transferring a result between machines with different settings. The practical outcome is a mode-specific execution record that supports a deployment decision while preserving the limits of the evidence.
Review and preserve the finished local-inference evidence
Before handing over the result, perform a review that starts from the evidence rather than the generated prose. Pick a clearly supported item, a disputed item, and an item with missing information. Write the expected treatment of each before reading the proposed conclusions. Then open the cited originals and compare the result with those expectations. Check the surrounding text, headings, dates, and qualifications, because a citation can point to the correct document while supporting a narrower statement.
Ask a colleague to use the finished deliverable without your explanation. They should be able to locate the original records, identify unresolved questions, and understand which statements are direct evidence and which are your interpretation. Revise any place where they must guess. Keep the reviewed output, source manifest, prompt, and correction history together. Record the review date and the event that should trigger another check. When a source changes, preserve the earlier assessment and explain which conclusions were affected rather than silently replacing the evidence.
Do not equate an empty result with the absence of a problem. Check that all intended inputs were included and readable. Explain exclusions and merged records. A useful handover makes incompleteness visible and assigns a next action to the person who can resolve it.
Frequently asked questions
Does a desktop app run locally?
Not necessarily. It may be a client for hosted inference or offer both local and cloud modes.
Do downloaded weights prove they are being used?
No. Connect the selected model to process or service evidence for the actual request.
Does local inference mean no network traffic?
No. Updates, telemetry, search, synchronization, and other features can have separate connections.
What does an offline test establish?
It supports the tested prepared configuration and feature, with the recorded conditions and limitations.
When should I recheck?
After application updates, model changes, new connectors, or configuration changes that alter the execution path.
