ISO 26262 Evidence for On-Device AI: A Practical Clause-by-Clause Mapping

Start with the boundary

Before any mapping, the honest part. EdgeGate is a verification evidence tool. It is not a qualified software tool, it does not certify a system or an item, and it does not replace a functional-safety assessor. What it does is produce signed, reproducible, requirement-traceable evidence that an ISO 26262 assessment depends on. Tool confidence level (TCL) evaluation under ISO 26262-8 clause 11 remains the responsibility of the organization deploying the tool. Any vendor who tells you their tool “makes you ISO 26262 compliant” is selling you a problem, not a solution.

With that boundary set, the clauses where on-device evidence actually helps are concentrated in Part 8 (supporting processes) and Part 6 (software-level verification). Here is the practical mapping.

The clause-by-clause mapping

Configuration management (Part 8, cl. 7)

Configuration management asks a deceptively hard question: can you identify, unambiguously, exactly what was verified? For an AI model that has been quantized and compiled, “the latest build” is not an answer. The evidence has to pin the artifact by content hash, not by a movable label.

A signed bundle records the model SHA-256, the evaluation-set SHA-256, the target device, and the SDK and driver versions in effect at run time. Six months later, anyone can confirm that the binary in the field hashes to the same value that appears in the verification record. That is configuration control that survives an audit, not a wiki page that drifts.

Change management (Part 8, cl. 8)

Change management requires that every change be evaluated for its safety impact and re-verified. In a modern ML workflow, “a change” is a pull request that swaps a model artifact. The natural place to enforce re-verification is therefore the PR gate: no model change merges until it has been re-run on real hardware and the gate has passed. The version-control history becomes the change record, and the gate becomes the enforcement point. There is no separate, manual ceremony to forget.

Verification (Part 6, cl. 9–10 and Part 8, cl. 9)

This is the heart of it. Part 6 covers verification at the software unit and integration level; Part 8 clause 9 covers the verification process and its records. For on-device AI, verification has to happen on the actual silicon, because that is where quantization and operator-fallback behavior actually lives. An emulator result verifies a different thing.

The piece that turns a test result into ISO 26262 verification evidence is traceability: each check has to map back to the requirement it satisfies, carrying its ASIL. A latency number floating in a dashboard is not evidence. The same number, bound to a safety requirement and its integrity level and signed, is.

Here is what that looks like for an in-cabin LLM safety gate — a real signed verdict from an on-device run on a Snapdragon 8 Gen 2:

Each line is a verification claim an assessor can place directly into a safety case: the on-device model refused unsafe requests (SR-CABIN-014, ASIL D), held its safety-probe pass rate (SR-CABIN-021, ASIL D), and did not regress task success versus the full-precision reference (SR-CABIN-007, ASIL B). The behavior was measured on the real chip, and the result is signed so it cannot be quietly edited afterward.

Documentation (Part 8, cl. 10)

Documentation in ISO 26262 is not a formatting exercise — it is the requirement that work products be recorded, identifiable, and available for assessment. A signed evidence bundle satisfies this by construction: the Ed25519 signature and SHA-256 manifest make the record tamper-evident, and a one-click report renders the same evidence in a form a human assessor reads. The documentation is not produced after the fact from memory; it is the by-product of the verification run itself.

What this does not do

It is worth repeating the boundary, because it is where credibility is won or lost with safety teams. A signed bundle does not certify the item, does not discharge the safety case, and does not perform tool qualification. SOTIF (ISO 21448) considerations for the AI's intended-function behavior, the broader safety argument, and the TCL evaluation under clause 11 all remain the program's work. What the evidence removes is the worst part of that work: the scramble to reconstruct, late in a program, what was actually tested and whether it can be trusted. That material now exists, signed, from the moment the gate ran.

In-vehicle LLMs, ISO 26262, SOTIF, and the EU AI Act are all converging on the same demand: prove, with reproducible evidence, what the AI does on the device it runs on. The teams that wire that evidence into CI now will spend their assessment cycles defending a safety argument, not rebuilding a paper trail.