The Model Card Is Not a Dependency Review: Open-Weight AI for Embedded Teams

Model cards do not answer the questions embedded teams already ask of third-party code, and that matters when deploying Chinese open-weight models.

An embedded AI team downloads DeepSeek R1 weights, quantizes the model to 4-bit, and begins testing it on a local inference stack. The 14B distilled variant fits in roughly 8 GB of VRAM. The model clears the latency budget, fits the memory ceiling, and passes the benchmark suite. Two weeks later, the machine learning lead signs off for integration into a firmware build.

But nobody ran the review that an npm package would have triggered.

That gap is where recall risk hides. Foundation models are starting to enter embedded systems as build artifacts, but they behave more like dependencies. Their upstream provenance, license terms, safety behavior, update path, and replacement cost determine whether the product remains supportable years after shipment.

While the documentation in a model card is useful, it is not a dependency review, and embedded teams need to evaluate specific questions before an AI model enters production deployment. In the case of Chinese open-weight models, this is even more important, as there are additional filings and public artifacts that teams will need to consider.

What Model Cards Don't Document

Embedded teams already know how to review dependencies. Who maintains it? What license governs use? What known vulnerabilities exist? What assumptions does it make about the host environment? What happens when the upstream project goes silent?

Open-weight models deserve the same review. Llama, Mistral, Gemma, DeepSeek, and Qwen are all dependencies in any production firmware path that calls into them.

A model card may describe architecture, training approach, benchmark results, intended use, and known limitations. It will rarely provide the full evidence packet that an embedded product team needs before placing the model on a firmware path: exact checkpoint license, provenance, support expectations, failure behavior under domain-specific inputs, quantization changes, replacement candidate, and named owner.

In addition to these dependencies, it is also important for embedded teams to understand where AI models originate. For example, Chinese open-weight models add one more diligence artifact most Western teams have not learned to read: the Chinese public filing or registration category attached to the provider's release path. That filing is not a model card and is not a substitute for testing. It is a regulatory provenance signal recorded with China's Cyberspace Administration, whose registry crossed 5,000 entries by November 2025, drawn from roughly 2,353 companies. For supply-chain review, that signal belongs beside the license, the model card, the eval report, and the deployment threat model.

Three Approval-Gate Questions

These three questions convert the available evidence into a production decision applicable to any open-weight model. Chinese filings provide an additional public artifact when available.

Question 1: What upstream review path did this model pass through?

Every Chinese model has a release path. The interesting question is what that path required the provider to disclose, attest, or submit before the weights went public.

For Western open-weight releases, the answer is mostly self-published: a model card, a system card, a research paper, a license file. For Chinese models, that includes checking whether the provider's release path maps to an algorithm filing, a generative-AI service filing under the 2023 Generative AI Interim Measures, or another public registration category. The second track governs flagship Chinese foundation models, including DeepSeek V4, Qwen 3.6-Plus, Baidu's ERNIE 5.0, and ByteDance's Seed2.0 services. 

A model registered under the generative track has passed a review, including content-safety self-assessment against thirty-one risk categories defined in China's GB/T technical standard, spanning political sensitivity, violence, discrimination, privacy, and intellectual property. The review does not tell you what the training data was. It tells you what the provider committed to excluding from the training data. The model's refusal patterns and content filters will not match those of Western models from OpenAI, Anthropic, or Meta.

Filing-category mismatch is the practical risk. A model whose filing declares it as a consumer education assistant has been reviewed for that use case. Deploying it as the natural-language interface to an industrial control system inherits a regulatory commitment that does not apply to your context, and a behavioral profile shaped for one that does not match yours.

What to do: Map the candidate model to its filing or release category. Read the Hugging Face model card against the provider's own system card. Flag any gap between the provider's declared deployment domain and yours.

Question 2: How does the model behave at the edges of your input distribution?

When a model refuses a prompt, redirects, or filters its output, that is runtime behavior, not a content-policy footnote.

The practical concern is not whether a model refuses politically sensitive prompts. The practical concern is whether the same learned refusal behavior fires on legitimate diagnostic, medical, industrial, or customer support inputs during deployment.

A Fudan University benchmark tested Chinese language models against prompts targeting the content baseline Chinese regulators require. ByteDance's model scored 66.4 percent compliance. Baidu's scored 31.9 percent. Alibaba's scored 23.9 percent. Refusal behavior is an engineering target implemented with varying disciplines, and the variance travels with the weights.

In an embedded context, refusal behavior is a control-path event. It changes latency, suppresses an instruction, alters output length, triggers fallback logic, or creates an unexplained no-response state. If the test harness only measures happy-path accuracy, the refusal path ships untested.

The failure modes are concrete. A voice assistant on an automotive head unit encounters passenger speech that a Chinese training pipeline has never seen. An industrial chatbot translates a maintenance log containing a geopolitically sensitive place name. A medical triage assistant processes a query using a locally common clinical term. In each case, the model may refuse, produce truncated output, silently redirect, or generate filtered output that looks correct but is not.

What to do: Build an evaluation set that includes inputs from your deployment's worst-case edges, not just the happy path. Log refusal rate, latency variance on refusal paths, output length distribution, and coherence on boundary inputs. Run the same set against an alternative open-weight model from a different regulatory origin and record the delta. Track that delta as a supplier risk.

Question 3: Can you support or replace this model for the product's field life?

An embedded system shipping today may be in the field in 2035. An open-weight model adopted today must remain viable across that horizon, or the architecture must make replacement cheap.

The license governs your rights. Not the general reputation of the lab, not the license the lab’s models usually carry, but the specific license attached to the specific checkpoint you downloaded. DeepSeek-V4-Pro and DeepSeek-V4-Flash weights are MIT-licensed. Qwen3.6 open-weight releases generally ship under Apache 2.0, but the answer still depends on the checkpoint. 

Some earlier Qwen2.5 variants, including Qwen2.5-3B, were released under Qwen Research / non-commercial terms, while most other Qwen2.5 open-source variants were Apache 2.0, and Qwen2.5-72B used Alibaba’s custom Qwen license. Alibaba’s Qwen2.5-Max remains proprietary and API-only. The license file in the model repository is the first document to read before you ship

Update risk runs in two directions. Losing access to future model versions is less severe than it looks. Downloaded weights persist locally. The harder risk is losing the ecosystem around them: fine-tuning tooling, quantization implementations, reference inference stacks, and security disclosures for vulnerabilities in the weights themselves. Over 130,000 derivative models on Hugging Face build on Qwen's architecture as of late 2025. That ecosystem is a force multiplier for any team using Qwen, and its durability is a supply-chain dependency with geopolitical exposure.

What to do: Record the exact license and checkpoint hash in your Software Bill of Materials (SBOM). Isolate the model behind an inference abstraction layer so that the day you need to swap it is a configuration change, not a rewrite. Maintain enough in-house alignment-evaluation capability that you are not dependent on a continued flow of community artifacts.

The Model Dependency Record

These three questions feed a single artifact that every embedded team approving an open-weight model should produce and version-control alongside the build.

Minimum fields:

• Exact model name and version
• Source repository and checkpoint hash
• Model size, quantization format, and runtime
• License attached to the specific weights
• Known prohibited or restricted use terms
• Model card, system card, and any declared restrictions
• Filing or registration category, where applicable
• Evaluation results on deployment-specific edge cases
• Refusal rate, latency variance, and output-length variance on boundary inputs
• Quantization, distillation, or fine-tuning modifications
• Release-blocking evaluation thresholds
• Identified replacement candidate
• Named owner for monitoring, reapproval, and incident response

The record is not paperwork. It is the artifact your security team, your auditor, and your future self will need when something behaves unexpectedly in the field.

Start manually. Pick the first candidate model and create the record before the next architecture review. The first version can live beside the SBOM, threat model, or release checklist. The important move is ownership: Someone must know which model shipped, which checkpoint it came from, which license governed it, how it was modified, what edge-case tests it passed, and what replaces it if the upstream project changes direction.

Decision Checklist

After running the three questions and producing the dependency record, map the answers to a production decision.

• Ship as integrated. Licensing is clear for the exact release. The deployment domain is low-sensitivity. Evaluation shows acceptable refusal behavior across boundary inputs. A replacement path exists.
• Ship behind an abstraction layer. Licensing is acceptable. Specific behavior is imperfectly characterized. Route inference through isolation, monitor for refusal patterns and output drift, and keep a validated alternative warm.
• Evaluate only, no production. The license carries use restrictions that the deployment cannot satisfy. Filing category mismatches the domain. Refusal behavior introduces undocumented failure modes in critical paths.
• Do not approve for safety-critical production. Long-lived regulated deployments such as medical devices, automotive safety systems, and industrial control environments require stronger provenance, replacement planning, and failure-mode characterization than most open-weight releases currently provide. Restrict to non-safety functions, isolate behind validated layers, or require an alternative supplier.

Review the Artifact, Not the Nationality

Every benchmark comparing DeepSeek, Qwen, and Western alternatives frames the choice as a trade-off between performance and cost. For a cloud deployment served from US or EU infrastructure, that may be the whole story. For an embedded system shipping into a regulated, field-serviceable product, it is not. The decision is a supply chain review.

The instincts are already there. Embedded teams have evaluated third-party code against license, maintainer, update cadence, and failure-mode assumptions for decades. Foundation models deserve the same discipline regardless of where they were trained.

The question is not whether a model came from China. The question is whether your team reviewed it with the same rigor you already apply to third-party code.