Tamames, en El Observador: IA y redundancia tras Urda

Rafael Tamames analiza en El Observador 107.9 qué enseña el accidente de Urda

Cuatro días después del choque de dos trenes de alta velocidad en Urda (Toledo), el emprendedor tecnológico Rafael Tamames puso el foco en una idea incómoda para cualquiera que construya producto: lo que falló no fue una máquina, fue un sistema sin redundancia. Lo dijo desde Madrid en «Domingo 1079», el programa de los domingos de El Observador 107.9 de Buenos Aires, entrevistado por Fernando González y con Gustavo Noriega en la mesa.

Su frase de arranque resume la tesis: «Los sistemas de seguridad en el mundo son una conexión entre humanos y máquinas». Para un founder, eso es una advertencia de diseño. La automatización no elimina el error humano: lo mueve de lugar, y si el sistema no tiene un plan B, el error se multiplica.

¿Qué falló en Urda según Rafael Tamames?

Tamames abre la entrevista con un mensaje para las víctimas, también las argentinas, y sus familias. Después entra en materia técnica.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Lo que falló fue el sistema de seguridad: no hubo un protocolo ni un sistema redundante que actuara cuando algo salió mal.
Señala que las primeras imágenes del centro de control de Adif muestran medios tecnológicos obsoletos y que el nuevo sistema de seguridad ERTMS llegaba con mucho retraso.
Coincide con Gustavo Noriega en que la automatización con redundancia tiene que dar una garantía de seguridad mucho mayor que los controles solo humanos.

La redundancia, dice, es algo que en los sistemas tecnológicos se trabaja mucho. La reconstrucción pública del siniestro apunta a que el sistema LZB dejó de funcionar alrededor de las 8:30, que seis trenes quedaron detenidos en un tramo de 63 kilómetros y que el centro de control de Adif en Atocha tomó el mando manual, según el seguimiento de Maldita.es. La orden de reanudar la marcha llegó a las 8:36 y el impacto se produjo a las 8:53. El siniestro dejó decenas de fallecidos y, a la fecha de la entrevista, no había una cifra definitiva.

¿Por qué el sistema de seguridad de 1992 seguía en servicio?

El sistema que dejó de funcionar minutos antes de la colisión fue el LZB, instalado en la línea Madrid-Sevilla en 1992, coincidiendo con la inauguración del primer AVE español, según El Correo. La sustitución por el estándar europeo ERTMS se adjudicó en 2021 a Thales España —hoy Hitachi Rail— por 93,8 millones de euros, con un plazo de ejecución de 52 meses que situaba la entrada en servicio en marzo de 2026, según El Periódico Extremadura.

Ese plazo no se cumplió. El Gobierno y Adif asumen ahora que la puesta en servicio definitiva no será completa hasta el primer trimestre de 2027, con un año de retraso, aunque desvinculan la demora de la tragedia. La línea Madrid-Sevilla es la única de alta velocidad española que aún no tiene implantado el ERTMS, de acuerdo con el mismo medio.

El ministro de Transportes, Óscar Puente, defendió que «el ERTMS también se cae, tanto o más que el LZB» y que lo relevante es cumplir los protocolos cuando los sistemas fallan. El presidente de Adif, Luis Pedro Marco, sostuvo que «no hay ninguna relación entre el plazo de ejecución de las obras con un demérito la seguridad».

Los datos de contexto ayudan a dimensionar el problema: entre el 1 de enero y el día del accidente, la línea Madrid-Sevilla había registrado 162 incidentes, según la información del Gobierno recogida por El Correo. Ese mismo medio detalla que, al caer el LZB, la circulación pasa a un sistema alternativo más limitado, el Bloqueo de Señalización Lateral (BSL), donde el maquinista se guía por semáforos laterales y depende del centro de control. En alta velocidad, el margen de frenado es de entre 3.000 y 4.000 metros.

¿Cómo automatizar sin quitar a las personas del sistema?

Ante la pregunta de cómo confiar en un tren o un coche sin conductor después de un accidente así, Tamames pone el ejemplo del Metro de Madrid. Tiene varias líneas automatizadas en las que se mantiene un conductor, sobre todo para que los viajeros no sientan que van solos.

Sus centros de control combinan medios técnicos, redundancia y un equipo humano muy bueno, con talleres propios y colaboración público-privada entre funcionarios y empresas de tecnología. Para Tamames, ese es el estándar que tenía la alta velocidad española y que hay que recuperar.

El punto es relevante para quien vende software: la adopción de un sistema automatizado depende tanto de su fiabilidad técnica como de la confianza que genera en el usuario final. Automatizar sin dejar una persona visible en el bucle puede ser más barato y, aun así, fracasar.

¿Por qué hay miedo a la IA y a la vez se usa masivamente?

Tamames describe una contradicción que ve en las sociedades occidentales, también en la argentina. Existe un miedo legítimo a la novedad —hoy la inteligencia artificial— por la sustitución de empleos o por su posible control por parte de dictaduras. Al mismo tiempo, esa misma sociedad la usa de forma masiva: alguien puede decir en una encuesta que teme a la IA y tener ChatGPT en el teléfono.

¿Qué propone Tamames para regular la IA?

Su propuesta es no regular la inteligencia artificial, en línea con los trabajos de Federico Sturzenegger y Javier Milei, y poner la inversión en la seguridad y en la justicia. El cambio tecnológico, argumenta, exige una justicia rápida, eficiente y moderna, que trabaje con los mismos sistemas que la tecnología que tiene que supervisar.

Como referencia de Estado eficiente y tecnológicamente avanzado cita a Estonia y, en algunos campos, a Noruega y Corea. Su conclusión: el miedo a los avances tecnológicos debería convertirse en inversión tecnológica en el Estado, para mejorar la vida de todos. En el cierre, la conversación repasó el efecto del accidente en la campaña de las elecciones generales del 29 de noviembre.

¿Qué significa esto para tu startup?

El caso de Urda es un recordatorio de ingeniería aplicada a cualquier producto que use IA o automatización.

Diseña la redundancia desde el día uno. Si tu producto depende de un solo proveedor de modelos, una sola región de nube o una sola persona que sabe cómo funciona el pipeline, tienes un punto único de fallo. Define explícitamente qué pasa cuando ese componente cae y pruébalo antes de que caiga solo.
Documenta el protocolo de degradación. En Urda existía un sistema de respaldo, pero la decisión humana fue el eslabón débil. En tu caso: ¿qué hace tu agente cuando la API de IA devuelve error? ¿Vuelve a un modo manual, avisa al usuario, encola la tarea? Si la respuesta no está escrita, no existe.
Automatiza sin borrar al humano del bucle. El ejemplo del Metro de Madrid muestra que la automatización que se adopta es la que mantiene a una persona donde aporta confianza. En productos regulados o de alto riesgo —salud, finanzas, logística— la supervisión humana visible puede ser una ventaja comercial, no un costo.
Sigue el debate regulatorio de cerca. Si operas en España o LATAM, la discusión sobre regular o no la IA define tu roadmap de compliance. Tamames apuesta por no regular y por invertir en la capacidad del Estado para supervisar; es una posición que conviene entender, incluso para discutirla.