Permission
Check the actual licence and intended use.
Article · Adoption
Access to a model creates options. It does not settle how the model should be used, operated or supported.
At a glance
Check the actual licence and intended use.
Evaluate the task and likely failure cases.
Agree who runs, updates and supports the system.
Open weights do not remove operating responsibilities.
An open-weight release can make a model available for testing and deployment under its published terms. For a product team, that may create useful choices about infrastructure, customisation and dependence on a hosted provider.
Those choices deserve evaluation. Downloading the model is the beginning of the operating decision, not its conclusion.
Start with the model version, the source from which it will be obtained and the terms attached to it. Include the inference code, libraries and other components required to run the application.
“Open-weight” and “open source” should not be used interchangeably. The Open Source Initiative’s definition includes permissions and access to the material needed to study and modify an AI system; weights alone do not establish that status. Open Source AI Definition.
The practical question is what your intended use requires. Will you host a service, distribute a product, modify the model or pass outputs into another commercial system? Record the relevant permissions and restrictions, and obtain legal interpretation where the terms are unclear.
Choose a representative set of work before looking at the results. Include ordinary cases, difficult cases and examples where the correct response is to stop or ask for clarification.
For a document assistant, that might include conflicting source documents, an answer absent from the material and a question whose wording is different from the relevant passage. Test the complete application, including retrieval and prompts, because users experience the combined result.
Keep the same evaluation brief for the current system and the alternative. If you optimise one configuration more heavily, record that difference so the comparison remains interpretable.
Self-hosting can give the organisation control over where inference runs. It does not automatically keep every interaction within that boundary.
The application may still use external embedding services, telemetry, error reporting, update services or remote tools. A model with no direct network access can sit inside an application that sends information elsewhere.
Map those connections and test the intended configuration. Decide who may access prompts, outputs, logs and stored documents, including during support and incident investigation.
Someone needs to manage deployment, capacity, security updates and recovery. If the model requires specialist hardware, include availability and support in the decision alongside measured performance.
For variable workloads, compare what happens during quiet periods and peaks. A continuously provisioned system and a usage-priced service have different cost patterns. Neither can be judged from a model price alone.
Include human work too. A cheaper configuration that needs more checking or produces more failed tasks may cost more to operate for the use that matters.
Pin the release used in the evaluation and record the supporting configuration. Agree how a later version will be tested and who can authorise its introduction.
A useful release record makes it possible to connect a result to the version that produced it. It also helps the team return to an earlier configuration if a change causes problems.
The NCSC’s guidance covers systems built from existing models and services as well as systems developed from scratch. It places secure operation and maintenance alongside design, development and deployment. NCSC secure AI guidance.
A model’s country of origin may be relevant to supplier due diligence, applicable law, support and procurement requirements. It does not replace examining the actual licence, deployment, dependencies and data flows.
A model developed in one country can be operated under several different arrangements. Equally, a familiar provider can introduce dependencies that a buying team has not examined. Apply a consistent standard of evidence to both.
The result should be a reasoned choice: adopt within a defined scope, run a limited trial, request more evidence or choose another option. Each is a useful outcome when the decision is clear.
Next step: Read Comparing AI options without hiding the operating cost, or talk to Beeston Labs about a task-specific model evaluation.
Working through this in your organisation?
Explore the related serviceA useful place to start
Tell us what you are building, adopting or trying to understand.