If you ship a device that makes automated decisions in the European Union, the question stops being "is the model accurate" and becomes "can you show what it decided, and prove the thing that decided it is the thing you tested". Those are engineering requirements, and on a microcontroller they are unusual ones.
This is an engineering note, not legal advice. Which obligations apply to your product depends on its classification, and that is a question for a lawyer. What follows is what the technical requirements look like when they land on a 32-bit part with 64 KB of RAM.
Four things a device is asked to demonstrate
| Requirement | What it means in firmware |
|---|---|
| Record keeping | A decision log that survives a power cut and that a third party can verify was not edited afterwards. |
| Transparency | The device can say which model version produced a given decision, and that identifier is bound to the actual bytes. |
| Human oversight | Low-confidence cases must be surfaceable rather than silently acted on. An abstention path, not a forced label. |
| Robustness and accuracy | A measured figure with a stated method, and the behaviour under inputs the model was never trained for. |
Why this is hard on a microcontroller
A cloud service writes to a database and calls it a log. A microcontroller has flash with a finite erase count, no clock it can trust across a power cut, and no filesystem worth the name. Three problems follow:
- Tamper evidence without a server. Storing decisions is easy; proving nobody rewrote them is not. A hash chain — each record covering the previous digest — means altering any past record invalidates everything after it, which is detectable offline with no network involved.
- Binding the model identity to the actual bytes. "Model v1.4" in a config field is a label. A signature over the model blob, verified at load time, is a binding. The difference matters the first time a field unit is found running something it should not be.
- Abstention that means something. A softmax always produces an answer. With
channel 0 flatlined in one of our integration tests, the model still answered
class=4, accept=1— a confident, meaningless label. The out-of-distribution guard suppressed it and logged a sensor-fault event instead. That is what a human oversight path has to look like at the bottom of the stack.
Where bit-exactness earns its keep
The obligation is to show that the deployed system behaves like the assessed one. Normally that is an argument about acceptable drift between a Python model and its quantized deployment. If the on-device engine is byte-identical to the reference, it becomes a test that passes or fails. Our max |Δ| across Python, C99 and an emulated Cortex-M3 is 3.7e-7, with multi-token generation exact; on the sensing line the C engine matched the reference on 2947/2947 held-out windows exactly. How that is checked.
The bandwidth argument, which is also a privacy argument
A device that transmits a raw waveform for classification elsewhere has to justify that transmission — data minimisation is a separate obligation from the AI rules and it applies anyway. A device that classifies locally and transmits a decision moves roughly 48× less payload, and the raw signal never leaves the enclosure. Doing the inference on-device turns a data-protection question into an engineering fact.
What we ship toward this, and what we do not
- Present: Ed25519-signed models with a load-time integrity check, a tamper-evident hash-chained decision log (154 bytes of overhead), an out-of-distribution guard with two-tier abstention, and bit-exact parity between reference and deployed engine.
- Not present: a certification. None of the above makes a device compliant. It makes the evidence a conformity assessment asks for possible to produce, which is a different and much smaller claim.
If you are building toward an assessment and want to know which of those pieces you would still have to build yourself, describe the device — that question has a concrete answer.
Questions
What does the EU AI Act require from an edge device?
In engineering terms: a decision log that can be shown not to have been edited, a model identity bound to the actual bytes rather than a config label, a path for surfacing low-confidence cases to a human instead of acting on them, and a measured accuracy figure with a stated method. Which obligations apply depends on how the product is classified, which is a legal question.
How do you keep a tamper-evident log on a microcontroller?
A hash chain: each record includes a digest covering the previous one, so altering any past record invalidates every record after it. That is detectable offline with no server involved, which matters on a device that may never have a network.
Does on-device inference help with data protection?
It removes the transmission. A device that classifies locally sends a decision instead of a raw waveform — roughly 48× less payload in our measurement — and the raw signal never leaves the enclosure, which turns a data-minimisation argument into an engineering fact.