How should an AI coding/engineering tool be treated under ISO 26262?
Treat an AI coding or engineering system as a software tool under ISO 26262-8 clause 11. Classify its intended use and the complete workflow around it, not the model name. Tool Impact is TI2 whenever its output enters or influences a safety work product and an error can be introduced or missed. Tool error Detection then depends on checks outside the failure path being assessed; the model does not set its own confidence level.
This is the classification foundation for a three-part series. The companion posts turn it into an operating method for an ISO 26262 project and examine whether AI can provide independent verification evidence.
What we reviewed, and on what
This is a desk review of published documents, not a measurement of a system. The document and workstream counts below are checkable against the reference list. The remaining counts are C42 decision templates and gap enumerations, each defined in the corresponding table.
The published set covers the ISO 26262 supporting-process framework and the adjacent AI, governance and autonomous-product sources most directly raised by this question. The workstream set covers four publicly announced revisions or guidance efforts. This is a bounded selection from one review on 2026-08-19, not an exhaustive standards search.
| Population reviewed | Count | Address AI as a development tool |
|---|---|---|
| Published standards and technical reports | 5 | 1 (ISO/IEC TR 5469, non-normative) |
| Standards workstreams in progress | 4 | 1 (ISO/IEC TS 22440, committee draft) |
| AI tool-use modes we classified | 6 | 4 are TI2 in every case |
| Places clause 11 gives no guidance | 12 | grouped into four families |
Laid out in time, the same review makes the gap plainer than the counts do.
Scope: ISO 26262-8:2018 clause 11 for tool classification and qualification, ISO 26262-6:2018 clause 9 for software unit verification, the related process standards, and the regulatory landscape as of August 2026.
Disclaimer. This is engineering analysis, not legal advice. Where it discusses product liability or regulatory frameworks, it reports the content of published directives as we understand them. Consult qualified counsel before relying on any statement here for liability or compliance decisions. Consult us for the engineering half: classifying a tool use, building the verification chain that sets TD, writing the qualification plan. The two companion posts show where that classification becomes project work.
Where this text extends past the standard into interpretation, we label it our analysis. No assessment body has validated any interpretation below, and nothing here measures an AI tool: we ran no model and no benchmark for this post.
Apply the decision templates against the licensed edition adopted by the project. The project record should cite the applicable clauses and tables and document any tailoring; the summaries below do not replace that controlled source.
How clause 11 classifies a tool
Clause 11 exists to answer one question: how much do you trust a software tool that touches your safety work products? It does not care whether the tool is a compiler, a static analyser or a large language model. It cares about what happens if the tool is wrong.
Tool Impact (TI) asks whether the tool can introduce or fail to detect an error in a safety work product. TI1 means no. TI2 means yes.
Tool error Detection (TD) asks how likely you are to catch a wrong output before it matters. TD1 is high confidence, TD2 medium, TD3 low or none.
Tool Confidence Level (TCL) combines the two. TI1 tools are always TCL1 whatever TD says. TI2 tools run from TCL1 with TD1 to TCL3 with TD3. Clause 11 is explicit that classification is per use case, not per tool binary, so the same tool used two ways gets two classifications.
One mechanism matters more than any other here, and it is the output verification route. It is not a separate provision. It is what TD means: where activities outside the tool independently verify a TI2 tool's outputs, detection confidence rises toward TD1 and the confidence level falls toward TCL1. Model-based toolchains have run this way for years, which is worth saying before anyone treats this as a special accommodation for AI. The generator is plainly TI2, and the confidence comes from what the project does to the generated code afterwards. The same route is open to an AI tool, on the same condition. The verification has to be genuinely independent and genuinely systematic.
Four qualification methods exist in clause 11: 1a increased confidence from use, 1b evaluation of the tool development process, 1c validation of the software tool, and 1d development in accordance with a safety standard.
AI does not stop at code
A model can draft requirements, architecture, detailed design, source code, tests, qualification cases and supporting documents. Clause 11 follows the intended use across all of them: a requirements assistant and a code generator are not different regimes merely because one emits prose.
Interpretation can carry the same impact without producing a file. When a model explains a manual, standard or existing specification and that reading influences a safety decision, the knowledge path reaches the work product. The use is therefore TI2 even if the controlled source is also available; the independent source check contributes to TD instead of changing TI.
The lifecycle map, artefact-specific failures and operational controls move to the practical workflow companion.
Six tool-use decision templates
Artefact type is one axis. Autonomy is the other, and it is the one that moves the detection rating. Table 2 sets out the six modes we see in practice, ordered from the mode where a human checks every output to the mode where automation is the only gate. Read the rows as templates rather than as verdicts: five of the six carry conditional values, because the answer depends on a chain only the project can describe. An LLM used as a suggestion engine and an LLM used as an autonomous agent present different profiles even when they produce the same work product.
| Mode | Description | TI | TD | TCL | Rationale |
|---|---|---|---|---|---|
| a Copilot | Human reviews every suggestion; full verification downstream | TI2 | From the named external chain | Project-specific | The tool can produce a wrong artefact. Systematic review and independently owned verification can support high detection confidence; their presence does not assign it automatically. |
| d AI reviewer | Marks findings on an artefact that a human also reviews | TI1 if not relied upon, TI2 once influential | From the separately accountable verification activity | Project-specific | An optional pass can remain TI1 only when neither its findings nor its misses carry the safety argument. Once a decision relies on it, classify that intended use as TI2. |
| f Retrieval and interpretation | Reads a manual, standard or specification and reports what it means | TI1 if not relied upon, TI2 once influential | From independent source checking | Project-specific | The manual remaining available does not make the AI use TI1. If the reported interpretation influences a safety decision, the tool is TI2; an independent reading of the controlled source contributes to TD. |
| e AI test generator | Produces test vectors, test code or qualification test cases | TI2 | From independently owned test objectives and oracle | Project-specific | Wrong tests can fail to detect errors. A systematic review against independently owned objectives and expected results can contribute detection evidence; the project still has to justify the rating. |
| b Agent produces a work product | AI drafts requirements, a design or a driver; engineer reviews; the full downstream chain runs | TI2 | From the named downstream chain | Project-specific | TD follows the systematic checks and the error classes they cover. A written artefact style, source-first review and independently owned verification are evidence inputs, not an automatic rating. |
| c Autonomous agent | Produces, tests, reviews and commits; continuous integration is the only gate | TI2 | TD2 or TD3 | TCL2 or TCL3 | If the AI wrote the checks, they are not independent. That correlated failure mode pushes toward TD3. |
Two things fall out of that table, and one caveat comes with it. TI is TI2 whenever the output enters or influences a safety work product, and the two TI1 rows hold only while the result is genuinely supplementary and not relied upon: once it influences a safety work product or safety decision, it is TI2. And TD is where the project has agency, because the difference between TCL1 and TCL3 is the chain, not the model. The caveat is that five of the six rows carry conditional values or ranges. They are decision templates for a project to complete against its own chain, not six finished classifications.
Tool output or work product
Clause 11 qualifies tools, not outputs. A compiler is qualified and its object code is verified by testing. An AI generator sits on that boundary, because its output is the same artefact a person would have written, whether that is source code or a requirements specification.
The answer is both. The output is the product of a tool and at the same time a work product entering the project's verification chain. Clause 11 governs the tool. Automotive SPICE governs the work product's lifecycle, and it does not depend on the work product's origin: its process areas specify what must be done to a work product, not who or what produced it. If the process is followed and the evidence trail is complete, an assessment does not fail because a model wrote the first draft.
When an agent chains tools, clause 11's single-tool framing strains. Our analysis: the most defensible approach today classifies the pipeline as a composite tool, with TI and TD assessed at pipeline level. The current text neither requires nor forecloses that treatment. It is an engineering choice a project makes and records.
Reproducibility, and which kind actually matters
Three kinds of reproducibility get discussed together and they are not equally difficult.
Generation-step reproducibility is not required. If the model writes a different draft each time, but the artefact that ships passes every verification activity the standard mandates, the variation is no different from human engineering. Ask two engineers to implement one specification and you get two implementations. Part 6 verification looks at the output.
Tool qualification reproducibility is the gap. Clause 11 expects tool validation to show that defined inputs produce defined outputs. Method 1a needs evidence of successful use with version continuity, and every model update breaks that continuity. Method 1c needs a suite with defined inputs and expected outputs, and temperature 0 does not guarantee determinism across API versions, quantisation or batching.
The human-engineer analogy has limits. Three asymmetries weaken the argument that a model is just another non-reproducible engineer. A human's competence is assessed under Part 2 and can be audited, while a model's is opaque. Model errors may be correlated across invocations, which undermines the independence assumption. And no validated statistical basis exists for confidence-from-use with a stochastic tool.
Our suggestionDo not rest a qualification argument on method 1a for a tool that changes silently. Run a fixed suite on a schedule instead, built from cases whose expected output a machine can check, and decide in advance what a failure buys you: pin the previous version, or stop using the tool for that use case until it validates again. A suite with no consequence attached is monitoring, not mitigation.
The agentic loop, and where the boundary goes
Put the two halves together and one agent runs the whole thing. It spikes on the target until the device behaves, then drafts requirements from what it learned. From there it proposes an architecture, writes the detailed design, writes the code and writes the tests. It runs them, reads the failures, revises whatever it decides was wrong, drafts the documentation, and hands you the set. Every step is a model making decisions. Where does clause 11 apply? Nothing in the population we reviewed addresses the question, checked 2026-08-19. What follows is our analysis.
Per step is the most faithful to the clause's text, and it fails on the part that matters. Each box is a separate tool use, but the decision to loop is none of them, and neither is the choice of which artefact to revise. You end up qualifying every blade in the blender and not the blender.
Per loop iteration hides the correlated-error problem. Each iteration looks independent and the errors are not. Honest detection rating is TD3, because the detection mechanism inherits the reading that produced the artefact. Across a full-lifecycle workflow it hides something worse: an iteration that resolves a failing test by editing the requirement leaves every artefact consistent and the product wrong.
Per agent as a whole treats the entire agent as one tool: input in, reviewed set out, spike included. Our analysis: this is the only practical framing, because it forces the right questions. TI2, and TD from what happens after the agent finishes. Drawing the boundary here also keeps the spike honest: a spike that stays inside the agent's own loop is not the independent check of the earlier chapter.
Our suggestionClassify the company-standard workflow, not one developer's setup. That means writing the workflow down and putting it in version control first, because a habit cannot be classified and cannot be shown to anyone. Developers will configure agents in their own style whatever you do; the classified unit is the workflow the company defines and imposes.
Agent as tool, not agent as engineer
Agent as tool maps onto clause 11. The agent takes inputs, produces outputs, and a human evaluates them and takes responsibility. This works inside the current standard.
Agent as engineer requires the competence-of-persons requirements in Part 2. The standard speaks of persons with demonstrated competence, training and safety culture. An AI cannot hold competence in that sense, and nothing in the population reviewed supports the framing. Until the standard defines non-human development participants, agent as tool is the only viable reading.
A project can classify an agentic system under the current standard with the five steps that follow. Each one leaves a record, and the record is the point: a classification nobody can show is a classification nobody can audit. No assessment body has validated them.
- Draw the boundary. Per agent as a whole, input in and reviewed artefact out. Record the boundary definition in version control.
- Set TI. TI2 from the harvest line down. Record the rationale against the clause.
- Rate TD. From independent checks only, because agent checks are implementation checks. Record the inventory of independent checks, and what each one covers. This step is where the work is.
- Read TCL. From the clause 11 matrix. Record the cell you landed in.
- Add measures. Approval gate, traceability, drift monitoring. Record which measure answers which residual risk.
Walking the decision tree
The framework collapses into three layers. An engineer gets through them in a single sitting, once per use case, which for one tool on one project usually means more than once.
C42 policyScale the rigour of the method 1c suite by ASIL: at A and B a representative sample of the project's actual use, at C boundary cases and error injection on top, at D a case in the suite for every AI error mode the project has recorded. This is our own conservative practice, not a reading of the clause, and we state no normative basis for the split. The clause weights its qualification methods by ASIL; these sampling rules are ours.
Layer 3 is the clause 11 matrix, reproduced here in the shape the clause defines rather than as a quotation of it.
| TD1 | TD2 | TD3 | |
|---|---|---|---|
| TI1 | TCL1 | TCL1 | TCL1 |
| TI2 | TCL1 | TCL2 | TCL3 |
Our working reading of the minimum action per level is that TCL1 requires the tool identity, version, configuration, use scope and TI/TD rationale, while TCL2 and TCL3 add one or more qualification methods under the clause's per-ASIL weighting. For a commercial LLM, use-case-specific validation under method 1c is usually the practical route; Figure 3 explains why the other routes are difficult. Verify the final method selection and weighting against the project's licensed copy of the standard.
The standards landscape, compactly
The classification cannot wait for an AI-specific edition of ISO 26262. The published and in-progress documents reviewed on 2026-08-19 divide as follows. Scope statements and previews are not substitutes for unpublished draft text.
| Source | Status in this argument |
|---|---|
| ISO 26262-8:2018 clause 11 | The governing software-tool framework used here; it does not name AI, machine learning or non-deterministic tools. |
| ISO/PAS 8800:2024 | Addresses AI as a vehicle component and excludes AI software development tools by scope. |
| ISO/IEC TR 5469:2024 | The only published source in the review that classifies AI used during development, through its non-normative B1/B2 usage levels and technology classes. |
| ISO/IEC 42001:2023 and UL 4600 | Address AI governance or autonomous-product safety cases, not qualification of an AI development tool under clause 11. |
| ISO 26262 Edition 3 and IEC 61508 Edition 3 | In progress. Public previews do not establish an answer for Part 8 tool qualification. |
| ISO/IEC TS 22440 parts 1 to 3 | The in-progress workstream whose public scope retains AI used to develop safety-related functions; committee draft as of April 2026. |
Regulatory classification of an internal AI development tool is outside this engineering analysis. Obtain that position from counsel and keep it separate from the clause 11 tool-classification argument.
The twelve gaps
Twelve places where ISO 26262-8:2018 clause 11 gives no guidance. Twelve is our enumeration, not a closed set. Numbered for reference, sorted into four families, and not ranked. Table 5 gives, for each one, the working assumption exposed by applying clause 11 and what a large language model does instead.
| Family | Gap | What clause 11 assumes | What an LLM does instead |
|---|---|---|---|
| Version identity | G1 Non-deterministic output | Defined inputs produce defined outputs | Stochastic generation |
| Version identity | G6 Model updates | A tool version can be pinned | Cloud-hosted models may change without notice |
| Version identity | G7 Prompt as configuration | Configuration changes are identifiable | Clause 11 names no prompt change as a re-qualification trigger |
| Classification inputs | G2 Tool chains | A single tool is classified | An agentic workflow chains drafting, review, testing and automation |
| Classification inputs | G3 Output or work product | The two regimes are distinct | An AI-produced artefact is both at once |
| Classification inputs | G10 Detection for novel error modes | Checks were designed for the error classes present | Plausible-but-wrong output was not in the design basis of those checks |
| Independence | G5 Competence | Competent persons perform activities | Part 2 defines no competence equivalent for a model |
| Independence | G8 Multi-model pipelines | Distinct tools fail independently | Models from one lineage share failure modes |
| Independence | G9 Independence of AI activities | Verification is independent of production | One model produces the artefact and the check on it |
| Independence | G11 ASIL decomposition | Decomposed elements fail independently | One model can put one error pattern into both elements |
| Outside clause 11 | G4 Training data and IP | Tool behaviour has a traceable origin | Training data is opaque and may carry licence obligations |
| Outside clause 11 | G12 Regulatory scope | Not addressed | A counsel-owned question, deliberately outside this engineering classification |
G8, G9 and G11 are developed in Can AI provide independent verification evidence under ISO 26262?, which keeps tool independence separate from element independence under decomposition.
Together, these findings establish a narrower conclusion: an AI engineering tool needs no special category under ISO 26262. Classify its intended use and complete workflow. Once its output influences a safety work product, treat the use as TI2 and derive TD from the external verification chain. The second post turns that classification into an operating model; the third examines what can count as independent verification evidence.
References
Clause and part numbers are cited without reproducing the standards' copyrighted text.
- ISO 26262-8:2018 — Road vehicles, functional safety, part 8: supporting processes, clause 11 on qualification of software tools
- ISO 26262-6:2018 — part 6: product development at the software level, clause 9 on software unit verification
- ISO 26262-2:2018 — part 2: management of functional safety, competence management
- ISO 26262-9:2018 — part 9: ASIL-oriented and safety-oriented analyses, requirements decomposition and dependent failure analysis
- ISO/PAS 8800:2024 — Road vehicles, safety and artificial intelligence
- ISO/IEC TR 5469:2024 — Artificial intelligence, functional safety and AI systems, usage levels and technology classes
- ISO/IEC CD TS 22440-1, -2 and -3 — functional safety and AI systems: requirements, guidance, examples, committee draft as of 2026-04
- ISO/IEC 42001:2023 — AI management system
- Automotive SPICE process assessment model 4.0 — SWE.1 to SWE.6 base practices
- UL 4600 — Standard for safety for the evaluation of autonomous products
- ARP6983, published jointly as ED-324 — aviation guidance for machine learning in airborne systems, in development, target late 2026
- IEC 61508 — functional safety of electrical, electronic and programmable electronic safety-related systems