Enterprise AI - Your best people are training someone else's AI.
Last week, Satya Nadella published a piece on what he calls the Reverse Information Paradox, and it named the leak precisely. It isn’t the data you upload. It’s the exhaust: your prompts, your corrections, your evals, draining into someone else’s model as you use it. His fix is a trust boundary plus five disciplines, the last of which he calls Compound: build a learning loop that accrues to your firm rather than someone else’s. I think that is exactly right. This post takes up the question he leaves open, which is what such a loop is actually made of. Because every time your best person corrects the AI (“no, that’s not how we handle this account,” or “no, the real cause was the valve, not the pump”), that correction is knowledge nobody had written down before. It helped once, it went into a chat log, and next quarter someone will work it out again from scratch.
What's happening
You already gave your expertise away once, with ChatGPT
Think about ChatGPT two years ago. Remember how stiff and wrong it often was, and how much sharper it is now. Most of that came from bigger models and better training. But part of it came from us. Every rephrased prompt, every thumbs-down, every time someone showed it a better answer became signal these systems learn from. Hundreds of millions of people spent two years teaching it, and not one of them owns a piece of what it learned.
Why it matters
Now your company is doing it, one correction at a time
Now run it inside your company, where the corrections aren’t trivia but your actual expertise. The loss is invisible by construction. It happens a little at a time, so no single day feels costly, and nothing on your bill ever names it. You are being charged in expertise instead of dollars, and that charge is invisible.
Picture a team using an AI assistant for a year. Every day they correct it. They tell it which answers were wrong, which edge cases matter, which shortcuts blow up in practice. Each correction is small. But stacked over a year, those corrections are the team’s hard-won judgment, expressed for the first time in a form a machine could actually use. And in most setups today, nothing keeps them.
So you end up in a strange trade. The better your people make the AI, the more of your edge you’ve handed over, and the more indispensable the vendor becomes. You are paying for the tool with money, and paying again with the expertise that made your business worth defending. That is the paradox Nadella named. The question this post is about is narrower and more practical: what would it take to keep that learning on your side of the line?
Why the obvious fix fails
Self-hosting solves where the model runs, not what your company learns
The obvious fixes each solve a different problem. Self-hosting settles where the model runs and who can see the data, which is real, but it does nothing about whether anything accumulates. Private fine-tuning leaves you owning weights nobody can read, retrained every time the base model updates. And documentation goes stale in a quarter, assuming anyone writes it.
So set the bar first, before anyone sells you an answer. A real fix has to do three things.
- Learn from all your decisions, not a handful. The rule that matters is rarely the one in the policy document, and it changes too often to write down.
- Improve without shipping your knowledge out. Your experts correct the LLM all day; those corrections should end up somewhere you control.
- Keep the learning when you switch vendors. If a new provider means starting from zero, you were renting it.
Put side by side, none of this requires new infrastructure. It requires writing different things down.
So which of the available approaches clears that bar? There are three common ways to make AI useful in your business, and each one fails a different test.
The third one deserves a closer look, because thoughtful teams build it and it is not obviously broken. Retrieval keeps your data where it belongs, and context length is not the issue: four thousand rows fits in a modern prompt. The problem is what happens next. It reads them and writes you a paragraph. If the cases it retrieved happen to be enterprise accounts that renew regardless, you will be told credits work, and you will believe it. Reading is not measuring.
Ownership is the test most approaches quietly fail. Ask any vendor what happens to everything the system learned about your business the day you leave. If the answer is that it stays in their model, you have your answer.
How it works
One approach that passes all three: Prior-Data Fitted Networks
Prior-Data Fitted Networks sidestep all three, and not by being more private but by rehearsing the task against a data generator: an endless stream of tables, each sampled fresh with a different hidden rule the model is scored on discovering. One task, throughout. Call it task intelligence.
Where the name comes from: that data generator is the prior. Not a stored dataset but a process that keeps producing new problems, which is why the model cannot memorise any of them. Prior-Data Fitted: fitted to data drawn from a prior.
Take Prior Labs’ TabPFN, the tabular one, since it is the one with published results in Nature. Its second version ran that single exercise on 130 million generated datasets.
The task, concretely: here are 4,000 past disputes with what was done and how each one ended. Here is a new one. What happens if we issue a credit?
None of that rehearsal used real company data, so nothing about any business is inside the finished model. What survives is not knowledge but a competence, and your decision log is just another unfamiliar table. The output is an estimate with uncertainty rather than a confident sentence, because what the model converges on is an approximation of Bayesian inference in a single forward pass.
Three caveats worth stating precisely. Correcting a chatbot does not retrain it; weights change through fine-tuning, or through a provider training on usage data, which most enterprise agreements exclude by default. The no-leak property holds only if you run the PFN yourself, since calling a hosted one sends your table in the request. And this only works for decisions that reduce to rows and columns. Plenty of judgment does not, and for that part of the problem the honest answer is that nobody has solved it yet.
And the table can lie to you. If your people only logged the cases that went badly, or only the ones someone remembered to write up, the pattern the model finds is a pattern in your record-keeping rather than in your business. Selection bias does not announce itself. It also helps if outcomes land quickly. A billing dispute resolves in a week, so the loop closes. A hiring decision or a plant retrofit may not reveal whether it worked for two years, and a table with a two-year lag compounds very slowly. None of this is fatal, but it decides which decisions are worth logging first.
Growth also has a ceiling. TabPFN v2 works over roughly ten thousand rows of context and the current release stretches that to fifty thousand; past the limit you subsample or chunk. Published scaling work finds accuracy flat to improving as the table grows, and on some problems it keeps improving well beyond the pretraining limit, but on others it saturates early because the extra rows are redundant given the prior. So a bigger table is usually better and never worse, which is not the same as always better.
How far it goes
One paradigm. A model for each problem class.
Something worth being clear about, because it changes how far this goes. A PFN is not a model. It is a recipe: define a prior over a class of problems, generate an endless stream of draws from it, rehearse on those, and ship something that infers at read time. What the finished model can do is decided entirely by what it rehearsed on.
Which means the prior is the variable. Change what the generator produces and you change what competence comes out the other end, without changing the training paradigm at all. That is not a thought experiment. There are now well over a hundred papers doing exactly this across seven or eight distinct problem classes.
So what
Smarter, or just more dependent
Nadella asked the right question and named the right goal: a loop that compounds inside your own boundary. What he left open was what the loop is made of. The answer, at least for decisions that fit in a table, is not a model that learns you better. It is a model that does not learn you at all.
The model stays fixed. The company gets smarter.
Your people decide, the outcome lands, the case becomes a row. The model reads that table, answers, and forgets. Nothing about your business is ever written into anyone’s weights, because the only thing accumulating is evidence you already own. That is the loop, and it is the reason it can compound on your side of the line rather than someone else’s.
Strip away the mechanism and the difference is one sentence.
You are going to spend the next three years correcting AI systems either way. The only question is whether, at the end of it, your company is smarter or just more dependent.
Two things worth doing this quarter, neither of which requires buying anything. Pick one decision your team makes repeatedly and start logging the situation, the action, and the result. Not a platform, just a table. And ask whoever sells you AI a single question: on the day we leave, what happens to everything the system learned about our business?
If you think I have this wrong somewhere, I would like to hear it.
Conclusion
Building on Satya Nadella’s The Reverse Information Paradox (July 2026), and on the tabular foundation model work of Prior Labs (TabPFN). The paradox and the exhaust framing are Nadella’s; the proof that prior-fitted, adapt-by-inference models work in production is theirs; the argument that the same substrate should be pushed from prediction into decisions is mine. I work on causal foundation models for industrial operations, so treat the enthusiasm accordingly, and the argument on its own terms.
Ready to transform the way you solve business challenges?
ProfitOps doesn’t just flag what will fail. It finds the root cause, recommends the intervention, and gets smarter with every plant you add so your operations outlast the experts who built them.
Shravan Talupula
Founder, ProfitOps
