EU AI Act Article 15: Proving Resilience to Manipulation, Not Just Claiming It

The EU AI Act high-risk obligations for the systems listed in Annex III were once due on 2 August 2026, and after the Digital Omnibus deferral they now apply from 2 December 2027. Article 15 sets a requirement that is easy to read and hard to satisfy: a high-risk system must be resilient to attempts by unauthorised third parties to alter its use, outputs or performance by exploiting its vulnerabilities. The provision does not ask for an opinion about robustness. It asks for a system that behaves resiliently, and for records that let an auditor confirm it. The proof requirements are unchanged, so the sensible response is to build now.

That shift matters because most organisations arrive at the deadline with a security policy and a shortage of evidence. A policy describes intent; Article 15 concerns fact. When a regulator, a notified body or a public-sector buyer asks how a system resisted a specific manipulation attempt, the answer needs to be a record that can be produced, dated and verified. The gap between claiming resilience and proving it is what this article examines.

What Article 15 actually demands

Article 15 sits alongside accuracy and cybersecurity as a single obligation, and its resilience clause is specific. It names data poisoning, model poisoning, adversarial examples, model evasion and confidentiality attacks as the categories a high-risk system must withstand. The regulation expects measures to prevent, detect, respond to and control these attacks, documented in the technical file.

The word documented is doing quiet, heavy work. A control that exists but leaves no trace is invisible to an auditor and therefore, for compliance purposes, unproven. The regulation does not reward the presence of a defence; it rewards the demonstrable exercise of one. This aligns Article 15 with the direction set by DORA, in force across the EU financial sector since January 2025, and by NIS2, both of which treat evidence, not assertion, as the unit of assurance.

Why a policy statement fails the test

Consider the lifecycle of a security claim. A team writes that its system defends against adversarial inputs. Six months later the model is retrained, a dependency is updated and a configuration is changed. The claim in the handbook is unchanged and now describes a system that no longer exists. Nobody lied; the document simply drifted away from reality.

An auditor examining that claim cannot tell a maintained defence from a stale one, because the sentence reads the same in both cases. What distinguishes them is a record produced at a known time, tied to a known version of the system, showing a known adversarial test and its outcome. Absent that record, resilience is a matter of trust, and Article 15 exists because trust is not evidence.

“Resilience that cannot be produced as a signed, dated record tied to a specific system version is, for the purposes of an audit, indistinguishable from no resilience at all.”

Evidence by construction, not by assembly

There are two ways to hold evidence. One is to assemble it after the fact, gathering logs and screenshots when an audit is announced; this is fragile, because evidence held apart from the system that generated it can be edited, lost or quietly curated. The other is to make evidence a by-product of running the system, so a defence cannot be exercised without leaving a durable, verifiable trace.

We build Mickai, a Sovereign Intelligence Operating System, on the second principle. Every action a SIOS takes is cryptographically sealed as it happens, so an adversarial test is not a separate exercise whose result someone types into a report. The test runs, and its inputs, the version under test and the observed outcome are recorded and signed in the same motion. The record exists because the work happened.

The mechanics of a tamper-proof audit chain

A signed record is only as good as the assurance that it has not been altered since signing, and this is where an audit chain earns its keep. Each entry is bound to the one before it, so changing any earlier record would break every record that followed. A reviewer does not have to trust the operator's word that the log is intact; they can check the chain for themselves.

The signatures we use are post-quantum, which matters for evidence that must remain verifiable for years. A record signed today may be examined by a regulator in 2032, and a scheme breakable by then would let a determined party rewrite history retroactively. Binding the signing identity to the hardware itself, rather than to a portable credential, closes a further gap: the record proves not only that a test occurred but that it occurred on the attested machine.

Designing out the manipulation surface

Resilience is not only about recording attacks; it is also about reducing the surface on which they can land. Confidentiality attacks and model evasion both depend on an adversary being able to reach the system at all, and a design that assumes constant outbound connectivity to a remote service accepts a large, permanent attack surface as the price of operation.

We take the opposite stance. A SIOS runs offline on operator-owned hardware behind a zero-egress inbound perimeter, so the model is not continuously exposed to the open network and its data does not leave the operator's control. Such a system is not resilient because of a stronger fence around the data; it is resilient because there is no journey for the data to make. The same logic explains why jurisdictional reach, such as the US CLOUD Act, becomes a design consideration: data that stays on sovereign hardware is not subject to a foreign production order.

Cross-model consensus and the limits of a single verdict

Adversarial examples exploit the blind spots of a specific model, so relying on any single model's judgement is itself a vulnerability. We run cross-model consensus, in which more than one sovereign model evaluates a decision and disagreement is surfaced rather than hidden. A manipulation crafted to slip past one model must now defeat several that do not share the same blind spots, and the attempt tends to show up as consensus that breaks down.

The consensus outcome is itself sealed into the audit chain, so the technical file records not only that a decision was made but how many independent evaluations supported it and where they diverged. That is the kind of verifiable detail an assessor can interrogate, and it maps onto the concerns catalogued in the OWASP guidance on AI risks and the expectations of ISO/IEC 42001. The point is not that consensus is infallible, but that its workings are visible and preserved rather than asserted.

Preparing for the standard of proof ahead

The organisations that will find August 2026 manageable treat resilience as something the system demonstrates continuously, not something a person vouches for periodically. As harmonised standards mature, the practical question narrows to a single test: when asked to show that a high-risk system resisted a specific manipulation on a specific date, can the operator produce a record a third party can verify without taking anyone's word for it.

Our answer is architectural. A SIOS produces that record as a condition of operating, signs it with post-quantum keys bound to attested hardware, and chains it so that tampering is detectable rather than deniable. The 104 filed UK patent applications and approximately 2,340 claims owned by Mickai LTD, patent pending, describe much of this sealed-evidence machinery, though the compliance value rests on the engineering itself. Article 15 rewards the operator who can prove resilience on demand, not the one who claims it most confidently, and proof of that kind has to be built in.