Azcuna Dynamics
← Capabilities
Deep dive

Model provenance and sovereign AI

Why the origin of an AI model's weights, training data, and toolchain is a supply-chain question for defense programs; how open-weight U.S.-origin models are selected, verified, pinned, and updated in an air-gapped deployment; and what 'sovereign AI' should mean when a vendor says it. From Azcuna Dynamics.

Updated 2026-09-06/7 min read/1,598 words

Every AI product has a model inside it. Ask a vendor which one, who trained it, on what, and how they verified the file they shipped you, and you will learn a great deal about the vendor. Model provenance is the discipline of being able to answer those questions with documents rather than assurances. For defense and intelligence programs it is not a nicety. It is the same supply-chain question the program already asks about every other piece of software, applied to the one component most vendors would prefer you not look at.

This page explains what provenance covers, how Azcuna Dynamics handles it in BABEL and ELLMENT, and what the phrase "sovereign AI" should mean before anyone is allowed to put it on a slide.

Models are software, and software has a supply chain

A language model is a large file of numbers plus the code that runs it. The numbers were produced by a training run on a corpus assembled by some organization, under some license, with some set of choices about what to include and what to filter. The file was published somewhere, possibly re-uploaded by third parties, possibly modified, possibly quantized by someone other than the publisher.

Each of those steps is a link in a supply chain, and each can fail in the ways software supply chains fail. A re-uploaded file can differ from the original. A quantized variant can be produced by an anonymous account. A license can be revoked or altered. A training corpus can contain material the program is not permitted to use, or content that shapes the model's behavior in ways no one documented.

Programs already have policies for this. NIST SP 800-171 and the CMMC framework expect a contractor to know what software is in the system and where it came from. A model is in scope. Provenance is how you show it.

What a provenance record contains

A defensible provenance record for a deployed model has six parts.

Publisher. The organization that trained and released the model, and the jurisdiction it operates under. For BABEL's default model set this is a U.S. company releasing open weights under a published license.

Exact version. Not "Llama" or "Gemma," but the specific release, the specific quantization, and the cryptographic hash of the file as it sits on the deployed machine.

Verification. Evidence that the deployed file's hash matches the publisher's published hash, recorded at the time the file crossed the air gap. A file that cannot be matched to a publisher release is not deployed.

License. The license text as of the date of deployment, and a note on any use restrictions that apply to the program.

Training data disclosure. Whatever the publisher has stated about the training corpus, and an honest note of what they have not stated. Most publishers disclose less than programs would like. The record should say so rather than fill the gap with assumptions.

Toolchain. The inference engine, its version, and the source it was built from. The model does nothing without the runtime, and the runtime is software with its own provenance.

Every BABEL deployment ships with this record for each model in the approved set, and the audit log ties every query to the model version that answered it.

Why U.S.-origin, and what that does and does not solve

Azcuna Dynamics defaults to open-weight models published by U.S. organizations. The reason is policy alignment, not a claim that a model's passport determines its quality.

Defense programs increasingly restrict AI components by origin, for the same reasons they restrict telecommunications equipment and semiconductors. A model trained and released under a foreign jurisdiction carries legal and counterintelligence questions that a program has to answer before it can accredit the system. Choosing U.S.-origin models by default removes that question from the critical path. It does not remove the need to verify the file, pin the version, or audit the behavior. Origin is one field in the record, not a substitute for the record.

We also evaluate models from allied publishers when a language pair or task justifies it, and we say so in the provenance record when one is used. The rule is disclosure, not pretense.

Open weights versus API access

There are two ways to use a frontier-quality model: call a vendor's API, or run open weights yourself. For an air-gapped program only the second exists, but the difference matters even where a network is available.

An API model can change without notice. The vendor updates it, retires it, adjusts its behavior, or changes its terms. Your system's outputs change with it, and yesterday's evaluation no longer describes today's model. You cannot pin a version you do not possess.

Open weights are a file. You verify it once, pin it, and it behaves the same on the last day of the program as the first. A new version is a deliberate decision, tested against the same question set, recorded in the audit log. Reproducibility, which an accreditation process requires, is only possible when the model is a fixed artifact under your control.

There is a cost. Open-weight models in the size class that runs on a laptop are smaller than the largest API models and score lower on general benchmarks. For grounded document work with retrieval, that gap matters less than it looks, because the model is reading evidence rather than recalling it. The model provenance decision is therefore also an architecture decision: retrieval-augmented, cited, and abstaining, so that a smaller controlled model outperforms a larger uncontrolled one on the task that matters.

How a model crosses the air gap

The update path is where provenance is most often broken in practice, because it is where convenience pushes hardest against control.

BABEL's model updates are signed packages. A package contains the model file, its provenance record, the publisher's hash, and a signature from Azcuna Dynamics over the whole bundle. The package is carried across the gap on approved media. On the isolated side, the software verifies the signature and the hash before the model is made available, and refuses the package if either fails. The previous model remains in place until the new one is accepted. Rollback is a menu item.

Nothing in this path requires the isolated system to have ever seen a network. Nothing in it requires trusting the media. The trust is in the signature and the hash, both of which can be independently checked.

What we will not do

A few practices are common in the industry and excluded from BABEL and ELLMENT by policy.

We do not ship models pulled from anonymous re-uploads. If the file cannot be matched to a publisher release, it does not ship.

We do not auto-update. A model change is a human decision with a paper trail.

We do not fine-tune on customer material without a written agreement that specifies where the resulting weights live and who owns them. Domain adaptation is done on curated, licensed data, and the adapted model gets its own provenance record.

We do not phone home. The software has no license server, no telemetry endpoint, and no update check. Whether a network exists is not something the software can determine.

Sovereign AI, defined carefully

"Sovereign AI" has become a label applied to almost anything, including hosted services with a flag on the login page. A definition worth using has four tests.

Model control. The operator possesses the weights, has verified them, and can pin, roll back, or replace them without a vendor's participation.

Data control. Documents, embeddings, indexes, and logs never leave the operator's perimeter, and there is no copy elsewhere.

Hardware control. The system runs on hardware the operator owns or is accredited to use, with no dependency on a vendor's infrastructure remaining available.

Update control. New capability arrives on the operator's terms, through a verifiable channel, on the operator's schedule.

A product that passes all four is sovereign in the only sense that matters: the operator can keep using it if the vendor disappears, the network is cut, or the relationship with a supplier changes. BABEL and ELLMENT are built to pass all four. A useful question for any vendor is which of the four they fail, and why.

Provenance in the ELLMENT program

ELLMENT, the E-2D Large Language Model Entity, is proposed to NAVAIR under a Navy SBIR topic that names trusted AI as a technology area. Model down-select is an explicit early task in the Phase I plan, with candidate models evaluated against the origin policy, the license, and performance on a surrogate corpus of procedures and logs. The selected model's provenance record becomes part of the program's security and data-governance plan mapped to NIST SP 800-171, and every query in the audit log carries its version.

This is what provenance looks like when it is engineered in rather than asserted after the fact, and it is the standard we hold across everything we build.

Questions to ask any AI vendor

  • Which model, exactly, is running, and what is its hash?
  • Who published it, under what license, and what did they disclose about training data?
  • How did you verify the file you deployed against the publisher's release?
  • What happens to the model when your company's relationship with the publisher changes?
  • How does a new version reach an isolated system, and who signs it?
  • Can I keep running this if you go out of business?

If the answers arrive as documents, the vendor has provenance. If they arrive as reassurance, keep asking.

Questions

A documented, verifiable account of where a model came from: who trained it, on what data, under what license, which exact version of the weights is deployed, and how those weights were checked against the publisher's release before use. It is the software bill of materials applied to AI.

Model weights are software from a foreign or domestic supplier and inherit the same supply-chain concerns: undisclosed training data, licensing terms that can change, and the possibility of embedded behaviors that are hard to audit. Defense programs already restrict where their software comes from. Models are software.

Open weights are a file. Once verified against the publisher's published hash and carried across the air gap, the file cannot call home, update itself, or exfiltrate anything, because it has no code path to the outside. Safety then depends on the deployment, which is why the model runs inside a zero-egress stack with logging and abstention.

Used honestly, it means the operator controls the model, the data, the hardware, and the update path, with no dependency on a vendor's service staying available or a foreign supplier staying friendly. Used loosely, it is a marketing label for a hosted product. Ask who can turn it off.