Open weights vs. closed models: the split defining enterprise AI

There is a quiet architecture decision sitting underneath almost every AI project right now, and it rarely gets debated as openly as it should: do you build on a closed model you access over an API, or an open-weight model you can download and run yourself?

It sounds like an ideological question. In practice it is a coldly practical one, and the right answer increasingly depends less on which is 'better' and more on what you are actually trying to protect.

What each side really offers

The closed, API-first models — the frontier systems from the largest labs — tend to lead on raw capability, and the best of them are genuinely hard to match on the hardest tasks. You get that capability with no infrastructure to run and automatic upgrades. You give up control: the model can change underneath you, your data leaves your walls to be processed, and your unit economics are set by someone else's price list.

Open-weight models — those whose parameters you can download and run — invert the trade. You host them, so your data never leaves your environment, the model does not change unless you change it, and at scale you can often run them far more cheaply. You take on the operational burden, and you are usually working a step behind the absolute frontier on the very hardest problems.

The gap is narrowing where it matters

The headline benchmark race still favours the closed frontier. But most production workloads are not frontier-hard. For summarising, extracting, classifying, routing, and drafting — the unglamorous majority of real AI work — capable open-weight models are now good enough that the marginal capability of a frontier model does not justify its cost or its data-handling implications.

That is the shift worth internalising: the question is no longer 'which model is smartest' but 'what is the least powerful model that reliably does this specific job,' and for a growing share of jobs the answer is one you can run yourself.

How the decision actually gets made

Stripped to its essentials, the choice usually comes down to three tensions:

• Capability vs. control. Do you need the absolute best output, or do you need to own the model's behaviour and lifecycle?
• Convenience vs. privacy. Is sending data to a third party acceptable for this use case, or is data residency a hard line — legally or competitively?
• Opex vs. capex and effort. Is a predictable per-call bill fine, or does your volume justify the engineering to self-host?

Regulated industries and anyone handling sensitive data feel the privacy line hardest, and it pushes them toward open weights regardless of the benchmark gap. Teams optimising for speed-to-market and peak capability lean the other way.

Most people end up with both

The framing as a war — open versus closed — misses where mature teams are landing. They route. A hard, rare, high-stakes request goes to a frontier closed model. The high-volume, well-defined, privacy-sensitive work runs on an open-weight model they host. The interesting engineering is no longer picking a side; it is building the routing layer that sends each request to the cheapest model that will do it well.

The strategic mistake is treating this as a one-time, all-or-nothing bet. The model landscape moves too fast for that. Build so you can swap the model behind any given task, and the open-versus-closed question stops being a fork in the road and becomes a dial you tune per workload.