Every organization that ships AI has quietly inherited a supply chain it did not build and often cannot see. A single production feature may lean on a foundation model trained by a third party on data no one on your team has reviewed, a stack of open-source libraries pulled from public registries, fine-tuning datasets of uncertain origin, and a chain of tools and prompts wired together by different people over many months. The AI supply chain is the sum of all of that, and in 2026 it has become the part of the machine-learning lifecycle most likely to fail an audit and most likely to conceal a compromise.
The reason is structural. Traditional software supply-chain assurance, hard won after years of dependency attacks, largely stops at code. AI adds artifacts that existing tooling was never designed to track: model weights that cannot be diffed line by line the way source can, datasets whose licensing and lineage are frequently undocumented, and behavior that can be poisoned during training and lie dormant until a chosen trigger wakes it. Regulators have noticed. The EU AI Act places documentation and transparency duties on providers of general-purpose models, the EU Cyber Resilience Act pushes bills of materials and disciplined vulnerability handling onto any product with digital elements, and DORA makes financial firms accountable for the ICT third parties, foundation-model vendors squarely included, that they depend on. Securing the AI supply chain has become an engineering program with a compliance deadline attached.
The trust you inherit with every model
Pulling a model into production is an act of trust in everyone who touched it before you, and most of them are strangers.
- ▸Opaque weights: A model binary cannot be read like source code, so you cannot simply review it for a backdoor. Assurance has to come from provenance and behavioral testing instead.
- ▸Dataset lineage: Training and fine-tuning data arrive with licensing, consent, and copyright questions that flow straight into your GDPR lawful-basis analysis whenever the corpus touched personal data.
- ▸Model-hub risk: Downloading weights from public hubs invites the same typosquatting and poisoning that hit package registries, now with artifacts few teams know how to inspect.
- ▸Transitive tooling: The frameworks, serialization formats, and adapters around the model carry their own flaws, and unsafe deserialization of a model file remains a classic path to code execution.
What an AIBOM actually records
The response the industry has converged on is the AI Bill of Materials, an AIBOM, which extends the SBOM idea from code to the full machine-learning artifact set. Formats already exist to carry it, with CycloneDX supporting machine-learning components and the SPDX ecosystem adding AI and dataset profiles, so this is a discipline you can adopt today rather than a standard you must wait for.
- ▸Model identity and version: The exact weights, their source, and a cryptographic hash, so you always know precisely what is running in production.
- ▸Data provenance: The datasets used, their licenses, and the lawful basis for any personal data, closing the copyright and privacy gap auditors now probe.
- ▸Dependencies and formats: The frameworks, serialization formats, and adapters, tracked and scored like any other software component.
- ▸Evaluation and intended use: Benchmark and adversarial-test results alongside documented limitations, echoing the Model Card practice and feeding directly into AI Act and CRA documentation.
Provenance you can verify, not just assert
A bill of materials that anyone can edit is a spreadsheet, not a control. The assurance comes from making provenance cryptographically verifiable, borrowing the machinery that hardened the software build world.
- ▸Sign the artifact: Cryptographically sign model weights and datasets so a swapped or poisoned file fails verification before it ever loads. Emerging model-signing efforts built on Sigstore make this practical even for very large artifacts.
- ▸Attest the pipeline: Use in-toto attestations and SLSA-style provenance to record who built the model, from which inputs, on which system, turning the training run into an auditable event.
- ▸Verify at admission: Enforce signature and provenance checks at the deployment gate, refusing to serve a model that cannot prove where it came from.
- ▸Plan for crypto-agility: Signed model artifacts can outlive the cryptography that protects them, so keep a migration path toward post-quantum signatures such as ML-DSA, standardized by NIST as FIPS 204.
A model-governance program in seven steps
Provenance tooling only pays off inside a program that someone owns. The following sequence turns scattered good intentions into an auditable system.
1. Inventory every model and dataset in production, including third-party models embedded inside features and inside vendors' products. 2. Generate an AIBOM for each system in a standard format and keep it current inside your pipeline, not in a document that rots. 3. Set an approved-source policy defining where weights and datasets may come from and who signs off on an exception. 4. Sign and verify artifacts end to end, blocking unsigned or unverifiable models at deployment the way you block failing tests. 5. Assess model vendors as critical suppliers, with contractual security commitments, audit rights, and a real exit clause. 6. Anchor it in a management system, using ISO/IEC 42001 for AI management and ISO/IEC 23894 for AI risk so the governance is certifiable rather than aspirational. 7. Monitor continuously for new vulnerabilities, license changes, and behavioral drift, and rerun assurance every time a model is updated.
Foundation-model vendor risk under DORA and the AI Act
Depending on a foundation model is depending on a supplier, and the largest suppliers now sit underneath a huge share of the market at once.
- ▸Concentration risk: A small number of providers underpin much of production AI, so a single outage, price change, or policy shift ripples across everyone downstream at the same moment.
- ▸Right to evidence: Under the AI Act, providers of general-purpose models owe downstream deployers technical documentation and usage information. Demand it, store it in your AIBOM, and treat its absence as a red flag.
- ▸Exit and portability: DORA expects a workable exit strategy for critical ICT services, so avoid architectures that cannot survive swapping the underlying model for another.
Build, buy, or sovereign-host
There is no single correct answer, only a trade-off to make consciously and revisit as regulation tightens.
- ▸Buy a hosted API: The fastest path with the least infrastructure to run, but the weakest control over data residency and provenance and the deepest lock-in to one vendor.
- ▸Self-host open weights: Full control over residency and provenance and the freedom to inspect and sign everything, paid for with real operational cost and the duty to secure the stack yourself.
- ▸Sovereign or regional hosting: A middle path that keeps regulated data inside the jurisdiction while outsourcing the platform, usually at a price premium worth paying when the data cannot legally leave.
For a team that needs to move this week, four actions beat any strategy deck: list every model touching regulated or personal data and note where its weights came from, generate one rough AIBOM for your highest-risk system, switch on signature verification at the deployment gate for new model versions, and name a single accountable owner for each model's provenance, updates, and vendor relationship.
What this means for North African integrators and their EU clients
For businesses in Tunisia and across North Africa, the AI supply chain is where regulation and opportunity meet. Tunisia's data-protection regime, anchored in Law 2004-63 and overseen by the INPDP, sits alongside the reality that most foundation models are hosted by providers outside both Tunisia and the EU, which turns residency into a first-order design question rather than a footnote. An integrator building for European clients has to reason about where training data, prompts, and inference traffic physically live, and increasingly about whether regulated data may leave the jurisdiction at all.
That constraint is also a business. The same governance work that regulation demands, maintaining AIBOMs, verifying provenance, assessing model vendors, and keeping the evidence an auditor will ask for, is exactly the kind of high-skill, repeatable engineering that nearshore teams can own on behalf of EU customers. A Tunisian partner that runs a disciplined model-governance practice, backed by clean data-processing agreements and standard contractual clauses and a credible answer on residency, becomes the assurance layer between European buyers and a fast-moving global model market. The cost advantage is real, but the durable edge is trust: the firms that treat provenance and data residency as core competencies, not afterthoughts, will be the ones EU clients keep when the AI Act and DORA audits arrive.
The direction of travel is unmistakable. The software industry spent the last several years learning to demand a bill of materials, signed builds, and provenance for its code, and AI is now compressing that same journey into a fraction of the time under sharper regulatory pressure. Within a couple of release cycles, shipping a model without an AIBOM and a verifiable chain of custody will look as reckless as shipping code with unpatched, unknown dependencies does today. The organizations that start treating models as first-class, governed supply-chain artifacts, rather than convenient black boxes downloaded on a deadline, will be the ones still standing when the first major AI supply-chain incident forces everyone else to catch up in a hurry.