CENELEC is amending EN 50716 for AI. Here is what the draft says

The railway software standard is gaining guidance on generative AI. It adds no new requirements, but clarifies which rules govern AI tools writing code, data, or documents, and why they are harder to meet.

Generative AI has entered railway software engineering ahead of the standards governing it. Teams already use language models to draft specifications, propose code, generate test cases, and summarize evidence. The practical question is what EN 50716, the CENELEC standard for railway software, says about that work.

Until now, the standard has said very little. CENELEC technical committee TC 9X has now drafted an amendment, EN 50716:2023/prA1:2026, addressing artificial intelligence and machine learning directly, including generative AI. The text completed its CENELEC enquiry in spring 2026, with comments closing on June 26. Because the formal vote and final wording are still pending, clause numbers and details may change. What follows describes the enquiry draft.

No new requirements, but a clear answer

The foreword sets the tone: the amendment “does not introduce new technical requirements.” Its purpose is informative guidance to help users apply AI and ML tools “while upholding the established requirements.”

That sentence carries the core message. AI is treated as a tool, meaning existing rules for tool qualification and organizational independence apply in full. The amendment explains why those rules are harder to satisfy with generative models, without loosening any of them.

Five changes stand out:

1. A note in 6.7.4.1, the tool-qualification clause: AI and ML techniques can appear in any tool class, T1, T2, or T3.
2. New text after 6.7.4.10 on cloud-based and evolving tools: model versions can change outside project control, threatening version control and reproducibility. Projects should record and manage versions of models, data sets, and external services, and keep local copies to guard against discontinuation or interface changes.
3. A clarification in 7.3.4.14: architecture techniques in Table A.3 apply to run-time functions of delivered software. They are “not directly applicable to support tools, production of application data, or production of source code.”
4. A narrower reference in Table A.3, line 13, the row rating “Artificial Intelligence and Machine Learning” as Not Recommended for SIL 1 to 4. It now points only at subclauses governing AI inside the software architecture.
5. A rewritten Annex C.3, now covering AI both inside software architecture and as a support tool, plus a bibliography entry for ISO/IEC TR 5469 on functional safety and AI systems.

Two doors, each with its own rulebook

Changes 3 and 4 resolve a misreading that has troubled many discussions. Previously, Table A.3 line 13 was the only place EN 50716 rated “AI” at all, marking it Not Recommended. Some read that as a verdict across the project: if AI is Not Recommended, using a language model to write code or interlocking data would require a Not Recommended justification in the quality plan.

The draft closes that reading. Table A.3 describes techniques for software architecture running in the delivered product. A language model in the engineering pipeline is not part of that architecture. It is a support tool, and support tools are governed by clause 6.7.

The standard now has two distinct doors:

AI inside the delivered software. A trained model executing as part of a SIL function remains Not Recommended, requiring justification in the Software Quality Assurance Plan. Annex C.3.2 and C.3.3 explain why: EN 50716 builds its integrity argument on traceable hierarchical decomposition with progressive verification, a structure machine-learned functions lack. Requirements cannot be traced to components, coverage cannot be shown, and model code, training algorithms, and platform software must still be developed to the SIL. The annex lists four hard challenges, from training-data completeness to adversarial inputs, concluding that “generally-recognized good practice has yet to emerge.”

AI used to build the software. This path leads to tool-qualification rules in clause 6.7 and new subclauses C.3.4 and C.3.5. The requirements bar is unchanged, as the amendment simply clarifies which bar applies.

What the draft asks for when AI writes code or data

Under clause 6.7, a tool’s class depends on what output can affect. A tool whose output can contribute, directly or indirectly, to executable code or its data is class T3. A code-generating model or a tool generating interlocking application data falls squarely into that class.

For any T3 tool, the project must justify selection, identify potential failure modes, and provide evidence through one of the routes in 6.7.4.4. In practice, the route suited to generative AI is verification of tool output by an independent, diverse tool or process, an approach the standard illustrates with a rule-checking tool confirming balise positioning.

The new subclause C.3.5 adds conditions that make this verification route meaningful for generative models:

• Independence. If designer and verifier use the same or similar AI tools, shared bias undermines independence. The draft also cautions against a subtler shift: when a human reviewer catches AI errors, a single person can end up making the final judgment, bypassing the second independent reviewer expected by clause 5.
• Common cause. Generating requirements and their tests from the same model risks common-cause failures. Extensive automation across lifecycle phases makes the chain untrustworthy “without systematic phase by phase verification.”
• Plausibility. Fluent output easily masks defects. Generative tools may prioritize fluency over semantic precision and can reintroduce ambiguities that requirements engineering had removed. Verification must not depend on how convincing the text appears.
• Reproducibility. Output is non-deterministic, even cosmetically, complicating diffing and impact analysis. Updating a model alters behavior, requiring re-evaluation of tool suitability and previously generated outputs.
• Diversity is not free. Two different AI tools may share biases from overlapping training data, so tool diversity alone is not a defense.

The draft is equally clear on human engineering responsibility. Writing a document is an analytical discipline, and over-reliance on generated text risks hallucinations and the loss of that rigor. Responsibility for output cannot diffuse to a tool, and a tool’s “competence” cannot be equated with the human competence that Annex B describes.

The draft also names the opportunities. Annex C.3.4 lists requirement extraction and ambiguity detection, traceability matrices, large-scale test generation with automatic evaluation, dependency mapping for change-impact analysis, and drafting and harmonizing documentation, all “provided that all requirements of this document are fulfilled.” The message is not to avoid these tools. It is to earn them.

What this means for a signaling project

Read together, the changes give practical shape to AI use under EN 50716.

An AI tool may draft proposals or generate candidate data, but its output must be verified by a process that does not share its failure modes. The more the AI does, the more rigorous the toolset analysis must be. As the draft puts it, “the more extensively these tools are employed, the more rigorous the analysis and justification of the entire toolset needs to be to comply with Clause 6.7.”

This is the pattern Prover has built its tools around, long before generative AI. Prover PSL and Prover Certifier check artifacts against formal specifications by mathematical proof. They evaluate logic rather than fluency, and contain no AI. Placed downstream of a generative tool, they provide the independent, diverse verification that 6.7.4.4 asks for. Prover Certifier is certified by TÜV NORD as a T2 tool against EN 50128:2011 and EN 50716:2023 for SIL 4 applications, meaning the verification step itself rests on qualified ground. The generative tool upstream does not become trustworthy. It becomes checkable.

Three habits follow directly from the draft and cost little to adopt now:

• Verify generated artifacts with a non-AI oracle. A proof engine or deterministic checker restores the independent second party that C.3.5 notes a shared AI tool removes.
• Do not generate a requirement and its test from the same model without an independent check. The common-cause warning is explicit.
• Record model versions, prompts, and data set versions, and keep local copies of generated outputs. The 6.7.4.10 addition asks for exactly this, guarding against silent drift in cloud-hosted models.

A draft, not yet a standard

The amendment is under CENELEC enquiry and may change before adoption. If adopted, CENELEC members would announce it within six months and implement it within twelve. Until then, cite it as a draft. Its direction, however, is clear: AI is welcome in railway software engineering as a support tool, under the same rules as other tools, with independent verification of what it produces.

For anyone who has argued that formal verification becomes more important as AI enters the workflow, the standard now says much the same thing.

Meet us at InnoTrans

Visit our AI Mobility Lab booth to explore how trustworthy engineering assistance can support the next generation of railway signaling. Booth 258 – Hall 7.

Ready to explore what AI can do for your railway software project? Book a meeting with us here!