Si la IA está en todas partes, ¿cómo puede un tren alcanzar por detrás al que va delante?

¿Qué sabemos del suceso en España?

El 28 de octubre de 2026 se informó de una colisión en la que estuvieron implicados trenes de Renfe e Iryo cerca de Urda, en la línea de alta velocidad Madrid–Sevilla. En su primera comunicación, el administrador de infraestructuras Adif describió el suceso entre Mora y Orgaz y Urda con la palabra «alcance», que indica una colisión por detrás. Renfe también publicó un comunicado oficial sobre el accidente. Los primeros avisos operativos aparecieron en la página de Adif sobre el estado de la red.

Esta información no explica la causa técnica de la colisión. Qué sistema de protección estaba funcionando y en qué modo, la secuencia de movimientos de los trenes, las autorizaciones concedidas y el proceso de frenado son cuestiones que deben examinarse por separado. Estos comunicados no bastan para atribuir el suceso a una «falta de IA», un «fallo del ETCS» o el error de una persona concreta.

La prioridad son los pasajeros y los trabajadores afectados. Este artículo no es una investigación del accidente, sino un análisis general de la pregunta tecnológica que plantea el suceso. En lugar de centrarnos en cifras de heridos que pueden cambiar rápidamente, nos centramos en el contexto verificable y en cuestiones técnicas de mayor recorrido.

¿Qué sistemas intervienen para evitar las colisiones entre trenes?

Reducir la seguridad ferroviaria a la luz que ve el maquinista o a un único ordenador ofrece una visión incompleta. Para que un tren pueda avanzar, distintos sistemas deben producir información coherente entre sí. Aunque la aplicación concreta depende del equipamiento de la línea y de los vehículos, las funciones básicas pueden resumirse así:

• Detectar la presencia y la posición del tren: Saber si un tramo de vía está ocupado es el punto de partida de una circulación segura.
• Establecer el itinerario adecuado: La posición de los desvíos y los movimientos autorizados no deben entrar en conflicto. Por eso es importante la relación de seguridad entre señales y desvíos.
• Transmitir la autorización de movimiento: El sistema correspondiente y las normas de explotación determinan hasta dónde puede avanzar el tren y en qué condiciones.
• Supervisar los límites de velocidad: Según el equipamiento, el sistema de protección del tren puede emitir avisos o intervenir sobre el frenado antes de que se rebasen los límites permitidos.
• Poder detenerse físicamente: El estado del sistema de frenos, la velocidad, las características del tren y las condiciones de la vía influyen en su comportamiento al detenerse.

La explicación de Network Rail sobre la señalización describe una estructura compuesta por numerosos elementos y señala que pasar a un estado seguro en caso de fallo es uno de los objetivos fundamentales del diseño. Por eso, una avería de señalización puede provocar a veces la interrupción del tráfico o retrasos. En determinadas circunstancias, el retraso que percibe el pasajero es consecuencia de la activación de un mecanismo de seguridad.

De esto no puede deducirse la causa de ningún accidente. Además del diseño de los sistemas, deben examinarse su mantenimiento, su configuración, la gestión de los cambios y su explotación en condiciones excepcionales. La pregunta «si había un ordenador, ¿por qué no lo evitó?» solo puede responderse a partir de los registros del suceso.

¿La protección automática de trenes y la inteligencia artificial son lo mismo?

No todos los sistemas que funcionan de forma automática son inteligencia artificial. En particular, conviene distinguir la IA generativa de las funciones de control destinadas a la seguridad. Un modelo de lenguaje puede redactar explicaciones, buscar información en documentos y resumir registros de incidentes. Un sistema de protección del tren, en cambio, se diseña para operar dentro de unas condiciones de explotación y seguridad definidas.

Como ejemplo general, el Sistema Europeo de Control de Trenes, o ETCS, supervisa la velocidad y la posición del tren respecto a los límites autorizados. Según la explicación sobre las curvas de frenado de la Agencia Ferroviaria de la Unión Europea, el ordenador embarcado calcula las distancias de frenado a partir de las características de frenado del tren y de los datos sobre la vía situada por delante. Cuando es necesario, envía una orden de intervención a los frenos del tren, que constituyen un sistema independiente.

La existencia de este cálculo no significa que se esté utilizando un modelo conversacional. Además, aquí se presenta el ETCS como ejemplo para explicar su lógica de funcionamiento; no se afirma que estuviera activo o que hubiera fallado en el momento del suceso en España.

Por tanto, no hace falta esperar a la IA generativa para prevenir los alcances. El correcto funcionamiento de las funciones de seguridad existentes ya es una exigencia por sí mismo. Los proyectos de inteligencia artificial deben explicar con claridad qué beneficio adicional aportarán, sin diluir esa responsabilidad.

¿Dónde puede aportar valor la inteligencia artificial al ferrocarril?

Las oportunidades más concretas aparecen en tareas que exigen revisar periódicamente grandes cantidades de datos. Los ejemplos siguientes son posibles ámbitos de aplicación; no deben interpretarse como capacidades actuales de una línea determinada ni como una solución infalible para cualquier accidente.

Detectar cambios inusuales en los datos de los sensores

El análisis conjunto de temperatura, vibraciones, mediciones eléctricas y registros de mantenimiento permite investigar cambios que no son visibles en una medición aislada. Por ejemplo, si un equipo se aleja de su comportamiento histórico en condiciones de funcionamiento similares, puede señalarse como una situación que requiere revisión.

Detectar una anomalía no equivale, por sí solo, a diagnosticar una avería. El sensor podría estar dañado, las condiciones de funcionamiento podrían haber cambiado o un registro podría haberse asociado de forma incorrecta. Por eso, la alerta debe ir acompañada de los datos utilizados, su información temporal y el motivo de la revisión; el resultado debe trasladarse al especialista correspondiente para que lo examine.

Establecer prioridades para el mantenimiento predictivo

El mantenimiento predictivo busca evaluar antes las necesidades de mantenimiento mediante el seguimiento del estado de los equipos. La IA puede explorar patrones entre averías anteriores y mediciones, y proponer prioridades a los equipos de mantenimiento. Su utilidad no se observa únicamente en la predicción del modelo, sino también en que la recomendación se convierta en una orden de trabajo, una inspección y un registro.

También es necesario distinguir el grado de madurez de los trabajos en este ámbito. La solución de mantenimiento dinámico de Europe’s Rail describe un sistema de apoyo a las decisiones que combina datos de estado y mantenimiento procedentes de distintas fuentes. La página presenta la solución como un prototipo de nivel TRL 6 demostrado en un entorno relevante e indica la necesidad de una aplicación piloto y de validaciones adicionales. Un resultado de investigación no debe presentarse como una garantía de seguridad lista para utilizarse en cualquier lugar.

Apoyar las inspecciones basadas en imágenes

Los modelos de procesamiento de imágenes pueden destacar, en las imágenes de inspección, las zonas que requieren la atención de especialistas. El objetivo es facilitar la selección de los casos que merecen revisión entre un gran volumen de imágenes. Si cambian la iluminación, el tiempo, el ángulo de la cámara o la calidad de imagen, es necesario volver a evaluar el rendimiento.

Los resultados del proyecto RAILS, publicados por la Comisión Europea, incluyen líneas de investigación como la detección de obstáculos mediante cámaras, la inspección de infraestructuras y los gemelos digitales para el mantenimiento predictivo. Son ámbitos prometedores, pero no deben considerarse soluciones terminadas que funcionen igual de bien en todos los escenarios.

Hacer llegar la información dispersa al equipo que debe decidir

Cuando una alerta está en una pantalla, el historial de mantenimiento en otra aplicación y una nota de campo en una cadena de mensajes, a los equipos les cuesta comprender la situación. Una capa de integración puede reunir los registros correspondientes a un mismo activo. La IA, a su vez, puede ayudar a clasificarlos o resumirlos.

El detalle crítico es la correspondencia entre los datos. Si los identificadores de los equipos, las marcas de tiempo y las versiones de los registros no coinciden entre sistemas, un resumen bien redactado puede ofrecer una imagen equivocada. Los enlaces a las fuentes y las indicaciones de datos ausentes pueden resultar más valiosos que una explicación fluida.

Buscar en documentos y apoyar el análisis posterior a un incidente

La IA generativa puede utilizarse como asistente para buscar en documentación técnica aprobada u organizar registros extensos para una primera revisión. Es necesario mostrar en qué documento y versión se basa la respuesta, impedir el acceso a información no autorizada y remitir los casos inciertos a un especialista.

Dar a ese asistente autoridad para modificar por su cuenta una instrucción operativa supone otro nivel de riesgo. Buscar un documento y actuar sobre un sistema físico no deberían agruparse sin más dentro del mismo proyecto. Los permisos deben definirse por separado en función del uso previsto.

¿Por qué más IA no significa, por sí sola, más seguridad?

Aunque un modelo obtenga buenos resultados de media, su rendimiento puede ser insuficiente en situaciones críticas. Una situación poco frecuente puede estar escasamente representada en los datos de entrenamiento. Tampoco puede suponerse que los resultados obtenidos en otra línea, con otro tipo de equipo o en otra estación del año sigan siendo válidos en condiciones nuevas.

El coste de los dos tipos de error también es distinto. Pasar por alto un problema real puede retrasar la intervención. Generar alarmas constantes cuando no hay ningún problema puede aumentar la carga de revisión y dificultar que las advertencias se tomen en serio. La evaluación debe mostrar por separado ambos resultados y sus efectos operativos, en lugar de limitarse a una tasa global de acierto.

Los cambios requieren la misma atención. Sustituir un sensor, cambiar el nombre de un campo de datos o actualizar el modelo puede afectar a un comportamiento ya probado. Debe quedar claro quién puede hacer cambios, qué debe volver a probarse y cómo se recuperará la versión anterior si resulta necesario.

En su análisis de la seguridad digital, el regulador ferroviario británico ORR destaca que los riesgos no solo pueden proceder de los sistemas individuales, sino también de su integración, modificación y explotación. Los procesos de decisión de las personas y la cadena de suministro también forman parte de este conjunto.

Por eso, decir que «hay aprobación humana» tampoco basta. La persona que aprueba debe poder consultar la fuente, comprender la alerta, rechazarla cuando proceda y disponer del tiempo necesario para hacerlo. Tener a una persona frente a una pantalla, sin capacidad de intervención o sin visibilidad sobre lo que está aprobando, no constituye un diseño de control sólido.

¿Qué relación tiene este debate con los proyectos de IA en las empresas?

Las consecuencias de un error de inventario en el comercio electrónico no son, por supuesto, las mismas que las de un accidente ferroviario. Aun así, algunas preguntas al evaluar aplicaciones tecnológicas son comunes: ¿están actualizados los datos? ¿Quién tiene autoridad para decidir? ¿Cómo se detecta una acción incorrecta? Si el sistema se detiene, ¿cómo continúa trabajando el equipo?

Por ejemplo, si un asistente de atención al cliente utiliza una versión antigua de la política de devoluciones, expresarse con más fluidez no resuelve el problema. Si la integración de inventario se retrasa, un modelo de recomendación comercial puede recomendar con mayor eficacia un producto que no está disponible. En un hotel, clasificar correctamente el mensaje de un huésped también se queda a medio camino si no se comprueba que la tarea ha llegado al equipo adecuado y se ha completado.

Estos ejemplos muestran por qué, en la consultoría de IA, conviene examinar el flujo de trabajo antes de elegir el modelo. El punto de partida debe ser una operación concreta en la que los equipos pierden tiempo o cometen errores de manera repetida. Después, la fuente de datos, los límites de decisión, el control humano y la medida de éxito deben diseñarse conjuntamente.

Algunos problemas quizá ni siquiera requieran un modelo nuevo. Una conexión de datos bien resuelta, una regla clara o un flujo de aprobación pueden ofrecer una solución más sencilla y auditable. El valor adicional de la inteligencia artificial se hace visible al compararlo con estas alternativas.

¿Cómo se diseña un piloto de inteligencia artificial medible?

El siguiente plan es un marco de trabajo que proponemos para que las empresas inicien proyectos de IA operativa. No sustituye a la ingeniería de seguridad ferroviaria, las evaluaciones de conformidad ni los procedimientos de autorización específicos del sector. Para un enfoque general del riesgo, el AI Risk Management Framework del NIST es una referencia útil: aborda la gestión de riesgos durante todo el ciclo de vida del sistema.

1. Elegir un único flujo de trabajo y definir sus límites

En lugar de proponerse «transformar la empresa con IA», se puede elegir, por ejemplo, la asignación de solicitudes de soporte al equipo adecuado. Hay que dejar por escrito si el sistema solo hará recomendaciones, creará registros o también ejecutará acciones. Facultades como enviar mensajes al cliente, realizar pagos o borrar datos deben evaluarse por separado.

2. Registrar el rendimiento actual

Hay que medir el tiempo de tramitación, la tasa de errores y la carga de trabajo del equipo antes del piloto. Sin conocer la situación actual, resulta difícil comprobar una supuesta mejora. La comparación debe hacerse con volúmenes de trabajo y condiciones similares; comparar directamente un periodo de campaña con uno tranquilo puede inducir a error.

3. Separar los datos y los ejemplos de prueba

Es necesario definir cuál es la fuente autorizada, qué antigüedad de los datos se admite y cuáles son los permisos de acceso. El éxito no debe medirse únicamente con los ejemplos empleados para preparar el sistema. Además de utilizar casos de prueba independientes, deben ensayarse situaciones como registros incompletos, información contradictoria, solicitudes inesperadas y pérdidas de conexión.

4. Probar primero sin ejecutar acciones

El funcionamiento en modo sombra consiste en que el sistema genere recomendaciones sin modificar la decisión real. Así se pueden comparar sus sugerencias con el proceso existente. Es posible revisar los casos fallidos y reducir el alcance. En la fase siguiente, avanzar con permisos limitados y aprobación humana permite observar los problemas de forma más controlada.

5. Definir de antemano cuándo continuar y cuándo detenerse

Antes de iniciar el piloto, hay que establecer por escrito qué resultados justificarán ampliarlo, qué errores obligarán a detenerlo y quién será responsable. Cumplir un objetivo no debe ocultar otro riesgo. Si la velocidad aumenta, pero también lo hacen las acciones incorrectas o la carga de revisión, la aplicación puede no estar aportando todavía el beneficio esperado.

El informe de resultados debe presentar, como mínimo, estas medidas de forma conjunta:

• Resultado operativo: El objetivo elegido, como el tiempo de tramitación, la asignación correcta o la finalización a tiempo.
• Distribución de errores: Problemas no detectados, falsas alarmas y ejemplos de errores críticos.
• Trabajo humano: Tiempo dedicado a comprobar, corregir y gestionar excepciones.
• Coste total: Costes de integración, mantenimiento y revisión, además del uso del modelo.
• Viabilidad operativa: Registros trazables, actualidad de los datos, comportamiento ante interrupciones y funcionamiento de la vuelta al estado anterior.

Un buen piloto no siempre termina en un despliegue mayor. Volver a preparar los datos si son insuficientes, mantener una solución basada en reglas si el beneficio es limitado o detener el proyecto si el riesgo es alto también son resultados valiosos.

Preguntas frecuentes

¿Puede la inteligencia artificial evitar por completo los accidentes ferroviarios?

No se puede ofrecer esa garantía. La IA puede facilitar la detección temprana y el apoyo a las decisiones en tareas concretas; la seguridad exige abordar conjuntamente la infraestructura, la protección del tren, el mantenimiento, la explotación y los factores humanos. Cada aplicación debe validarse en sus propias condiciones.

¿Es el ETCS un sistema de inteligencia artificial?

El ETCS es el sistema europeo de control de trenes que supervisa que el tren se mantenga dentro de los límites autorizados de velocidad y distancia. El uso de cálculos matemáticos, como las curvas de frenado, no lo convierte en IA generativa ni en un modelo conversacional.

¿El mantenimiento predictivo elimina el mantenimiento existente?

No lo elimina automáticamente. Las predicciones basadas en datos pueden ayudar a establecer prioridades de mantenimiento. Las obligaciones de mantenimiento o los procedimientos de seguridad existentes no deben modificarse solo porque lo sugiera un modelo; los cambios deben someterse a la evaluación técnica correspondiente.

¿Por dónde debe empezar una empresa un proyecto de IA?

Por un flujo de trabajo acotado, con datos accesibles, un responsable definido y un resultado medible. Primero hay que registrar el rendimiento actual; después, evaluar conjuntamente el beneficio, los errores y el control humano en un piloto pequeño.

¿La consultoría de IA consiste únicamente en elegir herramientas?

Elegir herramientas es una parte del trabajo. Si no se abordan conjuntamente las fuentes de datos, las integraciones, los permisos de acceso, la formación del equipo, los procesos de aprobación y la medición de resultados, incluso una buena herramienta puede quedar al margen de la operativa diaria.

Evaluemos juntos dónde puede aportar valor la IA a su empresa

En GadgetMall abordamos la transformación con IA mediante la evaluación de flujos de trabajo y fuentes de datos, la elaboración de una hoja de ruta, la integración, la formación de los equipos y la medición de los resultados. Este enfoque se dirige a procesos empresariales como la atención al cliente, los contenidos, el comercio y las operaciones internas.

No necesita preparar unas especificaciones técnicas exhaustivas para empezar. Basta con compartir una tarea repetitiva, las herramientas que utiliza y el resultado que desea mejorar. Podemos estudiar qué paso es adecuado automatizar, dónde debe mantenerse la aprobación humana y cómo medir un piloto.

Hable con GadgetMall sobre la transformación con IA o escriba a hello@gadgetmall.uk.

Que la IA aparezca en todas partes no demuestra que todos los sistemas funcionen mejor de forma automática. El progreso real empieza cuando podemos mostrar con claridad qué problema se resuelve, cuáles son los límites de la solución y qué resultado se obtiene en la práctica.