Industry Voices: Railway Certified Doesn't Mean Safe

There's a document sitting in your project archive. It shows you met every requirement. Every standard was addressed, every checklist ticked. The system went into service. Passengers are on it right now.

And there's a good chance it still has a safety blind spot nobody caught — because everyone involved was too close to the work to see it.

That's not hypothetical. That's what an Independent Safety Assessors (ISA) observes, project after project, across suppliers and countries. The gap between intent and reality in safety-critical railway software is systemic, repeatable, and almost invisible from the inside.

We sat down with Lucas Sanchez, Branch Director of CERTIFER (one of the leading ISA and independent assessment bodies in the railway sector), to understand what that gap actually looks like, why the best-intentioned teams still fall into it, and what the arrival of AI is about to do to a system already under pressure.

Before getting into AI and the future, there's a more immediate problem worth naming. Most suppliers who struggle with certification aren't struggling because of technical weakness. They're struggling because of a mindset that treats safety as something you handle at the end.

Lucas Sanchez: Successful companies embed safety and certification into the design from the very beginning, treating them as part of engineering rather than as a final administrative step. Those who postpone safety considerations often face costly redesigns and delays, similar to trying to get regulatory approval after a product is already finished.

Part of what makes the ISA's position so unusual is the sheer breadth of what it sees. Developers, operators, and regulators each have their own lens and yet, none of them sees all three at once — and that gap is where the real risks live.

CERTIFER sits at a distinctive vantage point: you see the systems that developers build, the expectations of operators, and the requirements of regulators all at once. What does that aggregated view reveal that none of those three groups can see individually?

LS: From our vantage point, one clear observation is the gap between intent and reality across the lifecycle of critical software. Developers often design systems to meet standards and technical specifications; operators focus on availability, punctuality, and day-to-day usability; regulators define rules to ensure safety and public trust. Seen separately, each perspective makes sense. Seen together, however, we observe where assumptions made by one group silently depend on the behavior of another.

This aggregated view also reveals systemic patterns that individuals rarely notice. Recurring safety issues are often not caused by a single software defect, but by misunderstandings at interfaces: between software and operations, between automation and human action, or between national rules and international standards. Developers may not see how their design choices affect maintenance; operators may adapt procedures without realizing the safety assumptions embedded in the code; regulators may update requirements without visibility of practical implementation constraints.

"Safety is as much about consistency and culture as it is about technology. No single group can see how decisions made early in development echo years later in operation."

This is the ISA's fundamental value proposition: it's not just another reviewer. It's the only party in the room whose entire mandate is to connect those dots before something goes wrong in the field.

The organizations that consistently navigate certification efficiently share a common trait: they treat assessors as partners in risk reduction, not as gatekeepers to get past. That shift — from adversarial to collaborative — is what separates projects that hit the market on time from ones that enter expensive, late-stage redesign loops.

A common industry frustration — especially among engineers — is that CENELEC standards like EN 50128 and EN 50716 are slow-moving relics of a different technological era. The argument goes: by the time a standard is finalized, the technology it's meant to govern has moved on.

The reality, according to the ISA's assessment, is more nuanced — and more actionable.

How well do standards like EN 50126, EN 50128, and EN 50716 prepare the industry for the future? Do they enable innovation, or do they risk constraining it?

LS: The challenge for the future is not whether these standards allow innovation, but how they are applied. While they were written in a different technological era, they are largely goal-based rather than technology-prescriptive. When interpreted with flexibility and supported by strong safety arguments, they can accommodate agile development, new architectures and emerging technologies. The real risk lies in overly rigid interpretations that equate compliance with innovation constraints.

"Used wisely, CENELEC standards should act as a safety compass, guiding the industry as it continues to innovate — not a cage that locks it in place."

In other words: the standards are not the ceiling. They're the floor. The teams treating them as a maximum are the ones falling behind.

Ask most engineers what concerns them most about AI in safety-critical systems, and you'll hear about algorithmic explainability, training data integrity, edge-case failure modes. These are real concerns. But the ISA's most pressing worry is something far more human.

If you had to identify the single biggest risk that AI introduces into railway safety — not a theoretical risk, but a risk you expect to materialize in practice — what would it be?

LS: My concern is overconfidence in AI outputs combined with a loss of visibility into how decisions are made. A useful analogy is a GPS navigation system: most of the time it gives excellent directions, but if you stop paying attention and follow it blindly, it may eventually lead you down a closed road. The biggest challenge is not the AI algorithm itself, but how humans and organizations interact with it over time.

"AI must never be something we simply trust because it is clever; it must remain something we understand, supervise, and are always ready to override. In rail, that principle is absolute: a human being is always the ultimate responsible for the safety of a running train."

This matters for suppliers right now. If you are designing a system where AI plays any role in safety-relevant decision-making, the assessment question won't just be "does the AI perform correctly?" It will be "what happens when it doesn't — and will your operators know?"

What advice would you give to a railway supplier looking to integrate AI into a safety-related product — one that wants to approach certification correctly from day one?

LS: Whether AI is used or not, it remains of vital importance to engage with assessment and certification bodies at an early stage to help ensure that potential concerns are identified before they become costly redesigns. As with building a house, solid foundations matter more than decorative features.

The ISA won't design your system. But it will tell you — early, clearly, and at a point when you can still act on it — whether the foundations are sound. That conversation, deferred to the end of the project, is one of the most expensive mistakes in railway software development.

In ten years, do you think the role of the ISA will look fundamentally different?

LS: I am confident the core mission of the ISA will remain the same: to provide an independent, evidence-based judgment that a railway system is safe for its intended use. What will change is how that mission is carried out. In the future, I expect to rely less on static documentation and more on ongoing, data-supported safety arguments.

The implication for suppliers is significant. The era of producing a thick evidence pack at the end of a project and considering the job done is ending. Continuous safety argumentation — living, evolving, data-backed — is where the industry is heading. The organizations building those capabilities now are the ones who will have a structural advantage when that shift arrives.

One final observation worth sitting with: railway's pace of change is often framed as a weakness — a sector stuck in its ways while automotive and aerospace race ahead.

The ISA sees it differently.

"Railway systems are designed to operate safely for 30 to 50 years within complex, highly interconnected networks, where any change must be carefully assessed at system level. I don't see this as a sign of conservatism, but a reflection of the sector's fundamentals."

Deliberate is not the same as slow. And in a sector where the consequences of failure are measured in lives, the discipline to move carefully — while still moving — is arguably the industry's greatest strength. The challenge is not abandoning that discipline in the face of AI, automation, and digital transformation. It's extending it to cover new kinds of risk that the existing frameworks were never designed to see.

That's exactly the kind of blind spot an independent assessor exists to find.

Critical Software develops safety-critical software and systems for the railway sector, working across the full development lifecycle — from architecture through to verification and validation. If you are navigating certification for a complex railway system, get in touch.