The AI Training Question Your Vendor Can't Answer
The Navier-Stokes dispute between OpenAI and the mathematicians who paved the route is being read as a story about credit. Read it instead as the clearest public demonstration yet of what it costs to do your most valuable thinking inside somebody else's model.
On September 8, one of the Clay Mathematics Institute's seven $1 million Millennium Prize problems appeared to fall.4 OpenAI announced that an unreleased internal model had produced a full proof of Navier-Stokes existence and smoothness, a problem that has stood for roughly ninety years; the run took 88 hours3 and about $22.5 million of compute at list rates.2 The same day, an NYU mathematician named Tristan Buckmaster published a four-page statement describing the days that led up to it.1
Most coverage treats this as a story about credit: who deserves the prize, who was rude on which call.6 That reading undersells it. Buried in OpenAI's written response is one sentence that matters to any company that does its thinking with AI tools, and it deserves a closer look than the drama around it. Let's walk the timeline first, then name the actual problem, then get concrete about the one architecture that makes the problem go away.
What happened, in order
Buckmaster and his collaborator Levent Alpöge spent about a year on finite-time blowup for the fluid equations; Alpöge is a mathematician at Anthropic, and the project was independent of his employer.1 The reconstruction below follows Buckmaster's public statement and contemporaneous reporting. OpenAI disputes parts of his reading, and where the accounts differ, the rows say whose claim is whose. The rows start expanded; collapse them to skim the shape of it.
A year of work, five days of dispute
- 2025
- Aug 15
- Aug 22
- Sep 1
- Sep 3
- Sep 6
- Sep 6-7
- Sep 8
- Sep 8
Three numbers carry the asymmetry:
Notice what the numbers don't say. They don't say the model trained on the pair's sessions; that remains unknown, and OpenAI denies its researchers saw the work before release.2 What they do say is that once a frontier lab decided this specific problem was ripe, the marginal cost of taking it was a long weekend of compute. The scarce input wasn't the proving. It was knowing what to prove and which route was live. That knowledge spent a year accumulating inside another company's product.
The custody question
Set the accusations aside entirely; assume every party behaved exactly as they say they did. Something uncomfortable is still true. For twelve months, the highest-leverage unpublished thinking in a small field sat on the servers of a company that later raced its authors, under policies the authors couldn't inspect, with recourse limited to asking politely after the fact. Here is the ask, in Buckmaster's words:
"I asked whether the model had been trained on, or had access to, our sessions in Codex, into which we had been putting all our drafts for the whole of this project. I was told the model did not look up user data. I asked again, about training, and I did not get an answer."
— Tristan Buckmaster, public statement, September 8, 2026
The written answer arrived five days later, at the end of OpenAI's public statement:
"We cannot rule out that de-identified data derived from their usage of our products helped improve our models."
— OpenAI, written statement, September 8, 2026
Call the underlying issue IP custody: who physically holds your intellectual property while you work on it, and what they're structurally able to do with it. Custody is a different question from trust. A bank doesn't ask you to trust the teller; it builds a vault, so the teller's character stops being the load-bearing element. Buckmaster's training question got a probability estimate instead of a no because the vendor's architecture makes a no impossible: the sessions lived on their systems, pipelines evolve, and de-identified derivatives travel. The sentence isn't an evasion. It's the truthful output of a system in which somebody else has custody.
One word in it deserves extra weight: de-identified. De-identification is a privacy control; it exists so a person can't be re-linked to a record once the name and the birthdate are stripped. It does nothing for a proof strategy, a trading signal, a codebase, or a term sheet, because the value of those never lived in an identifier. Privacy tooling protects who you are. It was never built to protect what you've figured out.
A policy is a promise; custody is a property
The obvious reply is that this is what enterprise agreements are for, and directionally that's right. OpenAI's published data controls draw the line plainly: consumer-tier sessions can feed model training by default, while business and enterprise tiers are excluded.5 Sign the DPA (Data Processing Agreement), set the toggles, and the leakage channel narrows to the residual in that sentence above. If your risk assessment stops there, though, it stops one step early.
First, defaults meet human behavior. It isn't public which tier those Codex sessions ran on, and that is rather the point: the answer to "was any of this trainable?" hinged on account settings, policy versions, and retention windows, none of which the authors could verify from outside. Every company has engineers with a personal account for the moments the sanctioned tool is slow, rate-limited, or missing the newest model. Your DPA doesn't cover the tab they actually had open.
Second, even a perfectly honored no-training clause closes only one of the two channels.
The second channel is signal
By OpenAI's own account, its Navier-Stokes effort didn't start from anyone's data. It started from a rumor.2 Sit with that detail, because it should worry you more than the training question, not less: a rumor was enough for a frontier lab to point an unreleased model and eight figures of compute at the exact problem two people were about to finish, on the same route, within days. No files had to move.
Now translate that to your company. The vendor running your team's AI tools can see, at minimum, where the effort goes: which product areas burn the most agent hours, which problems your strongest people keep returning to. Reading a single line of your work is unnecessary for holding its heat map. And every frontier lab is simultaneously a product company, with a research organization pointed at whatever looks valuable next. None of this requires bad faith. It only requires incentives to keep being incentives.
What owning the model changes
Owning your AI means the weights run on infrastructure you control: open models, on your hardware or in your cloud tenancy, with your logs. Let's be precise about what that buys, because it isn't magic; it's one specific inversion. Every question in this story flips from something you ask a vendor into something you can demonstrate. Did the drafts leave? No, and here's the network boundary that proves it. Could they have fed a training run? No, and here's where the tokens live and die. "Can you rule it out?" stops being a probability estimate offered by the counterparty and becomes a property of your architecture, demonstrable to a regulator, a client, or your own board.
The honest caveats belong here too. Running your own inference is real work: capacity planning, serving, evals, and upgrades don't vanish because the weights are yours. And on some tasks, the largest hosted models are still ahead. A year ago that gap was wide enough to settle the argument; it isn't anymore, and for most production workloads the open-weight frontier is now close enough that custody, not capability, is the deciding variable for sensitive work.
Nor is this all-or-nothing. The practical move is to sort work by custody sensitivity. Marketing drafts and public-documentation questions can ride hosted APIs indefinitely. The work that is the company, the methods a competitor would race you on, belongs on weights you hold. Buckmaster's mistake, if it's even fair to call it one, wasn't using AI to do frontier mathematics. It was doing vault-grade work in teller-grade custody.
Key takeaways
- 01OpenAI put it in writing: it cannot rule out that de-identified usage data improved its models. Treat that sentence as the honest end-state of every vendor training assurance.
- 02De-identification protects identities, not ideas. Methods, code, and strategy carry no name to strip, so privacy controls were never guarding them.
- 03Data never has to move for damage to occur: by OpenAI’s own account, a rumor alone aimed an 88-hour, eight-figure compute run at the exact problem two mathematicians were finishing.
- 04Custody beats policy. With open-weight models in your environment, “can you rule it out?” becomes provable by construction instead of a favor you request.
Sources
- Tristan Buckmaster, public statement, September 8, 2026, as reproduced by Prof. Edward Lee, chatgptiseatingtheworld.com (September 9, 2026): https://chatgptiseatingtheworld.com/2026/09/09/controversy-swirls-as-openai-claims-its-internal-ai-model-solve-navier-stokes-existence-and-smoothness-problem-provoking-statement-by-nyu-prof-tristan-buckmaster/
- TechCrunch, "OpenAI fought dirty on career-making math problem, says NYU mathematician" (September 8, 2026): https://techcrunch.com/2026/09/08/openai-fought-dirty-on-career-making-math-problem-says-nyu-mathematician/
- CNBC, "OpenAI claims to have solved the 90-year-old Navier-Stokes math problem in 88 hours" (September 9, 2026): https://www.cnbc.com/2026/09/09/openai-navier-stokes-math-problem-solved.html
- Quanta Magazine, "AI Has Solved One of Math's $1 Million Millennium Prize Problems" (September 8, 2026): https://www.quantamagazine.org/ai-has-solved-one-of-maths-1-million-millennium-prize-problems-20260908/
- OpenAI, "How your data is used to improve model performance," data-controls documentation, accessed September 2026: https://help.openai.com/en/articles/5722486-how-your-data-is-used-to-improve-model-performance
- Fortune, "OpenAI says it cracked Navier-Stokes, one of math's grand challenges" (September 8, 2026): https://fortune.com/2026/09/08/openai-says-it-cracked-navier-stokes-math-grand-challenge-buckmaster-accusation-cheating-intimidation-tao-lament/