A creative agency recently asked a question that I wish more shops were asking. They want to move some frontier model usage to local models, and their dev team wanted to know how other agencies handle governance, liability, and vetting. Not benchmarks. The review process.
They split the stack into four layers: the runtime that hosts the model, the repository you download weights from, the model and its license, and the agent framework that sits on top.
Open source software and security is my jam, so I took some time with it. A colleague, Kip Boyle, added a formal review process and pushed back on two parts of my answer. He was right to do it.
The runtime is the attack surface.
The most risky layer is going to be the runtime or the hosting provider. This is the main attack surface. Even with a bit of a security background, I would personally not expose Ollama, LM Studio, vLLM, or llama.cpp from my local or office network to the internet, ever. LM Studio is closed source, so it's a black box.
What to use locally depends on your hardware. For anything close to the frontier, it's a 10k+ investment, minimum. I would highly recommend a domestic provider instead. I've been happy with Fireworks. I chose them mainly for speed, but I did look through their credentials as well.
Hugging Face has no sheriff.
I use Hugging Face. I still don't trust what I download.
As far as I know, there is nothing like the Apple App Store for open weights. Hugging Face is the Wild West. People can put up a model with just about any name they want, so it looks official. Models have contained malware before. Automated scanners are not a guarantee.
When you pull a model from Hugging Face:
- Download Safetensors models only.
- Confirm for yourself that the hash matches what is expected.
- Scan it locally in a sandbox with no network access, so if something goes wrong it can't hurt anything.
- Use OpenSSF Model Signing when the publisher supports it.
A provider like Fireworks handles this layer for you with, I feel, less risk and no big up-front hardware cost.
Check the exact license, not the model family.
MIT and Apache 2.0 are permissive licenses and good options for commercial work. They still have conditions, including keeping the required notices. I use Qwen and GLM myself in production. That does not mean every new release from either company gets a pass.
As of September 3, 2026, these are the releases and license differences worth looking at:
Qwen3.8-27B is Apache 2.0. Qwen3.8-Flash-Next-FP8 is not. It uses the Qwen Community License. If you or an affiliate operates a Model-as-a-Service business or an independent AI coding or office-productivity assistant, you need a separate license before commercial use. No revenue minimum for that requirement. There are exceptions for certain narrower tools and embedded features. Its internal-use exception does not cover making outputs available to third parties. It also requires model-name display above 100 million monthly active users or $20 million in monthly product revenue. Read this one carefully if you build coding agents.
GLM-5.3 is worth testing for coding and agent work, but uses its own license, not plain MIT. If you or an affiliate operates a Model-as-a-Service business and your combined revenue exceeds $10 billion over any consecutive twelve months, commercial use requires passing Z.AI's security review. That is a high threshold, but it is a real condition. GLM-5.3-Flash, despite the similar name, is MIT. Same family, different terms.
DeepSeek V4-Pro-0813, V4-Flash-0731, and the newer experimental V4-Flash-Vision-Exp use MIT. Those weight licenses do not contain company exclusions or revenue gates. The older DeepSeek-LLM license does contain use restrictions. A hosted service also has its own terms. Don't mix those up with the license on the weights you are actually downloading.
Mistral Small 4 combines reasoning, coding, and image understanding under Apache 2.0. Mistral Medium 3.5 uses modified MIT. It does not grant you rights if your company or employer's global consolidated revenue exceeded $20 million in the preceding month. That is company revenue, not revenue from the model. Above that, you need a separate license or can use Mistral's hosted service under its terms.
Gemma 4 is now Apache 2.0. The 26B-A4B and 31B models, along with the newer 12B release, belong on the local-model review list. I would not apply the older Gemma licensing warning to Gemma 4. Phi-4 remains MIT, though it is an older option rather than a new release.
MiniMax M3 is another coding and multimodal model worth looking at. Its Community License requires commercial products to display "Built with MiniMax M3" on a related site, interface, or documentation. Above $20 million in yearly revenue from those products and services, you need prior written authorization. Below that, you still have to send a one-time notice. It also prohibits uses including military purposes. This is not a download-it-and-forget-it license.
NVIDIA Nemotron 3.5 Lightning 30B-A3B is worth a look for a smaller reasoning and agent model. It uses OpenMDW 1.1, not MIT or Apache. It permits commercial use without a revenue gate and explicitly places no restrictions on using or sharing outputs. Keep the license and notices when redistributing. There is also a termination clause for certain patent or copyright lawsuits involving the model materials. Permissive does not mean no conditions.
Kimi K2 and K3 have their own licenses. K2 is modified MIT and requires its name in the interface when a commercial product crosses 100 million monthly active users or $20 million in monthly revenue. K3 has a similar display requirement. If you or an affiliate operates a Model-as-a-Service business, K3 also requires a separate agreement once your combined revenue exceeds $20 million over any consecutive twelve months. Its exceptions include official products, certified inference partners, and internal use. But internal use means not making the software, its outputs, or its capabilities available to third parties. That is narrower than saying anything used behind the scenes is exempt.
Llama 4 still has its own community license, attribution requirements, acceptable-use conditions, and a separate permission requirement for very large platforms. I would avoid that extra complexity when a suitable model with a cleaner license is available.
Treat the license as a release-level fact, not a family-level fact. Check the exact model card and license every time. Fine-tunes can add terms or fail to state them clearly; they don't erase upstream obligations. Keep a copy of the license with the version you approve. A permissive license does not clear third-party rights in the training data or your outputs.
These model licenses offer no warranty. Hey, the download may be free. The responsibility is still yours.
Formal checklists exist.
Formal checklists do exist. The approval tiers I use move a tool from contained experimentation, to daily internal use, to production work touching client data, credentials, or deliverables.
The longer controls are already covered by the CISA agentic AI guide, the OWASP Top 10 for LLM Applications, the NIST AI Risk Management Framework, and CSA's note on model poisoning and self-hosted LLM stealers.
Kip Boyle has run a cybersecurity firm since 2015. He added the process he sees working in most situations. Stop treating local AI as special. A model is a third-party software component. So is the runtime. So is the agent framework. Use the same tiered approval as anything else in your stack:
- Intake. One short form anyone can submit: what it is, where it comes from, what data it'll touch, and who owns it.
- Classify by data, not by tool. A model that only sees public marketing copy gets a light review. The same model touching client files under NDA gets the full one. Most teams over-review the tool and under-review the data path.
- Start in a sandbox. Isolated machine, no client data, no outbound network. Promotion takes three things: technical checks passed, a named business owner accepts the risk, and a written answer to "what happens when this thing is wrong?"
- Give agent frameworks one extra gate. Kip considers them the riskiest layer in application use because they execute code and touch file systems. Can you limit what the tool can reach? Does a qualified human review its output before it goes out? If you can't answer yes to both, it stays experimental.
- Re-review on a calendar. Licenses, maintainers, and forks change. What passed in March may not pass in September.
The runtime is the exposed attack surface. An agent framework earns the extra gate because of what it can reach and do. Those are different risks.
Liability is a trade, not a win.
My initial take was that Apache and MIT offer no warranty. You are on your own and accept liability from your derivative work. I could not see this being much of an issue in most creative work. I also thought self-hosting simplified SOC 2 and client NDAs because the data did not leave your office. Anthropic and OpenAI offer some indemnification and contractual recourse, but I did not see that being useful for derivative work.
Kip pushed back on both parts.
On indemnification, he pointed out that Anthropic and OpenAI commercial terms can cover an important scenario: a third party claiming that AI output you delivered infringes its intellectual property. For an agency, that matters. The protection depends on the product and contract, and it has real carve-outs. Going fully local can mean giving it up, leaving your company or client contracts to absorb that risk. Talk to whoever writes those contracts before you switch.
On SOC 2, self-hosting does not shrink the work so much as move it. You drop a subprocessor. You add your own box to scope: patching, access control, monitoring. Often still worth it for the data-control story. But, as Kip put it, it is a trade, not a win.
I'm not a lawyer. Do your own research. Kip is an operator, not a lawyer either. Your mileage may vary.