The rail industry has identified over 100 AI use cases. About 20 are actively deployed. Most sit in predictive maintenance, disruption management, and traffic optimisation.
That gap between potential and deployment says something about the industry. Rail is not software. It's decades of physical infrastructure, legacy relay interlocking, bespoke SCADA systems, and hard-won knowledge in the heads of engineers who have been doing this for years.
Where AI actually works in rail
The pattern is consistent across operators. AI consumes sensor data, CCTV feeds, and maintenance logs, then proposes insights or actions. The engineer stays in control of what gets done with that information.
The industry treats AI as a tool that supports the work. Not one that does the work.
Where it's proving useful:
- Predictive maintenance for points, track circuits, signals, and rolling stock
- Anomaly detection using sensor streams and CCTV
- Real-time disruption management and traffic optimisation
- Engineering design verification support
None of these replace an engineer. They give an engineer better information, faster.
The legacy problem
Software is a small fraction of rail infrastructure. The bigger part is legacy systems that require deep domain knowledge to understand, maintain, and integrate.
Rail networks run on ageing signalling. Relay interlocking, SSI. Bespoke interfaces, historic constraints, often poorly documented. UIC identifies siloed data infrastructure and lack of standardisation as key barriers to AI deployment at scale.
The integration of legacy and new is where the real engineering work happens. It's where experienced engineers are most irreplaceable. Without deep domain knowledge, AI integration risks misinterpreting data or generating recommendations that don't account for how the system actually works.
This is why AI is unlikely to take over jobs in this industry. The knowledge required to integrate old and new systems can't currently be encoded in a model. It lives in the people who have been doing the work for years.
What AI can do: make projects faster and cheaper
AI is unlikely to replace engineers. It will make projects happen faster and cheaper. And that opens something: budget to build better, more reliable systems.
The UIC-McKinsey report estimates wider AI adoption could unlock $13-22 billion annually across the global rail sector. For a large rail company (€5 billion revenue), they estimate roughly €700 million a year in value. That's not money saved by cutting headcount. It's money freed to build better infrastructure.
The applications that matter to project delivery:
RAG systems and second brains. Project knowledge databases where AI agents can access lessons learned, design decisions, and historical data. The problem with lessons learned is that the job is too busy and nobody goes back to read them. RAG systems make that knowledge searchable and available when you actually need it. Not filed in a report nobody opens.
Live project data dashboards. Real-time reporting from site. Progress, blockers, test status. Without the endless progress meetings that eat half the week. Managers see the data live. Engineers spend their time engineering, not sitting in rooms explaining what they did yesterday.
Automated documentation. Test records, compliance reports, inspection logs generated in real time rather than compiled after the fact from memory and notes. This is close to what we're building with Tracer (our own product). Not AI-assisted. Automating the record so the engineer's time goes to the work, not the paperwork.
This is the next industrial revolution for infrastructure. But it comes with a cost question that nobody is talking about.
The cost test
AI is cheap right now. OpenAI and Anthropic are losing money to grow the market. Their prices don't yet reflect the full cost of building and running these systems. Training costs, free tiers, and flat-rate plans are being subsidised by investor capital.
OpenAI's compute spending reportedly ran into the billions in 2025, sharply up on the previous year. Anthropic is in a similar position. Per-token costs are dropping fast, but usage is growing even faster, so the total bill keeps climbing.
At some point these companies need to make money. Free tiers will shrink. Prices will move closer to what the compute actually costs. Enterprise software is already shifting from "AI included in your subscription" to billing based on how much you use.
When that happens, we'll find out which AI applications are genuinely useful and which only made sense because the compute was cheap. The tool that saves a project team 20 hours a week will survive. The dashboard nobody looks at won't.
Building AI into rail projects now needs to be done with a clear eye on the economics. If a tool only makes sense at today's prices, it doesn't make sense.
The junior engineer problem
Junior engineers will face the hardest transition. The routine work that used to teach the trade is the first to be automated. Calculations, drafting, data analysis, documentation.
Industry bodies and engineering institutions are flagging the risk. If entry-level engineers don't do the groundwork themselves, they may struggle to understand failure modes and limitations of AI tools. They may be less able to challenge algorithmic outputs or know when the tool is wrong.
The solution isn't to ban AI from junior work. It's to be deliberate about what gets automated and what doesn't. Juniors need to do enough of the foundational work to build the judgement that makes them good engineers. Then they use AI to go faster on top of that foundation. Not instead of it.
Engineers who combine traditional rail expertise with data and AI literacy will be in the strongest demand. The domain knowledge has to come first.
The balanced view
Not everyone agrees with this framing. Unions argue that AI leads to deskilling. Engineers repositioned from decision makers to system monitors, eroding professional autonomy and bargaining power. The threat is gradual task erosion, not sudden job elimination.
There's also the question of whether the industry can attract and train enough people with hybrid skills. UIC highlights the shortage of people who understand both rail engineering and data science. The skills gap is a barrier to adoption, not just a consequence of it.
And some in the industry are sceptical that AI will deliver at all in rail environments. The regulatory and standards environment is strict and hard to navigate. As Rail Engineer magazine has argued, don't use AI where conventional technology suffices.
These are fair challenges. The answer is to be honest about where AI helps and where it doesn't.
What happens next
The question is whether the industry builds the skills to manage AI before the cost test arrives.
Companies that figure out how to use AI to make projects faster and cheaper, while keeping engineers in control, will have a competitive advantage. The ones that dismiss AI entirely or adopt it blindly will both lose.
Build the RAG systems. Build the dashboards. Automate the paperwork. But the current economics are temporary. The real value of AI in rail is not in replacing engineers. It's giving them better tools and more time to do the work that matters.
Sources
- UIC-McKinsey report: "The journey toward AI-enabled railway companies" (Feb 2024). UIC PDF | McKinsey article
- Rail Engineer: "Artificial Intelligence in Rail". railengineer.co.uk
- Tracsis: "AI and automation in rail: working smarter, not harder". tracsis-us.com
- Epoch AI: LLM inference price trends. epoch.ai
- Header image: Modern computer-based signalling system, Alstom Derby Litchurch Lane Works. Network Rail, CC BY 4.0, via Wikimedia Commons. Source file
- Rugby ROC: Rugby Rail Operating Centre. CC BY-SA 4.0, via Wikimedia Commons. Source file
- Relay interlocking: Relay based interlocking for railway operation. CC BY-SA 4.0, via Wikimedia Commons. Source file
- Track renewals: 2015 Taunton track renewals. CC BY-SA 4.0, via Wikimedia Commons. Source file
