U.S. Restrictions on New Chinese Robots: What Deployment Teams Need to Document

The July 28, 2026 restrictions focus on the country of origin and manufacturing provenance of physical AI systems deployed in sensitive facility contexts. For deployment teams, this creates a documentation requirement that goes beyond the standard acceptance record. The standard acceptance record captures performance, integration behavior, and commissioning outcomes.

A provenance record captures where the robot was manufactured, who manufactured its primary components, what software stack is running on it, where that software connects to for updates or telemetry, and what identities or organizations have remote access to it. These fields were not historically required for standard deployment acceptance. Restrictions that hinge on national origin and technology provenance create demand for records that most deployment teams have not systematically maintained.

The gap between what was recorded and what is now needed to respond to procurement reviews, facility security audits, or operator inquiries is the central documentation challenge that this guide addresses. Teams that built strong configuration and commissioning records will find they already have a substantial portion of the required evidence; teams that relied on informal documentation will need to reconstruct the provenance record from secondary sources.

The restrictions do not apply uniformly to all robots with Chinese-manufactured components. They target specific combinations of manufacturer affiliation, system type, and deployment context. Before investing in a full provenance audit, deployment teams should determine whether the robots in their portfolio fall into the affected categories: humanoid robots and quadruped robots from entities named in applicable restrictions, deployed in facility categories defined as in-scope by the relevant restrictions.

For robots that are clearly outside these categories, a brief written assessment documenting that determination is sufficient for most review processes. For robots that fall within or close to the defined scope, a complete provenance record is necessary. For robots in ambiguous territory, specifically systems with components from multiple origins or with partial supply chain involvement from entities close to those named, the documentation standard should be conservative: capture all available provenance information and note clearly which fields could not be verified from available records.

The provenance record itself does not resolve ambiguous cases, but it provides a structured basis for the compliance review that will ultimately resolve them, and it shows that the deployment team conducted a good-faith investigation.

A complete provenance record for a robot subject to origin-based restrictions contains several distinct categories of information. Manufacturing provenance covers the robot manufacturer's registered entity name, country of incorporation, primary assembly facility location, and any parent company or affiliated entity relationships relevant to the applicable restrictions. Component provenance covers the origin of major subsystems including the compute platform, actuation hardware, sensor arrays, power system, and communication hardware; for each subsystem, the record should note the manufacturer, country of manufacture where available, and how the information was verified - whether from the technical datasheet, the manufacturer's integration documentation, or physical inspection.

Software provenance covers the version and build identifier for all software layers running on the robot at the time of deployment: operating system, middleware, navigation stack, perception stack, application software, and any embedded firmware on subsystem controllers. Network and telemetry provenance covers every external endpoint the robot communicates with, the data type sent or received, and the organizational identity responsible for each endpoint.

Access provenance covers every organization and individual with remote access credentials to the robot, the access method, and the stated purpose for that access. A record covering all five categories can support a compliance review that asks about any one of them without the deployment team needing to reconstruct information under time pressure.

Many robots currently deployed were accepted without any of the provenance fields described above, because those fields were not part of the acceptance criteria at deployment time. Remediating gaps in an existing record requires working backward from the deployed state. The most accessible provenance information is software versions: current configuration can be read from the robot directly in most cases, and version histories can often be reconstructed from update logs if those logs were retained.

Hardware component information is harder to reconstruct after deployment; the primary sources are the robot manufacturer's technical documentation, the bill of materials provided at sale, and physical inspection of accessible hardware. Network endpoint information can be reconstructed by running a controlled network observation session during a maintenance window and comparing observed traffic against the manufacturer's documentation.

Access records are often the hardest to reconstruct: if the deployment team did not maintain an access log from the beginning, reconstructing it requires contacting all parties who have had involvement with the robot and requesting a declaration of what access they have or have had. A remediated record assembled retrospectively should note clearly that it was not maintained from initial commissioning, which fields were verified from primary sources and which were reconstructed, and what gaps remain unresolved.

A documented gap is more defensible than an absent field.

As reported on July 28, 2026, coverage of U.S. government actions regarding the deployment of certain Chinese-manufactured humanoid and quadruped robots was published by Reuters and other major news organizations. This guide is prepared on the basis of publicly available reporting as of July 29, 2026; it does not reflect internal legal analysis, regulatory agency guidance, or official compliance interpretation from any government body.

Deployment teams seeking authoritative guidance on whether specific restrictions apply to specific systems, manufacturers, or facility types should consult current official regulatory sources and qualified legal counsel. The documentation practices described in this guide are intended to support compliance review processes by providing a structured deployment record, not to substitute for legal or regulatory advice. Dagmont records evidence, configuration, and acceptance decisions; it does not certify legal compliance, regulatory conformance, or any form of government approval.

• Identify each robot in the portfolio by manufacturer entity name, country of incorporation, and robot type
• Determine whether each robot falls within the scope of current restrictions based on manufacturer, system type, and facility category
• Record the robot's serial number, model number, and build date from manufacturer documentation
• Document all major hardware subsystems by manufacturer name and country of manufacture where available
• Record the complete software version for every layer: operating system, middleware, navigation, perception, application, and subsystem firmware
• List every external network endpoint the robot communicates with, the data type, and the responsible organizational entity
• Document every organization and individual with remote access to the robot, the access method, and the stated purpose
• Record whether each provenance field was verified from a primary source or reconstructed from secondary sources
• Note explicitly any fields that could not be verified and the steps taken to obtain the information
• Store the provenance record linked to the robot's standard deployment acceptance record