The EU AI Act Is Coming for Edge AI — Here's the Evidence You'll Need

The clock everyone in edge AI should be watching

The EU AI Act entered into force in August 2024 and applies in phases. Prohibited-practice rules took effect in early 2025. General-purpose AI obligations followed. The phase that matters most for teams shipping AI on devices is the high-risk tier: obligations for Annex III high-risk systems apply from August 2026, and for AI embedded in products already covered by EU safety law — vehicles, medical devices, machinery — from August 2027.

Those 2027 dates feel far away until you remember how long an automotive or medical program is. A model going into a vehicle launching in 2027 is being quantized and validated now. The evidence obligations do not start when the law applies; they start when the work that has to be documented begins.

What the Act actually asks of a high-risk system

The legal text is long, but for an engineering team the high-risk obligations collapse into a handful of recurring demands. You need to maintain technical documentation that shows how the system was developed and tested. You need record-keeping — the system and its development have to leave a traceable log. You have to demonstrate an appropriate level of accuracy, robustness, and cybersecurity, and document how you measured it. And once it ships, you owe post-market monitoring: evidence that it still behaves as claimed in the field.

None of those is satisfied by a number in a slide. Each is, at its core, a demand for evidence that survives scrutiny: identifiable, reproducible, and tied to the specific system that shipped. That should sound familiar — it is the same shape as the ISO 26262 verification requirements automotive teams already work to, which is not a coincidence. Regulators and safety standards are converging on the same idea.

Why “we tested it in the cloud” doesn't cover on-device AI

Here is the specific trap for edge AI. The system the regulator cares about is the one running on the device — the quantized, compiled binary on the NPU, not the full-precision model you evaluated on a cloud GPU. Those are different artifacts that can behave differently. Accuracy and robustness measured on the cloud model are not, strictly, evidence about the system you placed on the market.

So a high-risk on-device AI system needs evidence measured where it actually runs. That evidence has to identify the exact model that shipped, the hardware it ran on, and the conditions of the test, and it has to be reproducible later when an auditor or a post-market investigation asks. A dashboard screenshot from a CI run six months ago is not that.

Where signed on-device evidence fits

This is the throughline across the whole Act's high-risk regime, and it maps directly onto a signed evidence bundle:

Technical documentation — the bundle records what was tested, on which device, with what result, pinned by content hash. It is documentation produced as a by-product of the test, not reconstructed afterward.

Record-keeping — each run is a tamper-evident, signed record. The version-control history of which model passed which gate becomes the audit log.

Accuracy and robustness — the gate measures these on the real chip, against the full-precision reference, and signs the result. For on-device LLMs, that extends to safety behavior under adversarial inputs.

Post-market monitoring — the same gate, run on a schedule against the same signed reference, catches drift from driver and firmware updates after deployment, with a signed record each time.

The honest boundary

To be clear about what evidence does and does not do: producing signed on-device evidence does not make a system compliant, does not perform a conformity assessment, and is not legal advice. Conformity is a determination made through the Act's assessment routes, with your legal and regulatory teams. What evidence does is remove the worst failure mode — arriving at an assessment, or a post-market incident, without a credible, reproducible record of how the deployed system was tested. That record is expensive to reconstruct under pressure and cheap to generate at the moment the gate runs.

What to do now

You do not need to have the compliance program finished to start accumulating the evidence it will need. The practical move is to gate your on-device models on real hardware in CI today, and keep the signed bundles. By the time the high-risk obligations bind your product, you will have a back-catalog of reproducible, requirement-traceable evidence for every model build — instead of a scramble to reconstruct one. The teams treating on-device evidence as infrastructure now will spend the next two years building products. The ones treating it as a paperwork exercise later will spend them building paper trails.