Data Provenance Is Now the Law: EU AI Act Article 10 and the Signed Lineage

On 2 August 2026 the substantive obligations of the EU AI Act reach full application for high-risk systems. Among them sits Article 10, which governs data and data governance. It requires that training, validation and testing datasets be relevant, sufficiently representative and, as far as possible, free of errors. It requires operators to document the provenance of that data, to examine it for bias, and to handle special categories of sensitive information under strict conditions. The obligation is no longer good practice; it is enforceable law.

The gap this exposes is uncomfortable for most organisations. For years, data governance has been evidenced by a document: a written policy describing how data should be sourced, labelled and reviewed. Article 10 asks a harder question. Not what your policy says you do, but what your system actually did, on this dataset, for this decision, on this date. A policy PDF describes intent. It cannot prove what happened inside a running model, and that distance is where regulatory and reputational risk now sit.

What Article 10 actually asks for

Read plainly, Article 10 is a demand for continuous, examinable evidence. It expects operators to know where their data came from, how it was collected, what it represents and what it excludes, and it expects sensitive attributes to be identified and controlled rather than silently absorbed. For an assessment body, or a regulator acting after an incident, the relevant material is the record, not the intention behind it.

The Act sits alongside other 2026 pressures pointing in the same direction. ISO/IEC 42001 has made an auditable AI management system a procurement expectation. The UK Sovereign AI programme has pushed data residency up the agenda for public bodies. Concern over NHS data sovereignty has made the question of who can see, move or retain sensitive records a board-level issue. Each strand converges on one requirement: verifiable provenance that survives scrutiny long after the decision was made.

Why a policy document cannot answer the question

A policy is a statement about the future written in the present. It says how data ought to be handled, but carries no binding to any specific event. When an auditor asks whether a particular decision drew on a dataset that was representative and lawfully sourced, a policy offers a description of the process, not a record of the instance. The two can diverge quietly, and usually do.

Worse, a document can be edited after the fact with no trace. There is nothing in a written policy that fixes it to a moment in time or proves it was not amended once a problem surfaced. Provenance evidence that can be revised retroactively is not evidence at all. It is a narrative. Article 10 is asking for something a narrative cannot supply: a tamper-evident account of what the system did with what data, that a third party can independently check.

The signed decision lineage

A signed decision lineage record answers the question a policy dodges. For every consequential action a system takes, it captures the inputs consulted, the data sources drawn on, the model or models that reasoned over them, the sensitivity classification applied, and the outcome produced. That record is then cryptographically sealed, so any later alteration breaks the seal and becomes immediately visible.

This is the design principle behind Mickai, our Sovereign Intelligence Operating System, a SIOS that runs offline on operator-owned hardware with every action cryptographically sealed. Each decision is written into an append-only chain protected by post-quantum signatures, so the audit record remains verifiable even against future cryptographic attack. The identity that signed each entry is hardware-attested, so the record proves not only what happened but on which machine and under which credential.

“Article 10 does not ask what your data policy says; it asks what your system did, and only a signed lineage can answer that without asking anyone to take your word for it.”

Offline verifiability and the inbound perimeter

Provenance is only as trustworthy as the boundary around the data. If sensitive records can leave the estate, or unaccounted inputs can enter it, the lineage becomes incomplete precisely where it matters most. This is why we operate a zero-egress inbound perimeter: data can be brought in for the system to reason over, but nothing is sent out, and there is no dependency on a remote endpoint that could see, log or retain it.

Running offline on operator-owned hardware makes the guarantee concrete rather than contractual. The sensitive dataset never traverses a third party. The lineage record is generated and held within the operator's own control, and can be verified there without contacting any vendor. For a public body weighing data sovereignty, the difference between a promise of confidentiality and an architecture that makes disclosure structurally impossible is decisive.

Consensus, sensitivity and defensible decisions

Article 10 places particular weight on sensitive data and on the risk of bias. A single model reasoning alone offers no internal check on either. Our approach applies cross-model consensus, where several sovereign models, never dependent on any external vendor, evaluate the same question and their agreement or disagreement is itself recorded in the lineage. A contested decision is flagged rather than hidden, and the disagreement becomes part of the evidence.

Sensitivity classification is likewise captured at the point of use, not asserted in a separate register. When a decision touches a special category of data, the record shows that the classification was applied and how the data was handled under it. That turns compliance from a claim into an artefact. An auditor need not trust that sensitive handling occurred; they can read the sealed entry and confirm it.

What buyers should now demand

For a CISO, a regulator or a public-sector buyer, the practical test has changed. The question is no longer whether a supplier has a data governance policy. Every serious supplier has one. The question is whether the system produces a tamper-evident record of what it actually did, whether that record can be verified without trusting the supplier, and whether the sensitive data ever left the operator's control.

Agentic systems raise the stakes further. When a system takes actions on its own initiative, the count of decisions that must be governed rises sharply, and after-the-fact reconstruction from logs becomes unworkable. A lineage sealed at the moment of each action is the only evidence that scales with that behaviour. The engineering that supports it, from the sealed audit chain to the hardware-attested identity, forms part of the 104 filed UK patent applications and approximately 2,340 claims owned by Mickai LTD, none of which is granted or patented.

The direction of travel

2 August 2026 is a threshold, not an endpoint. The logic of Article 10, that governance must be evidenced rather than asserted, will not stay confined to high-risk categories or to the European Union. Wherever consequential decisions are automated, the demand for provenance that a third party can independently verify will follow. A written policy will increasingly read as a statement of good intentions, useful but not sufficient.

We built Mickai on the assumption that this shift was coming, and that the measured response was to make every decision self-evidencing rather than merely well-documented. The organisations that fare best under the new regime will be those that can hand an auditor a sealed record and invite them to check it, rather than a document and a request to be believed. Provenance is now the law, and the considered step is to be able to prove it.