If you’ve followed this series so far, we’ve established that AI is moving beyond simple chat interfaces toward agents that can pursue goals and use tools. We’ve also looked under the hood at the inference services and physical infrastructure required to run them.
In this section, we examine who controls that underlying infrastructure.
Much of the AI market is dominated by a small number of proprietary vendors. They train highly capable models, operate enormous inference platforms, and make those capabilities available through consumer applications, managed organizational tenants, and APIs.
These services are useful. They give institutions immediate access to models that would be difficult and expensive to operate themselves. But relying on any one of them for every AI workload creates a dependency. Prices can change. Models can be retired. Product behaviour and usage policies can shift. A service available in one region today may not be available there tomorrow.
For National Research and Education Networks (NRENs) and the institutions we serve, the question is not whether proprietary AI is good or bad. The question is whether we have enough choice to meet our long-term responsibilities around research, education, privacy, cost, and sovereignty.
Open-weight models give us another option.
Relying on one provider
There are several points of friction when an organization or institution depends exclusively on a proprietary model or platform.
Data governance and sovereignty
Research institutions hold information with very different levels of sensitivity: public documents, unpublished research, student records, security logs, health information, intellectual property, and privileged infrastructure configurations.
A managed commercial service may provide strong contractual protections, regional processing, centralized identity management, and data retention controls. Those controls can make it entirely appropriate for many workloads.
Even so, the institution remains dependent on a third-party entity for managing a portion of its data workflow. This requires a clear understanding of prompt and output processing locations, logging, access privileges, data retention timelines, and applicable legal or contractual frameworks. When dealing with certain categories of sensitive or restricted data, these third-party arrangements might fall short of institutional standards or research compliance needs.
Unpredictable economics
Many commercial models use consumption-based pricing: you pay for the tokens submitted to the model and the tokens it generates in return. This is attractive when usage is small or sparse.
Agentic workloads can introduce chaos and uncertainty into predictive usage, though. Agents rarely perform the same task in the exact same way. While each variation might achieve the same goal, the cost of each task will differ. For example, maybe one time an agent decides it needs to read a 100 MB PDF to reach its goal. That extra step adds an additional cost. At scale, that makes costs harder to forecast.
Product and policy dependency
A proprietary API is more than an endpoint. Workflows can become dependent on one vendor’s model names, tool-calling format, safety behaviour, context limits, identity system, and administrative controls.
Even if another provider offers a similar API, the same prompt may behave differently on another model. An agent that works reliably today may need to be evaluated again after a model update. Portability therefore requires more than changing a URL; it requires good abstractions, repeatable tests, and the ability to compare models against your actual workloads.
There are also broader jurisdictional and supply-chain risks. Access to models and AI infrastructure can be affected by regulation, export controls, corporate decisions, or changes in regional availability. Institutions should not assume that an external capability will remain stable, especially with the current fast paced development of AI.
What does “open-weight” mean?
An AI model is produced by training a mathematical system with a large collection of data. The resulting learned parameters are called its weights.
An open-weight model makes those weights available to download. This allows you to run the model using your own infrastructure rather than sending every request to a proprietary service or inference provider.
The de facto home for these models is Hugging Face. You can think of Hugging Face as something like GitHub for AI models: model creators publish repositories containing model weights, configuration files, documentation, licence information, and often examples showing how to run them. Many of the organizations building open-weight models publish their official releases there, and most popular inference tools know how to download models from the Hugging Face directly.
Hugging Face makes models easy to discover and distribute, but it does not mean that every model on the site has the same level of openness or can be used for any purpose. Each repository has its own publisher, licence, documentation, and collection of files. Those details still need to be reviewed before a model is used within an institutional service.
Open-weight is not necessarily the same as open source.
A model may publish its weights without publishing the training data, the complete training code, or enough information to reproduce the model. Its licence may also restrict commercial use, redistribution, modification, particular fields of use, or the number of users an organization can serve.
Before adopting a model, an institution therefore needs to examine several separate components:
- Are the model weights available?
- Is the inference and training code available?
- Is there meaningful information about the training data and evaluation process?
- What does the licence permit us to use, modify, and redistribute?
- Are there documented security, safety, and operational limitations?
Calling every downloadable model “open source” hides these differences.
Capable Does Not Mean Interchangeable
Open-weight models have improved rapidly. Many can now summarize documents, generate software, call tools, analyze images, and support useful agentic workflows. Smaller models can also be surprisingly effective when they are given a narrow task and good context.
However, there is no single point at which a model crosses a threshold and becomes useful for every case. A model that performs well with coding may struggle with a Juniper router configuration. A model that writes excellent prose may struggle with writing clean code. A model that works well in English may not meet the needs of a multilingual institution.
Published benchmarks and tests are useful data, but they are not substitutes for your own verification. NRENs and member institutions should test models using relevant tasks, context sizes, production agent harnesses, and criteria for accuracy, latency, cost, and safety.
The practical question is not “Which model is best?” It is “Which model is good enough for our specific tasks and how can we validate that?”
What Self-Hosting Changes
When you run an open-weight model on your own infrastructure, your prompts, files, and model responses can remain entirely within your network.
This is the practical advantage of self-hosted inference. Sensitive research data, student information, network configurations, and operational logs do not need to be sent to an external AI provider. You decide where the service runs, who can access it, what gets logged, and how long that information is retained.
You also control the model itself. You can select the model that best fits your workload, continue running a particular version, and upgrade it on your own schedule. A vendor cannot unexpectedly retire the model or change its behaviour underneath your application.
Of course, this control comes with responsibility. Your organization has to operate the hardware, secure the service, manage access, and keep the software current. But for institutions that already operate sensitive research and computing infrastructure, these are familiar responsibilities.
In practical terms, this is what AI sovereignty means for many of us: the model runs on infrastructure we control, and our data stays on our network.
Why This Matters for NRENs
NRENs do not need to become another global AI vendor. We are valuable because we can address the specialized needs of our community that the market does not usually optimize for.
We already have trusted relationships with research and education institutions, high-capacity networks, experience operating shared infrastructure, and a mandate grounded in public benefit. Depending on local roles and partnerships, that puts NRENs in a position to help with:
- Shared inference services governed for the research and education community
- Private network paths and federated institutional identity
- Evaluation of models against regional, multilingual, research, and operational workloads
- Guidance on data classification and appropriate deployment models
- Shared expertise in inference operations, security, procurement, and cost measurement
- Portability standards that keep applications from depending unnecessarily on one provider
This capability does not have to replace commercial services. In many cases, the strongest architecture will be hybrid.
A realistic goal is not to force every workload onto local hardware. It is to ensure that institutions have meaningful choices and can place each workload in an environment appropriate to its data, performance, capability, and cost requirements.
Preserving the Ability to Choose
Vendor lock-in is not caused by using a vendor. It occurs when leaving that vendor becomes impossible or very difficult.
We can reduce that risk by separating agent tools from model providers, using portable API conventions, keeping institutional data in systems we control, recording model and prompt versions, and maintaining evaluation suites that can be run against alternative services.
Most importantly, we should avoid treating the model as the application. Models will continue to change. The durable parts of an institutional AI service are its data governance, identity, workflow design, evaluation criteria, and the evidence used to decide whether a result can be trusted.
In the next post, we’ll leave the architecture behind and start generating some actual outcomes. I’ll show you how we are using a locally hosted, open-weight model to investigate a real network configuration, including where it succeeds, where it makes a confident mistake, and how a human operator verifies the difference.
Missed the previous blogs in this series?
Pt. 1: A primer on agentic AI for network administrators
Pt. 2: Inference Services