Local AI and privacy: How to check what data actually leaves your device

What “local” really means

“Local” can describe several different things: where a model’s weights are stored, where a response is computed, or which parts of a workflow take place on your device. These conditions are not equivalent. A model can be downloaded and run on your computer while the application contacts an external service for an optional feature, checks for updates, or searches for available models. An application can also send a request to an inference server running on the same computer, while saving conversations or logs in files that other system users can access.

That is why the useful question is not just “Is the model local?” but “Which components are involved in this task, what data does each one receive, and what evidence do I have about how they behave?” The boundary to examine includes the chat interface, the process that loads the model, enabled tools, extensions, network connections, storage, and backups. Your assessment applies to a specific configuration: application version, settings, operating system, installed model, and actions performed.

Running inference on the device can reduce the need to send a prompt to a remote provider for that operation, but it does not by itself prove that the full application is offline. Nor does it automatically protect information from other accounts with access to the computer, malicious software, broad permissions, or files retained after the application closes. These are separate questions about where computation happens, how data travels, and how the device is secured.

Map the data flow before testing

Make an inventory of all the components involved, not just the model. Include the application that displays the chat, the inference server, the model and its download manager. Then add web search, tools, extensions, plug-ins, update checks, and any options that may use cloud services. If an application lets you switch between local and remote modes, note which mode is active in each test. A label on a screen is no substitute for checking the configuration actually in use.

For each component, record what information it might receive. A prompt may contain sensitive text; a document attachment may be read by a tool; a search may transmit a query; and a log may retain inputs and outputs. Do not assume all this data is handled in the same way. A response-generating service, a feature that accesses the internet, and a chat-history file are different destinations and exposure points.

Your inventory should distinguish between activities. Downloading a model, installing an extension, entering a prompt, attaching a file, running a search, and checking for updates are separate actions. If you do them all at once, you will not be able to clearly attribute a change in network traffic. NIST’s network-characterization methodology offers a basis for organizing observations around predefined activities. Its report concerns IoT devices, so it is adapted here as a testing method, not treated as a certification of AI applications.

Run a controlled offline test

An offline test can show which features remain available after the environment has been prepared, but it does not prove that data was never transmitted. Before disconnecting, install the application, download the model you intend to evaluate, and prepare your test documents. Note which resources were obtained during this stage. If the product offers search, on-demand downloads, or remote tools, identify those as functions separate from basic chat.

Disconnect the computer from the internet using a method you can verify, and record the connection status. Test each activity separately: a simple conversation with the model already loaded, a query using a local document, and any optional feature you care about. Note whether the task completes, fails with a message, waits indefinitely, or produces a partial result. Repeat each test under similar conditions, and avoid changing several settings between trials.

State the limits of what the results show. If a conversation works offline, you can conclude that this specific task worked in this configuration during the test. You cannot conclude that the application never transmits data, that it will not connect after you reconnect, or that a different mode of use will behave the same way. If a feature fails, that shows the tested operation was unavailable without a network under those conditions; it does not, by itself, tell you what data the feature would have sent or where it would have gone.

For example, LM Studio’s documentation distinguishes tasks it describes as available offline, such as chat and working with documents, from actions that generate network requests, such as searching for or downloading models and checking for updates. This is a useful example of how an application can describe its modes, but it does not replace testing the specific device, version, and settings under evaluation.

Observe traffic one activity at a time

The most informative test separates events and takes notes before, during, and after each one. Record connections while the application is idle; then start the program, load the model, submit a test prompt, attach a harmless document, enable a search, install an extension, and check for updates. Do not combine all these steps into one session if you need to attribute connections. Repeat relevant actions to see whether the pattern occurs again.

Document the time, the action, the associated process if you can identify it, the visible destination, and the approximate duration. Also preserve the exact configuration and any error messages. Observing a connection is not enough to establish what content passed through it; nor does a destination’s name, on its own, prove how data was handled. If you cannot inspect the content, record that limitation rather than filling the gap with an assumption.

Compare three situations: the application idle, basic use, and each optional feature. If a connection appears during an update or download, separate it from the prompt test. If you observe no traffic during a test, limit your conclusion to that test and the observation tools you used: a brief capture may miss intermittent or delayed connections, or connections initiated by another component. For a higher-impact review, ask a technical reviewer to document the method and repeat the protocol.

Review chat history, logs, and permissions

Privacy questions do not end when the response is generated. Find out where conversations, temporary documents, caches, and logs are stored. Check both the application settings and the files it creates, and identify which system accounts can read them. Also consider folder synchronization, backups, and diagnostic tools if they are used on the computer. Do not assume that closing a window deletes data or that one cleanup option covers every component.

As a specific example, LM Studio’s documentation says its conversations are stored in JSON files and describes storage locations for different operating systems. Its documentation for the log-streaming command notes that logs can show the model’s and server’s input and output text. These details are relevant when reviewing that application and its configuration; they should not automatically be generalized to other runtimes.

Before entering sensitive information, test deletion using fictitious data: locate files before and after, use the documented deletion method, and check what remains. If the product does not explain where data is stored or how to remove it, record that as an uncertainty and ask the provider or system administrator for clarification. Limiting the permissions of the account running the application can reduce who has access to its files, but it does not replace system controls, encryption where appropriate, or a retention policy.

A server on your computer may be reachable from the network

A local API lets a client application send requests to an inference server. “Local” may mean that the process runs on your computer, but the network interface on which it listens determines where it can be reached from. A service limited to a loopback interface is intended to accept requests from the same computer; a service reachable through a network interface may accept connections from other devices, depending on its configuration and network rules. Check the actual behavior rather than inferring it from the word “local.”

Review the listening address, port, network-access options, and authentication controls. Confirm whether another device on the network can reach the service and whether it can submit requests without credentials. Do this only in an authorized environment, using a test model and non-sensitive content. A response from the server does not prove that all its tools are isolated: separately check which files, features, or extensions the client making requests can invoke.

LM Studio’s documentation describes a local API server that can be used on localhost or across a network. That possibility is a reason to inspect the active interface and settings, not evidence that every installation listens on the network or is exposed by default. If you do not need access from other devices, restrict the service to the computer itself using available options and system rules. If you do need that access, apply access controls and limit the process’s permissions to what it requires.

Separate observed facts, provider statements, and open questions

A useful report distinguishes three levels. The first is what you observed: for example, a particular feature failed offline, or a connection was recorded during a specific action. The second is what the provider states in its documentation or policies, such as which features it says work offline or under what circumstances it says data is transmitted. The third is what has not yet been established: the content of an encrypted connection that was not inspected, the behavior of another version, or file access by unrelated processes.

A privacy policy is a primary source for the provider’s statements about its product, but it does not independently verify what a particular installation did. Conversely, a traffic capture describes what a tool observed during a specific period and configuration, but it does not replace a contractual explanation of retention or processing. Combine the two kinds of evidence, and preserve the date, version, and conditions associated with each.

The matrix below helps prevent conclusions from going beyond the test. If a result depends on a setting, record both the observed state and the exact value of that setting. If you cannot reproduce an observation or identify its origin, classify it as unresolved. For high-risk decisions, an informal assessment does not replace a review of applicable security, privacy, and legal requirements.

Checklist before using sensitive data

Your final decision should not depend on a marketing label or a single test. Consider the type of data, the impact of disclosure, which features are actually necessary, physical and logical access to the computer, the evidence you have gathered, and your ability to delete or control logs. If you cannot resolve an important question, do not turn it into a favorable assumption: narrow the scope of use, remove the uncertain feature, or pause the evaluation until you get a verifiable answer.

To maintain control, keep a brief record of the configuration and protocol. Repeat tests after major updates, extension changes, or network changes, because the results describe the configuration you tested, not every future configuration. Keep screenshots or notes with sensitive data removed, and restrict who can consult them. If you detect an unexpected transmission, stop using real data, preserve non-sensitive evidence, and request a technical review before resuming.

Use this checklist as a practical threshold, not as a privacy certification. To explore local model options, consult a comparison, or discover other tools, you can start with Inferama’s local-model guides, comparison pages, and discovery catalogue. The privacy assessment, however, must be carried out on the application and configuration you plan to use.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.