A 3.6% disclosure rate measures visibility, not model safety

A SemiAnalysis census examined 857 releases from nine Chinese AI developers between 2021 and 15 September 2026: 741 product releases and 116 research releases. The researchers searched model cards, release notes and technical reports for safety-evaluation results tied to the named model version. They found public results for 31 releases, or 3.6%.

Only nine releases, 1.1% of the full set, disclosed results at or before launch. Sixteen published them later, with a median lag of 42 days and a maximum of 349 days. The remaining six are accounted for by the study’s other timing categories. Reuters reporting independently describes the census and its strict release-level definition.

The denominator is the important part. The unit is a release, not a company, model family or test. A disclosure counted only when a public result could be connected to that exact named version. A corporate safety page, policy, generic benchmark or result for a predecessor did not fill the cell. That makes the measure useful for procurement evidence: can a buyer inspect what was reported for the exact artefact being considered?

It does not answer a different question: was the model privately tested, or is it safe? The study could miss non-public evaluations and cannot compare undisclosed results. Public disclosure can also be selective, use different tests or omit operational conditions. A release with a result is not automatically safer than one without it. The work is one research firm’s census rather than a regulator-maintained registry.

The timing split adds a second decision variable. A result published 42 days after launch may help later users but cannot support the original launch decision. Conversely, a result available by launch can still be too generic for a specific deployment. Procurement should retain both the result date and the decision date, rather than converting every eventual disclosure into an “available” flag.

Different release cadences can also distort company comparisons. A developer shipping many named variants contributes more rows than a developer bundling changes under one version. Compare like-for-like release types and report product and research releases separately before drawing a trend conclusion. The source counts visibility events; it does not normalize the commercial importance, user population or risk of each release.

Reproduce the denominator for your shortlist

For each candidate model version, create a release-level row with launch date, exact identifier, evaluation name, result date, test owner, method, operating conditions and link. Record “not found” rather than carrying evidence forward from a related version. Separate three states: disclosed by launch, disclosed later, and no public result found.

Then add a second layer for evidence quality: independent or vendor-run, method available or absent, reproducible or not, and relevant or irrelevant to the intended workflow. This prevents the disclosure denominator from becoming a false ranking. Use it as an evidence-availability gate alongside a local evaluation, incident history and the human-in-the-loop AI skill.

The immediate decision is not whether to reject 96.4% of releases. It is whether a buyer can explain which release-specific safety evidence exists, what it measures, what remains private or unknown, and what local test will cover the gap.