What is intelligence exhaust?

Intelligence exhaust is the continuous trace an enterprise leaves behind while using a rented AI model: every prompt an expert writes, every evaluation a team runs, every correction a reviewer makes to a wrong answer. None of it looks like data leaving the building. All of it teaches the provider's model something about how your company thinks, and none of what it learns comes back to you.

Satya Nadella named the pattern this month in a widely read essay on the risk of renting intelligence, but stopped short of the audit: what counts as exhaust, how it differs from the data movement your contracts already track, and how to measure how much of yours has already leaked.

Intelligence exhaust vs data egress

Data egress is a term procurement teams already know how to test. A record leaves a permitted boundary or it does not. A data processing agreement names what is stored, for how long, and who may read it, and a security review can confirm the boundary holds by watching where bytes travel.

Intelligence exhaust never crosses that boundary in a form any data processing agreement describes. When an underwriter phrases a prompt, the phrasing encodes years of judgment about how she weighs a risk. When she corrects a wrong draft, the correction encodes exactly what the model got wrong and what right looks like at your company. Neither event moves a record anywhere. Both events teach the model something, on infrastructure the vendor controls, the moment the interaction happens. Kenneth Arrow described a version of this trade in a 1962 paper: a seller of information has to reveal it to prove its value, which destroys the reason to pay for it. Intelligence exhaust runs the trade in reverse, and a data processing agreement was never built to see the reversal.

The distinction matters because most enterprises test the wrong boundary. A security review confirms no customer record crossed the perimeter and calls the question closed, while the pattern behind the correction leaves anyway, carried in the same request that produced a helpful answer.

The three leak surfaces

Exhaust has three surfaces, and each carries a different density of judgment.

Prompts that encode judgment. The way a claims examiner frames a request, which details she includes and which she assumes the model already knows, is a compressed statement of what she thinks matters. Enough of those prompts and a pattern emerges that a general-purpose model can learn, and no manual describes it as well as the prompts do.

Corrections that encode expertise. When a reviewer edits a model's output, the edit is the gap between what the model produced and what an expert knows is right, made explicit. A single correction is a data point. A quarter of corrections from your best people is a curriculum, and the provider is the one enrolled in it.

Evals that encode standards. Every evaluation a team runs to check whether a model's output is good enough encodes the standard the team is holding it to: what a passing answer looks like, what a failing one looks like, and where the line sits between them. That line took years of internal disagreement to settle. An eval set hands the settled version to whoever reads the eval traffic.

None of the three requires an intruder. Each is a normal, well-run AI program doing its job: writing good prompts, catching bad output, measuring quality before shipping. The better the program, the denser the exhaust, because a careful team produces sharper corrections and tighter evals than a careless one.

The audit: where your experts' corrections go

The audit is short enough to run in an afternoon: three questions, asked in order.

Which tools do your best people correct every day? Not which tools they use. Which ones they correct: the sales copilot a top producer rewrites before every call, the underwriting assistant an examiner overrides on the risks she actually understands, the support macro a senior rep never sends without editing. Corrections cluster around your most valuable judgment, because your most valuable people are the ones with strong enough opinions to disagree with a draft.

Where do those corrections go? For most AI tools bought off a shelf, the honest answer is a vendor's training pipeline, reached through a shared endpoint the buyer never sees inside. The correction leaves the session, joins a queue with every other customer's corrections, and becomes training signal for a model every competitor in your industry can rent next quarter. Ask the vendor directly where an edited output travels after the edit. A vague answer is itself the finding.

Who owns the fine-tune those corrections feed? This is the question that ends the audit, because it has only two honest answers. Either your company holds the resulting weights, with an exit right if the relationship ends, or the vendor does, and what your experts taught it stays taught after you leave. Most contracts signed for convenience rather than architecture default to the second answer without either side stating it directly.

Run those three questions against every AI tool a senior person touches daily, and the audit produces a short list: the handful of surfaces where your highest density judgment meets a system you do not own. That list is the actual exposure. Everything else is noise.

Why it concentrates in data-sensitive enterprises

The audit matters most where the underlying judgment is hardest to replace. A retailer's chatbot corrections teach a model about return policies. A Fortune 500 insurance carrier's underwriting corrections teach a model about how a specific book of risk behaves, built from decades of claims nobody else has seen. The density of the exhaust tracks the density of the domain, and insurance, financial services, and other data-sensitive enterprises sit at the dense end.

They also sit at the end where the corrections keep coming. A data-sensitive enterprise reviews nearly everything an AI tool proposes, because the cost of one bad output is high enough to justify a human reading every draft. That review discipline is exactly what produces the richest exhaust. The instinct to check the model's work and the leak that checking creates come from the same source.

None of this argues for less review. A model nobody checks is worse, not safer. It argues for putting the review loop somewhere the resulting judgment stays with the enterprise that built it, instead of training a model any competitor with a contract can rent.

The architecture that closes the vent

An audit only tells you the size of the leak. Closing it takes a different deployment shape, not a policy layered on top of the one you have.

Inference has to run inside the enterprise's own environment, single tenant, so the interaction itself, the prompt and the correction, stays inside a boundary the enterprise controls. NIST's zero trust guidance settled a related question about network access years ago in Special Publication 800-207: proximity to a boundary is not a reason to trust a request, evidence is. Intelligence exhaust asks the same question of inference instead of network access. The interaction should not be trusted with judgment because it happens near your systems. It should be trusted because it happens inside them, on infrastructure you own.

The weights have to be the enterprise's property. A model fine-tuned on a year of corrections is worth more than the corrections themselves, because it is the corrections compressed into something reusable. Customer-owned weights mean that compression stays where the judgment came from, with an exit right if the relationship ends.

The learning loop has to close inside the boundary. Every approval, edit, and decline a reviewer makes on a proposed workflow is exhaust of the densest kind: expert judgment applied to a live decision. Route that loop through a rented model and the signal ships out continuously. Keep it inside, and the model gets better at one thing no frontier release will ever match: being that specific enterprise. I wrote the full case for this shape, and why naming the problem does not close it, in the reverse information paradox.

An enterprise that has never run the three-question audit above has no way to know which shape it is currently operating in. Score any AI vendor against the questions in the AI sovereignty diligence test before the next contract renews.

Intelligence exhaust will not stop leaking because a policy names it. It stops when the interaction itself has nowhere to go but back into a model the enterprise that produced it owns. The Nodes architecture is built around making that the default. The exhaust is already happening. Where it lands is the only question still open.

Sources

Economic Welfare and the Allocation of Resources for Invention

NIST Special Publication 800-207: Zero Trust Architecture

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.