Best Model for Enterprises: Capability Is the Easy Part

Enterprise model selection rarely comes down to benchmarks. By the time a model reaches a serious evaluation, three or four candidates are all capable enough, and the decision is made on constraints that never appear in a comparison table.

Those constraints are worth understanding early, because discovering them at the procurement stage after a nine-month pilot is how these programmes die.

Licensing is the first hard filter

Legal review will ask what the licence permits, and the answers differ more than the marketing suggests.

GLM-5.2 and both DeepSeek V4 variants are MIT licensed. That is unusually clean for legal review: you may host them, modify them, and deploy them internally without negotiation, and the review is short because there is very little to review.

Kimi K3 and K2.6 are not MIT. K3 is released under Moonshot's own terms, which include a revenue threshold above which model-as-a-service use requires separate arrangements. For internal engineering use that clause typically does not bite, but if any part of your organisation exposes model capability to customers as a service, it needs a specific reading rather than an assumption.

Qwen is permissive across most tiers, which keeps it in scope for deployments where a single-GPU dense model fits the requirement. Open weight versus closed models covers the broader trade-off, and the practical advice is simple: get legal to read the actual licence text during the shortlist stage, not after the pilot.

Data residency usually decides the deployment shape

Where inference happens is frequently a regulatory question rather than an engineering preference, and it constrains the model list directly.

If tokens cannot leave a jurisdiction or a network boundary, hosted APIs are out unless the provider offers a compliant regional deployment, and you are choosing among open-weight models you can run yourself. That immediately favours the MIT-licensed options, and it turns the memory footprint into a live concern.

Be realistic about what self-hosting a frontier model involves. Kimi K3's weights are roughly 1.6TB, which is a multi-node deployment with fast interconnect and a team to operate it. Mixture-of-experts models need memory for all parameters even though each token activates a fraction — DeepSeek V4 Pro is 1.6T total despite activating around 49B.

Where the requirement is residency rather than frontier capability, a dense model is often the pragmatic answer. Qwen 3.6 27B runs on a single GPU and reports 77.2 percent on SWE-bench Verified, which clears the bar for a great deal of internal work. Self-hosting model selection covers what fits on what.

Version stability matters more than the latest release

Consumer usage benefits from always being on the newest model. Enterprise usage frequently does not, because a silent model change means a compliance workflow that behaved one way in March behaves differently in June, and nobody can explain why.

Pin explicit model versions in production, and treat a version bump as a change requiring the same evaluation and sign-off as any other production change. Providers deprecate versions on their own schedule, so track deprecation notices as a standing operational task rather than reacting to them. Pinning model versions covers the practice.

Keep an evaluation suite that runs against any candidate version before it reaches production. Fifty representative tasks with known-good outcomes, executed automatically, turns a model upgrade from a leap of faith into a report — and it is the artefact auditors will ask about.

You must be able to reconstruct what happened

When a model-assisted decision is questioned six months later, someone has to be able to say which model, which version, which prompt, which retrieved context, and which output. If you cannot reconstruct that, you have an audit finding.

Log the full request and response with a version identifier, a timestamp and a user attribution, and retain it under your normal data retention policy. Sampling is not sufficient for anything touching a regulated process — you need the specific interaction, not a representative one.

Trace agentic runs properly, since a multi-step agent makes many decisions and only the final output is otherwise visible. Agent observability and tracing covers what to capture and how to keep the volume manageable.

The same logging underpins chargeback. Tagging every call by team and cost centre from the outset is straightforward; attributing spend retrospectively is not. Token accounting for finance covers the reporting shape finance will ask for.

Single-vendor dependency is a risk register item

A provider outage that halts developer productivity across a large organisation is a business continuity issue, and it will be treated as one.

Route model calls through an internal gateway rather than letting each team integrate a provider SDK directly. That gateway is where you enforce version pinning, apply rate limits, capture audit logs, attribute cost, and fail over to a secondary provider without touching application code.

Qualify a second model on a different provider and keep it warm, with your evaluation suite proving it is adequate. It does not have to match the primary — degraded service beats no service — but it has to be tested, because an untested fallback is a fallback that will not work when you need it. Model routing and fallbacks covers the pattern.

Security posture is about the pipeline, not the model

Enterprise security review will focus on the model and should focus on what surrounds it. The realistic risks are that an agent with tool access reaches systems it should not, and that untrusted content in a prompt influences behaviour.

Scope credentials narrowly per agent, sandbox execution, and require human approval for anything with a destructive or irreversible effect. Treat any content the model reads — a ticket description, a web page, a customer email — as untrusted input that could contain instructions. Prompt injection and agent security and agent sandboxing cover the controls.

Recommendation

For most enterprise engineering use, GLM-5.2 is the strongest fit: capable on coding and long-horizon work, MIT licensed so legal review is short, and deployable either hosted or on your own infrastructure. DeepSeek V4 Pro is the equivalent alternative on the same licence terms, with Flash on the same family for high-volume internal tooling.

Where residency requires on-premises inference without a cluster, Qwen 3.6 27B on a single GPU is the pragmatic option.

Consider Kimi K3 where its long-horizon results genuinely matter — 88.3 on Terminal-Bench 2.1 and 81.2 on FrontierSWE lead the open field — with legal having read the licence first.

The decision rule: filter on licence and residency, then pin versions, gateway every call, log everything, and keep a tested fallback. Capability differences among the survivors are usually smaller than the operational differences you create yourself. The provider selection checklist covers the procurement questions to ask.