Scared of the Weights, Not of the Wire
A conversation I keep having:
“You run Chinese models? On the system that touches your trading research? What about your IP?”
— asked, without irony, by people who pipe their entire codebase, their strategy documents, and their half-formed product ideas to a third-party API every working hour.
The instinct is understandable. The threat model is exactly backwards.
What a local model can and cannot do
An open-weights model running on my own GPU is a file of numbers. It has no network access I don’t grant it, no telemetry I don’t allow out, and no way to send anything anywhere — my hardware, my egress rules. It cannot phone home, because “home” is a machine in my rack. Where the weights were trained changes none of that physics. The legitimate questions about an imported model are about behavior — is it good, is it honest about what it did, does it fail in ways I can catch? — and those I answer the same way I answer them for every model, foreign or domestic: an evaluation battery with deterministic gates and an honesty track, run before the model earns any role at all. Judge models by their behavior under your own battery, not by their passport.
Now run the same audit on the API workflow. Every prompt leaves your custody. Your protection is a retention policy and a terms-of-service page — documents, not physics. They’re probably honored! But “probably honored” is a trust relationship, and the entire point of the last two years of AI engineering has been learning what happens when you extend trust without a verification mechanism.
The economics guarantee this question stays live: GLM-5.2 prices at roughly $1.40 per million input tokens against $5 for the Western frontier, and across the Chinese open-weights ecosystem the undercut runs 5–30×. That pull is too strong to flag-check away. So get the threat model right: the weights are the safe part. The wire is the exposure. And note the irony of this summer: the frontier American model got revoked by government order while the “risky” open weights kept running — a file on your own disk has no kill switch.
The wire’s second problem: getting Sherlocked
There’s an old Mac-developer word for the deeper API risk. In 2002, a small shop called Karelia built Watson, a beloved utility — and Apple’s next OS release shipped Sherlock 3, which looked an awful lot like it. Getting “Sherlocked” has meant platform-death-by- vendor ever since.
Now consider what a model API vendor sees: not just your data, but the shape of your ambition — what you’re building, how you’re structuring it, where the hard parts are, prompt by prompt, for months. I’m not accusing anyone of harvesting customer traffic for product ideas; I don’t need to. The incentive exists, the visibility exists, and the labs are all expanding from selling models to selling products. When your vendor ships something adjacent to what you were building, you’ll never know whether your API traffic was the market research — and that’s the problem: you can’t know. It’s another trust relationship with no verification mechanism, and this one is aimed at your roadmap.
The defense is the same as the last essay’s: what’s genuinely yours — the ideas that constitute your edge — gets built on hardware you own, with models you possess. The rented frontier intelligence gets the work that’s already public, or that teaches an observer nothing. (This blog post, for instance, is a fine thing to let a frontier model see. The parameters of my trading system are not — which is why they’re withheld from everyone, model vendors included.)
The rule, in one line
Fear behaviors, not flags; verify what you can, and don’t send what you can’t afford to have seen. The model that can’t betray you is the one that never sees the secret — and the only model guaranteed never to see it is the one running on your own machine.
How the local farm is built and how models earn roles on it — the crucible, the honesty gates, the routing chokepoint — is in the HMAS white paper.