Implementation Kit
Open-Weight AI Model Intake and Deployment Checklists
The controls that only apply when you download and self-host: license review, weight integrity verification, deployment configuration capture, and the pre-deployment testing no vendor did for you. An intake checklist, a config template, an integrity log, and an update policy.
Who this is for: The platform or ML owner bringing an open-weight or self-hosted model into production.
1. Open-weight model intake checklist
SpreadsheetThe gate for a self-hosted model. License, security, integrity, and classification before anything runs.
Template
| Check | Status | Evidence |
|---|---|---|
| License reviewed; permitted uses and redistribution terms understood | Y / N | |
| Model card / release notes reviewed for known limitations and evals | Y / N | |
| Weights downloaded from the official source over a verified channel | Y / N | |
| Integrity verified against a published checksum or signature | Y / N | |
| Security assessment: known CVEs, unsafe deserialization, bundled code | Y / N | |
| Pre-deployment adversarial testing run (prompt injection, jailbreak, harmful content) | Y / N | |
| Risk tier assigned via the classification method | Y / N | |
| Named owner for security-disclosure monitoring assigned | Y / N |
Worked example
| Check | Status | Evidence |
|---|---|---|
| License reviewed | Y | Apache-2.0; commercial use OK; attribution noted |
| Model card reviewed | Y | Weak non-English coverage; eval suite dated |
| Weights from official source | Y | Downloaded from the vendor HF org |
| Integrity verified | Y | SHA-256 matched the published manifest |
| Security assessment | Y | safetensors format; no pickle; no CVEs open |
| Adversarial testing run | Partial | prompt-injection + jailbreak done; harmful-content suite pending |
| Risk tier assigned | Y | Limited (internal drafting, no personal decisions) |
| Disclosure-monitoring owner | Y | ML Platform on-call |
| Gate | Blocked | complete the harmful-content suite |
Acceptance criteria
- ✓No self-hosted model serves traffic before every check passes or a named approver logs a time-boxed exception.
- ✓Adversarial testing is run in-house, since no vendor has done it.
- ✓The license review names the specific license and its commercial and redistribution terms.
2. Deployment configuration template
SpreadsheetA record of exactly what is running: which weights, at what precision, behind what guardrails, with what fine-tuning.
Template
| Field | Entry |
|---|---|
| Model and version | |
| Source and download URL | |
| Published checksum / signature | |
| Computed checksum at deploy | |
| Quantization / precision | |
| Serving stack and version | |
| Guardrail configuration (input filter, output filter, system prompt) | |
| Fine-tuning applied (dataset, method, date) | |
| Inference infrastructure and isolation | |
| Rollback target |
Worked example
| Field | Entry |
|---|---|
| Model and version | OpenLM-2 13B, release 2026-07 |
| Source | vendor Hugging Face org, tag v1.0 |
| Published checksum | sha256:4b91... (manifest signed) |
| Computed at deploy | sha256:4b91... (match) |
| Quantization | 8-bit (bitsandbytes) |
| Serving stack | vLLM 0.6.x |
| Guardrails | input PII filter; output harmful-content filter; system prompt v4 |
| Fine-tuning | LoRA on 12k internal support transcripts, 2026-08-05 |
| Infra | dedicated GPU node pool, no egress to public internet |
| Rollback target | previous LoRA adapter v3 |
Acceptance criteria
- ✓The computed checksum at deploy is recorded and matches the published one.
- ✓Every guardrail and any fine-tuning is captured, with dates.
- ✓The config is version-controlled and updated on any change to weights, quantization, or guardrails.
3. Weight integrity verification log
SpreadsheetA running record that every set of weights placed in the artifact repository was verified.
Template
| Model | Version | Download date | Published checksum | Computed checksum | Match | Verified by |
|---|---|---|---|---|---|---|
| <model> | <version> | YYYY-MM-DD | <hash> | <hash> | Y / N | <name> |
Worked example
| Model | Version | Download date | Published checksum | Computed checksum | Match | Verified by |
|---|---|---|---|---|---|---|
| OpenLM-2 13B | v1.0 | 2026-07-30 | sha256:4b91... | sha256:4b91... | Y | ML Platform |
| OpenLM-2 13B | v1.1 | 2026-09-02 | sha256:7c02... | sha256:7c02... | Y | ML Platform |
Acceptance criteria
- ✓Every set of weights in the repository has a log entry with a match result.
- ✓A mismatch blocks use and triggers a re-download from the official source.
- ✓The artifact repository has access controls and audit logging separate from this log.
4. Update and retirement policy
DocumentHow often you evaluate newer releases, what triggers an upgrade, and how a self-hosted model is retired.
Template
One page.
Evaluation cadence: review newer releases of the deployed model family every <N> months, and within <N> days of a release flagged for a security fix.
Upgrade triggers: a security advisory affecting the running version; a new release with a material capability or safety improvement on our eval suite; a license change.
Upgrade process: run the full intake checklist for the new version; compare on the internal eval suite; stage before production; keep the prior adapter as rollback.
Retirement: delete weights from serving infrastructure and the artifact repository per the data policy; archive the deployment config, eval history, and integrity log; update the registry and inventory; owner sign-off.
Worked example
OpenLM-2 update log:
- 2026-09-02: v1.1 released with a tokenizer security fix. Intake checklist re-run; eval delta negligible; promoted to production 2026-09-04; v1.0 adapter kept as rollback for 30 days, then archived.
- Next scheduled family review: 2026-12.
Acceptance criteria
- ✓The evaluation cadence is a specific interval, and a security release short-circuits it.
- ✓An upgrade re-runs the full intake checklist, not a subset.
- ✓Retirement removes weights from both serving infra and the artifact repository.
Governance controls this kit produces evidence for
Completing the artifacts above gives you a head start on the evidence requirements for these controls.
The whole kit is the self-hosted open-weight model governance process: intake, config, integrity, updates.
The license-review step of intake covers open-source license compliance for model artifacts.
The access-controlled artifact repository and infra isolation fields evidence AI system access controls.
The pre-deployment adversarial testing step is the adversarial robustness testing record.
The intake checklist is the approval gate for self-hosted models entering production.
This kit backs one playbook. Read the full guidance for the reasoning behind each artifact.
Decide what to implement next
Assess your governance gaps, then create an action plan with owners and target dates. Build and export without an account; sign in when you want to save your plan.
Start the AI governance assessment →