Auditing Cross-Border AI Dependencies Under China's Large-Model Export-License Requirement

Introduction

A licensing requirement on model exports doesn't break your inference endpoint. It breaks your ability to prove what you're shipping. This guide shows how to audit cross-border AI dependencies under China's reported large-model export-license requirement: inventory every model artifact, record the licensor and hosting jurisdictions, and make CI fail when provenance is missing.

That gap is the whole engineering problem. If the reporting is right that China will require export licenses for all new large AI models, teams outside China don't wake up to a broken API. They wake up to a compliance question with no artifact behind it. Nobody wrote down which checkpoint came from which legal entity, under which contract, from which host. That stuff lives in a Slack thread and a README badge.

So treat model provenance as a build-time dependency with a jurisdiction field — and fail CI when it's missing. What follows is the audit I'd actually run, a manifest format, and a script that refuses to pass.

What the Report Says About the Export-License Requirement, and What It Leaves Open

Claims the report states plainly

The report I worked from — a secondary tech-news account aggregated in a discovery feed — says China will require an export license for all new large AI models. The same report says this could hit unreleased models, citing Moonshot's Kimi K3.1, and pairs it with Taiwan criminalizing advanced-chip smuggling to China.

Three things are worth pulling apart right away:

• The licensing regime is the story. Everything else follows from it.
• "All new large AI models" is a scope claim, not a threshold. The summary names no parameter count, compute budget, or capability trigger.
• Kimi K3.1 is described as unreleased. The report frames it as potentially affected, not confirmed affected.

Claims that still need a primary source

Here's where I stop asserting and start flagging. What I received is a secondary tech-news account; I couldn't open the underlying article or read the instrument it describes.

Each open question below changes the engineering answer:

I haven't verified the Taiwanese statute either. I only know the report characterizes it as criminalizing advanced-chip smuggling.

Distribution Risk: Weights, Hosted APIs, and Model Derivatives

Open-weight releases are irreversible under an export-license regime

An open-weight release is irreversible in a way a hosted API isn't. Once model.safetensors is on a public hub, it gets mirrored, quantized, re-uploaded, and baked into Docker images. There's no revocation path.

That asymmetry means a licensing regime aimed at new large models will probably bite at the release moment, not the download moment — because that's the only step anyone can control. That's my inference, not something the report states.

Practically, your dependency graph needs two different risk treatments: weights you distribute and weights you consume.

Hosted API access is a jurisdictional dependency, not a technical one

If you call a hosted endpoint, your artifact dependency is thin — you have no checkpoint. What you have is a contract plus a network path. A licensing change rarely severs that overnight; more plausibly, it changes terms, model availability, or which version you're allowed to route to.

The failure mode is subtler than "the API breaks." It's that the endpoint now serves a different model, or your account region gets reclassified, and your eval suite silently stops measuring what you validated.

Record the endpoint's hosting region and the licensor's jurisdiction. They're often different, and that gap is exactly what you'll get asked about.

Fine-tunes, merges, and distillations are the ambiguity layer

This is where most teams will actually get hurt. A fine-tune is a derived artifact. A merge has two lineages. A distillation has a teacher lineage that may sit under a completely different regime than the student.

If you can't enumerate the ancestors of a checkpoint, you can't answer a licensing question about it. Most teams can't enumerate ancestors today.

A Four-Step Cross-Border AI Dependency Audit

Step 1 — Inventory every model artifact and where it came from

Start with digests, not names. Names lie; sha256 doesn't.

## Pin what you actually ship
sha256sum models/*.safetensors | tee artifacts.sha256

Observed output from a small local fixture:

9f2c1a...  models/base-q4.safetensors
3b7d40...  models/finetune-v3.safetensors

Anything you can't produce a digest for is a gap, not a pass.

Step 2 — Trace provenance to the licensing entity, not the download URL

The hub URL is a distribution channel. The licensor is a legal entity in a jurisdiction. Different fields. Conflating them is the most common mistake I see in dependency spreadsheets.

Ask: who granted the license, where are they incorporated, and who signed the contract? A model hosted at a US CDN can still be licensed by a Beijing entity.

Step 3 — Classify each dependency by distribution channel

Three channels, three different control points:

• Open weights you redistribute — highest exposure; release is irreversible.
• Open weights you consume internally — medium; exposure appears if you ship a product containing them.
• Hosted API — lowest artifact exposure, highest terms exposure.

Step 4 — Record the contracting jurisdiction and the hosting jurisdiction separately

Two columns, always. A Singapore-hosted endpoint run by a US subsidiary of a Chinese parent has three jurisdictions in play. The manifest should make that legible at a glance.

Encoding the Cross-Border Audit as a Machine-Checkable Manifest

The manifest shape for model dependencies

{
"schemaVersion": 1,
"models": [
  {
    "id": "example/base-model",
    "artifacts": [
      {
        "type": "weights",
        "file": "models/base-q4.safetensors",
        "digest": "sha256:9f2c1a00b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7"
      }
    ],
    "licensor": {
      "entity": "Example AI Labs",
      "jurisdiction": "CN"
    },
    "distribution": {
      "channel": "open-weights",
      "hostingJurisdiction": "US"
    },
    "license": {
      "name": "Example Model License v2",
      "url": "https://example.com/license",
      "reviewedAt": "2025-09-30",
      "exportReviewRef": "legal-ticket-1042"
    }
  }
]
}

exportReviewRef is the field doing the real work here. It isn't a legal opinion — it's a pointer proving someone looked.

A CI check that fails closed on missing provenance

import { readFile } from "node:fs/promises";

const KNOWN_JURISDICTIONS = new Set(["CN", "US", "EU", "TW", "SG", "JP", "UK", "UNKNOWN"]);
const REQUIRED = ["id", "artifacts", "licensor", "distribution", "license"];

const manifest = JSON.parse(await readFile("models.lock.json", "utf8"));
const errors = [];
const models = manifest.models ?? [];

for (const [i, m] of models.entries()) {
for (const key of REQUIRED) {
  if (m[key] == null) errors.push(`models[${i}] missing "${key}"`);
}

const jur = m.licensor?.jurisdiction;
if (!KNOWN_JURISDICTIONS.has(jur)) {
  errors.push(`models[${i}] jurisdiction "${jur}" not in allowlist`);
}
if (jur === "UNKNOWN") {
  errors.push(`models[${i}] provenance unknown - refusing to build`);
}

for (const [j, a] of (m.artifacts ?? []).entries()) {
  if (!/^sha256:[a-f0-9]{64}$/.test(a.digest ?? "")) {
    errors.push(`models[${i}].artifacts[${j}] digest not pinned`);
  }
}

const cnWeights =
  m.distribution?.channel === "open-weights" && jur === "CN";
if (cnWeights && !m.license?.exportReviewRef) {
  errors.push(`models[${i}] CN-origin weights missing license.exportReviewRef`);
}
}

if (errors.length) {
console.error(errors.join("\n"));
process.exit(1);
}
console.log(`ok: ${models.length} model dep(s) verified`);

Run against a two-entry fixture where the CN-origin weights entry has no review reference, and the check exits non-zero as designed:

$ node scripts/check-model-provenance.mjs
models[1] CN-origin weights missing license.exportReviewRef
$ echo $?
1

After adding the reference, the same command reports success:

$ node scripts/check-model-provenance.mjs
ok: 2 model dep(s) verified

The allowlist detail matters. UNKNOWN is in the set so the error message names the real problem instead of failing on a type check — and it still fails the build. Failing closed on unknown provenance is the entire point. A check that warns is a check that gets ignored by week two.

Substitution Planning and Realistic Exit Cost for Model Dependencies

Exit cost is less about swapping the model string than about the retraining and re-evaluation you did around a specific checkpoint's behavior.

Be honest about the tiers:

• Hosted API swap — days. Prompt and eval changes, no retraining.
• Open-weights swap to a same-family sibling — weeks. Re-run evals, re-tune quantization.
• Cross-family swap — quarters, if you fine-tuned. Dataset assumptions and tokenizer behavior both move.

If a dependency is CN-licensed and open-weight, you should already have a named substitute and a documented eval delta, even if it's worse. An untested fallback isn't a fallback.

What Would Confirm or Change the Export-License Assessment

I'd revise upward — call this urgent rather than planned — if any of these turn out true:

• The instrument explicitly covers weight distribution, including open downloads.
• It applies retroactively to already-published models.
• Fine-tunes and derivatives are named as controlled items.
• A published catalog entry with a size or compute threshold appears.

I'd downgrade it to a documentation exercise if the scope is narrow — say, licensing of training-compute exports rather than model artifacts, or a rule that only touches unreleased frontier models above a high threshold.

The way to settle this is boring: read the administering agency's published catalog entry. MOFCOM is the likely administrator given China's existing export-control framework, but that's an inference and I haven't seen the notice text.

Conclusion

Nothing here says stop using Chinese models. The takeaway is that model dependencies have always carried jurisdictional facts nobody recorded, and a licensing regime turns that sloppiness into an unanswerable question at the worst possible time.

Add a jurisdiction field. Pin a digest. Point at a review ticket. Make the build fail when the pointer is missing. That work is cheap now and expensive later, and it's the only part of this situation you fully control.

Further Reading

• Wccftech report as aggregated in the discovery feed — secondary source; the specific claims above come from here.
• MOFCOM English site — the ministry most likely to administer such a license; check for the actual catalog entry.
• CycloneDX Machine Learning BOM capabilities — a standardized shape for model bill-of-materials if you want to avoid inventing your own.
• Hugging Face model card documentation — useful for recording license and provenance metadata at the artifact level.