Can AI provide independent verification evidence under ISO 26262?
AI can generate verification artefacts, execute verification activities and report useful findings. Its output does not establish independence by itself. Independence belongs to the activity, its sources, its oracle, its assigned responsibility and the evidence chain around it. A second model instance, or even a second model provider, is not an independent-verification argument.
This post applies the tool-classification foundation from the first post to the verification controls used by the practical agentic workflow. It is engineering analysis, not an assessor position. Apply the decision templates against the licensed edition and the project's safety plan, and retain the clause mapping in the project record. No model benchmark was run for this post.
Four claims that must not be collapsed
“The AI verified it” can refer to four different claims. They require different evidence.
| Question | What would support it | What does not settle it |
|---|---|---|
| Is the artefact technically valid? | Result against a defined requirement and acceptance oracle | Fluent review prose or a passing self-generated test |
| Was the activity independent? | Separation from the producer in source, responsibility and acceptance authority | A new chat, seed or model name |
| Is the evidence trustworthy? | Retained inputs, configuration, execution environment, raw results and disposition | A summary that cannot be reproduced or audited |
| Can it support TD? | A project argument mapping detected error classes and uncovered gaps | A generic model-accuracy score |
The correlated error
Traditional tool errors announce themselves. A compiler crashes, a static analyser reports a false path. The AI-specific failure mode is quieter: a semantically wrong artefact that looks right, follows the conventions and passes checks designed by the same system.
Take a concrete case. An automotive microcontroller has status registers with write-one-to-clear fields, where writing a 1 to a bit clears that flag. The vendor headers carry the field layout, meaning mask, shift and width, but not its semantics. Whether a field is write-one-to-clear, reserved or ordinary read-write is stated only in the reference manual.
If the agent misreads or never had that semantics, it acknowledges the flag the ordinary way: read the register, set the target bit, write the value back. On write-one-to-clear hardware that write clears the target bit and every other flag pending in the register. The agent then writes a test asserting the target bit is clear after the call. It passes, because the bit genuinely is clear. Nothing asserts what happened to the neighbouring flags, and the interrupt they were about is gone. The tests run on the host against a register model the same agent wrote, so the mock encodes the same misreading and confirms it.
Our analysis: when one system generates both an artefact and its checks, the errors are correlated. Note where the failure sits. The test is not wrong; it is incomplete, and it is incomplete in exactly the direction the agent cannot see. Agent-generated tests still detect one class of error. They show that the code does what the agent meant it to do. That catches transcription slips, mechanical mistakes and regressions against the agent's earlier reading, meaning errors introduced after the reading was formed. They detect nothing already in the reading, however the reading went wrong. For that class, base the TD argument on checks whose source and oracle do not depend on the same reading. Agent-generated tests can contribute as implementation checks. Whether they also support specification checking depends on who owned the specification, oracle and acceptance decision.
Our suggestionAssess independence on at least three axes: prompt and context, skills and scope, and the person answerable for the result. The same model with the same prompt, context and owner is not independent. Record which axis was met and how, because an independence claim with no evidence behind it is the first thing an assessor takes apart.
There is a second-order effect on reviewers. This one is a hypothesis, not a measurement. An AI-produced artefact is clean, well structured and follows the house conventions. It may therefore anchor the reviewer, and it carries none of the smell signals a reviewer normally uses to set the depth of scrutiny. Read the artefact against its source, not against its own prose. Reaching TD1 may require review protocols built to counteract the anchor: specification-first review, where the reviewer writes the expected content before reading what the tool produced, or checklist-driven review against known AI failure modes.
Our suggestionWrite down what you expect before you read what the tool produced, then compare the two. The anchor works on a reader who starts from the text in front of them, so take that starting point away. Record what the review checked rather than that it passed, because a review with no checklist behind it cannot be shown to have covered any AI failure mode. The effect itself is unmeasured and we assume it is real.
A second model is diversity, not proof of independence
Model diversity can reduce one shared dependency and still leave every decisive dependency intact. Two systems may read the same incomplete requirement, retrieve the same stale manual passage, infer the same expected value and be approved by the same person against the same generated summary. Different weights do not repair a shared oracle.
Conversely, AI can perform a useful part of an independent activity when the controlling source and acceptance decision are outside its production path. An agent that implements a human-owned test specification and runs it against target hardware is not equivalent to an agent that invents the requirement, expected value, mock and test. The relevant difference is the evidence chain, not whether one or two model names appear in the log.
Seven verification patterns
| Pattern | What it can show | Independence limitation |
|---|---|---|
| Same agent writes code and tests | Consistency with the agent's implementation intent; regression detection | Shared interpretation, context and oracle |
| Second instance of the same model writes tests | Some prompt-run diversity | Lineage and source remain shared; a new instance is not a new authority |
| Different model writes tests from the same context | Implementation diversity | The same incomplete or stale source can dominate both |
| AI implements a human-authored test specification | Repeatable execution of externally owned cases | The generated harness and translation still need verification |
| AI derives tests from independently authored acceptance criteria | Coverage candidates against a source outside the implementation path | Expected results and completeness require an external oracle |
| AI orchestrates deterministic tests with an external oracle | Retained execution results against fixed acceptance rules | Orchestration errors and environment identity still need control |
| AI review supplements a separately accountable review | Additional findings, checklist coverage and triage | The independent activity must stand without the AI's conclusion |
Can an AI reviewer satisfy the verification activity?
An AI review can produce evidence, but “reviewer” is a role-shaped label, not an assignment of responsibility. The project still has to show who owns the verification objective, where the review criteria came from, what source was checked, which findings were accepted or rejected and who approved the result. Treat the AI reviewer itself as a software-tool use and classify it by reliance: a supplementary pass is not the same intended use as the sole detector of a defect class.
Do not substitute a generic ASIL A/B versus C/D rule for that argument. The applicable verification methods, required independence and confidence argument must come from the project's safety plan and the licensed standard. Model output may carry less or no weight under a conservative project policy. Label that choice as project policy rather than attributing it to a clause that does not state it.
Our suggestionGive the verification activity the source artefacts the producer did not control: the requirement, register semantics, interface constraints, call sites and independently fixed expected results. Keep a project-local list of AI failure modes actually found, and record what the review checked rather than merely that it passed.
What a verification-evidence record must retain
Ten fields make the claim inspectable. Retention of full prompts and outputs is a separate legal and project decision; hashes can establish identity where the content is retained under another controlled mechanism.
What this means for Tool error Detection
TD is not raised by counting AI reviewers. The project has to name the error classes a check detects and the classes that remain correlated with the producing tool. Deterministic execution against an independently fixed oracle is stronger evidence than a generated judgement against generated expected values. A human-owned test specification implemented by AI sits between those cases: the specification can be independent while the translation and harness remain tool outputs that require verification.
The verifier use is classified as a tool use in its own right. If the project relies on it as the sole detector of a safety-related defect, that reliance affects Tool Impact. If it is supplementary and the safety argument does not depend on its result, the classification can differ. Record the intended use; do not infer it from the label “review assistant.”
Do not confuse tool independence with element independence
Our suggestionKeep the two independence questions apart, because they are not the same question. Producing each element under a different prompt and context, different skills and scope, and a different responsible person reduces common-cause error in how the elements were developed. It does nothing on its own to show that the elements fail independently, which is what decomposition rests on. Argue element independence the way you would for human-written elements, name the shared training lineage as a common-cause candidate in the dependent failure analysis, and cover it with verification whose source, oracle and accountable authority do not depend on the same development path.
The experiment needed before a stronger claim
The useful experiment is a fault-seeded corpus with five arms: self-review by the producing agent, a second instance of the same model, a different model, AI implementation of a human-authored verification specification, and a separately accountable review against an independently authored oracle. Pre-register the faults and oracle, retain every miss, and compare correlated miss rate by fault class. Generic pass rate or model accuracy cannot answer the independence question.
We have not run that experiment. Until it exists, the defensible conclusion is narrower: AI may contribute verification artefacts and detection evidence, but no AI-only pattern in the seven-pattern taxonomy establishes independence without an external source of truth, acceptance oracle and accountable authority.
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, software verification
- ISO 26262-2:2018 — management of functional safety, competence and assigned responsibility
- ISO 26262-9:2018 — ASIL-oriented and safety-oriented analyses, decomposition and dependent failure analysis
- ISO/IEC TR 5469:2024 — artificial intelligence, functional safety and AI systems