When no external API will do, self-hosting Llama may be the only option. INTAI helps you decide.
Every other page in this series covers a platform run by a vendor, with that vendor's own trust and safety team, content filtering and incident response sitting behind it. Open-weight models are different. Once a model such as Llama is deployed on infrastructure you control, there is no vendor safety net underneath it.
That is precisely the point for the organisations that need this route, and precisely the reason it needs to be approached deliberately. Before going further, organisations need to understand:
This is the page where INTAI's governance expertise matters most, because there is no vendor to lean on, and where our implementation capability matters just as much, because someone has to select the infrastructure, deploy the model and build the safeguards a vendor would otherwise provide.
"Open-weight" describes a specific technical and governance arrangement, not a single product. Getting the terminology right matters, because it determines who is responsible for what.
Models whose underlying weights can be downloaded and run on infrastructure you control, rather than accessed only through a vendor's hosted API. No data passes through the model creator's own servers at any point.
The organisation running the model, not the model creator, owns the deployment.
Meta's family of open-weight models, published in several sizes, and the most widely adopted starting point for organisations building a private deployment.
Using Llama does not mean Meta has any visibility of how it is used once deployed.
Other openly-published models, including Mistral and DeepSeek, offer similar deployment characteristics with different capability, licensing and provenance profiles worth evaluating alongside Llama.
Model choice should follow a proper evaluation, not just brand familiarity.
Running the model on servers the organisation owns and controls directly, typically the highest level of data sovereignty available.
Brings the greatest control, and the greatest infrastructure and operational responsibility.
Running the model within an organisation's own cloud tenancy, or in a fully air-gapped environment with no external network connection at all, for the most sensitive work.
The right option depends on the specific sovereignty and connectivity requirement, not a default assumption.
Whichever route is chosen, the defining feature is the same: no data ever reaches the model creator, because the model is running on infrastructure the organisation itself controls.
Most UK SMEs do not need this route, and it would be dishonest to suggest otherwise. Open-weight, self-hosted deployment is a genuine answer to a genuine problem, but it is the right answer for a narrower set of organisations than the marketing around it often implies.
If you are not sure which column describes your organisation, that uncertainty is itself a reasonable place to start a feasibility assessment from, rather than a reason to assume the answer either way.
Vendors selling open-weight deployment tools tend to lead with data sovereignty and stop there. The full picture includes costs that are just as real and considerably less discussed.
Frontier closed models from providers such as Anthropic and OpenAI generally lead open-weight alternatives on raw capability. That gap narrows over time, but it rarely disappears, and it needs to be weighed honestly against the sovereignty requirement driving the decision.
Test the model against your actual use case before committing, not just its published benchmarks.
Running a model privately means acquiring and maintaining the compute infrastructure, and the ongoing MLOps and security expertise to operate it. This is a materially different, and generally larger, cost profile than an API subscription.
Budget for the ongoing operational cost, not just the initial deployment.
Closed vendors provide content filtering, abuse detection and a trust and safety team as standard. None of that comes with an open-weight model. It has to be built in-house or sourced from a third party, and accounted for in the deployment from the start.
This is usually the most underestimated cost in the whole decision.
None of this is a reason to avoid open-weight deployment where it is genuinely needed. It is a reason to make the decision with the full cost, not just the headline benefit, in view.
There is no Anthropic or OpenAI trust and safety team behind a self-hosted model. Every one of the following sits with the organisation running it, in full:
What the model can and cannot be used for, defined and enforced internally.
Building or buying the safeguards a closed vendor would otherwise provide by default.
Recording who used the model, for what, and what it produced, in a form that can be reviewed later.
What happens when something goes wrong, and who is responsible for handling it, without a vendor to escalate to.
Who can use the deployment, and how that access is granted, reviewed and revoked.
Testing the model against your specific use cases before relying on it, rather than trusting published benchmarks alone.
Keeping the model, its serving infrastructure and any safety tooling up to date over time.
Securing the servers, network and storage the model runs on, to the same standard as any other sensitive system.
Who is accountable for a given application of the model.
Which outputs must be checked by a person before they are used or relied upon.
How usage, performance and emerging use cases are tracked over time.
What records exist to demonstrate the deployment is appropriately governed.
These are the situations where a private, open-weight deployment is most commonly the right answer.
Air-gapped document review for law firms handling material protected by legal professional privilege, where no external processing is acceptable under any circumstances.
Reviewing and summarising privileged disclosure material entirely within the firm's own environment.
On-premises drafting support for healthcare providers working with patient data at a scale where external processing is not appropriate, with clinical sign-off remaining with the clinician.
Drafting a first-pass clinical note from structured patient data, checked before use.
Internal applications where a client contract or regulatory undertaking specifically prohibits sending data to any third-party API, regardless of that provider's own terms.
A document analysis tool built to satisfy a specific client confidentiality clause.
Secure analysis of sensitive material for organisations operating in or alongside the defence and national-security sector, where data cannot leave an accredited environment.
Summarising technical documentation within an accredited, air-gapped environment.
Family offices and similar organisations analysing highly confidential financial and personal information where discretion is a core part of the client relationship, not just a compliance requirement.
Reviewing sensitive financial documents without any of the content reaching a third party.
A self-hosted model can produce useful output quickly, with no vendor checking that output behind the scenes. Organisations need to determine:
With no vendor safety net, the appropriate level of oversight needs to cover the infrastructure and tooling as well as the individual output.
This route exists specifically for organisations with genuine data-sovereignty constraints. Sectors we see it most often in include the following.
INTAI helps these organisations consider private AI deployment within existing governance, risk, compliance and security structures, rather than treating it as a separate, isolated project.
Can your organisation answer these questions? Tick the statements that already apply to generate an indicative feasibility score. It does not replace a formal assessment, but it helps show where the gaps are before committing to a private, open-weight deployment.
The profile reflects the number of statements ticked above. It does not replace a formal assessment, but it helps show where attention is needed before committing.
Tick the statements that apply to your organisation to generate an indicative feasibility profile.
0-7 | Requirement Unclear
The underlying requirement, or the governance to support it, is not yet well defined. The priority is a feasibility assessment before committing to infrastructure spend, including whether a zero-retention API might actually be enough.
8-14 | Building the Case
The requirement is becoming clearer, but gaps remain in governance, infrastructure planning or budget. Closing these gaps before committing reduces the risk of an expensive, ungoverned deployment.
15-20 | Ready to Proceed
The requirement and the governance around it both look well defined. The remaining work is largely around infrastructure selection, deployment and ongoing assurance.
This checklist provides an indicative view only and should not be treated as a formal AI governance assessment, legal opinion or assurance conclusion.
INTAI can help you assess whether a private, open-weight deployment is genuinely necessary, and build a practical, proportionate plan around it if it is.
Book a Feasibility AssessmentINTAI supports organisations end-to-end, from an initial feasibility conversation through to a governed, monitored deployment. Because this route involves genuine infrastructure and model decisions, our role covers both governance and hands-on implementation.
We start by understanding why a private or open-weight deployment is being considered, what problem it is meant to solve, and what has already been tried, including any hosted AI tools already in use.
A clear statement of the problem and the constraint driving it.
We test whether a private deployment is genuinely justified against the alternatives, including zero-retention API terms and enterprise agreements with existing vendors, before recommending the more demanding route.
A feasibility assessment with a clear recommendation.
Where a private route is justified, we help select the appropriate model, whether Llama or a comparable open-weight alternative, and the infrastructure to run it, whether self-hosted, private cloud or air-gapped.
A recommended model and infrastructure configuration.
We design the acceptable-use policy, access controls, content filtering, audit logging and incident response arrangements that a self-hosted model needs, since none of this is provided by a vendor.
A governance framework specific to the deployment.
We support the technical deployment of the selected model into the chosen environment, working alongside your infrastructure or MLOps team where one exists, or providing that capability where it does not.
A working deployment in the agreed environment.
We run a controlled pilot with a defined group of users and use cases, so issues with the model, infrastructure or governance framework surface before wider rollout.
A pilot with defined success criteria.
We train the people who will use the deployment, covering what it can and cannot do, how outputs should be verified, and what the acceptable-use policy requires of them.
Role-appropriate training for users and administrators.
Once live, we provide ongoing monitoring and review of the deployment, including model performance, evolving risks and any changes needed to the governance framework as use develops.
Ongoing assurance and periodic review.
This sits alongside our wider AI implementation services, for organisations that need support across more than one platform.
Some organisations reach this page already running a proof-of-concept or pilot deployment of Llama or another open-weight model, often built by a technical team without a full governance framework around it. INTAI can work with an existing deployment to understand:
The objective is not to undo a working pilot.
It is to put the governance framework around it that a production deployment needs but a pilot often does not have.
A self-hosted model has no vendor onboarding, support desk or built-in guidance for users. Training needs to cover both the people using the deployment and the people running it:
The second group is often overlooked, but a self-hosted deployment is only as safe as the team operating it.
Explore AI TrainingOpen-weight models are updated by their publishers, infrastructure ages, and employees find new uses for a deployment that was originally built for one narrow task.
Organisations therefore need to continue reviewing:
INTAI can provide ongoing governance and assurance as a private AI deployment matures.
Explore Governance as a ServiceBefore committing to a private or open-weight deployment, it is worth testing that conclusion against the simpler alternative one more time. A zero-retention or enterprise API from a closed provider is generally cheaper, faster to deploy and comes with vendor-provided safety tooling that a self-hosted model does not.
The private route is generally the right answer only when at least one of the following is true:
If none of these apply, a governed API deployment of a closed model is usually the more proportionate route, and INTAI can help assess which fits your circumstances.
Compare AI PlatformsINTAI does not start with a preferred AI vendor. We help organisations assess and govern technologies including Meta Llama and other open-weight models, Google Gemini, Microsoft Copilot, ChatGPT / OpenAI, Claude / Anthropic, Amazon Bedrock, IBM watsonx, Perplexity, and private or self-hosted AI infrastructure.
The appropriate platform depends on what the organisation is trying to achieve, the sensitivity of its data, its existing technology environment and the level of governance and control required. Where appropriate, INTAI can support the complete journey from initial selection through to ongoing governance.
Recommendations are shaped by an organisation's requirements, risk profile and regulatory exposure, not by which platform or infrastructure we sell. Where a client has already committed to a private or open-weight deployment, we work within that constraint and focus on making its use appropriately governed, effective and aligned with organisational requirements.
INTAI does not imply partnership, endorsement or certification by the technology providers referenced unless explicitly stated. Prices, service names and specific figures referenced elsewhere on this page are indicative and subject to confirmation.
An open-weight model is one whose underlying model files can be downloaded and run on infrastructure you control, rather than accessed only through a vendor's hosted API. Meta's Llama models are a well-known example, alongside other openly-published models such as Mistral and DeepSeek.
Not generally, no. Frontier closed models from providers such as Anthropic and OpenAI typically lead on raw capability, and come with vendor-provided safety tooling and support. Open-weight models are chosen for a different reason: they can run entirely on infrastructure you control, which matters when no external API is acceptable at all.
For most organisations, a zero-retention or enterprise API from a closed provider is enough, and is simpler and cheaper to run than private infrastructure. Open-weight, self-hosted deployment is generally only necessary where a specific contractual, regulatory or client confidentiality undertaking genuinely prohibits sending any data to any external service, regardless of that provider's retention or training terms.
This depends heavily on the model size, the infrastructure chosen, and the level of governance tooling built around it, and is significantly more than the cost of an API subscription. Organisations should expect to budget for compute infrastructure, MLOps and security expertise, and the governance and safety tooling that a closed vendor would otherwise provide, not just the model itself.
Most UK SMEs do not need this route. It is generally relevant only to organisations with a genuine data-sovereignty constraint, such as law firms bound by specific client confidentiality undertakings, healthcare providers handling health data at scale, defence-adjacent businesses, and family offices, where no data can leave the organisation's own infrastructure under any circumstances.
The main trade-offs are a capability gap against frontier closed models, the ongoing infrastructure and MLOps cost of running and maintaining the deployment, and the fact that the safety and governance tooling a closed vendor provides by default has to be built or bought separately.
The organisation is. There is no vendor trust and safety team behind a self-hosted open-weight model, so the organisation running it owns the acceptable-use policy, content filtering, audit logging and incident response in full.
Yes, this is one of the more common use cases, typically as air-gapped document review where privileged material cannot be sent to any third-party service. It still requires the same governance discipline as any other deployment: access controls, audit logging and clear rules on what the model can and cannot be used for.
Yes. INTAI supports infrastructure and vendor selection as part of a wider feasibility assessment, helping organisations choose an appropriate model and hosting environment based on their specific data-sovereignty, performance and budget requirements.
Yes, more so than with a managed vendor product. Because there is no vendor trust and safety team, the organisation needs its own acceptable-use policy, content filtering approach and incident response process in place before the deployment goes live.
Training should cover what the deployment can be used for, its limitations, how outputs should be verified, and how to escalate problems. Technical and administrative staff also need training on operating and governing the underlying infrastructure, which is not required with a managed vendor product.
The appropriate level of human oversight depends on the risk and consequences of the use case, as with any AI deployment. With a self-hosted model, oversight also needs to cover the infrastructure and safety tooling itself, since there is no vendor safety net checking outputs behind the scenes.
Monitoring should cover model and infrastructure performance, usage patterns, content filtering effectiveness, incidents, and whether the governance framework still matches how the deployment is actually being used, reviewed at a similar cadence to other business-critical infrastructure.
Yes. INTAI regularly works with organisations that have already started a proof-of-concept or pilot deployment, helping them build the governance framework, audit logging and incident response process that a production deployment needs but a pilot often does not have.
INTAI supports the full journey from feasibility assessment through infrastructure and model selection, building a governance framework from scratch, deployment, staff training and ongoing assurance, since a private deployment needs delivery capability as well as governance advice.
Whether you are exploring Llama, weighing up a private deployment against a governed API, or already running a pilot, INTAI can help you assess feasibility and build the governance framework a self-hosted model needs.