The AI supply chain needs a record of what changed after the download

The 2026 G7 SBOM-for-AI announcement and joint data-security guidance make component identity useful only when it survives transformation and updates.

An AI component can arrive with a recognisable publisher name and still become difficult to account for inside a project. Someone converts its format, another person adds a dataset, and a later update replaces the retrieval index. Months afterwards, the team knows the model family but cannot identify the package that produced an important answer.

Supply-chain security begins earlier than incident response. It requires a way to explain where each component came from, which transformations were authorised and what changed between accepted versions. For AI applications, that includes operational data as well as software and weights. A trustworthy delivery process must preserve the distinction between file identity, source authenticity and behavioural acceptance.

A concrete 2026 transparency development

On 12 May 2026, [CISA's official advisory bulletin](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/416bd74) announced joint G7 guidance on minimum elements of a software bill of materials for AI. This article uses that announcement as evidence of an institutional transparency initiative; it does not claim that a particular inventory conforms to the full guidance.

An inventory is useful when it supports a decision. A long list of package names without revisions or relationships may leave the operator unable to answer the question that matters during a problem: which running systems received the changed component? The desired record connects a named component to a named application release and its accountable maintainer.

Include the data that remains in motion

The [joint AI data-security guidance published through Australia's cyber authority on 23 May 2025](https://www.cyber.gov.au/publication/ai-data-security) examines the data supply chain, maliciously modified data and data drift. It recommends provenance tracking, integrity controls and protection throughout the AI lifecycle. These are different risks: an unexpected change may be malicious, accidental or an ordinary change in the population using a service.

That distinction prevents a team from treating every changed answer as evidence of an attack. An outdated document and a deliberately poisoned document may both be unsuitable inputs, but they demand different investigations. Record the observation first, preserve the affected version and determine the cause through the appropriate process.

A fictional archive follows the transformations

Imagine a conservation workshop in Valencia building a search assistant over invented maintenance manuals. This is an illustrative organisation and dataset. Its assistant suggests relevant passages; a conservator remains responsible for a repair decision. The workshop receives new manuals periodically and corrects transcription errors in older ones.

The first inventory records the original document, its permitted use, source location, acquisition date and content identity. A second record describes transcription and extraction. A third identifies the index built from those outputs. The application release connects that index to its embedding model, generation model and serving software.

This is more informative than assigning one checksum to a folder called latest. If a transcription correction changes the meaning of a safety instruction, the team can identify the affected derivative and rebuild it without pretending the original supplier document changed too.

A hash answers a limited question

A content hash helps distinguish bytes and detect a difference from a retained reference. It does not establish that the first reference was legitimate, that the content was authorised for use, or that a model behaves safely. Keep the reference's origin and the responsible reviewer beside the identity record.

For the fictional workshop, an unexpected mismatch pauses the update. The maintainer compares the candidate with the expected release information and asks the supplier through an established channel. The process should not automatically replace the retained reference with the newly arrived file simply to make the mismatch disappear.

Digital signatures can add information about who attested to a version, subject to the team's trust in the signing identity and its custody. They still do not transform a dangerous or inaccurate component into a good one. The security review and the task evaluation remain separate records.

Loading is an execution decision

[Hugging Face's pickle-scanning documentation](https://huggingface.co/docs/hub/security-pickle) warns about arbitrary code execution when loading pickle files and explicitly describes its scanner as imperfect. A clean-looking scan should therefore not be treated as permission to load an unfamiliar artifact on a machine holding valuable credentials.

The workshop's intake area is separate from the service that uses accepted packages. Reviewers inspect the format and required loading behaviour before an authorised test. Custom code, conversion tools and dependencies receive their own review; they do not inherit trust merely because they arrived alongside model weights.

No loading commands are supplied here. The practical lesson is to avoid using an experiment as the first point at which a team discovers that its proposed model loader executes code. A safer design makes that authority visible before the component reaches a useful operational environment.

Preserve the old accepted package

When the workshop prepares an update, it keeps the earlier accepted release and records what is replacing it. Tests use the same set of permitted synthetic questions where comparison is meaningful, alongside new cases prompted by the changed documents. A repaired transcription should not silently justify a different model or a new external service connection.

The rollback plan needs to account for data as well as software. Returning the old application while leaving a new index in place may not restore the earlier behaviour. Likewise, removing a document from a source folder does not demonstrate that all derived copies have been removed. The inventory should make those dependencies inspectable.

Put maintenance responsibility in the record

[NIST SP 800-218A, finalised on 26 July 2024](https://csrc.nist.gov/pubs/sp/800/218/a/final), extends the Secure Software Development Framework with practices specific to AI model development and is intended for producers and acquirers. It is a secure-development reference, not an assertion that every downstream package built with an inventory is secure.

For a small organisation, responsibility can be expressed simply. Name who accepts a new source, who operates the transformation, who reviews changed behaviour and who can withdraw a release. Give unresolved provenance questions an owner and a practical consequence. A component that cannot be traced may remain outside the production package while the team continues a smaller, permitted experiment.

The useful result is a history that supports action. The workshop can identify which source revision reached a particular release, explain the transformation and recover without erasing the evidence of the change. That is a stronger foundation than trusting a familiar family name attached to an unfamiliar collection of files.

This is defensive educational reporting, not legal advice or supply-chain certification. The workshop and its manuals are fictional. No model, dataset, executable or dependency was downloaded or loaded for this article; public reference pages were read on 15 October 2026.

Evidence diagram and readable guide


Original explanatory diagram: a provenance chain retains a prior release and a separate comparison path; file identity is not certification.

[Open the complete evidence diagram](/assets/cyber-workflow-data-model-provenance-20261015.svg)

Read the diagram

**Keep the release history recoverable**

Arrows describe provenance and update review. The prior-version lane supports recovery; a hash does not certify safety or rights.

- **Identified source.** Record origin, reference identity and responsible reviewer.

- **Permitted intake.** Review rights, format and required loading behaviour.

- **Documented transformation.** Name each tool, input and authorised change.

- **Derived data and index.** Bind derivatives to their actual parent records.

- **Accepted release.** Connect the components to a tested application version.

- **Retained prior version.** Keep a recoverable comparison without rewriting history.

The solid retention path preserves a prior version. The dashed return path compares it with the accepted release; neither path certifies safety or rights.

How the connections work

- Identified source to Permitted intake: provenance; solid directed link. Proposed provenance relationship; no measured causal effect.

- Permitted intake to Documented transformation: review; solid directed link. Proposed review relationship; no measured causal effect.

- Documented transformation to Derived data and index: derivation; solid directed link. Proposed derivation relationship; no measured causal effect.

- Derived data and index to Accepted release: release; solid directed link. Proposed release relationship; no measured causal effect.

- Accepted release to Retained prior version: retention; solid directed link. Proposed retention relationship; no measured causal effect.

- Retained prior version to Accepted release: comparison; dashed directed link. Proposed comparison relationship; no measured causal effect.

Keep the paths separate

Accepted release and retained prior version remain distinct records linked by retention and comparison.