If AI is everywhere, how can one train still crash into the back of another?

What do we know about the incident in Spain?

On 28 October 2026, a collision involving Renfe and Iryo trains was reported near Urda on Spain's Madrid–Seville high-speed railway line. In its initial update, infrastructure manager Adif described the incident between Mora y Orgaz and Urda using the word “alcance”, meaning a rear-end collision. Renfe also published an official statement about the incident. Initial operational notices appeared on Adif's network status page.

This information does not explain the technical cause of the collision. Which protection system was operating in which mode, the sequence of train movements, the authorities issued and the braking process all require separate examination. These statements are not sufficient to attribute the incident to a “lack of AI”, an “ETCS failure” or an error by a particular person.

The priority is the passengers and staff affected by the incident. This article is not an accident investigation; it is a general analysis intended to explore the technology question the incident raises. Rather than injury figures that can change rapidly, we focus on the verifiable context and more enduring technical questions.

Which systems work to prevent train collisions?

Thinking of rail safety solely in terms of the signal in front of the driver or a single computer gives an incomplete picture. For a train to move, different systems need to produce information that is consistent with one another. Although implementation varies with the equipment on the line and on the trains, the main tasks can be summarised as follows:

• Detecting a train's presence and position: Knowing whether a section of track is occupied is the starting point for safe movement.
• Setting a suitable route: The position of points and the movements authorised must not conflict. This is why the safety interlocking between signals and points matters.
• Communicating movement authority: How far a train may proceed, and under what conditions, is determined through the relevant system and operating rules.
• Supervising speed limits: Depending on the equipment, the train protection system can provide a warning or intervene with braking before permitted limits are exceeded.
• Being physically able to stop: The condition of the braking system, speed, train characteristics and track conditions affect stopping behaviour.

Network Rail's explanation of signalling describes how this arrangement consists of many components, and how reaching a safe state in the event of a fault is one of its fundamental design objectives. This is why a signalling fault sometimes results in services stopping or being delayed. In some cases, the delay a passenger experiences is a safety mechanism taking effect.

None of this establishes the cause of any particular accident. Alongside system design, investigations also examine maintenance, configuration, change management and operation under abnormal conditions. The question “There was a computer, so why didn't it prevent this?” can only be answered through the incident records.

Are automatic train protection and artificial intelligence the same thing?

Not every system that works automatically is artificial intelligence. In particular, we need to distinguish generative AI from safety-related control functions. A language model can write explanations, search documents and summarise incident records. A train protection system is designed to operate within defined operational and safety conditions.

As a general example, the European Train Control System, or ETCS, supervises a train's speed and position against permitted limits. According to the European Union Agency for Railways' explanation of braking curves, the on-board computer calculates braking distances using the train's braking characteristics and data about the track ahead. When necessary, it issues an intervention command to the train's brakes, which are a separate system.

The existence of this calculation does not mean that a conversational model is being used. We are also using ETCS here as an example to explain how such systems work; this is not a claim that ETCS was active or failed at the time of the incident in Spain.

Preventing rear-end collisions therefore does not have to wait for generative AI. Existing safety functions must work correctly in their own right. Rather than obscure that responsibility, artificial intelligence projects should state clearly what additional benefit they will provide.

Where can artificial intelligence help on the railway?

The most tangible opportunities arise in work that requires large amounts of data to be reviewed regularly. The following examples are potential applications; they should not be read as descriptions of a particular line's existing capabilities or as a definitive solution to any accident.

Spotting unusual changes in sensor data

Considering temperature, vibration, electrical measurements and maintenance records together makes it possible to investigate changes that may not be visible in a single measurement. For example, equipment behaving differently from its own past performance under similar operating conditions can be flagged for inspection.

Anomaly detection is not, by itself, a fault diagnosis. A sensor may have failed, operating conditions may have changed or records may have been matched incorrectly. An alert should therefore include the data used, timing information and the reason for checking, and the result should be passed to the relevant specialist for review.

Setting priorities for predictive maintenance

Predictive maintenance aims to assess maintenance needs earlier by monitoring the condition of equipment. AI can explore patterns linking past faults and measurements, and suggest priorities to maintenance teams. Its value lies not only in the model's prediction, but in that recommendation becoming a work order, an inspection and a recorded outcome.

It is also important to distinguish the maturity of work in this area. Europe's Rail's dynamic maintenance solution describes decision support that combines condition and maintenance data from different sources. The page describes the solution as a TRL 6 prototype demonstrated in a relevant environment, and notes the need for pilot implementation and further validation. Research results should not be presented as a ready-to-use safety guarantee for every setting.

Supporting image-based inspections

Computer vision models can highlight areas in inspection images that need a specialist's attention. The aim is to make it easier to select examples that warrant attention from large numbers of images. Performance needs to be reassessed when lighting, weather, camera angles or image quality change.

The European Commission's RAILS project results include research directions such as camera-based obstacle detection, infrastructure inspection and digital twins for predictive maintenance. These are promising areas of work; they should not be treated as finished solutions that perform equally well in every scenario.

Getting scattered information to the team making the decision

When an alert sits on one screen, the maintenance history in another application and a field note in a message thread, it becomes harder for teams to understand the situation. An integration layer can bring together records relating to the same asset. AI can then help classify or summarise those records.

Matching the data is the crucial detail here. If equipment identifiers, timestamps and record versions do not align across systems, a well-written summary can present a misleading picture. Source links and flags for missing data may be more valuable than a fluent explanation.

Searching documents and analysing incidents afterwards

Generative AI can serve as an assistant that searches approved technical documents or organises lengthy records for an initial review. It must show which document and version an answer is based on, prevent access to information without authorisation and leave uncertain cases to a specialist.

Giving that assistant the authority to change an operational instruction on its own introduces a different level of risk. Finding a document and taking action on a physical system should not be squeezed into the same project scope. Permissions must be defined separately according to the intended use.

Why does more AI not automatically mean more safety?

Even if a model performs well on average, its performance in critical scenarios may be inadequate. A rare situation may have very little representation in the training data. Results obtained on another line, with another equipment type or in another season cannot be assumed to hold under new conditions.

The costs of the two types of error also differ. Missing a real problem can delay intervention. Repeatedly raising alarms when there is no problem can increase the review workload and make it harder for warnings to be taken seriously. Evaluation should show these two outcomes and their operational effects separately, rather than report only an overall accuracy rate.

Changes require the same care. Replacing a sensor, renaming a data field or updating a model can affect behaviour that has already been tested. It must be clear who can make changes, what needs to be retested and how to revert to a previous version if necessary.

In its digital safety assessment, the UK's rail regulator, ORR, emphasises that risks can arise not only from individual systems but also when systems are integrated, changed and operated. Human decision-making and the supply chain are part of this picture too.

Simply saying “there is human approval” is therefore not enough either. The person providing approval needs to be able to see the source, understand the alert, reject it where necessary and have enough time to do so. Having someone at a screen without the authority to intervene, or without being able to see what they are approving, is not a robust control design.

What does this discussion have to do with AI projects in businesses?

The consequences of an e-commerce stock error are, of course, not the same as those of a railway accident. Even so, some questions are shared when assessing technology implementations: is the data current? Who has decision-making authority? How is an incorrect action detected? How does the team keep working if the system stops?

For example, if a customer service assistant is using an old version of the returns policy, more fluent responses will not solve the problem. If inventory integration is delayed, a sales recommendation model may become better at recommending a product that is out of stock. In a hotel, correctly classifying a guest's message is also only part of the job if there is no confirmation that the task reached the right team and was completed.

These examples show why AI consulting needs to examine the workflow before selecting a model. The starting point should be a specific process in which teams repeatedly lose time or make mistakes. The data source, decision boundaries, human oversight and measures of success should then be designed together.

Some problems may not even require a new model. A reliable data connection, a clear rule or an approval workflow may offer a simpler, more auditable solution. AI's added value becomes clear when it is compared with these alternatives.

How do you design a measurable AI pilot?

The plan below is a working framework we recommend for businesses starting operational AI projects. It does not replace railway safety engineering, conformity assessment or sector-specific approval procedures. For a general approach to risk, the NIST AI Risk Management Framework is a useful reference; it addresses risk management throughout a system's lifecycle.

1. Choose a single workflow and define its boundaries

Instead of “transforming the company with AI”, choose, for example, routing support requests to the right team. Write down whether the system will only make recommendations, create records or also carry out actions. Assess permissions such as sending messages to customers, making payments or deleting data separately.

2. Record current performance

Measure processing time, error rates and team workload before the pilot. Without knowing the current situation, it becomes harder to test claims of improvement. Make comparisons under similar workloads and conditions; directly comparing a promotional period with a quiet period can be misleading.

3. Separate the data and test examples

Identify the authoritative source, how up to date the data needs to be and the access permissions. Do not measure success only on the examples used to prepare the system. Use separate test examples and also test situations such as missing records, conflicting information, unexpected requests and connection failures.

4. Test without allowing actions first

Shadow operation is a form of testing in which the system produces recommendations without changing the actual decision. This allows its recommendations to be compared with the existing process. Failed examples can be examined and the scope narrowed. Moving on to limited permissions and human approval in the next stage allows problems to be observed in a more controlled way.

5. Set continuation and stopping criteria in advance

Before the pilot starts, write down which results would justify expanding it, which errors would require it to stop and who is responsible. Meeting one target must not conceal another risk. If speed improves while incorrect actions or review workload increase, the implementation may not yet be delivering the expected benefit.

The results report should show at least the following measures side by side:

• Business outcome: The chosen objective, such as processing time, correct routing or on-time completion.
• Error breakdown: Missed problems, false alarms and examples of critical errors.
• Human effort: Time spent on checking, correction and exception handling.
• Total cost: Integration, maintenance and review costs alongside model usage.
• Operability: Traceable records, data freshness, behaviour during outages and a working rollback process.

The outcome of a good pilot is not always a larger deployment. Returning to preparatory work if data is insufficient, keeping a rule-based solution if the benefit is limited or stopping a project if the risk is high can also be valuable outcomes.

Frequently asked questions

Can artificial intelligence prevent train accidents completely?

No such guarantee can be given. AI can provide early detection and decision support for specific tasks; safety requires infrastructure, train protection, maintenance, operations and human factors to be considered together. Every application needs to be validated under its own conditions.

Is ETCS an artificial intelligence system?

ETCS is the European train control system that supervises whether a train remains within its permitted speed and distance limits. Its use of mathematical calculations such as braking curves does not make it generative AI or a conversational model.

Does predictive maintenance eliminate existing maintenance?

Not automatically. Data-driven predictions can support maintenance priorities. Existing maintenance obligations or safety procedures should not be changed merely because a model recommends it; changes must undergo the relevant technical assessment.

Where should a business start with an AI project?

With a limited workflow whose data is accessible, whose owner is clear and whose outcome is measurable. First record current performance; then assess benefits, errors and human oversight together in a small pilot.

Is AI consulting only about choosing tools?

Tool selection is one part of the work. Unless data sources, integrations, access permissions, team training, approval processes and the measurement of results are considered together, even a good tool can remain disconnected from daily operations.

Let's explore where AI could help your business

At GadgetMall, our approach to AI transformation covers assessing workflows and data sources, developing a roadmap, integration, team training and measuring results. This approach is aimed at business processes such as customer support, content, commerce and internal operations.

You do not need a comprehensive technical specification to get started. Simply share a repetitive task, the tools you use and the outcome you want to improve. We can discuss which step is suitable for automation, where human approval should remain and how a pilot could be measured.

Discuss AI transformation with GadgetMall or email hello@gadgetmall.uk.

AI appearing everywhere does not show that all systems are automatically working better. Real progress begins when we can clearly demonstrate which problem is being solved, the limits of the solution and the results achieved in practice.