Open-Source AI vs Closed: SME Procurement Guide

For most of 2024 and 2025, the open-source AI question for UK SMEs was largely theoretical. The capable models lived behind closed APIs, and the open-weight alternatives lagged badly enough that the conversation rarely got past curiosity. That has changed. The latest Stanford AI Index 2026 shows roughly 88% of organisations now use AI in some form, with the GitHub AI ecosystem swelling to over 5.58 million projects. Open-weight releases from Mistral, Meta, DeepSeek, Alibaba, and Google's Gemma family have closed enough of the capability gap that procurement teams now have a real choice.

That choice is also more confusing than it looks. Open-source AI is not a single thing, and the loose use of the term hides material differences in what you can actually do with a model. Here is a vendor-neutral framework for SMEs trying to make a serious decision rather than follow a trend.

What "open" actually means

The first job is to read the licence. The labels are doing a lot of work, and they are not consistent.

• Apache 2.0 and MIT. Genuinely permissive. Commercial use, modification, redistribution, and embedding in products are all allowed with minimal obligations. Mistral's open releases (including Mixtral 8x22B-Instruct), much of the Qwen family, OLMo, and Google's Gemma 4 release sit here.
• Custom community licences. Llama is the prominent example. The Llama Community License permits commercial use but adds conditions (notably the 700 million monthly active users threshold, attribution requirements, and an acceptable use policy). Workable for almost every UK SME, but read it before you build a product around it.
• Bespoke "model licences." DeepSeek, some Mistral commercial variants, and others use their own licences. Most are usable commercially but each has its own constraints on derivatives, commercial-scale use, or restricted applications.
• Open weights, closed everything else. The provider releases trained weights but not training data, training code, or evaluation harnesses. You can run and fine-tune the model, but you cannot reproduce or audit it. This is most of the open-weight market.

If you do not know which bucket your shortlisted model is in, you are not ready to deploy it. This is a procurement question, not a developer question.

Seven dimensions that actually matter for SMEs

When we run model selection for clients, we score the candidates on seven dimensions. None of them are about benchmark league tables, because benchmarks rarely reflect the workload that matters to a specific business.

1. Total cost over twelve months. Not just per-token API pricing or GPU hourly rates, but the realistic full picture: hosting, fine-tuning runs, evaluation infrastructure, the engineering hours to keep it healthy, and the support contract you may need.
2. Data residency and sovereignty. Where does the prompt go, where is it logged, and who can access it. For UK SMEs handling personal data, regulated client information, or sensitive commercial material, this often forces the answer before any other dimension matters.
3. Fine-tuning and customisation rights. Can you fine-tune at all, can you keep the resulting weights, can you deploy them anywhere, and can you redistribute. Closed APIs typically restrict all of these. Open-weight models give you the most freedom, but only if the licence allows it.
4. Support and accountability burden. Closed providers absorb the operational load and carry some accountability. Open-source shifts that burden to you, your hosting partner, or a managed open-source vendor. This is a real cost, not a free lunch.
5. Security and model risk review. Can you produce evidence the model meets your governance standards. The Stanford Foundation Model Transparency Index recorded a sharp drop in disclosure across the major closed providers, with average scores falling from 58 to 40 in a year. Open-weight models are not automatically more transparent, but the documentation is often more inspectable.
6. Model retirement risk. What happens when the provider deprecates the model, raises prices, or changes the terms. Closed providers do this routinely. Open-weight gives you the option to keep running the same model indefinitely, which matters more than it sounds for any system you cannot easily re-validate.
7. Exit cost. If the choice turns out to be wrong, what does it cost to switch. This is the dimension SMEs underweight most often. Lock-in is rarely visible until you try to leave.

Where open-source wins

Open-weight is the right answer when one of these is true:

• The data cannot leave a controlled environment (regulated sector, sensitive commercial material, or strict client contracts).
• You need to fine-tune on proprietary data and keep the resulting weights confidential.
• The workload is high-volume and predictable, and per-token pricing on closed APIs makes the unit economics painful.
• Lock-in risk is a board-level concern, often after a previous bad experience.
• You have, or can hire, the operational capability to run inference at production quality.

For most SMEs, this looks like a hosted open-weight model on a UK-based provider, fine-tuned on internal data, with a clear runbook for monitoring and updates. It is not free, but it is auditable and portable.

Where closed wins

Closed providers still win clearly in these cases:

• You need the absolute frontier capability for the use case (deep reasoning, long context, multimodal complexity), and the workload does not justify operational investment.
• The use case is exploratory and you will not know if it works until you have tried it. Renting before owning is the right discipline.
• The team has no operational AI capability and you do not want to build it.
• The compliance posture of a major closed provider (SOC 2, ISO 27001, ISO 42001, signed DPAs) is faster to obtain than building the equivalent on top of an open-weight stack.

If you find yourself defending a closed model on the basis of brand familiarity rather than one of the points above, that is a procurement signal worth taking seriously.

A hybrid is usually the honest answer

Most SMEs we work with end up with a hybrid. Closed APIs for exploration, customer-facing low-volume use, and frontier reasoning. Open-weight for the steady-state, sensitive-data, high-volume workloads where the economics and governance both tilt that way. The procurement work is to know which is which, write that decision down, and revisit it on a fixed cadence rather than letting it drift.

This is requirements work, not a model bake-off. The first step is being clear about what each AI workload actually needs to do, and only then matching it to the model that best fits. We treat that as a defined deliverable: a workload-by-workload model selection matrix, with the seven dimensions scored, the choice justified, and the renewal trigger documented. It is the kind of artefact that survives staff turnover and procurement audit alike.

How We Can Help You Decide

If you would like a structured selection exercise across your AI workloads, scoring open-weight and closed options against the dimensions that actually matter to your business, our AI business analysis service produces a clear decision matrix and supplier specification. For deeper governance and supplier management, our fractional AI officer service embeds senior expertise alongside your team. Book a free consultation to talk through your shortlist.