Map the complete data flow

Running the weights locally removes one network dependency. It does not prove the complete application is private.

Draw every place data can travel:

input -> application -> local model -> output
   |          |              |          |
 logs     telemetry       tools      backups

A local agent may call web search. A desktop application may send crash reports. Your own application may log prompts to a hosted service. A backup may copy generated files to cloud storage.

Classify the data before choosing the model. Decide which fields may enter prompts, which must be removed, how long outputs remain, and which tools may receive derived information.

Bind a local server to the smallest network boundary possible. Add authentication and isolation when several users or devices share it. localhost is a good default for Ollama during development. A shared office server is a different threat model.

Privacy is a property of the whole data flow, not a label attached to the model.

My advice is to write a one-page data map before legal or security reviews. List sources, destinations, retention, and who can read logs. “We use local AI” is one line in that page, not the whole page.

Redact before you log. If you must log prompts for debugging, strip names, account IDs, and free-text notes the user did not intend to leave the machine.

When you add tool calling, extend the diagram. A read-only calendar tool still exports derived text back into the prompt. That text may later appear in telemetry if you are not careful.

Try this on your own project: trace one summarizer request from button click to stored output and mark every hop that could leave the device. Fix the surprises before you call the feature private.