Local AI privacy

The direct answer

A workflow is meaningfully local only when the model inference, embeddings, retrieval, document storage, chat history, and required tools stay within the boundary you intend. Optional remote features do not become local merely because the user interface is installed on your computer.

Start with a single-machine, loopback-only setup. Use explicitly local model and embedding endpoints. Keep sensitive files outside synced folders. Disable remote providers, web search, plugins, and tools until each one has a defined reason and data path.

Map the workflow before using sensitive material

1. Write down every component. Include the desktop app or browser UI, model runtime, chat model, embedding model, vector database, parser, OCR tool, reranker, plugins, and storage locations.
2. Identify every provider. Confirm whether each endpoint is on the same machine, another machine you control, or a third-party service.
3. Trace every data type. Prompts, uploaded files, extracted text, chunks, embeddings, answers, logs, crash reports, telemetry, and API keys can follow different paths.
4. Check storage and retention. Find chat databases, model files, document indexes, temporary files, backups, sync, exports, and deletion behavior.
5. Check network binding. Distinguish loopback-only services from LAN or internet exposure.
6. Test the real workflow without outbound access. Pre-download required models, disable remote features, and verify that the intended task still works.

Where “local” workflows commonly stop being local

Single-machine private setup

For a straightforward confidential-document workflow:

1. Download the model from a known source before introducing sensitive files.
2. Run the model and embedding service on the same machine.
3. Bind local services to loopback unless another device genuinely needs access.
4. Store source documents, chats, and indexes outside consumer sync folders.
5. Disable remote providers, web search, plugins, and external tools.
6. Import one non-sensitive test document and confirm extraction, retrieval, and deletion behavior.
7. Block outbound network access temporarily and repeat the actual workflow.
8. Document the final configuration so an update or new user does not silently change the boundary.

What success looks like: the intended model and document workflow continues to function with outbound traffic unavailable, and you can identify every stored copy of the source, extracted text, index, chat, and export.

Browser interfaces and remote access

A browser interface can be entirely local, but the browser, backend, and model provider are separate layers. The browser reaching the interface does not prove that the backend uses a local model or that document processing stays on the host.

Keep single-user services on loopback where practical. For LAN or remote access, decide who can connect, how they authenticate, whether transport is protected, where logs and uploads are stored, and which ports are exposed. Do not broaden a bind merely to work around a connection error.

Documents, embeddings, and deletion

Deleting the original PDF may not remove extracted text, chunks, embeddings, vector indexes, thumbnails, temporary files, chat citations, backups, or exports. Find the application’s actual storage locations and test deletion on a harmless document.

For important work, the answer should expose the retrieved passage or page. That is not a status badge; it is part of the document workflow itself and lets the reader see what the model used.

When the local path is the wrong answer

A local setup is a bad choice when the machine cannot run a model capable of the task, the organization cannot maintain the software and storage boundary, required collaboration needs controlled central services, or the workflow depends on external tools that cannot be removed. Use a controlled remote system deliberately rather than pretending a hybrid workflow is entirely local.