Question 36 of 53
How do we intake and govern open-weight and self-hosted AI models?
By Cody Maxwell · AI Governance Institute · March 2026 · Updated September 2026
Review open-weight models before downloading, fine-tuning, or self-hosting them. Set deployment and maintenance controls suited to those responsibilities.
If you only do 3 things, do this:
- 1.With an open-weight model, you download the model files (the weights) and run them yourself, so the security work moves in-house. You own the defenses against hidden malicious instructions (prompt injection), the checks on what the model outputs, and the schedule for updates. There is no vendor to call when something goes wrong.
- 2.Treat model files as critical software: confirm on download that they have not been tampered with, store them where access is controlled, and document where they came from, back to the original release.
- 3.The biggest governance gap in open-weight deployments is the absence of a model update process: teams download a model, deploy it, and never revisit it. Define an update cadence and a process for evaluating new releases before deploying them.
The Situation
Who this is for: AI Engineering, Security, and GRC teams at organizations considering or actively using Llama, Mistral, Falcon, or other open-weight models in production
When you need this: Before the first open-weight model is deployed to production, or when conducting a governance audit of existing self-hosted deployments
The Decision
What governance controls apply specifically to open-weight models, and how do they differ from API-based vendor controls?
The Steps
- 1Create an intake checklist for open-weight models: licensing review, security assessment, performance benchmarking, and risk classification
- 2Confirm the downloaded model files match what the developer published, using the published checksums or digital signatures (digital fingerprints that reveal tampering)
- 3Store model files in a controlled storage location that logs who accessed them
- 4Document how the model is set up: any compression applied to make it run on cheaper hardware (quantization), where it runs, what output safety checks are in place, and any additional training on your own data (fine-tuning)
- 5Before deployment, have testers actively try to make the model misbehave, since no vendor has done this for you
- 6Define a model update policy: how often do you evaluate newer releases, and what criteria trigger an upgrade or replacement
- 7Assign a named owner responsible for monitoring security disclosures and community findings related to the deployed model
The Artifacts
- —Open-weight model intake checklist (license review, security assessment, integrity verification, risk classification)
- —Model setup template (model file version, compression settings, output safety checks, fine-tuning log)
- —Model update and retirement policy for self-hosted deployments
- —Model file tamper-check log (download date, checksum, result)
The Output
Every open-weight model in production has a documented intake record, a named owner, verified weight integrity, and a scheduled update review.
How open-weight governance differs from vendor API governance
When an organization uses a model as a vendor-hosted service, most of the behind-the-scenes governance work sits with the vendor: they manage model updates, train in safety behavior, monitor for misuse, and publish security advisories. When an organization downloads and self-hosts an open-weight model, that burden transfers entirely to the organization. This is a significant governance shift that is frequently underestimated.
The most important differences are: the organization owns the checks on what the model outputs (no vendor safety filters apply unless you build them); the organization is responsible for monitoring security disclosures and community findings about model vulnerabilities; and the organization must manage its own update cadence, including evaluating whether new model releases improve or change the risk profile.
Open-weight models also add a new thing to control: whether the model files themselves are genuine. Downloaded files can be tampered with on the way in or while in storage. Organizations that do not check them against the developer's published checksums or digital signatures cannot confirm they are running the model they think they are.
The intake process
Every open-weight model entering production should go through a structured intake process before deployment. This should cover four areas. First, licensing: open-weight models carry widely varying license terms: some prohibit commercial use, some restrict specific industries, some impose attribution requirements, and some (including the Llama 2 license) have restrictions on use by large organizations. Legal must review the license before deployment.
Second, security assessment: run the model through your standard attack testing before deployment. For models that will receive input from outside users, test whether hidden instructions can hijack it (prompt injection) and whether clever wording can talk it past its safety rules (jailbreaks). Third, performance testing: confirm the model works acceptably for your specific use case, and do not assume published test scores carry over to your business.
Fourth, risk classification: apply your standard AI risk classification framework. A self-hosted large language model (LLM) handling customer queries is still a Significant-risk system regardless of how it was deployed. The intake process should produce a signed record showing who reviewed what and when.
Ongoing maintenance obligations
The most common governance failure in open-weight deployments is the absence of a model maintenance process. Teams deploy a model and do not revisit it. Over time, the gap between the deployed model and current releases grows; new attack techniques emerge that the model has not been tested against; and any extra training applied at deployment drifts out of step with how the model is now being used.
Define a model update review cadence: quarterly for Critical-tier deployments, semi-annually for others. Assign a named owner who monitors the model's originating community (Hugging Face, GitHub, the model developer's security channels) for safety disclosures and significant new releases. When a new release appears, the owner evaluates whether it warrants an upgrade and documents the decision.
Also define a retirement process: what happens to the model files when the model is decommissioned? They should be deleted from every system that holds a copy, and the deletion should be logged. Leaving unused model files in accessible storage is a security risk.
Governance Controls
Operational controls that implement the guidance in this playbook.
Related frameworks
Recent Coverage
News and developments relevant to this playbook topic.
Not sure where to start? Answer 3 questions and get a tailored compliance action plan.
What applies to me? →More guidance like this, every week
New playbook articles, governance controls, and the regulatory changes driving them. Every Thursday.