How can I actually use agentic AI during an ISO 26262 development project?
Use the agent inside the project's existing authority structure. Give it a bounded task, named inputs, written artefact rules and a defined verification route; retain the configuration and provenance of every output that reaches a safety work product. The agent may draft, implement, analyse and execute. It does not own requirements, acceptance criteria, safety decisions or release approval.
This post assumes the classification method developed in How should an AI coding/engineering tool be treated under ISO 26262?. The separate question of whether an AI-generated review or test can carry an independence argument is handled in Can AI provide independent verification evidence under ISO 26262?.
The operating contract
Before an agent starts, the project records seven decisions. They are the minimum interface between an agentic workflow and the safety lifecycle.
Those decisions apply per intended use. A chat used to brainstorm disposable code and the same service connected to a repository are not one use merely because the model endpoint is the same.
AI does not stop at code
AI can influence more than source code. A model can draft requirements, propose an architectural decomposition, write the detailed design, generate unit, integration or qualification test cases and explain what a controlled document means. Any of those outputs can become or influence a safety work product when the project relies on it. Classify each intended use and its workflow; do not limit the clause 11 assessment to code generation.
Requirements are where this bites first. A model is fluent, and fluency is precisely the wrong failure mode at the top of the V. Ask for requirements without giving the model the rules and you get statements that read like requirements and cannot be verified: two obligations in one sentence, the system missing as the subject, "fast", "robust" and "as appropriate" standing where a value with a tolerance belongs, and no verification method named anywhere. That output passes a casual review because it has the shape of the real thing. Everything below it inherits the defect, and the defect surfaces at integration, after every artefact below it was written against it.
The fix is not more review. It is giving the tool the same written rules you would give a new engineer: one obligation per statement, active voice with the system as the subject, a measurable value with its unit and tolerance, a verification method attached to each statement, and an identifier for traceability to reference. Our judgement from practice, not a measurement: a model held to a written requirements style produces reviewable requirements, and the same model given a blank prompt produces prose. We ran no controlled pair.
There is a second class the work-product lifecycle does not catch, because it never becomes a document. When a model reads a reference manual, a standard or an existing specification and tells the engineer what it means, that interpretation is an input to a safety decision and leaves no work product behind. Nothing in configuration management holds it, no review is scheduled against it, and no traceability link points at it. It is still TI2 whenever its interpretation influences the engineer's decision, and it is the AI use least likely to appear in a review plan, because there is no artefact to schedule a review against.
| Work product | What a model gets wrong | What catches it |
|---|---|---|
| Requirements | Unverifiable statements in requirement clothing: compound obligations, vague values, no verification method | A written requirements style, review against that style, and a verification method named per statement |
| Architecture | A decomposition that looks conventional and does not carry the safety argument, especially freedom from interference | Review as outsourced design; check the argument, not the diagram |
| Detailed design and code | Semantically wrong code that compiles, follows the conventions and reads correctly | Specification-first review, independently authored tests, qualified static analysis |
| Unit tests | Tests that encode the model's own reading of the specification rather than the specification | Test specification from a source independent of whatever produced the code |
| Integration tests | Interface behaviour taken from the code rather than from the interface control document | Test design driven from the interface document, reviewed independently |
| Qualification tests | Test cases that mirror the requirements the same model wrote, confirming the wrong requirement | Requirements and their verification produced under separate ownership |
| Interpretation of an artefact | A confident reading of a manual or standard that is wrong, with no document produced | Recording the interpretation, and an independent reading of the source |
Our analysis: the correlated-error problem is usually discussed at unit level, where one model writes the code and its tests. Extend AI across the lifecycle and the same problem stretches the full height of the V. If one model drafts the requirements and another instance of the same model derives the qualification tests from them, the qualification campaign confirms that the product matches a requirement nobody independently checked. Every verification activity in between passes, because each one is measuring against the same original misunderstanding. That version spans the whole V, and the project cannot see it from inside, because every check inside agrees.
Our suggestionGive requirements and their verification separately accountable owners. Record the sources, oracle and shared tool dependencies as well as the two owners. Organisational separation alone does not prove independent evidence; the verification companion develops that argument.
AI-driven development: the enabler before the V
The V-model is drawn on an assumption that quietly fails on unfamiliar silicon: that the specification is knowable before anything is built. For a peripheral driver it often is not. A clock has to be ungated in an order the manual states elsewhere, a bit that reads as reserved has to be written anyway, an erratum contradicts the register description. A model will produce a complete and confident analysis of a device it has never made work, and if the result does not run on the target, every hour in that analysis is spent for nothing.
So we invert the order, once, and only where the hardware is the only authority. Write the check, write the smallest code that satisfies it, run it on the target, read what actually happened, and iterate until the device behaves. The target's behaviour is a source outside the model. It becomes useful independent evidence only if a separately accountable person fixes what counts as passing and reviews the raw capture. The loop comes from test-driven development, the verification structure that follows comes from the V, and the discipline of specifying before building comes from the sequential model. AI-driven development suspends that last discipline for the uncertain part and restores it for everything else.
This is an enabler in the sense that scaled agile frameworks use the word: work that buys knowledge rather than features, done ahead of the implementation it de-risks. The deliverable is not the demonstration code. The deliverable is the device behaviour the reference manual did not state plainly, now known rather than assumed, and available to the requirements that follow it.
Our analysis: this creates two intended uses, not one tool use split by file type. The first is disposable implementation exploration. It can remain TI1 only when the project relies on neither the generated code nor conclusions derived through the agent. The second is the retained-evidence and harvest path. It is TI2 once a measurement or interpretation influences a requirement or another safety work product. Classify that complete workflow, including the AI orchestration, and derive TD from the independent output-verification route. Destroying the code alone does not make the workflow TI1.
There is a sharper reason to put hardware first when AI is involved. The correlated error survives because the model's checks encode the model's reading, and no generated test escapes that circle while its expected result comes from the same reading. Silicon does not share the model's training data and holds no opinion about what the manual seemed to say. A spike on the real target therefore adds a source of evidence outside the model's semantics. Its acceptance oracle, instrumentation and measurement chain still require independent ownership. We expect that to be a cheap way to reduce correlated error, but it remains a hypothesis: we have not compared it against a specification-first order under controlled conditions.
| Phase | What the tool does | What comes out | Clause 11 status |
|---|---|---|---|
| Enabler spike, timeboxed | Writes a check and the smallest code that satisfies it, runs it on the target, reads the failure, iterates | Disposable demonstration code plus raw device observations | The exploration use can remain TI1 only when neither its code nor its conclusions are relied upon; retained evidence belongs to the TI2 harvest workflow |
| Harvest | Turns what the hardware proved into requirement statements and interface facts, written from the manual and the measurements | Requirements, interface entries, register semantics with the evidence behind them | TI2: retained evidence and the first controlled work products |
| Architecture and design | Proposes the decomposition with the unknowns already removed | Architecture and detailed design | TI2, reviewed as outsourced design |
| Implementation | Writes product code against the requirements, not against the spike | Source code | TI2, provenance recorded per unit |
| Verification and qualification | Generates or executes checks under the project's independence rules | Unit, integration and qualification evidence | TI2; contribution to independence is argued from source, oracle and responsibility |
Two things break this, and both are easy to do by accident. The first is promoting the spike code into the product because it works and the deadline is close. That turns an unqualified experiment into a work product with no requirements above it and no provenance behind it, which is the situation the whole framework exists to prevent. Mark spike code as non-product at creation, keep it as evidence of what was learned, and write the product implementation again.
The second is writing the requirements from the spike code rather than from the manual and the measurement record. That is documentation reverse-engineered from an implementation, an assessor recognises it on sight, and it reproduces the original misunderstanding one level higher, where it costs more to find. The spike tells you which questions the manual failed to answer. The answers still come from the manual and from what the target actually did.
Our suggestionTimebox the spike before it starts, and keep its output somewhere the product build cannot reach it. A convention that spike code is not product lasts until the first deadline; a separate repository lasts longer. Give the harvest to someone who did not run the spike, so the person writing the requirement is not the person who already believes the spike's answer.
The validation delta: what changes in your verification plan
If you adopt an AI tool tomorrow, the project's applicable Part 6 baseline remains in force. The ASIL, safety plan and intended use still determine the required verification activities. Our proposed delta adds six controls for AI-produced or AI-influenced work products; it does not replace or relax that baseline.
| Addition | What it means in practice | Applies to |
|---|---|---|
| Provenance recording | Model name and version, the input, the timestamp and the configuration, recorded per artefact and carried into configuration management | every AI-produced work product |
| A written style per artefact type | The rules the tool is held to, and the rules the review checks against: statement form, mandatory fields, measurable values, verification method | requirements first, then design, interface and test artefacts |
| Systematic-bias review | Checklist items for the failure modes of that artefact type, not a generic review checklist | every AI-produced work product |
| Independence, per artefact and along the V | The check uses an independently owned source and oracle; shared producer/verifier dependencies are recorded and assessed | tests against code, qualification tests against requirements |
| Recorded interpretations | When a tool explains a manual or a standard, the answer and its source are recorded, because otherwise nothing in the lifecycle holds it | retrieval and interpretation use |
| Model-version tracking | Which artefacts came from which model version, and what triggers re-verification when the provider updates it | every AI-produced work product |
Set retention with counsel and the project's information-handling owners before fixing the schema. Hashes can establish the identity of content kept under another controlled mechanism. They do not preserve the evidence or replace source material needed to audit the activity.
Our suggestionRun licence-detection software on every delivery and treat the result as one release input. A scan can report that it found no match in its configured databases; it cannot prove absence of a match or establish provenance. File its configuration and results with the provider's copyright policy and training-content summary, and label the remaining provenance gap explicitly.
What the failure would look like
A constructed scenario, from a failure mode we have seen the ingredients of, not an incident we observed. A retrieval pipeline pulls register semantics out of a reference manual so a firmware engineer can review a driver. The chunk it returns comes from a superseded revision, where the standby-enable field sat one bit lower. In the current silicon that position is reserved, and the chunk returns it as writable. The engineer trusts the retrieved context and approves the driver. The write is benign on the bench silicon and gates a clock domain on the production stepping, so nothing before the field sees it. A field failure follows.
Under clause 11 this scenario puts the retrieval tool at TI2 in both branches: the retrieved semantics influence a safety decision and can introduce an error into the safety work product. Reading the controlled manual as an independent input does not change Tool Impact; it supplies detection evidence and can improve TD. Note also what is absent from the whole chain. No interpretation record was produced, so no review was scheduled and no traceability link exists. This is the retrieval-and-interpretation template from the classification companion, and it is why the practical workflow records interpretations.
Retrieval missing the passage is the normal case, not the exotic one. Our own factorial bench on a 4,837-page reference manual put the best of 24 configurations at 0.283 recall at a 1024-token budget over 30 questions, measured 2026-08-18.
The defence can be made measurable, and that is the useful part. Require the configuration to return the driver code, the vendor header and the manual passage inside the deployment's context budget. Then score the retrieved passage against a hand-labelled register table, field by field: name, offset, width, access type and reset value. Set the gate at no access-type error on the sample, because access type is the field that produced this failure. A configuration below the gate does not enter the candidate set, and the gate re-runs on every model version change and every release cycle. We have not run this gate, and no threshold here is a measured result.
What a prudent project does today
Seven actions, ordered by our judgement of risk reduction against implementation cost. We measured neither quantity. Between them they address 10 of the 12 indexed gaps inside one project; “address” does not mean close. G11 is developed in the verification companion, while G12 remains a counsel-owned regulatory question.
| Action | What it means in practice | Gaps |
|---|---|---|
| Pin model versions and re-qualify on change | Treat every model update as a new tool version, and define the re-qualification triggers before you need them | G6, G7 |
| Do not rely on AI as the sole verifier | Use a separately accountable activity with an independently owned source and oracle; document its actual contribution to TD rather than assigning a generic rating | G5, G9 |
| Maintain provenance | Tag every AI-produced artefact at creation and make the tag survive into configuration management. Without it no clause 11 argument can be made | G3 |
| Run licence detection as a release input | Scan every delivery and retain the configured databases and result. A clean scan neither proves absence nor establishes provenance | G4 |
| Build the validation delta | The six additions of Table 3, written into the software development plan rather than a side note | G10 |
| Run periodic fidelity audits | Check the tool's output against ground truth on a fixed sample, at a frequency matched to how often the model changes | G1, G6 |
| Keep AI conclusions off the direct acceptance path | Use the tool for drafting and acceleration, and route every influential output through named, separately accountable verification | G2, G8 |
Where this becomes work
We classify the tool use, build the verification chain the classification rests on, then write the evidence an assessment would examine. That is engineering work on your project. It is not an opinion on your compliance position, and it does not replace your assessor or your counsel.
Classify the tool use. We walk the decision tree once per tool and once per project. We record TI, TD and TCL with the rationale against the clause, and name the downstream activities the TD rating rests on.
Write the artefact rules. The style and structure a tool is held to, per artefact type, starting with requirements, so that review has something to check against rather than an impression to form.
Build the verification chain. TD is where your project has agency. We design the independent review protocol, the independently authored test specification, the analysis configuration and the coverage measurement. For each one we state which AI-specific error modes it covers and which it leaves open.
Write the validation delta into the development plan. The six additions of Table 3, in the software development plan itself.
Write the qualification plan, and run the fidelity audit. One plan per tool per project, and a fixed sample checked against ground truth on a schedule set by how often the model changes.
What to put in the qualification plan
One instance per tool per project, updated on any re-qualification trigger. Nine sections, and this is the skeleton we fill. It states no sample sizes and no pass thresholds, because those are project decisions.
What this work is not: we do not certify anything, we do not state your compliance position, and we do not stand in for your assessor or your counsel. No assessment body has validated the framework in this post, we have not run it end to end on a production ISO 26262 project, and the classification companion names twelve places where the standard gives no AI-specific guidance. A project that adopts this framework adopts a documented position, not an approved one.
Tell us what has to work—and where it has to survive. Send the environment, constraints and project stage. A useful first message can be short; the engineering questions come next. Write to office@c42.ro.
References
Clause and part numbers are cited without reproducing the standards' copyrighted text.
- ISO 26262-8:2018 — supporting processes, clause 11 on qualification of software tools
- ISO 26262-6:2018 — product development at the software level
- ISO 26262-2:2018 — management of functional safety and assigned responsibilities
- Automotive SPICE process assessment model 4.0 — SWE.1 to SWE.6 base practices