The EU AI Act Goes Live on 2 August 2026: What High-Risk Deployers Must Now Prove
From 2 August 2026, high-risk deployers must prove logging, human oversight and data governance as evidence, not as written policy.
On 2 August 2026 the EU AI Act reaches full application for its most demanding tier. The obligations attached to high-risk systems, including the Annex III use cases spanning biometrics, critical infrastructure, education, employment, essential public and private services, law enforcement, migration and the administration of justice, become enforceable against the organisations that operate them. This is the date the regulation stops being a roadmap and starts being a standard that a supervisory authority can measure a live deployment against.
The detail that many boards have underweighted is where the burden lands. Providers build the system, but under Article 26 it is the deployer, the organisation running the system in the real world, that carries the operational accountability. A hospital, a bank, a benefits agency or a police force cannot delegate that duty upward to a supplier. When an inspector arrives, the question is not whether a policy document exists. The question is whether the deployment can produce evidence, on demand, that it did what the law requires at the moment it mattered.
What Article 26 actually asks a deployer to demonstrate
The deployer obligations are specific and testable. Human oversight must be assigned to named natural persons who have the competence, training and authority to understand the system, monitor it, detect anomalies, and override or refuse its output. Automatically generated logs must be retained for at least six months. Input data, to the extent the deployer controls it, must be relevant and sufficiently representative for the intended purpose. Where the use case demands it, a Fundamental Rights Impact Assessment must be completed before the system goes into service.
Read together, these are not documentation requirements. They are claims about how a system behaves in production. Each one implies an artefact that either exists at the moment of an event or does not. A log written after an incident, an oversight decision that cannot be traced to a specific person, or a data lineage that breaks under questioning are all failures that no amount of governance prose will repair.
The gap between a written control and a provable one
Most compliance programmes today prove intent rather than fact. They present a policy stating that oversight happens, a screenshot suggesting logs are kept, and an attestation that data governance is in place. This is the model that ISO/IEC 42001, the international standard for AI management systems, formalises, and it is genuinely useful as a management discipline. It describes the processes an organisation intends to follow.
An intended process and a proven event are different things. A regulator examining a high-risk deployment after a contested decision does not want to know what the organisation meant to do. They want the record of what happened: which model version ran, on which inputs, under whose oversight, with what output, and whether that record could have been altered afterwards. When the log lives in a mutable database on infrastructure the deployer does not fully control, the honest answer to the last question is that it could have been.
“Under the EU AI Act, the burden has shifted from stating that a control exists to producing the evidence that it operated, and evidence is an engineering property, not a policy one.”
Proving obligations by construction rather than by assertion
Mickai is built as a Sovereign Intelligence Operating System, a SIOS, precisely because compliance of this kind is more reliably achieved in the architecture than in the paperwork wrapped around it. A SIOS runs offline on operator-owned hardware, and every action it takes is cryptographically sealed as it happens. The distinction matters for the Act: an obligation that is satisfied by the design of the system is one the deployer can demonstrate rather than merely assert.
Consider the six-month logging duty. When each action is written into a post-quantum signed audit chain at the moment of execution, the log is not a report generated afterwards. It is a tamper-evident sequence in which any later alteration breaks the cryptographic link and is therefore detectable. The deployer is no longer asking a regulator to trust that records were not touched. The chain either verifies or it does not, and that verification runs without reference to any external supplier.
Human oversight that leaves a signed trace
Human oversight is the obligation most often reduced to a training slide. The Act asks for something harder: a named, competent person able to interpret, override and refuse, with the authority to do so. To prove that a specific individual exercised that authority at a specific moment, oversight has to be bound to identity at the point of action.
Hardware-attested identity closes that loop. When the person exercising oversight is authenticated against the hardware itself, and their decision to accept, override or reject an output is sealed into the same signed chain as the model's action, the record answers the regulator's question directly. It shows not that oversight was policy, but that this person made this decision on this output at this time. Data governance under Article 10 is reinforced by the same design, because a zero-egress inbound perimeter means the input data a deployer is accountable for never leaves the operator's control to begin with.
Why offline and sovereign is the load-bearing choice
The strategic backdrop makes this concrete rather than abstract. The UK established a Sovereign AI Unit in 2026, and clinical bodies have warned openly that NHS data, including data derived and structured by AI, must remain under domestic stewardship rather than drift onto infrastructure the country does not control. The concern is not merely legal. It is that data sovereignty determines who can answer for a system when it is questioned.
An offline SIOS answers that in the only durable way. When the model, the data and the audit chain all sit on hardware the operator owns, egress is not a risk to be monitored but a path that does not exist. Cross-model consensus, where more than one sovereign model must agree before a high-stakes output is issued, adds a further layer of defensibility for exactly the Annex III decisions the Act treats as high-risk. The architecture supporting this approach is the subject of 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD, all patent pending. We note this only to be clear that the mechanisms are engineered rather than aspirational.
What buyers and regulators should expect after August
The date is not the end of the story, and it would be misleading to suggest otherwise. The Digital Omnibus discussions in Brussels may adjust the timing for some stand-alone Annex III systems, and organisations should track the final text as it is published in the Official Journal rather than assume every deadline is fixed. What will not soften is the underlying demand: that a high-risk deployer be able to prove, from the record, what its system did.
That is the test we would encourage any CISO, regulator or public-sector buyer to apply to every high-risk deployment they are accountable for, whoever supplies it. Ask to see the log for a specific past decision. Ask who is cryptographically bound to the oversight of it. Ask whether the record could have been changed after the fact, and whether the answer depends on trusting a third party. Systems that can answer those questions from their own construction will carry their operators through the coming decade of scrutiny. Systems that can only answer with a policy will find that policy is not evidence.