Executive Summary

Read the data section of the MAI-Thinking-1 technical report and the first surprise is its specificity. Microsoft wrote that it used the open-source extractor Trafilatura to pull body text from web HTML, and that it stripped out adult and piracy domains with the University of Toulouse's UT1 blocklist. More than ten billion web PDFs were OCR'd with Azure Document Intelligence, of which only 620 million survived; 7.4 trillion tokens of GitHub code went through three layers of deduplication — exact SHA-512, fuzzy MinHashLSH, and semantic dedup using Qwen3 embeddings. STEM material was selected with seven topic classifiers, and there is even a sentence saying that mathematical expressions were solved with SymPy to confirm they were correct.

Read this far and the model looks as though it has disclosed its data-processing pipeline with unusual transparency. And at this layer, it genuinely is transparent. Know the names of the tools and a third party can reconstruct the same pipeline, reproduce the results, and verify them. The problem is what comes next. On the question of where those carefully cleaned and filtered materials came from in the first place, the same report falls silent. Which publishers supplied the books and journals, which vendors sold the STEM and coding problems, who created the human preference data — all three categories are sealed off by a single phrase: "privacy, legal, safety, and competitive reasons."

This is what the report calls the "disclosure asymmetry." What was disclosed is a list of reproducible tools; what was hidden is the list of raw materials those tools handled. The boundary splits cleanly in two. On the left are the tools the report named down to the specifics; on the right are the suppliers obscured category by category.

What matters is that the left column cannot stand in for the right. Knowing the tools is not the same as knowing the materials. Which book, from which publisher, was fed into the same OCR engine can never be recovered from eight tool names. This is not to say Microsoft hid something; on the contrary, it honestly stated that "this part will not be disclosed." But explicit silence is still silence, and from a procurement standpoint that silence remains a verification gap.

To see the disclosure asymmetry clearly, you have to treat AI data as a single supply chain and break it into layers. Just as a manufacturing supply chain divides into raw materials, processing, assembly, and packaging, training data can be split into four layers. Raw materials is where the data came from in the first place — sources like publishers, journals, the web, and vendors, together with their license terms. Refining is the tools and pipelines that clean and filter those raw materials. Processing is the actual training of the model on the refined data. Packaging is the model cards and data cards that describe the result.

The key point is that each layer differs in how far an outsider can verify it. The refining layer is made of tools, so if you know the names you can reproduce it. The raw-materials layer, by contrast, offers almost no way to confirm anything beyond the vendor's assertion. An outsider who never sees the contract can only take "we obtained it from News Corp" on faith, or not. The processing layer (training) reports scale — so many tokens on so many GPUs — but how the data was actually mixed cannot be reproduced, and the packaging layer (model cards) is a document the vendor writes itself, so if the upstream is opaque that account cannot be verified either. Set the four layers against their verifiability and the pattern is plain: what MAI disclosed is the verifiable refining layer; what it hid is the unverifiable raw-materials layer.

What the diagram says is simple. The layer a vendor discloses most confidently (refining) happens to be the only one an outsider can confirm for themselves, and the layer a procurement team most wants to know (raw materials) happens to be the one with no way to confirm anything beyond the vendor's word. Disclosure and the need for verification are precisely misaligned. So the impression that "they disclosed the tools, therefore they are transparent" becomes an optical illusion that hides the very raw-materials layer where the risk is concentrated.

Microsoft's grounds for hiding the sources came down to four words: privacy, legal, safety, competitive. Take those reasons as one bundle and the conversation ends at "well, it can't be helped." But pull them apart one by one and they carry very different weights of justification.

3.1Privacy: partly legitimate

If the aim is to protect the individual labelers who produced the human preference data, or a particular corpus laced with sensitive information, then privacy is a genuine reason. But that is a logic for shielding individuals, not for hiding institution-level sources (which publisher, which database) wholesale. The mere fact that "we signed a deal with this journal" does not violate anyone's privacy.

3.2Legal: a defense that doubles as verification-avoidance

The worry that disclosing sources makes you an easy target for copyright litigation is real. Training-data provenance has indeed been the central issue in lawsuits over the past few years. But that is precisely the problem. The logic "we don't disclose because disclosure invites lawsuits" is, flipped around, also a signal that "sources may have been used that cannot be disclosed." Non-disclosure justified by legal risk does not protect the buyer; it comes closer to burying that risk where the buyer cannot see it.

3.3Competitive: it works only selectively

The weakest shield is "competitive." The claim that a data-procurement strategy is a trade secret is understandable, but the logic is strikingly inconsistent. First, the existence and price of licensing deals are already out in the open. Reddit–Google at roughly $60M a year, News Corp–OpenAI at over $250M across five years — both surfaced in the press and in disclosures. When the existence of a contract is public but only its contents are a trade secret, that is a selective application of the competitive rationale. Second, MAI used a third-party open model (Qwen3-Embedding-0.6B) as a pipeline component while asserting "no third-party model distillation" — circumstantial evidence that what gets guarded as competitive advantage and what gets disclosed is decided by convenience, not principle.

The power of third-party audit does not stop at reconstructing a list. When the Data Provenance Initiative went through more than 1,800 datasets one by one, it was not uncommon to find that the license recorded in a repository was actually stated more permissively than the real terms allowed. In other words, even data believed to be openly available can carry a narrower actual scope of permission than its label suggests — and the audit later widened to datasets from hundreds of organizations across dozens of countries. That a great deal of source and license information surfaces when examined from the outside, even without the vendor disclosing it, has now been confirmed repeatedly. The evidence that there is no reason it cannot be disclosed keeps accumulating.

And this non-disclosure is no aberration unique to MAI. Stanford's Foundation Model Transparency Index shows that the data-related sub-domains (data acquisition, data properties) scored the lowest in the industry for three straight years starting in 2023, and "data access" transparency actually retreated from 20% in 2023 to 7% in 2024, with legal-risk concerns cited as the cause. Overall participation in the index also fell, from 74% in 2024 to 30% in 2025. Hiding sources is not the exception; it is the direction the industry is collectively backing into.

The story so far has been about the vendor's choices. Now turn the lens to the buying side. When a legal, procurement, or compliance officer adopting an AI model or dataset hears the vendor say "our data is fine," how do they verify it? In theory there are several instruments. You can write an audit right into the contract, demand a datasheet or data card, bring technical means like membership inference to bear, or lean on third-party certification and representations-and-warranties clauses. The problem is that every one of these instruments has sharp limits.

What this table shows coldly is that most of the tools in a procurement team's hands never reach the raw-materials layer. The audit right audits only what was chosen to be disclosed, membership inference cannot reconstruct composition, and certification looks somewhere else. Which is why the numbers come out the way they do. According to Kiteworks's 2026 survey, 77% of organizations cannot trace the provenance of their training data, and 78% cannot verify data before it enters the pipeline. (As a vendor-published survey it should be read as an estimate, but it is the most direct public figure quantifying the inability to verify.)

When verification fails, the risk does not disappear. It is quietly transferred to the buyer. If a source turns out to be illicit, retroactive copyright liability spreads to the buyer, and regulatory exposure — such as the EU AI Act's training-data summary obligation for general-purpose AI — also becomes the buyer's burden. When only the vendor knows the data lineage, neither audit nor retraining is possible (non-reproducibility), and what remains is a dependence in which nothing can be done without that vendor. These four transfers are exactly what "buying provenance you cannot verify" means in practice.

It would be inaccurate to cast MAI as a uniquely opaque exception. Source disclosure is not black-and-white but a spectrum, and MAI is one point on it. At one end sits the full-disclosure camp that enumerates sources individually (OLMo, Common Corpus); at the other end are closed models that barely speak of data at all. MAI sits in between, in the "partial disclosure" band that discloses the tools while hiding the sources.

Knowing the spectrum alone is of little practical help to a procurement officer. What is needed is a questionnaire that can interrogate "where the vendor sits" layer by layer. Carry the four-layer model straight over into a checklist and, at each layer, what to demand and what can actually be verified come apart into separate columns. Knowing which layer you can demand but cannot verify — that is the heart of this table.

Regulation is moving to narrow this gap. The EU AI Act's Code of Practice for general-purpose AI (GPAI) has required disclosure of a training-data "summary" since August 2025, and Microsoft is among the signatories. But whether that "summary" stops at a list of tools or extends to a list of sources is not yet settled, and whether MAI actually published such a summary needs to be confirmed. South Korea's Framework Act on AI (in force since 2026-01-22) points the same way but leaves a similar blind spot. While regulation raises the floor, what more you can demand above that floor still comes down to the buyer's bargaining power. (For reference, estimates of the AI training-data market range widely, from $3.2B to $11.9B depending on the source; because definitions differ, any statistic that speaks of this market with a single number should be read with caution.)

This piece has moved from the start along a single distinction: the layer you can verify and the layer you cannot. What the MAI case revealed is where the boundary between what can be instrumented and documented and what cannot currently runs in the data supply chain. The refining tools are instrumented; the raw sources are not. That boundary is not a limit of technology but a choice of convention, and conventions can change.

If sources cannot be verified, then neither what a model learned nor what biases and copyright risks were seated inside it can be audited after the fact. Quality is decided upstream in the supply chain (sources and terms), not in the finished product (the model). To call something "clean" downstream while the upstream stays opaque is a declaration that has given up on verification. So the real question shifts from "is this data clean?" to "how far down this data can we instrument and document?"

Primary Sources · The Event

• 1.Microsoft AI. "Introducing MAI-Thinking-1." microsoft.ai, 2026-06-02.
• 2.Microsoft AI. "MAI-Thinking-1 Technical Report." microsoft.ai, 2026-06-02. (Data-processing tools named · original text of the "privacy, legal, safety, and competitive" non-disclosure rationale)
• 3.Kili Technology. "Data Story: Microsoft MAI-Thinking-1." kili-technology.com, 2026.

Data Documentation · Transparency (Academic)

• 4.Gebru, T. et al. "Datasheets for Datasets." Communications of the ACM, 2021 (arXiv:1803.09010).
• 5.Pushkarna, M., Zaldivar, A., Kjartansson, O. "Data Cards: Purposeful and Transparent Dataset Documentation." FAccT 2022 (arXiv:2204.01075).
• 6.Longpre, S. et al. "The Data Provenance Initiative: A Large Scale Audit of Dataset Licensing & Attribution in AI." arXiv:2310.16787, 2023 (Nature Machine Intelligence, 2024).
• 7.Bommasani, R. et al. "The Foundation Model Transparency Index." Stanford CRFM, v1.0 2023 / v1.1 2024 (2025 ed. arXiv:2512.10169).
• 8.Shokri, R. et al. "Membership Inference Attacks Against Machine Learning Models." IEEE S&P 2017 (arXiv:1610.05820). — basis for the ceiling on external verification

Open Camp · Regulation · Market

• 9.Allen Institute for AI. "Dolma / OLMo: An Open Corpus and Language Model." allenai.org, 2023– (ODC-BY).
• 10.Pleias. "Common Corpus: The Largest Multilingual Open Dataset." arXiv:2506.01732, 2025 (HuggingFace README).
• 11.European Commission. "GPAI Code of Practice — Transparency & Training Data Summary Template." digital-strategy.ec.europa.eu, 2025-07.
• 12.Kiteworks. "2026 Data Security, Compliance and Risk Forecast Report." kiteworks.com, 2026. (Procurement verification-failure rate 77–78% — vendor-published survey)
• 13.Columbia Journalism Review / SEC filings. "AI Content Licensing Deals: Reddit–Google, News Corp–OpenAI." 2024–2026. (Licensing-deal amounts)