The AI Model Provenance Field Guide

Executive Brief

An enterprise may know which AI product it bought without knowing the exact model version, the source of an adaptation dataset or the library on which the deployed service depends. The practical answer is to create a bounded evidence trail. This guide helps teams document what they can verify, record what they must accept from a supplier and decide what to do when information is incomplete.

CycloneDX describes an ML bill of materials as a way to represent model, dataset, training and dependency metadata. [1] The format provides structure for transparency; the existence of an inventory does not confirm that its entries are accurate or that a model cannot be poisoned. Use it as a record to validate, not a substitute for evaluation.

The worksheets work best with one real but non-sensitive AI service. Write in short answers, mark gaps without embarrassment and nominate a decision owner for each next action. A field left blank should not silently become an approved fact when the guide is filed.

How to Use This Field Guide

Select one deployment and keep its business boundary narrow: a summarization service, an internal knowledge assistant or an approval recommendation. Avoid starting with a corporation-wide list of every model. For each worksheet, collect one source document, an accountable reviewer and the date on which the evidence was checked.

When a supplier makes a claim, preserve the original statement and identify it as supplier evidence. When an engineer executes a reproducible verification or evaluation, record its result separately. When the organization accepts a limitation, retain the decision and expiration trigger. These three categories should never be blended into a single score.

Worksheet 1. Define the AI Service

Begin with the business task the model supports. Identify the owner, the people affected, the type of information used and any operation the model can initiate. A model that drafts an answer for human review does not have the same authority as one that automatically acts on customer accounts.

Draw the simplest possible path: user request, approved information sources, model or API, connected tools and final business action. For each connection, write who controls access and who can pause it. Separate internal services from third-party services so the responsibility boundary is visible.

Start by interviewing two people separately: the business sponsor and the technical operator. Ask each to describe the approved task and what the model may do without human intervention. If their answers differ, capture the difference and resolve it before attempting an advanced provenance assessment. Misaligned task boundaries can distort both testing requirements and the supplier evidence needed.

For example, an employee knowledge assistant may be permitted to retrieve policy documents and propose answers, while a customer-facing chatbot may also access account information. The two services could use the same model but require different data-access and response controls. The provenance record should point to the specific business workflow, not merely the common model family.

Worksheet 1. Service Boundary

Worksheet 2. Trace the Model and Data

Record the provider, model family, full identifier, version or revision, storage location and acquisition method. Where a hosted service does not expose exact model weights, name the provider-controlled versioning method and describe the resulting visibility limit.

Now list what changed after acquisition: fine-tuning, adapters, prompts, retrieval sources, filtering rules and environment variables relevant to behavior. A document used for retrieval is not the same as training material, but it can still influence a response. Keep the distinction explicit to preserve a truthful provenance record.

For datasets, record who collected them, permitted use, sampling or filtering decisions, the validation approach and the date used. Avoid implying that a dataset is clean merely because its repository is public or its publisher is familiar.

Record snapshots at meaningful change points. A training-data catalog updated monthly and a continuously changing retrieval index are not equivalent; the reviewer needs to know which one affects the currently deployed behavior. If an adaptation run has no reproducible input list, describe that uncertainty and decide whether repeatable evaluation or a more restricted use case is required.

Data rights deserve a separate line in the ledger. A public dataset can still carry license conditions or restrictions on commercial use. The fact that data are technically accessible should not be treated as permission to train with them. Ask the relevant legal or data governance owner which rights record supports the intended action.

Worksheet 2. Origin and Adaptation Ledger

Worksheet 3. Examine Third-Party Components

A model service can depend on container images, orchestration libraries, tokenization packages, evaluation tools, vendor APIs and data connectors. List the components that can materially affect security or behavior and record how updates arrive. Do not assume that a software bill of materials covers model artifacts or proprietary datasets unless those items appear and are described.

Hugging Face notes risks associated with Python pickle serialization and documents safeguards around repository scanning. [3] Scanning can help identify certain dangerous content, but it is not a guarantee that an untrusted model is safe to execute. Treat unknown artifact formats, unexpected executable content and unexplained publisher changes as review questions.

For each outside component, capture who updates it, what kind of evidence is available and how the organization would identify affected deployments if the component were withdrawn.

Include less visible dependencies in the review: packaging jobs, evaluation pipelines, container base images and service identities used to retrieve model files. An attacker does not need to alter training data to introduce a problem through conventional software. Conversely, a flawless package scan cannot establish that a model’s learned behavior is appropriate. Maintaining two connected inventories avoids both forms of overclaim.

When a library or connector changes, write down whether it can change execution behavior, data exposure or model inputs. That determines who must review the change. Routine updates can follow a lightweight path, while material changes require the relevant service owner and assurance function to reconsider the risk decision.

Worksheet 3. Dependency Review

Worksheet 4. Decide What Counts as Evidence

A signature and an evaluation report solve different problems. SLSA distinguishes basic records from stronger signed and hardened build assurances. [6] Sigstore documents how to verify signatures attached to software artifacts. [2] Verification can support origin and integrity checks for the artifact within its trust assumptions; it does not establish that the training process was honest or that every output will be safe.

Use four evidence grades. Grade A is locally reproducible verification tied to a version and retained logs. Grade B is a supplier-authored document with scope and dates. Grade C is a generally applicable standard or threat reference. Grade D is an editorial hypothesis or planning assumption. Grade C informs what to check but does not validate your deployment.

For important claims, write a short proof statement: “The deployed component matched the approved signed release at the time checked,” rather than “The model is completely secure.” That narrower statement is far more useful in a risk review.

A useful exercise is to compare two candidate evidence statements. “Our AI is protected by verified provenance” is broad and undefined. “The production model package matched the digest approved for release on the stated date” is narrower but inspectable. A buyer can ask for the record and understand what the claim does and does not cover.

If the evidence comes from a supplier presentation, log its version and author. If it comes from an executed check, retain the command, environment and output. If it comes from a standard, write which policy or test requirement the standard informed. These steps stop an explanatory link from being misreported as a completed local control.

Worksheet 4. Claim-to-Evidence Test

Worksheet 5. Plan Testing and Response

NIST's Generative AI Profile supplies voluntary risk-management considerations specific to generative applications. [4] It does not provide a universal test that makes every model safe. Define an evaluation around the actual task: appropriate data handling, accuracy on representative cases, unusual input behavior and changes after updates.

Run a before-and-after comparison when a model version changes. Document the test set, expected behavior, observed result, reviewer, resolution and residual uncertainty. Avoid reporting “100% secure” based on a small test. Instead state which checks passed and which risks were not evaluated.

Plan one exercise in which a release is withdrawn for integrity reasons. Identify the affected deployment inventory, the owner authorized to stop it, the last approved artifact and the communication route to the business. The exercise need not involve a real attack; it tests the organization's ability to act responsibly.

Use a small regression suite that includes representative correct cases, known failure cases and situations that should trigger refusal or human review. Store the case definitions with the model version and application configuration. A change in prompts or connected data may affect outputs even when the underlying model weights remain unchanged, so relevant configuration belongs in the test record.

During a tabletop exercise, provide the team with a hypothetical withdrawal notice and ask them to list the affected services without using guesswork. Can the inventory locate each environment? Can business operations identify the consequence of pausing it? Can security distinguish verification failure from confirmed malicious change? The exercise outcome is a process improvement list, not a public incident claim.

Worksheet 5. Release Decision Record

Worksheet 6. Translate Assurance Into Buyer Value

Cybersecurity vendors often describe the risks they can detect but leave buyers unsure which action those results enable. Rewrite the proposition as an answerable question. “Can your team identify the model version deployed in each business-critical service?” is more useful than “Complete AI visibility” when the product covers inventory rather than full training lineage.

CyberTech Intelligence describes research, cybersecurity intelligence and buyer-oriented demand programs. [5] Buyer intelligence can segment organizations by the decisions they are exploring: supplier assurance, model inventory, secure deployment or executive governance. Managed demand generation can share the appropriate worksheet with each role and gather consent-based responses. Pipeline activation begins only when an interested buyer agrees on a relevant next step.

A CISO may value an accountable risk decision, engineering may need integration detail, procurement may need evidence requests, and a revenue leader at the security vendor may need clarity on which conversations represent actual intent. Build one evidence narrative with role-specific entry points rather than seven unrelated promises.

Create a content ladder. The opening asset explains why model origin matters. A mid-stage worksheet helps a practitioner discover which records are missing. A deeper guide gives evaluators sample supplier questions and control evidence. Only after a buyer identifies a live evaluation should outreach move to an executive working conversation. This sequence respects the difference between curiosity, research and buying readiness.

Worksheet 6. Buyer Message Planner

Eleven-Domain Readiness Score

Score each domain 0 to 4 using only evidence available for the chosen AI service. Zero means no owner or record; one means an informal description; two means a documented process; three means version-specific evidence reviewed by a named owner; four means the control has been exercised or independently checked within its defined scope. A high self-score is not a certification, product quality guarantee or security incident prediction.

The total possible score is 44. Document the source of each rating. A category with little information should score zero rather than receiving estimated credit. The purpose is to prioritize next actions, not compare companies on an unvalidated benchmark.

Readiness Domains, 0 to 4

Ninety-Day Activation Planner

Days 1–30: pick one service and complete the first three worksheets. Identify unknown origins and update paths. The goal is a truthful baseline, not a complete enterprise mapping. Select the two highest-impact evidence gaps for further investigation.

Days 31–60: build a claim-to-evidence register and run a limited version-specific test. Agree on owners for supplier questions and exception decisions. For vendors, draft buyer-specific education that describes the supported scope of the product rather than general category risks.

Days 61–90: exercise an update or rollback scenario, review the readiness domains and capture what improved. In a CTI-supported demand program, review qualified engagement by persona, account, and agreed next step. Do not infer purchase intent from anonymous reading activity.

At every milestone, record the acceptance criteria in advance. “Inventory completed” should mean the selected production services, owners, and model identifiers are present, not that a spreadsheet was created. “Evidence reviewed” should mean records were checked against a specific version. For CTI campaign reporting, “qualified conversation” should have an identified role, need and agreed follow-up. These definitions prevent activity volume from being mistaken for control or commercial progress.

90-Day Working Plan

CyberTech Intelligence Perspective

The commercial value of supply-chain research is its ability to make a complex security topic discussable. CTI recommends starting with concrete buyer questions, using evidence-focused content to build understanding and moving toward executive discussion only when the audience confirms relevance. The worksheets above can serve as a useful common language for engineering, risk, procurement and cybersecurity vendor GTM teams.

References and Source Boundaries

Numbered citations identify the primary source used for the nearby factual statement. A standard, threat taxonomy or supplier description does not establish the condition of any named enterprise or predict campaign results. Source review date: October 21, 2026.

1. CycloneDX. Machine Learning Bill of Materials. Use in this asset: Inventorying models, datasets, dependencies, and metadata.  URL: https://www.cyclonedx.org/capabilities/mlbom/ 
2. Sigstore. Verifying Signatures with Cosign. Use in this asset: Verification of signed software artifacts; not proof of model behavior.  URL: https://docs.sigstore.dev/cosign/verifying/verify/ 
3. Hugging Face. Pickle Scanning. Use in this asset: Serialized model loading risks and repository scanner boundaries.  URL: https://huggingface.co/docs/hub/security-pickle 
4. NIST. Generative AI Profile, AI 600-1. Use in this asset: Additional voluntary generative AI risk-management considerations.  URL: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence 
5. CyberTech Intelligence. Cybersecurity Demand Intelligence. Use in this asset: CTI published market intelligence and audience-engagement offerings.  URL: https://cybertechintelligence.com/ 
6. SLSA. Build Track Basics, v1.2. Use in this asset: Difference between basic build provenance and stronger signed or hardened evidence.  URL: https://slsa.dev/spec/v1.2/build-track-basics