How do we intake and govern open-weight and self-hosted AI models?

When an organization uses a model through an API, most of the infrastructure-level governance burden sits with the vendor: they manage model updates, apply safety fine-tuning, 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 output guardrails (no vendor-side 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 introduce weight integrity as a distinct control surface. Downloaded model weights can be tampered with in transit or at rest. Organizations that do not verify the integrity of downloaded weights against published checksums or cryptographic signatures cannot confirm they are running the model they believe they are.

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 adversarial testing suite before deployment. For models that will be exposed to external user input, include prompt injection and jailbreak testing. Third, performance benchmarking: validate that the model performs acceptably on your specific use case — do not assume published benchmark scores translate to your domain.

Fourth, risk classification: apply your standard AI risk classification framework. A self-hosted 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.

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 fine-tuning applied at deployment becomes misaligned with the current production context.

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 weights when the model is decommissioned? Weights should be deleted from all environments, and the deletion should be logged. Leaving unused model weights in accessible storage is a security risk.