Owning the Weights Is Not Owning the System: What Open-Weight Models Give an Enterprise

For three years the enterprise AI conversation has run on a single question: which model should we use?

It is being replaced by a better one: which models, under whose control, for which classes of work — and how does the organisation decide?

Open-weight models are the sharpest version of that question, because they are the point at which an enterprise can stop renting intelligence and start operating it. That is a genuine strategic option. It is also a transfer of responsibility that is regularly underestimated, because the thing that moves is visible and the things that do not move are not.

Saying that a model is open weight does not answer who controls its runtime, dependencies or update path.

That sentence is from Chapter 15 of my forthcoming book, The Contextual Agentic Enterprise. This article is the short form of the argument around it.

At a glance

• “Open weight” and “open source” are not the same thing, and the difference has procurement and compliance consequences.
• Open weights genuinely transfer five things: inference location, adaptation rights, the shape of the cost curve, disconnected operation, and independence from one provider’s roadmap.
• They do not transfer the supply chain, the regulatory obligation, the evidence burden or the contestability of knowledge.
• The decision belongs to a workload, not to an enterprise. Both “all sensitive work must run locally” and “public APIs are always fine” are architecture by slogan.

First, the definition problem

The two terms are used interchangeably and they do not mean the same thing.

The Open Source Initiative’s Open Source AI Definition 1.0 sets out four freedoms — to use the system for any purpose without seeking additional permission, to study how it works and how its results are generated, to modify it for any purpose including changing its outputs, and to share it with or without modifications. Meeting them requires the training code, sufficient information about the training data, and the parameters.

A published set of weights, on the OSI’s reading, “fall[s] short of this because they do not provide the underlying training process, code, or comprehensive data details required for full-fledged use, study, modification, and sharing.”

This matters beyond terminology in two places. In procurement, a licence that permits deployment is not the same as one that permits any use — several widely deployed weight releases carry acceptable-use terms, field-of-use restrictions or user-count thresholds. In compliance, the labels are load-bearing: under the EU AI Act, the free and open-source exemption in Article 53(2) relieves providers of the technical-documentation and downstream-information duties in 53(1)(a) and (b), but not of the copyright policy in (c) or the public training-content summary in (d) — and “this exception shall not apply to general-purpose AI models with systemic risks.”

If the architecture record says “open source model” where it should say “weights published under a restricted licence”, the obligation analysis that follows it is built on the wrong noun.

What open weights genuinely give an enterprise

Five things, and they are not small.

Placement. Inference can run inside a boundary the organisation defines: a regional environment, a dedicated tenancy, an on-premises cluster, an edge device, a disconnected facility. Chapter 15 formalises this as a small set of Sovereign Inference Zones — a deliberately short list, because too many placement profiles make governance harder rather than easier.

Open weights are what make S3 possible at all, and what make S2 a design choice rather than a vendor’s product decision.

Adaptation. The right to fine-tune, quantise, distil, prune and serve a model on your own terms is the difference between configuring a capability and engineering one. For narrow, high-volume, domain-specific work, a small adapted model frequently outperforms a large general one on the only benchmark that matters — the organisation’s own.

The shape of the cost curve, not simply its height. Self-hosting trades metered per-token spend for fixed infrastructure. That is a change of shape: capital and capacity planning replace variable draw. It rewards high, predictable volume and punishes spiky, low-volume experimentation. Chapter 22 treats model routing as an economic decision for this reason — the question is never “is this model cheaper per token” but “what does a resolved outcome cost, retries and escalations included.”

Operation without the network. A model whose weights you hold can serve a factory floor, a vessel, a remote site or a contested environment. Chapter 15 calls the design obligation here sovereign fallback: a defined local degraded mode, specified in advance, rather than an outage discovered during one.

Independence from a roadmap you do not control. A provider can deprecate, reprice, re-tune or restrict a model. Held weights do not change underneath you. That is a real form of continuity — provided the rest of the exit architecture exists, which is the subject of the next section.

What they do not transfer

Here is where the book’s argument diverges from the enthusiasm.

1. The supply chain does not shrink; it moves

Chapter 15 is blunt about this. The inference stack is “model weights, tokenisers, adapters, quantisation artefacts, inference servers, GPU drivers, container images, Python packages, compilers and model-serving extensions.” Holding the weights means owning every one of those, including their vulnerabilities, their licences and their update paths.

The chapter’s table of sovereignty anti-patterns names this one directly — the local-model fallacy: local weights are assumed sovereign while memory, telemetry or update channels remain external. The control is to assess the complete execution and supply chain, not the model file.

A sovereign model lifecycle, on the book’s account, needs an approved model registry carrying ownership, licence, source and allowed-use metadata; cryptographic digests and signatures for model artefacts; controlled import into restricted environments; malware and unsafe-serialisation scanning; an SBOM or AI-BOM for the inference stack; versioned model profiles rather than mutable model names; promotion through shadow and regression evidence; and a tested revocation process for when a model, library or provider becomes non-compliant.

That is a platform engineering programme. It is the price of the placement freedom above, and it should appear in the business case beside the token savings.

2. The obligation does not follow the licence

Whatever relief Article 53(2) offers a provider of an openly licensed model, an enterprise deploying one carries its own duties unchanged: risk management, human oversight, transparency to affected people, data protection, sector regulation. A model self-hosted in your own data centre is not a model outside your regulator’s interest. If anything, an organisation that has taken the serving stack in-house has taken on the assurance evidence that a managed provider was previously generating.

3. You now own upgrade management

This is the quiet one. With a managed endpoint, a behaviour change at least has a provider’s version number and a date attached to it. With held weights that your own team quantises, adapts and re-serves, nothing announces the change but your evaluation suite.

Chapter 20 states the rule for the whole model portfolio and it applies with most force here: benchmark the deployed artefact, not the base-model reputation. Capabilities vary by serving stack, quantisation, adaptation and hardware. A published leaderboard score for a base model tells you very little about the quantised, adapted, locally-served artefact that will actually take the call. Version pinning on every record, and a reproducible Execution Fingerprint, are what make a behaviour change explainable three months later.

4. Knowledge in weights is not knowledge you can govern

The most attractive argument for open weights is the most dangerous one if it is taken too far: that an organisation can encode its proprietary knowledge into weights it owns and controls.

In a residency sense this is true. In a governance sense it inverts what the enterprise needs. A fact baked into a model’s parameters cannot be cited, dated, corrected, attributed or revoked the way a fact in a governed knowledge store can. Chapter 21 makes this a named principle — model memory is not organisational truth — alongside a reversibility principle for learning: prefer the mechanism you can undo. Retrieval from a governed store is reversible in an afternoon. A fact trained into weights requires a retraining cycle to remove, and cannot be shown to a reviewer as a source.

Owning the weights changes who holds the knowledge. It does not make the knowledge contestable. Contestability is an architecture property, and it lives outside the model.

The decision belongs to a workload

The book refuses the ideological version of this question, in terms worth quoting:

This trade-space should not be turned into an ideological rule that all sensitive workloads must use local open-weight models or that all public APIs are unsafe. The right choice depends on the workload’s sovereignty envelope. A low-risk public-research task may legitimately use a public managed API. A regulated internal task may require a regional managed service. A classified or disconnected task may require local inference with no internet dependency.

Two constructs carry that decision. The Sovereignty Envelope (Chapter 15) states, per action type, where processing may occur, under whose jurisdiction, with which keys, and what happens when that zone is unavailable. The task envelope (Chapter 20) states what the work actually requires: quality, latency, cost and risk. A routing objective built on those four dimensions — and constrained before it is optimised — is what turns a collection of models into a portfolio.

The ordering is the whole point, and Chapter 20 puts it plainly: constrain first, rank second, never the reverse. A learned router may optimise freely among admissible candidates. It must never be in a position to route restricted context to an unapproved destination. The book lists agent-selected provider — the model choosing where to send work from natural-language instructions — among its sovereignty anti-patterns for exactly this reason.

And underneath all of it, Chapter 20’s opening claim: models are replaceable computational components. An architecture that survives provider churn is one where the semantic fabric, the security policy, the tool contracts and the evaluation suites are untouched when the model changes. Open weights are one good answer to provider dependence. They are not the only one, and they do not substitute for the exit architecture — portable memory; versioned prompts, skills, policies and Context Contracts; provider-neutral capability interfaces; canonical audit event formats; model-role profiles mappable to alternatives; exportable evaluation suites; cryptographic ownership of keys; and periodic exit tests for critical workloads.

Five questions before you self-host

1. Which action types actually require it? Name them. If the answer is “everything sensitive”, the classification work has not been done.
2. Who owns the inference stack on a Tuesday afternoon? A named team, a patch cadence, a vulnerability process and an on-call rotation — or the sovereignty is theoretical.
3. What is the benchmark for the deployed artefact? Not the base model. The quantised, adapted, locally-served version, measured on enterprise evidence.
4. What is the local degraded mode? Write down what the system does when the zone, the hardware or the adapter fails. Untested fallback is not fallback.
5. What did you put in the weights that should have stayed in a store? Anything a reviewer might need to cite, date, correct or revoke belongs in governed memory.

On Monday

Take one workload that has been proposed for self-hosting. Write its sovereignty envelope and its task envelope on a single page: where processing may occur, under whose jurisdiction, with what keys, what happens when that zone is unavailable — and what quality, latency, cost and risk the work actually demands.

If the two pages justify the placement, the open-weight case is real and the engineering programme behind it is now visible and costable. If they do not, you have just saved a platform build, and you have a reusable artefact for the next one.

Open weights create possibility. Contextual orchestration — deciding, per workload, what may be known, where it may be processed, what may be done and what evidence must survive — is what turns that possibility into an enterprise capability.

Where has your organisation found that self-hosting moved a problem rather than solved it — and what did that cost to discover?

References

1. Open Source Initiative, The Open Source AI Definition 1.0. https://opensource.org/ai/open-source-ai-definition
2. Open Source Initiative, Open Weights: not quite what you've been told. https://opensource.org/ai/open-weights
3. European Commission, AI Act Service Desk — Article 53: Obligations for providers of general-purpose AI models. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-53
4. NIST (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Released 26 January 2023. https://www.nist.gov/itl/ai-risk-management-framework
5. OWASP GenAI Security Project (2025) Securing Agentic Applications Guide 1.0. 27 July 2025. https://genai.owasp.org/resource/securing-agentic-applications-guide-1-0/
6. Karimi, H. (forthcoming) The Contextual Agentic Enterprise, Chapters 15, 20 and 21.

Share on LinkedIn (opens in a new tab)