Does Local AI Really Stay Local? A Local AI Privacy Audit of Ollama, LM Studio, Open WebUI, and Foundry Local

Local AI privacy sounds simple: install a model, run it on your computer, and keep your prompts away from the cloud. In practice, that is only part of the story. A local model can still sit inside a workflow that uses the internet for model downloads, update checks, cloud-hosted models, web search, document processing, remote embeddings, analytics, tool calls, plugins, sync folders, or a local server exposed to your network.

The right question is not just “does the model run locally?” The better question is: does the whole workflow stay local?

As of June 2026, the answer is mixed. Ollama, LM Studio, Open WebUI, and Microsoft Foundry Local can all be part of a privacy-conscious local AI setup. None of them should be treated as a magic privacy shield without checking the surrounding configuration.

Bottom line: local inference is not the same as local privacy

A workflow is meaningfully local only if all of these stay on your device, or on infrastructure you deliberately control:

• the model inference;
• your prompts;
• the model responses;
• uploaded documents;
• document chunks;
• embeddings;
• vector stores;
• chat history;
• logs;
• local server access;
• provider API calls;
• web search;
• tools, plugins, and MCP servers;
• sync or cloud storage; and
• telemetry, diagnostics, and crash-reporting paths.

Here is the practical summary.

Beginner recommendation: if you want the simplest private document-chat setup, start with LM Studio, download a local model, confirm offline mode works, and avoid LM Link, plugins, remote MCP servers, web search, and LAN serving.

Developer recommendation: if you want a narrow local inference layer, use Ollama or Foundry Local, keep the API bound to localhost, and audit any UI, RAG layer, or agent framework you connect to it.

Self-hosted UI recommendation: use Open WebUI only if you are willing to review provider URLs, embedding settings, storage settings, tool permissions, web search, telemetry, and Docker networking. Open WebUI can be private, but it is not private just because it is self-hosted.

What “local” should mean in local AI privacy

For local AI privacy, “local” should mean more than “the model file is on my computer.”

A local model means the model weights are stored and run on your machine. That is useful, but not complete.

A local workflow means the entire data path stays local. That includes prompts, documents, embeddings, generated answers, chat history, logs, local databases, API calls, and tools.

A local server means an app exposes an API from your computer. That can still be safe when it binds only to 127.0.0.1, which means your own machine only. It becomes riskier when it binds to 0.0.0.0, publishes a Docker port to all interfaces, or is placed behind a tunnel or remote-access service.

A RAG workflow means retrieval-augmented generation. In plain English, the app breaks your documents into chunks, turns those chunks into mathematical fingerprints called embeddings, stores them in a searchable index called a vector store, retrieves relevant chunks, and gives those chunks to the model. If the model is local but the embeddings or vector store are remote, the workflow is not fully local.

An MCP server is a Model Context Protocol server. It gives a model access to tools, such as a browser, file system, database, API, or external service. MCP is powerful, but it can also turn a local chat into a networked or tool-using workflow.

A practical privacy taxonomy for local AI

Use this taxonomy when evaluating any local AI app, not just the four products in this article.

This distinction is the core of the article. Local inference is a component. Local privacy is an architecture.

What stays local by product?

What can still use the network?

The practical lesson is simple: offline-capable does not mean never-networked.

Product audit: Ollama

Ollama remains one of the best ways to run local LLMs from the terminal or from a local API. For local models, its current privacy language is strong. The Ollama Privacy Policy says Ollama does not collect, store, transmit, or access prompts, responses, model interactions, or other content processed locally.

But Ollama is no longer best described as “local only by definition.” Its own FAQ distinguishes local use from cloud-hosted models. The FAQ says that when cloud-hosted models are used, prompts and responses are processed to provide the service. It also documents a way to disable Ollama cloud features.

For privacy-sensitive users, that matters. If you want Ollama to be local-only, set one of these controls and restart Ollama:

{
  "disable_ollama_cloud": true
}

or set:

OLLAMA_NO_CLOUD=1

Ollama’s FAQ says disabling cloud features removes access to Ollama cloud models and web search. That is the right tradeoff for confidential work.

Ollama’s local server is also a privacy boundary. By default, Ollama binds to 127.0.0.1:11434, which means only the local machine should be able to connect. The same FAQ explains that you can expose Ollama on a network by changing OLLAMA_HOST, and it gives examples for proxying and tunneling with tools like ngrok and Cloudflare Tunnel.

That does not make Ollama unsafe. It means you should not casually turn a localhost AI server into a LAN or internet-accessible AI server.

Ollama settings to check

Choose Ollama if

You want a simple local inference runtime, a terminal-first workflow, or a local API that other tools can call. Use it for sensitive work only with local models, cloud features disabled if necessary, and the server kept on localhost.

Product audit: LM Studio

LM Studio is the clearest beginner-friendly privacy story among the four tools in this audit.

The LM Studio Desktop App Privacy Policy says that none of your messages, chat histories, and documents are transmitted from your system, and that everything is saved locally on your device by default. It also says the app receives usage information only when you search for or download models, when the app checks for updates, or when you email LM Studio directly. The same policy says the app does not include telemetry or user-specific tracking.

LM Studio’s Offline Operation page is similarly direct. It says LM Studio can operate entirely offline after you have model files. It also says that chatting with models, chatting with documents, and running a local server do not require internet access. For document chat, it says the document stays on your machine, document processing is local, and nothing uploaded into LM Studio leaves the application.

That makes LM Studio a strong default choice for beginners who want to chat with documents locally.

The caveats are not contradictions. They are feature boundaries.

LM Studio can search for and download models from online repositories. It can check for updates. It can run a local API server. Its server docs say the server binds to 127.0.0.1 by default, but can bind to 0.0.0.0 to listen on all IPv4 interfaces. The docs warn that any bind other than 127.0.0.1 exposes the server beyond localhost and recommend authentication.

LM Studio also now has LM Link. The LM Link page describes using local models remotely, including models loaded on remote devices, local devices, LLM rigs, or cloud VMs. It says chats remain local while the heavy processing happens on devices you own. That may be private enough for many personal users, but it is not the same as single-device local inference.

Finally, LM Studio has a plugin and MCP ecosystem. Its plugin docs say plugins can access external APIs, and generator plugins can replace the local model, which is useful for online adapters. Its MCP docs show models using external tool servers, including remote MCP endpoints and custom headers.

For sensitive documents, LM Studio is excellent only when you stay inside the local lane.

LM Studio settings to check

Choose LM Studio if

You are a beginner, teacher, writer, lawyer, consultant, or small-business user who wants a desktop app for local chat and local document chat with the fewest moving parts. For confidential work, download models first, confirm offline mode works, keep the server on localhost, and avoid LM Link, remote plugins, and MCP tools.

Product audit: Open WebUI

Open WebUI is powerful, but it requires the most careful privacy explanation.

The Open WebUI documentation describes it as a self-hosted AI platform designed to operate entirely offline. In the same sentence, it says Open WebUI supports Ollama and OpenAI-compatible APIs and works with both local and cloud-based models. Both statements can be true. That is exactly why Open WebUI needs configuration review.

Open WebUI is not just a local chat app. It is a front end, a routing layer, a document system, a knowledge base, a tool platform, and often a team workspace. That power is useful, but it means the privacy posture depends on the deployment.

Open WebUI’s environment configuration shows why. Its default database URL is sqlite:///${DATA_DIR}/webui.db, which means chats and app data can live in a local SQLite database by default. Its RAG settings include RAG_EMBEDDING_ENGINE, with options for default local SentenceTransformers, Ollama, OpenAI, and Azure OpenAI. Its storage settings include STORAGE_PROVIDER, with local storage by default but support for S3, Google Cloud Storage, and Azure storage. It also has documented integrations for OneDrive and SharePoint.

That means Open WebUI can be local. It also means Open WebUI can become non-local with a few admin settings.

The tool surface is even more important. Open WebUI’s tools documentation warns that Workspace Tools and Functions execute arbitrary Python code on the server. Open WebUI also supports MCP, OpenAPI tool servers, web search, and Open Terminal. If those tools call the internet, read files, hit APIs, or execute shell commands, then your local model is now part of a tool-using system.

OpenTelemetry is another audit item. The OpenTelemetry docs describe variables such as ENABLE_OTEL, ENABLE_OTEL_TRACES, ENABLE_OTEL_METRICS, ENABLE_OTEL_LOGS, and OTLP exporter endpoints. Observability is not bad in a production deployment, but for confidential local use, telemetry and log export settings must be reviewed.

Docker networking is the other common trap. Open WebUI’s quick start uses -p 3000:8080. Docker’s port publishing documentation says that when ports are mapped without a specific host address, Docker publishes ports to all host addresses by default. For a private local setup, bind explicitly to loopback or use a protected deployment.

Open WebUI settings to check

Choose Open WebUI if

You want a self-hosted web UI, multi-user access, admin controls, tool use, RAG, and provider flexibility. Do not choose it as the “easy private” option unless you are willing to audit its providers, embeddings, storage, web search, tools, telemetry, database, and Docker networking.

Product audit: Microsoft Foundry Local

Foundry Local is Microsoft’s on-device AI runtime for shipping applications that run on user devices. The current Foundry Local overview says user data never leaves the device, responses start with zero network latency, and apps can work offline. It also says Foundry Local supports Windows, macOS on Apple silicon, and Linux.

That is a strong local inference statement, but the same Microsoft page gives the important nuance. It says Foundry Local can still use the network for model and component downloads, including execution providers for the user’s hardware, and for optional diagnostics if a user chooses to share logs.

Foundry Local is also not meant to be a general multi-user inference server. Microsoft’s docs describe it as optimized for hardware-constrained devices where a single user accesses the model at a time. If you need server-style batching, concurrent request queuing, or multi-user GPU sharing, Microsoft points users toward server inference stacks instead.

The Foundry Local CLI docs say first-time model and execution-provider downloads require internet access. They also document commands for downloading models in advance, listing cached models, checking the cache location, and changing the cache directory. The REST API reference shows local endpoints such as http://localhost:<PORT> and an /openai/status response that includes endpoint and ModelDirPath information.

That makes Foundry Local a good fit for developers building local AI into apps. It is not the same product category as LM Studio’s desktop document chat or Open WebUI’s self-hosted interface.

Foundry Local settings to check

Choose Foundry Local if

You are building or testing an app that needs Microsoft-supported on-device inference, OpenAI-compatible local endpoints, and model lifecycle management. For ordinary beginner document chat, LM Studio is simpler.

Risk by workflow

Safer local-only configurations

Safest beginner setup

Use LM Studio with a downloaded model, offline operation, no LM Link, no plugins, no MCP, no LAN server, and no cloud sync for the conversation folder.

This is the easiest recommendation for most readers who want a private local AI app without becoming a system administrator.

Safest developer setup

Use Ollama or Foundry Local as the runtime, pre-download models, keep the service bound to localhost, and use a minimal client that you control. Avoid browser extensions, remote RAG services, web search, and external tools unless you have audited them.

This is the cleanest pattern if you want a small local API surface.

Safest self-hosted web UI setup

Use Open WebUI only with local provider URLs, local embeddings, local storage, web search off, cloud storage off, OneDrive and SharePoint integrations off, OpenTelemetry off, Open Terminal off, and no external MCP or OpenAPI tool servers. Bind the service to loopback unless you deliberately need a network deployment, and then use authentication, firewall rules, and a trusted reverse proxy.

This is powerful, but it is not the easiest beginner privacy setup.

Safest professional setup for confidential documents

For lawyers, consultants, HR teams, finance teams, and enterprise users handling confidential material, use a dedicated machine or profile, enable full-disk encryption, keep models and chats out of cloud-sync folders, disable web search, disable remote tools, and test the workflow with the network disconnected.

Do not rely on the phrase “local AI.” Document the actual data path.

Checklist for privacy-sensitive users

Before using local AI with sensitive documents, answer these questions.

Checklist for lawyers, consultants, and enterprise users

Professionals should apply a stricter standard than hobby users. A local LLM setup for client-confidential or regulated material should have a written privacy posture.

Safe wording for privacy claims

If you publish or explain a local AI setup, use careful wording.

Claims to avoid

Do not say “fully private” unless you have verified the full workflow.

Do not say “air-gapped” unless the machine is actually isolated from networks and the workflow works without connectivity.

Do not assume that local inference means local embeddings.

Do not assume that a desktop app is offline.

Do not assume that a self-hosted web UI is safe if Docker publishes it on your network.

Do not assume that a local server is safe if it is exposed to the LAN without authentication.

Do not treat vendor privacy claims as complete architecture documentation.

Do not treat a remote device accessed through a private link as the same thing as single-device local inference.

Suggested screenshots for this article

These screenshots would make the article more useful:

So, does local AI really stay local?

Local AI can stay local, but only if you verify more than the model.

For most beginners, LM Studio is the safest first choice for local AI privacy because its desktop app privacy policy and offline docs are direct, its document chat is built in, and its default workflow has fewer moving parts. Use it offline after downloading models, and avoid LM Link, plugins, MCP, LAN serving, and cloud sync for confidential work.

For developers, Ollama is an excellent local inference layer, but you should disable cloud features if you want local-only behavior and keep OLLAMA_HOST on localhost. Remember that any front end or RAG app connected to Ollama becomes part of the privacy audit.

For self-hosters, Open WebUI is powerful but configuration-sensitive. It can be local, but it can also connect to cloud models, remote embeddings, web search, cloud storage, telemetry exporters, and external tools. Treat it as private after configuration, not private by default.

For app builders, Foundry Local is a strong Microsoft-backed on-device runtime. It processes prompts and outputs locally during inference, but setup and support flows may still involve downloads and optional diagnostics.

The final recommendation is cautious but useful: local AI privacy is real, but it is earned by configuration. A local model is the start. A verified local workflow is the goal.

FAQ

Does Ollama send my prompts to Ollama?

For local models, Ollama’s privacy policy says prompts, responses, model interactions, and other locally processed content stay on your machine. However, Ollama also documents cloud-hosted models, where prompts and responses are processed to provide the cloud service. If you want local-only behavior, disable Ollama cloud features.

Is LM Studio private for document chat?

LM Studio’s offline documentation says that when you drag and drop a document into LM Studio for document chat or RAG, the document stays on your machine, document processing is local, and nothing uploaded into LM Studio leaves the application. That assumes you are using the built-in local workflow and not adding remote plugins, MCP servers, or LM Link.

Is Open WebUI private by default?

Open WebUI can be run locally, but it should not be described as automatically private. It supports local and cloud providers, configurable embedding engines, cloud storage, web search, external tools, OpenTelemetry, and integrations such as OneDrive and SharePoint. You must review the configuration.

Does Foundry Local send anything to Microsoft?

Microsoft says Foundry Local processes prompts and model outputs locally during inference. Microsoft also says Foundry Local can use the network for model/component downloads and optional diagnostics if a user chooses to share logs.

Are local embeddings important for privacy?

Yes. Embeddings are numerical representations of text. If your document chunks are sent to a remote embedding API, your document workflow is not fully local, even if the chat model runs locally. Always check the embedding provider in RAG workflows.

Is a localhost AI server safe?

A localhost server is safer than a LAN or internet-exposed server because it listens only on your own machine. It can still create local logs and local attack surface. If you bind it to 0.0.0.0, publish Docker ports broadly, or put it behind a tunnel, it is no longer localhost-only.

What is the safest local AI setup for confidential documents?

For most non-engineers, use LM Studio with downloaded models, confirm it works offline, keep the local server off or bound to localhost, avoid plugins and MCP, and store chats outside cloud-sync folders. For developers, use Ollama or Foundry Local with a minimal local client and no remote tools or providers.

3. Source-Backed Claims

4. Publication Blockers

No publication blockers identified.

5. Editorial QA Checklist