One of the reasons people run local AI is privacy. But local AI logs quietly undermine that goal. They grow fast, they contain more sensitive data than most people realize, and they are almost never cleaned up.
Here is a practical policy for managing them without losing the debugging value you actually need.
—
What is actually in your logs right now
If you are running Ollama, LM Studio, or a local OpenAI-compatible server, your logs probably contain some combination of:
- Full prompt text, including anything the user typed
- Full model responses
- System prompts, which often contain configuration details or persona instructions
- File paths from tool calls or RAG pipelines
- API keys passed as headers or query parameters in debug output
- Timing data, model names, and request metadata
The prompt and response content is the sensitive part. If you are using local AI to process documents, emails, or anything personal, that content is sitting in plaintext log files, often in a system directory with broad read permissions.
Most people have never looked at these files. Worth doing once just to know what is there.
—
The minimum you actually need for debugging
Not all log data is equally useful. Here is what genuinely helps when something goes wrong:
Timing data. Request start time, time to first token, total generation time. This is how you diagnose latency issues and spot model loading problems.
Model and parameters. Which model was called, context length, temperature, and any stop tokens. You need this to reproduce behavior.
Error codes and messages. Full error text when a request fails. This is non-negotiable for debugging.
Request IDs. A unique ID per request so you can correlate log lines across a multi-step pipeline.
What you do not need for most debugging: the full prompt and response content. You can reproduce problem prompts manually. Storing them in logs adds privacy risk without adding proportional debugging value for the common cases.
—
Automatic redaction patterns
If you cannot change your logging configuration to exclude prompt content, redaction is the next best option. These are the patterns worth catching:
API keys in debug output. Match on common patterns: sk-, Bearer, Authorization:. Replace the value with [REDACTED]. This catches the most dangerous leak.
File paths. Replace absolute paths with relative ones or a placeholder. Full paths reveal directory structure and usernames.
Email addresses and phone numbers. Standard regex patterns cover most cases. Worth adding if your prompts process contact data.
Long text blocks. Any string over 500 characters in a log line is almost certainly prompt or response content. Truncate to the first 100 characters plus a [truncated] marker. You keep enough context to know what the request was about without storing the full text.
For Ollama specifically, the log level can be set with the OLLAMA_DEBUG environment variable. Leaving debug logging on in production is the single fastest way to accumulate sensitive data you did not intend to keep.
—
A simple retention policy
The default for most local AI setups is: logs are kept forever, because nobody configured rotation.
A practical policy:
- Error logs: 30 days. You rarely need to debug something older than that.
- Performance/timing logs: 7 days. Useful for spotting recent regressions, not historical patterns.
- Full debug logs: 24 hours maximum, and only when actively debugging a specific issue. Delete them when done.
Automate this with a cron job or logrotate. Here is a minimal logrotate config:
/var/log/ollama/*.log {
daily
rotate 7
compress
missingok
notifempty
}
For logs in non-standard locations (LM Studio stores them in ~/Library/Logs on macOS, for example), find them once, note the path, and add them to your rotation config.
—
The bigger picture
Running local AI is not automatically private. It is private by default from external services, but only as private as your local disk hygiene.
The three actions that make the biggest difference:
- Turn off debug logging unless you are actively debugging
- Add logrotate or equivalent with a 7-day max retention
- Check your log directories once a year to make sure nothing unexpected is accumulating
None of this is hard. It just does not happen automatically.
What logging setup are you running? Curious whether anyone has a more automated redaction pipeline they would recommend.
