A lot of developers work under a rule that sounds simple: proprietary code does not go to third-party services. It might come from a client contract, a security review, or just company policy. Whatever the source, it quietly rules out most AI tooling, because most of it assumes your code is welcome in somebody else's cloud.

If you want AI-written summaries, changelogs and release notes under that rule, you need two things: a tool that lets you choose where the code goes, and a clear picture of what it does with it before it goes there.

1. You Choose the Endpoint

gitaiflow has no AI service of its own. It talks to whichever OpenAI-compatible endpoint you configure with four settings: AI_PROVIDER, AI_API_KEY, AI_BASE_URL and AI_MODEL. The request that carries your diff goes to AI_BASE_URL, and nowhere else.

So running fully local means pointing that URL at a model on your own machine. With Ollama, it looks like this:

export AI_PROVIDER=ollama
export AI_API_KEY=not-needed
export AI_BASE_URL=http://127.0.0.1:11434/v1
export AI_MODEL=llama3.2:3b

Two details trip people up. AI_API_KEY must contain something even though Ollama ignores it, because gitaiflow refuses to start with an empty value. And AI_MODEL has to match what ollama list shows exactly.

The same four settings can live in a project .env or in ~/.gitaiflow/config.env, so you can keep the local setup as your standing default.

2. What It Filters Before Sending (and What It Doesn't)

Before any diff is built, gitaiflow always skips a fixed set of paths: .env files, a .certs folder, and its own change-summary output folder. Markdown files and common image and font formats are skipped by default, and you can add more with --skip.

On top of that, any changed line that contains a bare api_key, secret_key, private_key, access_key or client_secret is replaced with [REDACTED SENSITIVE CONTENT] before it reaches the model.

Be clear about what that is. It's a small safety net for the most common mistakes, not a secret scanner. A hard-coded password, a token stored under a different name, or a credential inside a longer identifier can still pass through. If you use a hosted provider, don't treat this filter as the thing protecting you. Running locally is.

3. What Else Leaves the Machine

Two other things are worth knowing about:

• Usage log: gitaiflow keeps a local usage log that is never transmitted.
• Telemetry: sending anonymous usage data is a separate, opt-in choice. It asks once, defaults to off in non-interactive runs, and never includes paths, diff content or summary text. gitaiflow --telemetry disable makes the choice explicit, and GITAIFLOW_TELEMETRY=false forces it off for a single run.

4. The Trade-Offs of Going Local

Local isn't free. Small models are more likely to drift from the response format gitaiflow asks for, so expect the occasional rejected summary. It won't be saved as a bad one; the next run simply tries again. Slower hardware can also exceed the default 60-second request limit, and AI_REQUEST_TIMEOUT raises it.

I'd start with the smallest model that gives usable summaries on your hardware and move up only if the quality isn't there.

Want the Full Picture?

This post covers the privacy side of the setup. The complete provider configuration, including Gemini, OpenRouter and other options, is in the gitaiflow documentation ↗.

What I'd Tell You If Your Code Can't Leave the Machine

1. Ask where the data goes before you ask what the tool does. Any AI tool should be able to tell you exactly which endpoint receives your code.
2. Treat filters as a seatbelt, not a wall. Pattern-based redaction catches common mistakes and misses unusual ones, so the real control is where the data is sent.
3. Plan for a weaker model. A local setup works best when the tool validates what the model returns instead of trusting it.