Your Cheapest AI Model Now Comes With a Congressional Inquiry: Running Kimi, Qwen and DeepSeek in Production Under Scrutiny

The Cheapest Tokens in Your Stack Now Come With Paperwork

On 29 April 2026, the House Committee on Homeland Security and the House Select Committee on the Chinese Communist Party announced a joint investigation into US companies' use of PRC-developed AI models, whether accessed through APIs or self-hosted as open weights. The first letters went to Airbnb, over its reported use of Alibaba's Qwen models in customer service, and to Anysphere, over Cursor's Composer 2 model, which was built on Moonshot AI's Kimi K2.5. A third letter followed on 31 July to DoorDash, after the company publicly said it used a Moonshot model for lower-level work to reduce AI costs.

The requests are not symbolic. According to McGuireWoods' summary of the letters, the committees asked for internal deliberations about using PRC models, data use and storage policies, agreements with model providers and third-party vendors, cybersecurity analyses, and communications, including among directors, about whether to disclose the use publicly. DoorDash was asked to brief the committees in person by 21 August with the people responsible for AI infrastructure, software security, model evaluation, procurement and legal review. That list reads like an org chart of who should already own this decision inside your company.

The trigger for the second wave was Moonshot's Kimi K3. Startup Fortune reported that Moonshot began rolling out the 2.8 trillion-parameter model on 16 July, with a one-million-token context window and OpenRouter pricing of $3 per million input tokens and $15 per million output tokens. Within days, Tom's Hardware, citing Axios, reported that the administration was reviving its push to restrict Chinese models, and the OSTP director said on 22 July that the US had evidence Moonshot may have run a covert platform for large-scale distillation against US models, as the DoorDash letter recounts.

None of this makes using Kimi, Qwen or DeepSeek illegal. There is still no general ban. But the regulatory posture has shifted from silence to scrutiny, and scrutiny is expensive in a specific way: it asks you to produce documents you may never have written. Most engineering organisations chose these models the way they choose any dependency, in a pull request, because the benchmark looked good and the bill looked small.

Why Engineering Teams Picked Them in the First Place

It is worth being honest about why adoption happened, because the reasons have not gone away. The first reason is price. In the same eWeek report, an OpenRouter data analyst said open Chinese models run 60% to 90% cheaper than the top offerings from Anthropic and OpenAI. A separate eWeek analysis cites MIT Sloan research on OpenRouter activity from May to September 2025: open-model inference averaged 23 cents per million tokens, against $1.86 for closed models.

The second reason is control. Open weights can be downloaded and run on your own infrastructure, which means no customer data leaves your environment and no vendor can change the model under you. For classification, extraction, routing and other high-volume, low-glamour workloads, that is exactly the trade engineering teams want. The licences help too: eWeek notes that Qwen3.5-397B-A17B ships under Apache 2.0 and DeepSeek-R1 under the MIT licence, both permissive enough for commercial use.

The third reason is ecosystem. By March 2026 the Qwen family had more than 100,000 derivatives on Hugging Face, the platform's largest model ecosystem, according to a US-China Economic and Security Review Commission report cited by eWeek. When the fine-tuned model that best fits your domain is a Qwen derivative, choosing it can feel like a technical decision rather than a geopolitical one.

The capability gap is real but smaller than headlines suggest. NIST's Center for AI Standards and Innovation found in May 2026 that DeepSeek V4 was the most capable Chinese model it had tested, with aggregate performance about eight months behind the US frontier, and that its cost ranged from 53% lower to 41% higher than a comparable US reference model depending on the benchmark, as eWeek reported. For many production tasks, eight months behind the frontier is more than good enough.

Three Ways a Chinese Model Enters Your Product, and Three Different Risks

Most of the public debate treats "using a Chinese model" as one thing. For engineering and compliance purposes it is at least three, and the controls for each are different.

The first is a hosted API run by the lab itself or a provider in China. Here the dominant risk is data transfer. Prompts, documents and customer records leave your jurisdiction, and European companies inherit a GDPR international transfer problem on top of any security concern. This is the exposure European regulators have already acted on: in June 2025 Berlin's data protection commissioner, Meike Kamp, asked Apple and Google to remove the DeepSeek app from their German stores over allegedly unlawful transfers of personal data to China.

The second is self-hosted weights, either on your own GPUs or through a Western inference provider. Data stays where you put it, so the transfer problem largely disappears. What remains is behavioural risk, meaning how the model responds to adversarial input and what it was trained to say, plus legal and reputational exposure if regulators decide that provenance matters regardless of where the model runs. The congressional letters explicitly covered self-hosted open-weight models as well as APIs.

The third, and the one most companies have not thought about, is a Chinese model inside something you bought. Cursor's Composer 2 was the clearest example: when it launched in March, a user discovered it was built on Kimi 2.5, and co-founder Aman Sanger said "it was a miss to not mention the Kimi base in our blog from the start." Moonshot confirmed the arrangement was authorised. The point is that a developer tool reportedly used by more than half of the Fortune 500 was running a model whose lineage most of its buyers did not know.

What the Security Evidence Says, and What It Does Not

The most cited evidence is NIST's September 2025 evaluation of DeepSeek. CAISI found that agents built on DeepSeek R1-0528, the company's most secure model at the time, were on average 12 times more likely than evaluated US frontier models to follow malicious instructions that pulled them off the user's task. With a common jailbreaking technique, R1-0528 answered 94% of overtly malicious requests, against 8% for US reference models. The same evaluation found DeepSeek models echoed four times as many inaccurate or misleading CCP narratives.

Those numbers matter most for agentic workloads. A model that is easier to hijack is a worse choice for an agent that reads untrusted email, browses the web or executes tools with real credentials, regardless of where it was built. That is a property you can test, and it is the strongest engineering argument for keeping certain model families out of certain roles.

But the evidence has limits that a serious risk assessment should state plainly. eWeek notes that the results apply only to the tested versions and configurations. A finding about R1-0528 in 2025 is not a finding about Kimi K3 or a Qwen derivative in late 2026. And the concern that worries policymakers most, a deliberately planted behaviour that activates under specific conditions, is by its nature very hard to rule out through testing. The Airbnb letter leaned on exactly that worry, citing China's 2017 National Intelligence Law and warning that such models may "covertly censor and manipulate information," per McGuireWoods.

The defensible engineering position sits between the extremes. Do not assume a model is safe because its weights run on your hardware, and do not assume it is compromised because of where it was trained. Run your own adversarial evaluations against the exact model version you deploy, for the exact role it plays, and keep the results. If a committee or an enterprise customer ever asks why you chose a model, those results are the document you will want to hand over.

The Regulatory Picture on Both Sides of the Atlantic

In the United States, the direction is towards pressure rather than prohibition. According to Startup Fortune's summary of the Axios reporting, officials have looked at Entity List designations for Chinese labs, federal procurement limits, security advisories, liability rules and pressure on US companies using Chinese models in production, rather than a single outright ban. Treasury Secretary Scott Bessent framed the line as "what we do not support is IP theft", and opposition inside the administration's own orbit, including from David Sacks, makes a sweeping ban less likely.

Enforcement is the other constraint. Tom's Hardware pointed out that downloadable weights make an outright ban nearly impossible to enforce. That cuts both ways for engineering leaders. It means your self-hosted model will probably not be switched off overnight. It also means that the realistic policy tools are the ones that land on companies: procurement rules, liability, disclosure and investigation. Those affect you whether or not anyone can technically stop the weights from running.

In Europe, the pressure arrives through data protection rather than national security. A hosted API that sends personal data to China triggers GDPR transfer rules, and the Berlin action against DeepSeek shows regulators are willing to use them. For companies selling to US enterprises, the bigger near-term issue is customers. Security questionnaires and AI procurement reviews are already starting to ask which models a supplier uses, and a European software vendor whose product quietly runs on a PRC model is going to be asked the same questions as DoorDash, just by a buyer instead of a committee.

The Inventory Problem: You Cannot Govern What You Cannot Name

Ask most engineering leaders which models their products and tools depend on, and the honest answer is a list of vendors, not models. That is the gap the congressional letters exposed. A request for "internal deliberations about using PRC models" assumes you know that you are using one, and that someone decided to.

An AI bill of materials closes that gap. For every AI feature and every AI-powered tool, record the model name and exact version, the original lab, any base model behind a fine-tune or derivative, where inference runs, which data classes it can see, who approved it and when, and which evaluations it passed. Derivatives deserve special attention: with more than 100,000 Qwen derivatives on Hugging Face, the model card of a fine-tune is often the only place its lineage is recorded, and it is easy to miss.

Developer tooling belongs in the same inventory. Coding assistants see your entire codebase, and some route requests across several models depending on the task. Vendors are starting to give administrators control here: GitHub, for example, introduced a model policy API in October to manage which models are available to organisations, teams and agents, as Info-Tech's weekly roundup noted. Use those controls, and add a model disclosure clause to every AI-related vendor contract, including a duty to notify you before the underlying model changes.

None of this is exotic work. It is dependency management applied to a new kind of dependency, and it is the same discipline as the software bill of materials that the Cyber Resilience Act is already pushing European suppliers towards. The difference is urgency: the first time most companies try to build this inventory will be the day someone outside the company asks for it.

Build for the Swap, Not for the Ban

The worst position to be in is not using a Chinese model. It is using any model you cannot replace. If a procurement rule, a customer demand or a new evaluation result tells you to move a workload off Kimi or Qwen next month, the cost of that move is set by your architecture today. We made the general case for this in our piece on model portability; provenance risk makes it concrete.

Start with a single model gateway that every AI call passes through. It gives you one place to enforce routing policy, log which model handled which request, and switch providers without touching application code. Then make routing data-aware: tag requests by data class, and let policy decide that customer personal data, source code or regulated records only reach approved models in approved regions. Infrastructure providers are moving the same way; OpenRouter now offers to guarantee that US traffic stays entirely in the US, a response to exactly this kind of customer demand.

Next, keep an evaluation harness for every production prompt that can score a candidate model on your real tasks in hours. Teams that have one can treat a forced model change as a regression test. Teams without one discover, in production, all the ways their prompts were tuned to one model's habits. Finally, keep a warm fallback: a second approved model, from a different lab and ideally a different jurisdiction, already wired into the gateway and periodically exercised.

This architecture also lets you keep the savings. A sensible policy might route internal, non-sensitive, high-volume tasks to the cheapest self-hosted open model that passes your evaluations, while customer-facing agents with tool access run on a model that has passed your adversarial tests and your customers' procurement review. You do not have to choose between cost and defensibility if the routing decision is explicit, logged and reversible.

Where a Nearshore Engineering Team Fits

Most of the work described here falls in an awkward gap. It is too important to leave to whichever developer picked the model, and too engineering-heavy for legal or procurement to do alone. Building a model gateway, writing an evaluation harness, red-teaming the models you actually deploy and assembling an AI bill of materials are concrete projects with clear deliverables, and they rarely fit into a roadmap already full of product work.

This is where Stepto's dedicated development teams in Serbia are a practical fit. Our engineers work in European time zones with good overlap for US East Coast clients, build model-agnostic AI integrations by default, and treat model choice as a documented, reversible decision rather than a line in a config file. We can audit which models your products and tools currently depend on, put a gateway and routing policy in front of them, and leave you with evaluation results you can show a customer, an auditor or a committee.

Just as importantly, we have no stake in which model you choose. If the cheapest open-weight model passes your evaluations for an internal workload, we will tell you to use it. If a customer-facing agent needs a model that will survive an enterprise security review, we will help you prove that choice. The goal is a stack where cost savings and defensibility do not have to trade against each other.