As automotive AI moves from research environments into safety-critical production systems, ISO/PAS 8800 is bringing greater focus to traceability, reproducibility and evidence across the full development lifecycle.
In this interview, Peter Kristiansen, Business Dev Exec – Automotive & Defence at Embedl discusses the practical gap between validating an AI model in PyTorch and proving the performance of the compiled, quantised binary running on vehicle hardware. He explains why compliance cannot be treated as an audit-stage task, and how automated evidence capture can help engineering teams continue innovating while building a stronger safety case for embedded AI deployment.
1. Where do organisations struggle most when applying ISO/PAS 8800?
The hard part is not reading the clauses. It is producing the evidence they ask for continuously, without grinding development to a halt.
The work lives in silos: data science, embedded engineering, and verification each hold a piece of the story, and nobody owns the whole chain. So evidence gets reconstructed by hand before an audit, and engineers spend considerable time proving their work was compliant. As AI models keep improving, this becomes unsustainable. Retrain on new data, switch quantization from symmetric to per-channel, recompile for a new runtime, and the safety argument is stale. You cannot freeze continuous development, so the evidence has to keep up automatically or you will fall behind.
2. What gaps exist between standards and deployment realities?
The standard is written at the level of the vehicle and the AI element. Deployment happens at the level of a specific binary, on a specific chip, with a specific runtime. The gap is the distance between the two.
The model a data scientist validates in PyTorch is not the model that ships. Between them sit compilation, quantization, and a target runtime such as TensorRT on a DRIVE Orin-X, and each step can change numerical behavior and latency. If your evidence stops at the float model in the notebook, you have documented something that never runs in the car. The safety-relevant artifact is the compiled, quantized binary on the target, and that is exactly the layer traditional toolchains leave undocumented. Reproducibility is the second gap: auditors ask whether you can rebuild this exact binary from this exact source and data and get the same result, and for most edge pipelines built from manual laptop scripts, the honest answer is no.
3. How should engineers balance compliance and innovation?
Stop treating them as a trade-off. Make the evidence a by-product of the work rather than a phase after it.
Compliance feels like a brake because it is bolted on at the end: build, optimize, benchmark, then scramble to collect screenshots before an audit. The fix is to capture evidence the moment the work happens. Every compilation, quantization, and hardware test logs itself: what model, what data snapshot, what target, what runtime, what result, who ran it, and a hash of the artifact. When that is automatic, part of the safety case assembles itself as you iterate, and you can move as fast as the product needs. This is the principle behind Embedls workflow: it logs every compilation, quantization, and test automatically on the real target, and links each result back to the requirement it satisfies. The benchmark proving 28.4 ms latency on Orin-X is the same record that lands in the compliance report.
4. What best practices have emerged from early adoption efforts?
Four patterns separate the teams making this work from the ones dreading their first audit.
Verify on the target, not the proxy. Measure accuracy, latency, and determinism on the chip and runtime that ship, and run integration testing across real devices early, so incompatibilities surface in week one rather than during integration crunch. Make builds reproducible by construction: tie every binary to its source commit, training data snapshot, and content hash, so any artifact can be regenerated and defended. Treat traceability as a shared system of record, not a document, so all three functions read from one place and the verification engineer stops chasing status. And plan for the field. ISO 26262 Part 7 and ISO 21448 clause 13 both define field-monitoring processes for the operation phase, and ISO/PAS 8800 sharpens the point that development and deployment are iterative long after the vehicle is released. A traceable, reproducible pipeline is what lets you retrain and reship safely across that whole lifetime, from PyTorch to the hardware in the vehicle.
Interested in exterior vehicle sensing technology?
With a pass to InCabin Europe, you’ll also get full access to our
co-located sister event, AutoSens. Find out more here >>
Want more inspiration? Check out more InCabin interviews here ⬇
