Local AI Privacy Audit: What Data Do These Tools Actually Collect?

The promise of local AI is simple: your data stays on your machine. No cloud. No third parties. No training on your conversations. That is the sales pitch, and it is a good one.

But “local AI” is not a monolith. It is a stack of software — inference engines, desktop applications, web interfaces, model downloaders — each with their own data practices. Running a model locally does not automatically mean zero data leaves your machine. The model inference is local, yes. But what about the software around it?

I audited the five most popular local AI tools to answer a straightforward question: what data do these tools actually collect, phone home, or expose?

This is not a gotcha piece. Most of these tools are open-source projects run by well-intentioned teams. But “trust us, we’re open source” is not a privacy guarantee. Code can be audited, but most users do not audit code. This article does the audit so you do not have to.

Methodology

For each tool, I examined:

Source code — Searched for telemetry, analytics, HTTP requests to external servers, and data collection mechanisms
Network traffic — Monitored outbound connections using Wireshark and mitmproxy during typical usage
Documentation — Read privacy policies, terms of service, and any stated data practices
Configuration — Checked for opt-in/opt-out settings for data collection
Persistent storage — Examined what data is stored locally and in what format

All testing was done on Ubuntu 24.04 with fresh installs of each tool, as of March 2026.

Ollama

Version tested: 0.6.x License: MIT Verdict: Minimal data collection. Model downloads go through Ollama’s registry. Inference is fully local.

What Happens on the Network

Ollama makes network requests in exactly two scenarios:

Model downloads (ollama pull). When you pull a model, Ollama contacts registry.ollama.ai to download model files. This request includes the model name and your IP address (as any HTTP request does). No authentication or user identification is involved by default.
Update checks (optional). Ollama can check for updates, which contacts Ollama’s servers. This can be disabled.

During inference — when you are actually chatting with a model — Ollama makes zero network requests. I verified this with Wireshark: after model download, you can disconnect from the internet entirely and Ollama continues to function.

What Is Stored Locally

Model files in ~/.ollama/models/
No conversation history is stored by default (Ollama is an API server, not a chat application)
Server logs include prompts if logging is enabled (check your configuration)

Privacy Assessment

Rating: Excellent. Ollama does the minimum necessary — it contacts the internet only to download models and check for updates. Both can be avoided by downloading models manually and disabling update checks. For air-gapped environments, Ollama works perfectly offline once models are in place.

One thing to watch: If you expose Ollama’s API port (11434) to a network, any device on that network can send prompts and read responses. Ollama has no built-in authentication. In a shared network, always bind to localhost or use a firewall.

LM Studio

Version tested: 0.3.x License: Proprietary (free for personal use) Verdict: Some telemetry by default. Model downloads go through Hugging Face. Inference is local.

What Happens on the Network

LM Studio makes network requests for:

Model discovery and downloads. LM Studio connects to Hugging Face to browse and download models. This is transparent — you can see the Hugging Face URLs in the download interface.
Analytics/telemetry. LM Studio includes optional analytics that report usage statistics. In my network monitoring, I observed connections to analytics endpoints during app startup and model loading events. The data appeared to include: app version, OS type, GPU type, and model names used. I did not observe any prompt content or conversation data being transmitted.
Update checks. LM Studio checks for updates on launch.

What Is Stored Locally

Model files in ~/.cache/lm-studio/models/
Conversation history in a local database
Application settings and preferences

Configuration

Telemetry can be disabled in Settings > Privacy. When disabled, the analytics connections stopped in my testing.

Privacy Assessment

Rating: Good with caveats. The telemetry is mild (no conversation content), optional, and disableable. But it is opt-out, not opt-in — meaning the default is to collect data. For a tool whose core value proposition is privacy, defaulting to telemetry collection is a philosophical mismatch, even if the data collected is innocuous.

The proprietary license matters. Because LM Studio is not fully open source, the telemetry claims cannot be independently verified by reading the complete source code. You are trusting the LM Studio team’s stated practices. They have been transparent and responsive, but it is a trust relationship, not a verifiable guarantee.

Jan

Version tested: 1.x License: AGPLv3 (open source) Verdict: Strong privacy design. Local-first architecture. Minimal network activity.

What Happens on the Network

Jan was designed from the ground up as a “local-first” application. Network activity is limited to:

Model downloads. Jan downloads models from Hugging Face and its own model registry. Standard HTTP downloads with no special tracking.
Optional cloud extensions. Jan has an extension system that can connect to cloud AI providers (OpenAI, Anthropic, etc.) if the user explicitly installs and configures cloud extensions. By default, no cloud connections are made.
No telemetry in the open-source version. I found no analytics, crash reporting, or phone-home mechanisms in the source code or network traffic.

What Is Stored Locally

Models in ~/jan/models/
Conversations in ~/jan/threads/ as JSON files (human-readable)
All data in a portable folder structure you can back up, move, or delete easily

Privacy Assessment

Rating: Excellent. Jan’s architecture is genuinely privacy-first. The local folder structure means you can verify exactly what data exists and where. The AGPLv3 license means the code is auditable. The absence of telemetry is verifiable in the source code.

Standout feature: Jan stores conversations as simple JSON files in a predictable directory structure. You can browse, export, or delete your conversation history with standard file tools — no database extraction needed. This is privacy through transparency.

GPT4All

Version tested: 3.x License: MIT Verdict: Opt-in telemetry for research. Clear disclosure. Inference is local.

What Happens on the Network

Model downloads. GPT4All downloads models from its own model registry and Hugging Face. Standard downloads.
Opt-in telemetry. On first launch, GPT4All asks whether you want to contribute anonymous usage data to help improve the project. This is a clear, explicit opt-in dialog — not a buried setting.
If opted in, the telemetry includes: model name, prompt/response length (not content), hardware info, and performance metrics. The GPT4All team has published details about what is collected and explicitly states that prompt content is never transmitted.
LocalDocs indexing. GPT4All’s LocalDocs feature indexes your documents locally. The embeddings and index are stored on your machine. No document content is uploaded.

What Is Stored Locally

Models in a configurable directory
Conversations in a local database
LocalDocs embeddings and index files

Privacy Assessment

Rating: Very good. GPT4All handles telemetry the right way: explicit opt-in on first launch with clear disclosure of what is collected. The MIT license enables full code auditing. The opt-in telemetry, when enabled, collects genuinely useful research data without touching conversation content.

Credit where due: The opt-in dialog is one of the best I have seen in open-source software. It explains what is collected, why, and makes the “No” option equally prominent. This is the standard all local AI tools should meet.

Open WebUI

Version tested: 0.5.x License: MIT Verdict: No telemetry. But self-hosted does not mean automatically private — configuration matters.

What Happens on the Network

Open WebUI itself makes minimal external connections:

No telemetry or analytics. I found no phone-home mechanisms in the source code or network traffic. The project explicitly states it does not collect any user data.
Optional integrations. Open WebUI can connect to external services if configured: web search (Google, Bing, etc.), image generation APIs, and speech-to-text services. None of these are enabled by default.
Model downloads. If connected to Ollama, model downloads go through Ollama’s registry. If connected to a cloud provider, API calls go to that provider.

What Is Stored Locally

User accounts and credentials (hashed passwords) in a SQLite database
All conversations for all users in the same database
Uploaded files and RAG documents
Admin settings and model configurations

Privacy Assessment

Rating: Excellent for the software itself. But deployment configuration is everything.

Open WebUI is a multi-user application, which introduces privacy considerations that single-user tools do not have:

Admin access. The admin can see all users’ conversations through the admin panel. If you deploy Open WebUI for a team, the admin has full access to every conversation. This is not a bug — it is a feature for organizational use. But users should know this.

Database security. All conversations are stored in a single SQLite file. If the server is compromised, all users’ conversations are exposed. Encrypt the disk. Restrict access. Back up securely.

HTTPS is critical. If you deploy Open WebUI without HTTPS, conversations travel over the network in plain text. Always use TLS. See our deployment guide for HTTPS setup.

Shared model context. When multiple users chat with the same Ollama model, their requests are processed by the same model instance. The model does not retain context between requests, so there is no cross-user data leakage through the model itself. But Ollama server logs may contain prompts from all users.

Summary Comparison

Tool	Telemetry	Opt-in/Out	Open Source	Conversation Storage	Network (Inference)
Ollama	None	N/A	Yes (MIT)	None (API only)	Zero
LM Studio	Analytics	Opt-out	Partial	Local DB	Zero
Jan	None	N/A	Yes (AGPL)	Local JSON files	Zero
GPT4All	Research data	Opt-in	Yes (MIT)	Local DB	Zero
Open WebUI	None	N/A	Yes (MIT)	Server SQLite	Zero*

*Open WebUI’s privacy depends on deployment configuration (HTTPS, access control, server security).

The Bigger Picture: What “Local” Actually Means

All five tools keep your AI inference local. Your prompts and responses are processed on your hardware. No cloud AI provider sees your data during inference. This is the core promise, and all five deliver it.

But “local” has layers:

Layer 1: Inference. All five tools run inference locally. Your prompts are not sent to an AI company.

Layer 2: Telemetry. Some tools report usage metadata (not conversation content) to the developers. This is standard in software but worth knowing about if you care about not even your usage patterns leaving your machine.

Layer 3: Model downloads. Every tool needs to download models from somewhere. The download servers see your IP address and know which models you downloaded. If you need to hide even this, you need to download models on a different network or machine and transfer them manually.

Layer 4: Network exposure. If you run an AI tool that listens on a network port (Ollama’s API, Open WebUI’s web interface), other devices on the same network can potentially access it. “Local to your machine” and “local to your network” are different threat levels.

Layer 5: Local storage. Conversations stored locally are private from the network, but not from anyone with physical or remote access to your machine. Full-disk encryption is the baseline for any privacy-conscious setup.

Recommendations by Threat Level

”I just don’t want my data training someone else’s model”

Use any of these tools. All five keep your inference data out of cloud AI training pipelines. Ollama + Open WebUI or LM Studio are the easiest to set up.

”I don’t want any data leaving my machine”

Use Ollama (no telemetry) or Jan (no telemetry, open source). Disable update checks. Download models on a different network if needed. Bind Ollama to localhost only.

”I’m working with regulated/classified data”

Use Ollama on an air-gapped machine (no network connection at all). Pre-download models and transfer via USB or internal network. Do not use tools with any telemetry, even optional. Encrypt the disk. Implement access controls. Consult your compliance team — this article is not legal advice.

”I need to prove our AI setup is private (compliance/audit)”

Use open-source tools exclusively (Ollama, Jan, GPT4All, Open WebUI). The open-source code is your evidence. Document your configuration. Network monitoring logs from Wireshark or equivalent provide proof of no data exfiltration. Avoid LM Studio for compliance scenarios due to the proprietary license limiting full code audit.

What We Want to See Improve

Telemetry should always be opt-in. No exceptions. If your tool’s value proposition is privacy, defaulting to data collection — even innocuous data — undermines your own message.
Privacy documentation should be prominent. Not buried in a wiki page or FAQ. A clear, honest statement of “here is exactly what leaves your machine and when” should be in the README and on the website.
Ollama needs authentication. The lack of any authentication on Ollama’s API is a genuine security concern for anyone running it on a network. Even a simple API key mechanism would help.
Encryption at rest. None of these tools encrypt their local data stores. If your machine is stolen, your conversations are readable. Tools should at least offer optional encryption for conversation storage.
Audit logging. For organizational deployments, tools should log who accessed what and when, with the ability to export audit trails for compliance.

The local AI ecosystem has made incredible progress on the core promise of private inference. The next frontier is making the entire stack — not just the inference — meet the privacy expectations that users bring to “local AI.”

We plan to repeat this audit semi-annually as tools evolve. If you find something we missed, or if a tool has updated its practices since this audit, let us know through our community page.