Open or Closed: A Practitioner’s Framework for Choosing Foundation Models in the Enterprise

The decision deserves better, because it is not one decision. It is a set of trade-offs across control, cost, liability, and lock-in, and the right answer changes with the workload. A framework beats a conviction here, held above the level of a tidy alternative, because the same organisation will correctly choose open for one system and closed for another, and only a framework lets it do that without contradicting itself.

Control: what you need to govern, not what you would like to own

The first axis is control, and the honest question is how much the workload requires, held above the level of how much you would like to have. Open weights give you control over where the model operates, what touches it, and whether it ever changes. That control is decisive for a workload with a hard data-residency constraint or a need to stay certified and unchanged over a long horizon. For those, the ability to operate the model inside your own boundary and freeze it is a requirement the closed API may be unable to meet, held well above the level of a preference.

For a great many workloads, that level of control is something you would enjoy without needing it. A closed API operating in a region that satisfies your residency requirement, under a contract your legal team accepts, meets the actual governance bar without you operating anything. The mistake is treating control as a universal good, held above the specific requirement it should be measured against. Control you do not need is not free. You pay for it in operating burden, which is the next axis.

Cost: the total, not the licence

Cost is where ideology does the most damage, because “the open model is free” is both true and misleading. The licence cost of an open model can be zero and its total cost of ownership can still exceed the closed API it replaced. Self-hosting means you own the infrastructure, the scaling, the capacity planning, and the engineering competence to keep frontier inference operating at production latency. A closed API prices all of that into a per-token rate that looks expensive precisely because it is doing the work you would otherwise staff for.

The number that decides this is sustained utilisation. A closed API costs nothing when idle and scales without your effort. Self-hosted infrastructure costs the same whether busy or idle, so its economics depend entirely on keeping expensive hardware genuinely used. Below a steady-volume threshold, closed usually wins on total cost. Above it, especially where control requirements are also present, open can win decisively. Model the total cost against real traffic before the licence line item persuades you of anything, because a governed AI deployment that blew its budget on idle hardware is not a saving.

Liability: whose problem is a bad output

Liability is the axis practitioners raise least and regulators care about most. With a closed model, some responsibility, and some contractual recourse, sits with the provider. The terms vary and they are rarely as protective as you would like, and there is a counterparty. With an open model you operate yourself, the responsibility for the model’s behaviour is entirely yours. There is no provider to point to when an output causes harm. You chose the model, you deployed it, you own the outcome.

Here is the position I will hold. For a high-stakes regulated workload, this liability difference should weigh more heavily than it usually does, and it often argues in a direction that surprises open-model advocates. Owning the model fully means owning its failures fully. That is acceptable, and sometimes preferable, when you have the evaluation and monitoring capability to stand behind the model’s behaviour yourself. It is a serious exposure when you do not, and “we saved on licence fees” is not a sentence anyone wants to say to a regulator after a harmful output. Choose open where you can genuinely own the accountability, held above the level of merely owning the weights.

Lock-in: the cost of changing your mind

The last axis is lock-in, and it cuts both ways, which is why it is misunderstood. Closed APIs create dependency on a provider who can deprecate a model, change its behaviour, or reprice underneath you, and building deeply against one provider’s specific interfaces raises the cost of ever leaving. Open weights protect against that particular dependency, because a model you hold cannot be taken away or altered.

Open has its own lock-in, quieter and real. The operational investment in serving a specific model, the fine-tuning, the infrastructure tuned to it, the team’s accumulated competence, all of that is its own switching cost. The defensible move is architectural: build your system so the model sits behind an interface you control, so that changing models, in either direction, is a contained change, held well below the level of a rebuild. A production AI system designed this way keeps both options open longer, which is worth more than winning the open-versus-closed argument once and hard-wiring the answer.

Where the framework earns its keep

Consider an organisation that standardised on open models across the board, on principle, after a strong result on one high-volume workload where self-hosting genuinely paid off. The same standard was then applied to a dozen low-volume internal tools. Each operated on infrastructure that sat mostly idle, the aggregate cost climbed well past what closed APIs would have charged for that traffic, and a small team found itself operating far more inference plumbing than the workloads justified.

The original decision was right for its workload and wrong as a policy. The fix was structural: drop the principle, evaluate each workload against control, cost, liability, and lock-in, and let the answers differ. The high-volume regulated workload stayed open. The low-volume tools moved to a closed API. That is end-to-end ownership of the decision, workload by workload, held above the level of a banner applied to all of them.

The conviction that arrives dressed as a technical decision is the thing to distrust. Open and closed are options with different shapes, held well below the level of teams to join, and a serious enterprise will pick each correctly for different systems in the same quarter without any inconsistency at all, because the framework, held above the flag, is doing the choosing.

The organisations that get this right treat the open-or-closed question as one they answer repeatedly, per workload, against control, cost, liability, and lock-in, held above the level of once, on principle, for everything. If you are standardising on either side across your estate, the question worth asking is whether the standard reflects the requirements of each workload or the conviction of whoever set it, because those two answers diverge more often than most policies admit.