The Training Data Is a Liability You Cannot See

You bought the model. You did not buy its memory.

Here is a question that ends most artificial intelligence (AI) procurement conversations the moment you ask it seriously. What, exactly, did this model learn from? Not the brochure answer. The real one. The list. Every corpus, every scrape, every licensed set, every synthetic batch, every quiet top-up someone added on a Friday to fix a benchmark. If you cannot produce that list, and prove it has not changed since, then you do not own a model. You own a stranger's memory wearing your logo.

I find this is the part people skip. They test the outputs. They red-team the prompts. They write a policy about acceptable use. And underneath all of it sits a training set nobody in the building can describe, sourced through a supply chain nobody mapped, frozen into weights that nobody can read. The behaviour you are testing is just the surface. The liability is the water underneath, and you cannot see it. Worse, the parts you can see give a false sense of control, because a system that answers your test questions well feels known even when its origins are a complete blank.

Provenance is the security property, not the paperwork

Security people have a habit worth borrowing. When something matters, they assume it is already compromised and ask what they can prove. Apply that to training data and the picture changes fast. A model is a lossy compression of everything it was fed. You cannot un-bake a cake to inspect the eggs. So the only place you can establish trust is at the input, before the data becomes weights, while it is still a thing with a name and a hash and a source you can point at.

This is why I treat data provenance as a security property rather than a compliance chore. Provenance is the chain of custody for everything that shaped the model's behaviour. Where each piece came from, who touched it, when it entered the set, what was done to it, and what it became. Without that chain you are not running a known system. You are running a black box that happens to be confident, and confidence is not the same as correctness. The gap between the two is exactly where the damage lives, and it is the gap nobody budgets for until an output goes wrong and the first question is where the data came from.

Poisoning does not need much, and that is the problem

Now add an adversary, because there always is one. Data poisoning is the deliberate contamination of a training set so the resulting model misbehaves in a way the attacker chose in advance. It is attractive precisely because it is cheap and quiet. You do not need to breach the model. You contribute to it. Open scrapes, public repositories, community datasets, and the long tail of third-party corpora are not a curated library. They are a shared surface that strangers can write to, and most pipelines ingest from that surface without ever recording which strangers wrote what.

The research direction over the last couple of years has been sobering in a consistent way. The volume of corrupted material needed to plant a reliable backdoor in a large model keeps looking smaller than intuition suggests, often a strikingly small slice of the whole rather than the large fraction people assume is required. The attack survives training. It hides until a specific trigger appears, then it does exactly what it was told. And critically, it leaves no obvious fingerprint in the finished weights that ordinary testing will find, because you cannot test for a trigger you do not know exists. A poisoned model passes your evaluations with a smile. That is the entire point of the technique.

So the defensive question is not whether your model has been poisoned. You cannot answer that by looking at it. The question is whether you can prove what went in. If you can attest the inputs, you can reason about the outputs. If you cannot, you are defending a position you were never able to see, which is to say you are not defending it at all. Provenance does not magically clean a corrupted dataset, but it tells you where every piece came from, which turns a guessing game into an investigation you can actually run.

The liability is moving from theory to law

For a long time this stayed an engineering argument, easy to defer. That window is closing. The regulatory direction across major markets is unambiguous: AI liability is rising, documentation duties are hardening, and the people deploying these systems are being asked to evidence what they built, not merely promise it. In the European Union (EU), high-risk obligations under the AI Act begin applying through 2026, and they lean directly on data governance, traceability, and record-keeping. The expectation is shifting from trust me to show me, and it is shifting in the direction of the deployer, not just the original developer.

Run that expectation against the average training pipeline and the exposure becomes obvious. A regulator, an auditor, or a court asks a simple thing. Prove the data behind this decision was what you say it was, and prove it has not been altered since. Most organisations cannot. They have logs that the same party who created them can quietly rewrite, dashboards that describe the present and forget the past, and assurances that evaporate the moment someone with subpoena power stops being polite. A record you control unilaterally is a record nobody else has any reason to believe, and a record nobody else believes is worth very little when the question is adversarial.

What a defensible record actually requires

If provenance is the security property, then the record that carries it has to meet a security bar, not a marketing one. From building Mickai, our Sovereign Intelligence Operating System (SIOS), I have come to think it needs four things, and that anything missing one of them is theatre. Each of the four closes a specific way that an ordinary log lies to you.

• Signed before the fact. The attestation of an input or an action is committed before that thing is used, not narrated afterwards. A log written after the event is a story. A signature made before it is evidence.
• Append-only and hash-chained. Each entry seals the one before it, so silently editing history breaks the chain and the break is detectable. You cannot quietly rewrite the past without leaving the rewrite visible.
• Post-quantum from the start. Signatures use a standard built to survive the next generation of computing, so a record that must hold for a decade is not retroactively forgeable. We use the United States National Institute of Standards and Technology (US NIST) standard FIPS 204, ML-DSA-65.
• Verifiable offline, with no trust in the vendor. Anyone can check the record in an ordinary browser, with no call home, no special access, and no faith in the company that produced it. If verification requires trusting the accused, it is not verification.

That last point is the one I will not move on. A provenance record you have to trust the vendor to read is just the vendor's word with extra steps. The whole value is that it removes the vendor, including me, from the position of being believed. You check the mathematics, not my character. Drop any one of these four and the record degrades into the same soft assurance it was meant to replace, which is why I treat the set as indivisible rather than a menu.

How we wired it, and why it sits underneath everything

In Mickai this is the Open Audit Record (OAR). Every AI action is signed before it executes, hash-chained into an append-only ledger, sealed with post-quantum signatures, and verifiable offline by anyone with a browser and no reason to trust us. The fifty brains, twenty-five domain and twenty-five operational, run on the Poseidon silicon substrate, and none of them act without leaving a sealed, ordered, tamper-evident trace. Pantheon, a sovereign Layer 1 that anchors the audit root to Bitcoin, extends that guarantee outward so the record's integrity does not rest on our infrastructure staying honest either. Pantheon is the one piece still being built, with its native token PAN fixed at a supply of five billion; the OAR it will anchor is already live.

It matters that we are actively training our own models now, fine-tuning and specialising open foundations such as Llama 3.2 and Qwen 2.5 while building a sealed corpus, with funding scaling toward fully native weights. The provenance argument applies to us first. We are not exempt from the question I opened with, and the credibility of everything above depends on us answering it before we ask anyone else to. The sealed corpus exists precisely so that the answer to what went in is a record, not a reassurance. The same discipline runs through the patent position: one hundred and one filed United Kingdom patent applications, roughly two thousand two hundred and thirty-four claims, owned by Mickai LTD with me named as the inventor, which is itself a documented chain rather than a claim you are asked to take on faith.

Attest the inputs, or stop defending the outputs

Strip away the architecture and the thesis is plain. A model is a claim about its data. If you cannot attest the data, the claim is unverifiable, and an unverifiable claim is a liability dressed as an asset. Poisoning makes that liability adversarial. Regulation makes it legal. Time makes it expensive, because the bill arrives later, when you can least afford to discover you cannot answer.

So I would put it as bluntly as I can. Do not ask whether your training data is clean, because you cannot know and neither can anyone selling you a model. Ask whether you can prove what it was. If the honest answer is no, then every output that system produces is a liability you cannot see, and the moment someone with authority decides to look, it becomes the only thing they can see. Build the record first. Sign it before the fact. Make it survive you. Then, and only then, you can defend what comes out, because for the first time you can prove what went in.