By Micky Irons, founder and CEO of Mickai.
The question has changed. Two years ago a diligence reviewer assessing an artificial intelligence system asked what it could do. Now the reviewer asks what it is made of. The shift follows the EU AI Act and its Annex III list of high-risk uses, obligations once due on 2 August 2026 that now apply from 2 December 2027 after the Digital Omnibus deferral, alongside DORA in force across the financial sector since January 2025, and NIS2 across critical infrastructure. The proof requirements survive the move unchanged, so the sensible response is to build now. Each of these regimes treats a supplied system as a supply chain, and expects the buyer to know that chain rather than trust it.
A model is not a single object. It is a composition of weights, training and fine-tuning data, tokenisers, evaluation sets, inference code, and the hardware and network path it runs on. Every one of those layers is a place where a risk enters and where a regulator may later ask a question. The honest answer to that question is not a claim about safety. It is a record. This is why the software world's bill of materials has arrived at the model.
What a diligence reviewer actually asks
A serious reviewer, whether a chief information security officer, a public-sector buyer, or a regulator conducting a conformity check, does not ask whether a system is good. They ask narrower questions. Which model produced this output, and what version. Trained on what corpus, and under what licence. Fine-tuned with what data, held where. Served from which datacentre, under whose jurisdiction, and changed by whom.
Most artificial intelligence systems cannot answer these questions after the fact. The model was called through an interface, the response was returned, and nothing durable recorded which weights, which prompt, and which policy were in force at that moment. The reviewer is left with an assurance, and an assurance is not evidence. In a high-risk deployment under the Act, it does not survive contact with an auditor.
From a list of ingredients to a signed record
A bill of materials for artificial intelligence begins as a list of ingredients, and it becomes useful only when it is signed. An unsigned manifest is a document anyone can alter. A signed manifest binds each entry to a cryptographic identity and a moment in time, so the record and the thing it describes cannot drift apart without the signature breaking.
Within a Sovereign Intelligence Operating System, the SIOS we build, provenance is a property of the system at the moment of every action rather than a report generated at the end. Each model carries a manifest of its lineage, and each inference is written to an append-only audit chain sealed with post-quantum signatures, so the record stays verifiable against adversaries who may one day hold cryptographic capabilities today's systems do not anticipate. A log you can edit is a story. A sealed chain is a witness.
A model you cannot trace is a liability you cannot bound, and provenance is the only mechanism that turns an assurance into evidence.
Where the parts came from, and why jurisdiction is part of the record
Provenance is also about where a model lives and whose law reaches it. A model served from a hyperscale datacentre is subject to the legal regime of that datacentre's operator, and under the US CLOUD Act a provider can be compelled to produce data held anywhere in the world. For a regulated buyer this is a line in a data-protection impact assessment and a question in a supervisory review.
A bill of materials that records the runtime jurisdiction answers this before it is asked. We design the SIOS to run offline on operator-owned hardware, so the model, its data, and its audit chain stay inside a perimeter the operator controls. The record then states a fact rather than a hope. The inference occurred on this machine, under this jurisdiction, with no egress path by which the data could have left. A zero-egress inbound perimeter makes that claim structural, because there is no outbound route.
Hardware-attested identity: proving the record is about this machine
A signature proves who wrote a record. It does not, on its own, prove which physical system produced it. Hardware-attested identity closes the gap by rooting the signing key in the silicon of the specific machine, so an audit entry traces not to a software identity alone but to an attested device.
When the manifest, the model, the inference, and the machine are cryptographically bound together, the reviewer is no longer trusting a chain of custody. They are verifying it. The 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD sit largely in this territory, binding identity, action, and audit into a single verifiable structure. They are filed and patent pending, never granted or patented.
Consensus as a check on a single source of truth
A bill of materials records what a system did. It does not by itself judge whether the answer should be trusted, and a single model is a single point of view that can be confidently wrong. The OWASP catalogue of risks specific to large language model applications, from prompt injection to data leakage to overreliance on a lone model, describes exactly the failure surface a provenance record should help contain.
We address this with cross-model consensus. Rather than accept the output of one model, the SIOS can route a decision through several sovereign models and record their agreement or disagreement in the same sealed chain. The record then shows not only which model spoke but how many concurred, and where they diverged. A disagreement that was surfaced and logged is a stronger control than a single answer that was never questioned.
Standards are converging on exactly this
None of this sits outside the emerging standards. ISO/IEC 42001, the management-system standard for artificial intelligence, expects an organisation to document the provenance and lifecycle of the models it operates and to control changes to them. The EU AI Act requires technical documentation and record-keeping for high-risk systems that a conformity assessment can inspect. NIS2 and DORA push the same discipline into the supply chain, holding an operator accountable for components it bought rather than built.
A signed model bill of materials is the artefact these regimes are circling. It lets an operator prove what went into the system, where each part came from, who changed it, and under whose law it ran. We build the SIOS so this document is a natural output of ordinary operation rather than a project undertaken in a panic before an audit. Provenance generated continuously is cheap. Provenance reconstructed under scrutiny is expensive, and often impossible.
What buyers should ask for next
A reviewer in late 2026 who accepts a model without a provenance record is accepting a liability whose size cannot be known. The response is not to slow the adoption of artificial intelligence. It is to insist that every model carry its bill of materials the way every regulated component in every other supply chain already does.
Any serious buyer should make three demands of any artificial intelligence they are asked to deploy. Ask for a signed manifest of the model's lineage that you can verify without trusting the vendor. Ask where the model runs and whose jurisdiction reaches it. Ask for an audit chain that cannot be edited after the fact. A system that can answer all three is one whose risk you can bound. A system that can answer none is one whose risk you are agreeing not to look at, and in 2026 a regulator will look for you.
Written by Micky Irons. Originally published at https://mickai.co.uk/articles/a-bill-of-materials-for-your-ai-model-provenance-and-the-supply-chain. More from Micky Irons and Mickai at mickai.co.uk.
Top comments (0)