Self-Hosted Open-Weight AI Model Governance
Establish an intake policy and governance controls for AI model weights downloaded from public repositories and deployed in the organization's own infrastructure, addressing integrity verification, license compliance, safety evaluation before deployment, and ongoing update management distinct from vendor-hosted AI procurement.
Objective
Prevent unvetted, unsafe, or license-non-compliant AI model weights from being deployed in organizational infrastructure, by requiring intake assessment, weight integrity verification, safety evaluation, and documented approval before any open-weight model is used in production.
Maturity Levels
Initial
Developers download and deploy open-weight AI models without a formal intake process. There is no central visibility into which open-weight models are running in organizational infrastructure, no integrity verification, and no safety evaluation before deployment.
Developing
Engineering or security teams are aware of open-weight model governance requirements and may conduct ad hoc reviews for high-profile deployments, but there is no standardized intake process, license tracking, or safety evaluation framework for this model category.
Defined
An open-weight model intake policy defines: required sources and verification steps for model weights (hash verification, source authentication), license review and classification for each model, safety evaluation requirements before production deployment, and an intake record in the AI inventory. All open-weight models used in production must complete the intake process.
Managed
The organization maintains an inventory of all open-weight models in use with version tracking and license documentation. Update management is defined: when a new model version is released, a defined process determines whether to update (re-evaluating safety and license) or stay on the current version. Security monitoring for vulnerabilities in deployed model infrastructure is in place.
Optimizing
Open-weight model governance is integrated into the software supply chain security program. Model card review and community safety research are systematically incorporated into intake evaluation. The organization participates in model safety research sharing for open-weight models it deploys. License compliance is audited annually.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Open-weight model intake policy defining source verification, license review, safety evaluation, and approval requirements.
- —AI inventory records for all open-weight models in production use, including version, source, hash verification record, license classification, and safety evaluation status.
- —License review documentation for each open-weight model in use, with legal counsel review for models with non-standard license terms.
- —Safety evaluation records for open-weight models deployed in production, including evaluation methodology and any mitigations applied.
- —Update management log showing decisions made when new versions of deployed open-weight models were released.
Implementation Notes
Why open-weight models need their own governance controls
Organizations that deploy open-weight AI models — model weights available for download from Hugging Face, model provider repositories, or community sources — face a governance challenge distinct from vendor-hosted AI procurement. The vendor-hosted AI procurement controls (PRC domain) are designed for a procurement relationship: there is a vendor, a contract, a service level, and ongoing communication about changes.
Open-weight models have no vendor relationship. There is no contract, no SLA, no incident notification, and often no clear commercial entity responsible for the model. The governance risks are:
No ongoing safety assurance: A vendor-hosted AI model is supported by the vendor's ongoing safety team, red-team cycles, and update cadence. An open-weight model deployed in organizational infrastructure receives the organization's own infrastructure security — but the model weights themselves reflect the safety evaluation and RLHF applied at the time of release. If new attack methods emerge that exploit the model, there is no vendor to patch it; the organization must update to a new model version or apply its own mitigations.
Supply chain integrity risk: Open-weight model weights downloaded from public repositories may have been tampered with. Malicious actors have demonstrated the ability to upload modified model weights to public repositories that include backdoors, trojans, or unsafe capabilities. Without weight integrity verification, an organization cannot confirm that the model it deployed matches the model it believed it was deploying.
License complexity: Open-weight models are released under a variety of licenses — Apache 2.0, MIT, Llama Community License, Gemma Terms of Use, various research-only licenses — with materially different restrictions on commercial use, modification, and redistribution. Deploying a model under a license that does not permit the intended use creates legal risk. License terms for popular models have been updated over time; the organization must track which version it is using and its license terms.
Safety evaluation responsibility: For vendor-hosted models, the vendor has conducted safety evaluation and maintains safety filters. For self-hosted open-weight models, the organization is responsible for safety evaluation in its deployment environment. A model that behaved safely in default configuration may behave differently with the organization's system prompts, fine-tuning, or retrieval augmentation.
Intake process for open-weight models
Step 1: Source verification
- Download only from the model provider's official repository or verified mirror (confirmed via SHA256 hash against the hash published by the model provider)
- Do not deploy model weights from unofficial community uploads without independent hash verification
- Document the download source, version, and hash verification result
Step 2: License review
- Identify the license governing the model weights
- Determine whether the intended use is permitted under the license (commercial use, modification, redistribution as applicable)
- Document the license classification: permissive commercial, restricted commercial, research-only, or custom
- Flag for legal review any model with non-standard license terms or use-case restrictions
Step 3: Model card review
- Review the model card for: training data, known limitations, intended use, out-of-scope uses, and safety evaluation results
- Document any safety concerns identified in the model card
- Check community safety research (published papers, red-team findings) for known vulnerabilities or unsafe behaviors
Step 4: Safety evaluation
- Conduct internal safety evaluation appropriate to the intended use case and risk tier (per HOC-001)
- For high-risk use cases: red-team evaluation (SAF-005) using scenarios relevant to the deployment context
- Document evaluation results and any mitigations required before deployment
Step 5: Intake record and approval
- Create intake record in AI inventory per MGV-002
- Document: model name, version, source, hash, license, model card summary, safety evaluation results, intended use, and approval
- Obtain required approvals per the intake policy (risk tier determines approval authority)
Update management for deployed open-weight models
Unlike vendor-hosted models that update automatically or through contract-managed processes, open-weight model updates require a deliberate decision. When a new model version is released:
- Review the changelog and any new safety evaluations for the new version
- Determine whether to update (new version has meaningfully improved safety or capability) or stay (current version adequate; update cost not justified)
- If updating: repeat the intake process for the new version before replacing the deployed version
- Document the update decision and rationale
Example Implementation
Open-Weight Model Intake Record — [Model Name]
Intake ID: OWM-2026-014 | Date: [Date] | Submitted by: [Engineering team]
Model identity:
- Name / version: Llama 3.3 70B Instruct
- Source: Meta AI official repository (huggingface.co/meta-llama)
- SHA256 hash (downloaded): [hash value]
- SHA256 hash (published by Meta): [hash value]
- Hash match: Yes — verified [date]
License:
- License: Llama 3 Community License Agreement (Custom)
- Commercial use permitted: Yes (with conditions — see license for user threshold restrictions)
- Modification permitted: Yes
- Redistribution: Restricted — must include attribution; may not remove safety filters
- Legal review: Reviewed by [counsel name] [date]. Confirmed: permitted for intended commercial SaaS use at current user scale.
Model card review:
- Training data: Publicly available internet text, licensed data, Meta-curated datasets; PII filtered
- Intended use: General-purpose language understanding and generation
- Out-of-scope: Providing medical, legal, or financial advice as sole information source
- Known limitations: May generate plausible-sounding but inaccurate information; limited knowledge cutoff
- Safety evaluation (Meta): RLHF applied; red-team results indicate low refusal bypass rate on direct harmful requests; 91.3% harmful content refusal rate on Meta's test set
Internal safety evaluation:
- Evaluation conducted: [date] by [team]
- Methodology: Internal red-team using use-case-specific scenario set (customer service + internal assistant)
- Findings: Refusal rate on harmful requests: 89.8% (slightly below Meta benchmark — likely attributable to our system prompt configuration). Two jailbreak vectors identified; mitigations applied (system prompt reinforcement, output filter for identified patterns).
- Mitigations applied: Yes — documented in eval report OWM-EVAL-2026-14
Intended use: Internal assistant for customer service drafting and knowledge base search; not customer-facing. Risk tier: Medium (per HOC-001: internal use, advisory output, human review of customer communications) Approval authority: AI Governance Committee (Medium tier) Approval status: Approved [date]