Where Does Your Code Go? AI Code Review Data Privacy, Explained

Every AI code review is, mechanically, an act of disclosure: a diff from your private repository is packaged up and sent somewhere else to be reasoned about. That is not a scandal - it is how the tools work - but it does mean the interesting privacy question is never whether code leaves your walls. It is exactly what leaves, where it lands, how long it lives there, and who else gets to see it on the way.

Vendors answer those questions with wildly different levels of honesty and precision. This guide is the checklist we wish every engineering team ran before switching on any reviewer - including ours.

The Four Hops Your Code Can Take

Trace a single review and there are at most four places your code can travel. Map them for any tool you evaluate and the privacy picture snaps into focus.

Hop one: the vendor's servers. Cloud review tools fetch your repository or your diff to orchestrate the review. Ask what is fetched - the diff alone, or a clone - what is cached between reviews, and what the deletion window actually is. A tool that keeps embeddings or file snapshots to speed up future reviews is keeping your code.

Hop two: the model API. The diff plus supporting context goes to a large language model - the vendor's own deployment, or a provider such as Anthropic or OpenAI. This hop is governed by a different company's retention terms than the tool you bought. If the vendor cannot tell you which model tier and which retention mode their requests use, that silence is your answer.

Hop three: logs and telemetry. Findings quote your code. Review comments, dashboards, error trackers, and analytics events can all end up holding fragments of source. Ask where findings are stored, who can read them, and whether debug logging captures prompts.

Hop four: subprocessors. Vector databases, queues, error reporting, analytics - each one is another data processing agreement you inherit silently. The subprocessor list in the vendor's DPA is the least-read, most-informative document they publish.

The Questions That Separate Marketing From Reality

Six questions cut through most datasheets. What exactly is sent per review - diff, files, or clone? What is cached or embedded between reviews, and for how long? Which model provider, tier, and retention mode serve our requests? Where do findings and quoted snippets live, and who can read them? Which subprocessors touch the pipeline? And what happens to all of it when we leave?

Zero Retention Is a Configuration, Not a Default

The phrase we do not train on your code is doing less work than it appears to. Training is only one use of retained data. The questions that matter are narrower: is the request retained at all, for how long, in whose logs, and under which agreement?

The major model providers all offer API tiers or agreements that exclude training on customer content, and several offer zero-retention modes for enterprise customers. But those are configurations someone must actually turn on. Make the vendor state, in writing, the retention mode of the exact API tier their product uses for your account - not the best mode the provider offers somewhere in its catalogue.

Data residency belongs in the same conversation. If your compliance regime cares where processing happens, ask which regions the vendor's infrastructure and their model provider actually run in - and whether that is configurable or just marketing prose.

The Self-Hosted Shortcut

Self-hosting collapses most of the map. When the orchestrator, the queue, the findings store, and the logs all run inside your own network, hops one, three, and four stop being another company's problem and become ordinary infrastructure you already govern. What remains is the model API - a single, visible, contractual hop. Our guide to self-hosted AI code review covers the architecture in depth.

Bring-your-own-keys narrows it further: with BYOK, review requests run under your organisation's own agreement with the model provider, on the tier and retention mode you negotiated - not on terms you cannot see. This is the architecture PURA is built around: everything self-hosted, reviews running on your keys, nothing persisted outside your network.

Privacy Questions Double as Security Questions

Every hop your code takes is also attack surface. A vendor holding clones of a thousand companies' repositories is a prize target; a reviewer that feeds untrusted PR text to a model is exposed to prompt injection; a findings store outside your control is a breach you cannot detect. The same map that answers the privacy question tells you how much security you are inheriting from someone else.

A One-Afternoon Privacy Review

None of this requires a procurement office. Draw the four hops for each tool on your shortlist, using the DPA and subprocessor list rather than the landing page. Get the retention mode of the model tier in writing. Decide which repositories are allowed through the pipeline at all - a public SDK and your crown-jewel monorepo do not deserve the same policy. Then revisit the answers quarterly, because providers change terms faster than annual reviews catch.

The teams that get this right are not the ones that banned AI review - they are the ones that can answer, in one sentence, where their code goes. After an afternoon with the map, you will be one of them.