AI Model Intake and Approval Checklist
The gate a model passes before it reaches production. Say where the model comes from and how it will be used; the checklist picks the items that matter for that context, marks each as a blocker, major or minor, and turns your answers into a decision: approve, approve with conditions or reject, with the reasons. Every item names the AIBOM field where its evidence belongs.
Who this is for: CISOs and security leads who sign off AI models and vendors, and AppSec and AI-security engineers who run the review. The item list and the decision rule are below; Pro runs the checklist and adds the approval record. Not legal advice.
What this tool is
- Pick where the model comes from (open weights from a hub, a commercial API, fine-tuned in-house, or embedded in a vendor product) and its risk context (internal tool, customer-facing, regulated decision, plus agentic if it can call tools).
- The checklist adapts: up to 37 items across seven areas, between 23 and 34 for any one context. Each is a blocker, major or minor for that context.
- Mark each item pass, fail or N/A and write the evidence. Every item names the AIBOM field that records it, in CycloneDX and, where one exists, SPDX.
- You get a decision by a fixed rule (approve, approve with conditions, or reject) with the reasons and the list of conditions.
- Downloads: a PDF approval record with a sign-off block, a CSV, a JPG of the decision card, and the decision as a CycloneDX annotation for your AIBOM.
- It records what the reviewer answered. It does not check the evidence, and it is not legal advice.
How the decision is made
- Reject if any blocker failed or is unanswered. Unanswered items count as not passed, so the result is always “the decision if you submitted now”.
- Approve with conditions if no blocker is open, but a major or minor item failed or is unanswered, or a blocker or major item is marked pass or N/A with no evidence written. A pass without evidence is a claim.
- Approve when every applicable item passed or does not apply, and each blocker and major item has evidence.
Severity depends on context. Safe serialization is a blocker for any model you host and does not apply to an API. Fairness testing appears only for regulated decisions, where it is a blocker. Tool scopes appear only when the model is agentic.
| Context | Items that apply | Of which blockers |
|---|---|---|
| Commercial API, internal tool | 23 | 4 |
| Open weights from a hub, customer-facing | 30 | 7 |
| Fine-tuned in-house, customer-facing, agentic | 33 | 10 |
| Fine-tuned in-house, regulated decision | 32 | 14 |
| Embedded in a vendor product, internal tool | 23 | 4 |
The 37 checks, and the AIBOM field for each
Sources: open weights from a hub, commercial api, fine-tuned in-house, embedded in a vendor product. Contexts: internal tool, customer-facing, regulated decision, and agentic. Field paths are CycloneDX 1.7 with the SPDX 3.0.1 equivalent where one exists. Where neither format has a field, the table says so.
Provenance and licence
| Check | Pass means | AIBOM field |
|---|---|---|
| Exact model identity and version pinned | You can name the exact artefact: hub repo id plus commit revision, your own model name plus semantic version, the API model id with its dated snapshot, or the vendor feature version. | components[].group / name / version and purl (CycloneDX); name, software_packageVersion (SPDX) |
| Supplier and their contact identified | You know who publishes or supplies the model and how to reach them about a problem. | components[].supplier / manufacturer (CycloneDX); suppliedBy (SPDX) |
| Licence or terms reviewed for this use | The licence (or API terms) allows your use: commercial use, field-of-use limits, acceptable-use policy, attribution, user-count thresholds. | components[].licenses (CycloneDX); hasDeclaredLicense / hasConcludedLicense (SPDX) |
| Base model and fine-tune lineage recorded | The base model id and revision, the adaptation method (e.g. LoRA, full fine-tune, merge) and the data used are recorded. | components[].pedigree.ancestors (CycloneDX); Relationship descendantOf (SPDX) |
| Provider data-use terms acceptable | Your prompts and outputs are not used to train the provider’s models without your agreement; retention period and processing region are stated and acceptable. | services[].data[] flow and classification, externalReferences[type=documentation] for the terms (CycloneDX) |
| Vendor discloses the model it embeds | The vendor names the model family or provider behind the feature and any sub-processor that receives your data. | components[] for the embedded model and dependencies[] (CycloneDX) |
Artefact integrity
| Check | Pass means | AIBOM field |
|---|---|---|
| File digests recorded and checked on deploy | SHA-256 of every weights, config and tokenizer file is recorded, and deployment fails if the files differ. | components[].hashes (CycloneDX); verifiedUsing (SPDX) |
| Safe serialization: no pickle | Weights are loaded from safetensors (or another format that stores tensors only, such as GGUF), and the loader is pinned to that format. Pickle-based files (.bin, .pt, .pth, .pkl, .ckpt) can run code when loaded. | No standard field in CycloneDX or SPDX: a namespaced property such as <org>:weights:format = safetensors on the model component |
| No unreviewed code runs at load | The model loads without trust_remote_code, or the custom code was reviewed and is pinned to a commit. | The custom code as its own components[] entry with hashes (CycloneDX) |
| Model files scanned for malicious content | The files were scanned with a model-file scanner (for unsafe pickle opcodes, embedded code, suspicious layers) and the result is clean or explained. | externalReferences[type=static-analysis-report] on the model component (CycloneDX) |
| Signature verified against an expected signer | A signature over the model files (e.g. OpenSSF model signing with Sigstore) verifies, and the signer identity is the one you expect. For in-house models: your CI signs every release. | externalReferences[type=digital-signature] (CycloneDX); externalRef type other with a contentType (SPDX) |
| Build provenance for the training run | A provenance attestation (in-toto, SLSA format) from your build platform covers the job that produced the released weights, and records the fine-tune inputs: base model revision, dataset digests, training config. If training ran outside the attested build, the record says so. | externalReferences[type=attestation] (CycloneDX); externalRef type other (SPDX) |
| API model version pinned, deprecation known | You call a dated or versioned model id rather than a moving alias, and you know when it will be retired. | components[].version for the model, services[] for the endpoint (CycloneDX) |
Documentation
| Check | Pass means | AIBOM field |
|---|---|---|
| Your use is inside the intended use | The model card or vendor documentation states intended and out-of-scope uses, and your use is intended, not excluded. | modelCard.considerations.useCases / technicalLimitations (CycloneDX); ai_informationAboutApplication, ai_limitation (SPDX) |
| Model card is adequate | The model card scores Adequate or better (12/20 or more on the Model Card Scorer rubric), or the vendor documentation answers the same questions. | modelCard (CycloneDX); externalReferences[type=model-card]; ai_* fields (SPDX) |
| Training data documented | The training and fine-tuning data are described: sources, size, dates, licence. For your own datasets, a dataset card exists. For a general-purpose model, the provider’s public training-content summary is read. | modelCard.modelParameters.datasets[] and components[type=data] (CycloneDX); dataset_DatasetPackage, Relationship trainedOn (SPDX) |
| Personal data in training data assessed | You know whether personal or sensitive data went into training or fine-tuning, how it was de-identified, and the lawful basis. | components[type=data].data[].sensitiveData (CycloneDX); dataset_hasSensitivePersonalInformation, ai_useSensitivePersonalInformation (SPDX) |
| Evaluated on your task, not only benchmarks | Accuracy (or the task metric) was measured on a labelled set from your own use case, with a pass threshold set before the test. | modelCard.quantitativeAnalysis.performanceMetrics (CycloneDX); ai_metric, ai_metricDecisionThreshold (SPDX) |
| An AIBOM exists for the deployed system | A CycloneDX or SPDX AIBOM is generated in the build and lists the model, data, runtime libraries, RAG sources and tool servers. For an embedded model, the vendor provides one or answers the same questions. | The BOM itself: serialNumber, version, metadata.lifecycles (CycloneDX); SpdxDocument (SPDX) |
Security testing
| Check | Pass means | AIBOM field |
|---|---|---|
| Prompt-injection and jailbreak testing done | The integrated system, not just the model, was tested for direct and indirect prompt injection (through retrieved documents and tool outputs) and jailbreaks, and findings are fixed or accepted. | externalReferences[type=pentest-report] (CycloneDX) |
| Output safety tested for your context | Harmful, toxic or out-of-scope outputs (e.g. medical or legal advice where excluded) were measured on prompts from your domain. | modelCard.quantitativeAnalysis.performanceMetrics, modelCard.considerations.ethicalConsiderations (CycloneDX); ai_safetyRiskAssessment (SPDX) |
| Fairness assessed for the people affected | Performance was compared across the groups the decision affects, and gaps are explained or mitigated. | modelCard.considerations.fairnessAssessments (CycloneDX) |
| Serving stack scanned for vulnerabilities | The inference server and its libraries were scanned, and no critical or high vulnerability is open without an exploitability verdict. | components[] (libraries) and vulnerabilities[] with analysis.state (CycloneDX) |
Runtime
| Check | Pass means | AIBOM field |
|---|---|---|
| Every tool and MCP server listed, writes gated | Each tool or MCP server the model can call is listed with its permissions, and every write action either needs human approval or is reversible. | services[] with endpoints, authenticated, x-trust-boundary and a permissions property (CycloneDX) |
| Tool scopes narrowed to the use case | Credentials given to tools grant only what the use case needs (e.g. draft-only rather than full write), not the scope that was easiest to configure. | services[].properties (permissions) and services[].data[] (CycloneDX) |
| Retrieval sources listed with owner and refresh | Every index or source the model retrieves from is listed with its owner, what it is built from, refresh cadence and who can write to it. Mark N/A if there is no retrieval. | services[] or components[type=data] for the index (CycloneDX); dataset_DatasetPackage (SPDX) |
| Logs answer “which model ran, and what did it do?” | Prompts, outputs, tool calls and the model version (or AIBOM serial number) are logged, with retention that matches your policy and any legal minimum. | Not an AIBOM field. Log the BOM serialNumber and version so each log line ties to one AIBOM. |
| Human oversight defined | A named role reviews or can override outputs before they take effect, and knows when to stop the system. | ai_autonomyType (SPDX); modelCard.considerations.users (CycloneDX) |
| Network and data boundary checked | A self-hosted model has no unexpected outbound network access; API traffic goes only to the approved endpoint and region. | services[].endpoints, services[].trustZone (CycloneDX) |
Approvals
| Check | Pass means | AIBOM field |
|---|---|---|
| Named business owner accepts the risk | One named person is accountable for the model in production and has accepted the residual risk. | annotations[] (annotator, timestamp, text) on the model component (CycloneDX) |
| Data protection review done | Privacy or the DPO reviewed the data flows; a DPIA was done where the law requires one. | externalReferences[type=risk-assessment] and annotations[] (CycloneDX) |
| Legal and regulatory classification checked | Legal reviewed the licence or terms and whether the use is regulated, e.g. high-risk under the EU AI Act, and which obligations follow. | annotations[] (CycloneDX); ai_standardCompliance for standards claimed (SPDX) |
| Security sign-off on this checklist | Security reviewed this checklist and its evidence and signs it. | annotations[] (CycloneDX) |
Monitoring and change
| Check | Pass means | AIBOM field |
|---|---|---|
| Model changes are notified and re-reviewed | You will know when the model changes (vendor notice in the contract, a watched repository, your own release process), and any new version comes back through this intake. | A new BOM version per change; compare versions with an AIBOM diff (CycloneDX version, metadata.timestamp) |
| Quality and safety monitored in production | The metrics you evaluated are tracked in production, with alert thresholds and a rollback or switch-off plan. | Not an AIBOM field. The AIBOM holds the baseline values in modelCard.quantitativeAnalysis. |
| Incident route to the supplier known | You know how to report a model problem or vulnerability to the supplier, and your incident plan covers the model. | externalReferences[type=security-contact] or [type=issue-tracker] (CycloneDX) |
| Re-approval date set | The approval expires on a set date (for example after 12 months) even if nothing changes. | annotations[] (CycloneDX) |
Worked example: Northwind’s Triage Assistant
Northwind Health and its Triage Assistant are fictional, used across the AIBOM Library. The base model, Mistral-7B-Instruct-v0.3, and the libraries are real; the scores and dates are invented.
Triage Assistant v2.3 is a LoRA fine-tune of Mistral-7B-Instruct-v0.3, served with vLLM, reading a weekly-refreshed help-centre index and calling one MCP tool server, ticketing-mcp. It drafts replies; a human agent approves each one. So the context is fine-tuned in-house, customer-facing and agentic: 33 items apply, 10 of them blockers.
The decision is Approve with conditions. Every blocker passes with evidence: safetensors only, digests checked at deploy, the use inside the stated intended use, a named owner. Two major items fail and become conditions:
- Tool scopes narrowed to the use case. ticketing-mcp holds tickets:write, which can change any ticket field. The use case needs drafts and internal notes only.
- Logs answer “which model ran, and what did it do?”. Prompts, drafts and tool calls are logged for 12 months, but log lines do not carry the model version or AIBOM serial number.
For contrast, the second example is a model pulled from a hub by repo name into an internal tool, with pickle-only weights, no revision pinned and a licence of “other”. It is a Reject with 5 blockers open. Both examples load in the tool.
Where the evidence comes from
- Provenance and integrity. What each field means is in identity, provenance and lineage and the security and runtime section. For signing and build provenance end to end, see sign a model and attach provenance.
- Documentation. Score the card in the Model Card Scorer; the intended-use and evaluation fields are explained in evaluation, intended use, limitations and risk.
- Vendors and APIs. When you cannot see the weights, the evidence is the vendor’s answers. Ask with the AIBOM questions to ask every AI vendor.
- Attestations. Which signatures, provenance and certificates you need, and who can issue each, is the job of the AI Model Attestation Planner. Everything else is on the AIBOM Library hub.
What it does not do
It does not open your files, verify a signature or read a model card. It records what the reviewer answered and applies a fixed rule. A pass is only as good as the evidence written next to it. It is not legal advice and not a regulatory conformity assessment.
Sources
Field names were checked against these on 29 October 2026.
Frequently asked questions
What should we check before deploying an AI model to production?
Seven things: where the model came from and under what licence; that the file you deploy is the file you reviewed (digests, safe serialization, a verified signature); that its documentation covers your use; that the assembled system was tested for prompt injection and unsafe output; what it can reach at run time (tools, MCP servers, retrieval sources) and what is logged; who approved it; and how you will notice when it changes or degrades.
Is a pickle model file dangerous?
It can be. Pickle-based files (PyTorch .bin, .pt, .pth, and .pkl or .ckpt files) can execute code when they are loaded. safetensors stores only tensors and does not. For any model you download, require safetensors (or another tensor-only format such as GGUF) and pin the loader to it. The checklist treats this as a blocker for self-hosted models.
Who should approve an AI model for production use?
A named business owner who accepts the residual risk, a security reviewer, and, depending on the context, data protection and legal. For customer-facing and regulated uses the checklist makes the privacy and legal reviews major or blocking items. The PDF record has a sign-off block for each.
Do we need an AIBOM to approve a model?
The checklist treats it as a major item for models you host or call, and minor for a model embedded in a vendor product. Without one, the evidence for each item lives in scattered tickets. With one, each piece of evidence has a field, and the approval itself can be recorded in the AIBOM as an annotation.
What is the difference between "approve with conditions" and "reject"?
Reject means a blocker failed or is unanswered: for example the use is outside the model’s intended use, the weights are pickle-only, or nobody owns it. Approve with conditions means no blocker is open, but a major or minor item failed, is unanswered, or has no evidence. Each condition needs an owner and a date.
Is this an EU AI Act conformity assessment?
No. It is an internal approval gate. If the system is high-risk under the AI Act, the provider has separate obligations, including a conformity assessment. The checklist only asks whether legal has checked the classification. For the attestations a regulator or customer may ask for, use the AI Model Attestation Planner.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.