ISO 26262 with AI — ASIL evidence kept alive, not rebuilt the night before the TÜV audit.

The problem

The Safety Case rests on a chain nobody sees until the auditor asks for it.

ISO 26262 is not a paper standard: it is a logical chain that runs from the vehicle hazard analysis, down through the architecture, assigns an ASIL to each safety-relevant component and requires production to prove, serial number by serial number, that the component meets the derived requirements. The classic crack sits exactly here:

1. The FMEDA lives in a safety PDF updated “whenever there is a relevant change”.
2. The Safety Case lives in another tool (GSN, Word, spreadsheets), with nodes that say “evidence: see annex”.
3. The annex is the per-component evidence chain produced by the MES, the test team and process traceability — each one on its own island.
4. On TÜV day: the safety engineer asks for the dossier of one serial number and a team spends the weekend assembling paperwork.

That happens because the cross-cutting work (joining heterogeneous formats living in different systems) was, until very recently, an impossible cost. Today it no longer is, and that is where iLEAN comes in — not to replace the safety methodology, but to close the chain underneath it.

How it fits the IRIS system

iLEAN does not invent the safety work — it chains the evidence your own line already generates.

The ISO 26262 problem in production is not a lack of evidence: it is evidence scattered across stations, files and systems that were never designed to talk to each other. iLEAN acts as putty between your MES, your test stations, your PLM and the Safety Case, without asking you to change the methodology or the safety engineer.

Tracer marks each component with its ASIL on the line. Writer chains every control to the requirement that covers it. Agent keeps the FMEDA alive with deviations detected on the plant floor. When TÜV asks for the dossier by serial number, it is already done.

The three iLEAN pieces applied to ISO 26262:

• Tracer — reads the unique identifier of every safety-relevant component at the moment the process is already handling it (marking, dimensional check, electrical test). It tags the component with its ASIL and chains it to the batch, the process equipment and the operator. ASIL traceability is not bolted on; it becomes the shape of the chain.
• Writer (Agent) — chains every process control (vision, dimensional, electrical, thermal, BIST) to the component, to the FMEDA safety requirement and to the Safety Case node. When the component goes out the door, it carries its signed dossier behind it, with evidence and argument. It works with no network: Tracer keeps marking and chaining on the panel's own power, because the safety chain cannot depend on WiFi.
• Agent (live FMEDA) — the classic FMEDA is a static document. The agent cross-references the FMEDA with the deviation data the line captures (failure modes appearing more often than predicted, controls detecting more than expected) and raises review proposals with evidence to the safety engineer. The person validates and signs — the FMEDA stays alive without becoming a separate project.

See the full IRIS architecture →

Before and after

ISO 26262 by sprint vs. living ISO 26262 with iLEAN

Aspect	Classic	With iLEAN Tracer + Writer + Agent
FMEDA	Static PDF updated “when there is a change”	Alive, fed by real plant deviations
ASIL traceability	Loose metadata on separate sheets	The shape of the chain: every control tied to its requirement
Safety Case	“Evidence: see annex”, to be rebuilt	Node linked to live evidence by serial number
Dossier request by serial number	Manual sprint by the quality team	Generated on the spot, already assembled
Product or supplier change	Reopen the chain part by part	The new part enters in the same format
TÜV audit	Time spent finding and assembling paperwork	Time spent talking about the content

Impact estimate

Impact estimate for your plant — to be validated with your numbers.

The block below is an estimate to be validated with the specific data of your plant. We put it forward so the committee has an order of magnitude; we refine it during the diagnostic.

• Tier-1 supplier of safety-relevant components (power electronics, sensors, actuators) with a mix of ASIL B and D, recurring TÜV audits and a sprint before each one.
• Pilot: Tracer + Writer on one ASIL D component family, chaining FMEDA + Safety Case + production evidence. First value expected within a few weeks, with the first dossier by serial number generated on the spot instead of in days.
• Reduction of pre-audit sprint time in the order of ≥ 30% by the end of the pilot, depending on the size of the team currently dedicated to rebuilding evidence.
• Indicative payback between 4 and 9 months, depending on the number of audits per year, the cost of the safety/quality team dedicated to evidence and the cost of a TÜV non-conformity.
• The hard lever is the risk of a major non-conformity at TÜV: a single blocking non-conformity in one audit can affect the nomination for the OEM's next platform — it costs far more than any pilot.

And the CIO's reasonable doubt

“Can I trust an agent to cross-reference evidence for a safety standard?” — yes, because the task is anchored: the agent does not generate the evidence, it chains it to the part, to the requirement and to the Safety Case node. Free generation is where AI hallucinates; in anchored tasks (recontextualizing a piece of data from one system to another) the best models are below 1.5% error ^[1]. And iLEAN's three safety rings guarantee that on anything critical only a person decides: the agent proposes, the safety engineer signs.

^[1] OpenAI paper “Why Language Models Hallucinate”, 2025 — on the reliability of AI in anchored tasks.