Arcee CTO: Chinese AI models not inherently dangerous

Lucas Atkins, CTO of Arcee, a US-based open-source AI lab, has taken a stance that contradicts rising calls for restrictions on Chinese AI models. As Chinese open-weight models such as Moonshot AI's Kimi K3 and Alibaba's Qwen grow in capability and market share, offering inference at a fraction of the token cost of proprietary models from US labs like OpenAI and Anthropic, concerns about security risks have intensified. There has been talk that the Trump administration might attempt to ban them, though it has not yet acted on the idea.

Atkins argues that these models are no more dangerous than any other open-source software a company might use. He pushes back against the framing that positions Chinese models as inherently suspect because they were "coded with certain intentions" that a bad actor could exploit. "That is fundamentally not how these models are trained," Atkins explains. Once a model is downloaded from open-source repositories like Hugging Face and run within an enterprise's own data center, "there is really not any way for an Arcee, or an Alibaba, to make a model, have someone run it in their own environment and for us have any access to it whatsoever." While the models are open-weight rather than fully open-source (the training methods and data remain proprietary), the source code that runs on servers is visible and reviewable.

Atkins acknowledges that large organizations should put any model through security testing and inspection processes before deployment, which is standard practice. Companies also often post-train models for their specific needs, examining areas like bias, toxicity, hallucinations, and sensitivity to certain topics. He concedes that theoretically, a model trained for coding could be designed to introduce malware under specific circumstances, but calls such a feat an "acrobatic" undertaking. Given that large language models are inherently creative and unpredictable, the odds of forcing one to reliably spit out malware in response to a predetermined combination of context and prompt are "slim." Even slimmer are the chances that an enterprise would actually use such code.

Atkins advocates for a different approach than banning: "I think instead of the conversation being about how to ban Chinese models, it should be about how do we foster a good, open ecosystem here in the U.S." He notes that Arcee itself benefits from Chinese models being open and widely available, as it allows the startup to learn from them and build on top of them. The competitive path forward, he argues, is to "release a model that is better." Enterprises, he adds, are increasingly building their AI applications to be model-agnostic and use multiple models, so they won't remain dependent on Chinese alternatives indefinitely, even if those alternatives offer the best price-to-performance today.

The debate over Chinese AI models reflects a collision between security concerns, competitive anxiety, and technical reality. As models from Moonshot AI and Alibaba offer inference at a fraction of the token cost of closed-source US alternatives from OpenAI and Anthropic, some policymakers and proprietary model makers have called for restrictions or bans. Arcee—a US startup building open models partly to compete with Chinese alternatives—would logically benefit from such restrictions, yet its CTO argues the opposite. Atkins frames open-weight models not as uniquely dangerous but as functionally similar to any open-source software an enterprise might adopt. His key claim rests on a technical distinction: open-weight models are not equivalent to closed-source software that a manufacturer can remotely control. Once downloaded and run in an organization's own infrastructure, the model maker loses all access. Moreover, large enterprises subject models to security testing, inspection, and post-training before deployment, giving them visibility into the model's behavior. While Atkins acknowledges that a sophisticated actor could theoretically design a model to inject backdoors under specific conditions, he emphasizes the practical difficulty of pulling off such an attack and the unlikelihood that an enterprise would then use the resulting code. His framing suggests that the real competitive advantage lies not in restriction but in capability—building better models that enterprises choose for their quality and cost, not out of lock-in.

No comments yet. Be the first to share your thoughts!