Summary
- An AI usage policy is a document. Documents don't intercept requests.
- Source code leaves a company through three distinct paths, and each one closes differently. Only one of them is solved by training people.
- The easiest path to close is the terminal assistant, and most companies haven't closed it because nobody looked at the tool's default configuration.
- A local model solves the leak definitively and costs you quality. Whether that trade is worth it depends on volume, and the math is simple.
What already exists on this topic
Search for the risk of sending source code to AI and you'll find plenty. Almost all of it written by lawyers: digital-law firms, legal portals, data-protection consultancies.
The material is good at what it sets out to do. It explains Brazil's LGPD, covers international data transfer and the ANPD's Resolution CD/ANPD 19/24, warns about shadow AI. And it invariably ends at the same recommendation: write an AI usage policy and train the team.
That's necessary and insufficient, for the simplest possible reason: a policy is a document, and documents don't intercept HTTP requests. If nobody enforced the rule somewhere along the path between the developer's editor and the provider's API, the policy describes desired behavior without changing actual behavior.
The most-cited case in this space shows exactly that. In 2023, Samsung engineers pasted proprietary code and internal transcripts into ChatGPT across separate incidents. The data entered the corpus and could not be retrieved. No policy written afterwards undoes that.
This article is about the missing layer.
The three paths
Source code leaves a company through three routes, and treating them as one thing is the mistake that makes policies fail.
1. The coding assistant in the terminal or IDE
A developer installs the tool, it reads the repository and sends context to a provider. Highest volume, and the easiest to close — because it's configuration, not behavior.
This is also where the most common trap lives: the default configuration is rarely the one your company would have chosen. I've documented a concrete case in Claude Code is the best, but: OpenCode, on a default install, points both the primary and the auxiliary model at a third party's free tier. Anyone who installed it without looking started sending repository context to a provider they never chose — without violating any policy, because no policy mentioned it.
What closes it: configuration versioned in the repository, with provider and model set explicitly, and a CI check that fails the build when someone points outside the list. The rule moves to where the code lives.
2. Agents, scripts and internal automation
This is the route nobody accounts for, because it doesn't look like product: the script that analyses logs, the agent that triages tickets, the automation that summarises pull requests. Each was built to solve one specific problem, each carries its own key, and each decides on its own what leaves the building.
Why it's hard to close: you can't write policy about something you don't know exists. Unlike the previous route, here not even the list exists.
So the work has two stages, in this order.
First, survey. An inventory script scans the repository and returns call sites, providers and keys in minutes. Without that number, every decision after it is a guess.
Then, centralise. A virtual key per application instead of a real key spread around, and a single layer every call passes through — the design is in An AI gateway in 40 lines of YAML.
3. A person pasting into a chat
This is the only one of the three that genuinely is a training and policy problem. The developer opens a browser, pastes a snippet, asks for help.
What closes it: partially, policy and awareness. And more effectively, giving them an authorized alternative that's actually good. When an approved tool works well, the incentive to route around it drops sharply. Blocking without an alternative produces creativity, not compliance.
What actually keeps code from leaving
In increasing order of cost and of guarantee.
Redaction at the boundary. A layer that strips identifiers before the call leaves. I measured Microsoft Presidio against Brazilian PII and it doesn't detect the national ID out of the box — the result and the fix are in PII and language models. Works well for personal data — national IDs, emails, phone numbers — and is mandatory if customer data is in the flow. It does not solve trade secrets, because there's no way to anonymize the logic of a proprietary algorithm without destroying the question.
A contract with the provider. Zero retention, no-training clause, defined processing region. Reduces risk in a real way and rests on contractual trust — the data still leaves, you've only agreed on what happens to it. Read which tier you signed: free-plan terms usually differ from paid ones.
A local model. The data doesn't leave. It's the only option that turns a contractual guarantee into a technical one. It costs quality, hardware and operations.
When a local model is worth it
I went deeper on this in The question isn't whether a small model is good enough.
Public figures, to calibrate the math — these are not my measurements:
- VRAM rule of thumb: roughly 0.5 GB per billion parameters at 4-bit quantization.
- A dedicated GPU server in Brazil starts around R$ 3,200 per month.
- The break-even point against API pricing is commonly cited from roughly 10 million tokens per month.
The math is direct: take your monthly token consumption, multiply by provider pricing, compare to the fixed cost of the machine. Below break-even, a local model is a compliance decision, not a cost decision — and that's fine, as long as it's approved as one.
And the honest caveat: a local 7-to-14-billion-parameter model does not match a frontier model on open-ended tasks. It ties on narrow, well-defined ones — classification, field extraction, fixed-format rewriting. The right question isn't "is a local model good enough", it's "which of my tasks fit inside one".
What to do about each route
The whole post is about three routes, so the close is what to do with each.
Route 1, the assistant in the IDE. Version the configuration in the repository and add a CI check that fails the build when someone points outside the approved list. It's the easiest of the three and the highest volume.
Route 2, agents and automation. Run the inventory this week. You cannot close what you don't know exists, and the survey takes minutes.
Route 3, a person pasting into a chat. Policy and awareness handle part of it. The rest is handled by giving people an approved tool that actually works — when one exists, the incentive to route around it drops.
And the decision that cuts across all three: how far the provider contract covers you. A zero-retention clause plus versioned configuration handles most of the risk at most companies. When the requirement is that data must not leave the network, the conversation changes, and it's in where local models fit.
How we help teams adopt AI
We work with engineering teams putting AI into the real development workflow — not as an experiment, but as an actual part of how the team ships.
That means choosing the right tools for the team's context, configuring them in a way that makes sense for the company's data policy, and making sure developers know how to use them in a way that genuinely increases productivity instead of adding friction.
If you have a development team and you're trying to put AI to work seriously, get in touch.