# What is intelligence exhaust? The customer-owned decision context prompts, evaluations, and corrections can expose in a rented model, and how to audit that boundary. > By Saad Bin Shafiq, Founder of Nodes ยท Jul 17, 2026 > Canonical: https://www.nodes.inc/blog/what-is-intelligence-exhaust **Answer:** Intelligence exhaust is the continuous record of prompts, evaluations, and human corrections an enterprise produces while using a rented AI model. Those interactions preserve customer decision context without serving as absolute proof that the human choice was correct. It differs from a data breach because the exposure can happen through ordinary use unlike a deliberate theft, leaving the provider with context the customer cannot independently recover. --- 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. Those interactions preserve customer decision context; they do not teach the provider's model what is correct. The exposure matters because the provider may retain a customer-owned record the enterprise cannot independently recover. 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 can cross that boundary in forms a data processing agreement does not describe. When an underwriter phrases a prompt or corrects a draft, the interaction preserves customer-specific decision context, but it does not establish that the human choice was correct or teach the model what right looks like. The exposure still matters because the provider controls the infrastructure and the resulting record. Kenneth Arrow described a version of this trade in a [1962 paper](https://www.nber.org/books-and-chapters/rate-and-direction-inventive-activity-economic-and-social-factors/economic-welfare-and-allocation-resources-invention): 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 context. In a People Decision Engine, measured outcomes are governed evidence with uncertainty rather than categorical truth or proof of an individual's success. Human decisions provide context, and a named human makes the final call. Calibration or production promotion requires validation. The 10,765-person figure belongs to the historical study cohort, not to records handled by Nodes. Enterprise talent at one Fortune 500 insurance carrier is the sole current production proof; underwriting, lending, and admissions remain ready for historical validation. Methodology: [Decision Traces](https://arxiv.org/abs/2604.19819). 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-controlled pipeline reached through a shared endpoint the buyer never sees inside. A correction is decision context; it may still leave the session and join records from other customers. Ask the vendor directly where an edited output travels after the edit and whether any customer context or calibration artifact crosses a customer boundary. A vague answer is itself the finding. Who owns the evaluation record and calibration artifacts linked to those corrections? This is the question that ends the audit, because customer context and governed measured outcomes should remain customer-owned. Your company should hold any resulting weights and validation record, with an exit right if the relationship ends. Human corrections remain context rather than lessons taught to a model, and most contracts signed for convenience independent of architecture fail to state who owns that record. 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 decision context is hardest to replace. A retailer's chatbot corrections preserve context about how a reviewer applied a return policy. At an insurance carrier, an underwriting correction can preserve why a reviewer read a specific risk differently; it does not by itself teach a model how the book behaves. Only governed measured downstream outcomes can support evaluation of a later calibration candidate. The density of the record 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. It argues for keeping human review as customer-owned decision context and linking it to governed measured downstream outcomes inside the enterprise boundary, preventing the exposure of that record through a product 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 that builds the boundary into the infrastructure. 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](https://csrc.nist.gov/pubs/sp/800/207/final): proximity to a boundary is not a reason to trust a request, evidence is. Intelligence exhaust applies the same standard to inference that NIST applied to 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 calibration artifacts have to be the enterprise's property. Human corrections remain decision context rather than judgment compressed into weights. When governed measured downstream outcomes support a validated customer-specific calibration candidate, [customer-owned weights](/blog/intelligence-compounds-data-stays) and the evaluation record remain inside the customer's environment, with an exit right if the relationship ends. The customer-owned record has to remain inside the boundary. Every approval, edit, and decline preserves decision context; none is training signal or proof that the human choice was correct. Governed measured downstream outcomes may support evaluation of a later customer-specific calibration candidate, but every candidate requires validation and named-human promotion, and improvement is not assumed. I wrote the full case for this shape in [the reverse information paradox](/blog/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](/blog/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](/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](https://www.nber.org/books-and-chapters/rate-and-direction-inventive-activity-economic-and-social-factors/economic-welfare-and-allocation-resources-invention) [NIST Special Publication 800-207: Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) *Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.*