Resumen ejecutivo
El 25 de septiembre de 2026, El Mundo reveló que un grupo criminal había vulnerado los sistemas digitales de Adif con ayuda de un sistema de inteligencia artificial y, desde ahí, había saltado a los servidores de Renfe. El botín inicial se cifró en 500 gigabytes de datos. Dos días después, el propio diario elevó la cifra a 150 millones de registros. El caso no es un incidente más de ciberdelincuencia. Es, según las fuentes técnicas citadas en el análisis forense difundido junto a la noticia, el primer ataque documentado en España en el que una IA actuó como motor autónomo de descubrimiento y explotación de vulnerabilidades, no como simple herramienta de apoyo a un operador humano.
El artículo reconstruye la cronología completa del incidente: la intrusión silenciosa en la web pública de Adif, el salto lateral hacia la infraestructura en la nube compartida con Renfe, la exfiltración escalonada de datos a lo largo de varios días y la respuesta de contención, que culminó con la recuperación del dominio adif.es la semana siguiente. Se examina también, con las cautelas propias del periodismo de fuentes, la afirmación de que la IA identificó de forma autónoma una vulnerabilidad hasta entonces no catalogada en los sistemas expuestos de Adif, un extremo que ninguna fuente posterior ha desmentido ni confirmado con documentación técnica independiente.
El informe dedica un capítulo entero a desentrañar el alcance real de la brecha. La diferencia entre "500 GB" y "150 millones de datos" no es solo una cuestión aritmética: describe magnitudes distintas (volumen bruto frente a número de registros afectados) que la comunicación pública de las empresas no siempre distinguió con claridad. Se reconstruye, a partir de las categorías que las propias compañías facilitaron a los medios, qué tipo de información quedó expuesta: desde datos de bajo riesgo, como nombres y correos electrónicos, hasta información con mayor potencial de uso fraudulento en campañas de suplantación e ingeniería social.
En el terreno normativo, el análisis sitúa el incidente en el marco de la Directiva NIS2, transpuesta de forma incompleta al ordenamiento español a través del Real Decreto-ley 12/2018 y del Esquema Nacional de Seguridad, y examina las obligaciones de notificación que con toda probabilidad se activaron ante la Agencia Española de Protección de Datos y ante el CCN-CERT. También se aborda la fragmentación de competencias entre los organismos llamados a intervenir en un incidente de esta naturaleza, un problema de gobernanza que el propio caso pone de manifiesto.
El texto cierra con una reflexión sobre las lecciones operativas para el sector ferroviario europeo: la necesidad de gobernanza compartida entre entidades distintas en lo jurídico pero con sistemas interconectados, la insuficiencia de las defensas basadas en firmas frente a amenazas generadas por IA y la urgencia de adaptar la velocidad de respuesta defensiva a la velocidad de ataque que estas herramientas permiten. El caso Adif-Renfe, sostiene el análisis, no representa una anomalía aislada, sino la confirmación local de una tendencia que ENISA y otros organismos europeos venían advirtiendo desde 2024: la inteligencia artificial ha dejado de ser un elemento accesorio en el ciberdelito para convertirse en su motor operativo.
Nota metodológica: este informe se construye a partir de fuentes periodísticas, documentación institucional y literatura técnica, todas identificadas en la bibliografía final. Las afirmaciones sin confirmación verificable se señalan como tales a lo largo del texto.
Cuando la inteligencia artificial se convierte en arma: el asalto algorítmico a la columna vertebral ferroviaria española
Subtítulo
Anatomía técnica, forense y regulatoria del primer ciberataque asistido por IA contra una infraestructura crítica de transporte en España, y sus implicaciones para la gobernanza de la ciberseguridad en el marco NIS2
Índice
- Introducción: el umbral de una nueva categoría de amenaza
- Cronología forense del incidente: de la intrusión silenciosa al colapso controlado
- El vector de ataque: IA como motor autónomo de descubrimiento y explotación de vulnerabilidades
- Alcance real de la brecha: tipología, clasificación y valor económico de los datos sustraídos
- Marco normativo aplicable y obligaciones incumplidas o activadas
- La respuesta institucional: coordinación, competencias y vacíos de gobernanza
- Análisis de riesgos y lecciones para el sector ferroviario europeo
- Conclusiones: hacia una doctrina de ciberresiliencia asistida por IA
- Bibliografía
Nota metodológica previa
Este informe se construye a partir de fuentes periodísticas, documentación institucional y literatura técnica. Todos los hechos proceden de las fuentes identificadas en la bibliografía final. Cuando una afirmación no tiene confirmación verificable, el texto lo indica. Las hipótesis se distinguen de los hechos comprobados. Las interpretaciones técnicas se atribuyen a sus autores.
1. Introducción: el umbral de una nueva categoría de amenaza
El 25 de septiembre de 2026, El Mundo publicó un reportaje sobre un grupo criminal que había utilizado un sistema de inteligencia artificial para vulnerar las infraestructuras digitales de Adif. Desde allí, los atacantes accedieron a los sistemas de Renfe y sustrajeron 500 gigabytes de datos (1). La noticia se replicó en horas por medios nacionales e internacionales. Lo que describía no era un incidente más de ciberdelincuencia. Describía, por primera vez en España, un ataque donde la IA no asistía al atacante humano. Operaba como motor autónomo de descubrimiento y explotación de vulnerabilidades.
La magnitud del incidente creció en los días siguientes. También importa la naturaleza de las entidades afectadas: dos operadores de infraestructura ferroviaria calificados como críticos en el marco normativo español y europeo. Pero lo que, en el fondo, define este caso es que materializa una transición que los organismos de referencia venían anticipando desde 2024. El uso de IA en ciberataques pasó de la experimentación a la capacidad operativa consolidada.
1.1. La advertencia de los organismos de referencia
ENISA publicó en 2026 su informe Threat Landscape. Allí documenta que la inteligencia artificial dejó de ser una herramienta auxiliar para convertirse en componente estructural de las operaciones maliciosas (53). El informe señala que el 38 % de los ataques registrados en la Unión Europea apuntaron a redes de administración pública. El sector del transporte representó el 8 % de los incidentes, consolidándose entre los cinco sectores más afectados (53). ENISA también constató que la distinción entre ciberdelincuencia, hacktivismo y actores vinculados a Estados se difumina. Las técnicas, infraestructuras y mecanismos de acceso se repiten entre todos ellos (53).
La evaluación específica sobre el uso ofensivo de la IA fue más explícita. Los grupos de amenaza seguían utilizando modelos de IA de consumo para aumentar sus capacidades existentes. Pero ya se observaban mejoras en los modelos que aceleraban el descubrimiento y la explotación de vulnerabilidades (53). El informe documentó la proliferación de malware generado por IA en contextos operativos reales. También el uso de IA para reconocimiento, desarrollo de scripts y post-explotación. Y la aparición de kits de herramientas asistidos por IA en mercados subterráneos (53).
En el ámbito normativo y técnico, el NIST publicó en marzo de 2025 su taxonomía sobre Adversarial Machine Learning (NIST AI 100-2e2025). Este documento establece un lenguaje común para clasificar los ataques contra y mediante sistemas de aprendizaje automático (54). La taxonomía distingue entre ataques de evasión, envenenamiento, privacidad y uso indebido. Los organiza según el tipo de sistema de IA objetivo, la etapa del ciclo de vida y los objetivos del atacante (54).
1.2. La doctrina española sobre IA ofensiva
El Centro Criptológico Nacional (CCN-CERT), organismo adscrito al CNI, publicó en junio de 2026 la guía de buenas prácticas BP/36, titulada Security Recommendations to Counter the Offensive AI Models (55). Este documento constituye la respuesta doctrinal más elaborada del ecosistema institucional español al fenómeno que el ataque a Adif y Renfe materializaría tres meses después.
La guía BP/36 describe el riesgo y lo enmarca como un cambio de paradigma. Obliga a repensar los fundamentos de la ciberseguridad. Su índice anticipa las dimensiones del problema: contexto actual de la defensa basada en IA, amenazas, riesgos y escenarios posibles, implicaciones estratégicas para el sector público, y mejores prácticas diferenciadas para entornos IT y OT (55). El CCN-CERT identifica la "IA ofensiva" como capacidad operativa ya desplegada. No como amenaza emergente. Advierte que su uso transforma los ciberataques al reducir la complejidad técnica requerida para ejecutar operaciones sofisticadas (55).
1.3. La literatura académica: de la teoría a la operación real
Zdrojewski publicó en 2025 un estudio en AI-TEEE que revisa las principales modalidades de ciberataque potenciadas por IA: phishing automatizado, explotación automatizada de vulnerabilidades, generación autónoma de malware, deepfakes y ataques de inyección de prompts (57). El estudio concluye que la inteligencia artificial dejó de ser un facilitador teórico. Es una realidad operativa. Los actores de amenaza utilizan generative adversarial networks (GANs) y modelos de lenguaje de gran escala (LLMs) para automatizar y personalizar ataques con precisión sin precedentes. Los sistemas tradicionales de detección de intrusiones, basados en firmas y reglas predefinidas, no pueden identificar amenazas novedosas o en evolución (57).
Las fuentes periodísticas indican que los atacantes no emplearon una vulnerabilidad de día cero ni un método de ataque novel. La IA buscó vulnerabilidades en la web de Adif hasta encontrar una "puerta trasera" por la que acceder (1). Lo novedoso no fue la técnica de intrusión. Fue la automatización inteligente del proceso de descubrimiento y explotación. La IA no inventó un nuevo agujero en la defensa. Encontró, a velocidad de máquina, el agujero que ya existía.
1.4. El objeto de este informe
Este documento analiza el ciberataque a Adif y Renfe de septiembre de 2026 desde una perspectiva multidisciplinar. Integra ciberinteligencia, forense digital, análisis de riesgos y marco regulatorio. No es una reconstrucción periodística. Es un análisis técnico y jurídico destinado a extraer consecuencias operativas y de gobernanza para el sector de las infraestructuras críticas.
El informe se estructura en ocho secciones. La Sección 2 reconstruye la cronología forense del incidente a partir de las fuentes disponibles. Distingue entre hechos comprobados, interpretaciones y lagunas informativas. La Sección 3 analiza el vector de ataque. Presta atención al uso de IA como motor de descubrimiento y explotación de vulnerabilidades, y a la hipótesis del fallo humano como factor coadyuvante. La Sección 4 examina el alcance real de la brecha. Incluye la evolución de las cifras de datos sustraídos y la tipología de la información comprometida. La Sección 5 aborda el marco normativo aplicable: Directiva NIS2, RGPD, Real Decreto-ley 12/2018. También las obligaciones que el incidente activa o revela incumplidas. La Sección 6 analiza la respuesta institucional. Presta atención a las competencias del CCN-CERT, la AEPD y la articulación entre los organismos afectados. La Sección 7 extrae lecciones y analiza riesgos para el sector ferroviario europeo. La Sección 8 presenta las conclusiones.
La información disponible sobre el incidente proviene de fuentes periodísticas. Se complementa con documentación institucional y académica de carácter general sobre la amenaza de la IA ofensiva. No se ha tenido acceso a los informes forenses de Adif, Renfe o el CCN-CERT. Tampoco a los expedientes que pudieran haberse abierto en la Agencia Española de Protección de Datos. Cuando las fuentes no permitan confirmar un extremo, el informe lo señalará.
2. Cronología forense del incidente: de la intrusión silenciosa al colapso controlado
Reconstruir la secuencia de hechos que condujo al compromiso de los sistemas de Adif y Renfe presenta una dificultad. Las fuentes disponibles son periodísticas. Ninguna reproduce un informe forense oficial de las entidades afectadas ni del Centro Criptológico Nacional. Lo que sigue es una cronología construida a partir de declaraciones institucionales recogidas por los medios y de informaciones atribuidas a "fuentes cercanas a la investigación". Cuando un extremo no pueda confirmarse con las fuentes disponibles, se indicará.
2.1. Fase preliminar: semanas de intentos continuados
El primer dato relevante no se refiere al día del ataque. Se refiere a las semanas previas. RTVE recogió el comunicado de Renfe: el incidente se produjo "tras varias semanas de intentos continuados de ataque contra los sistemas de Renfe, que habían sido detectados y bloqueados con éxito gracias a los mecanismos de protección desplegados por la compañía" (6). Esta afirmación procede de la propia operadora ferroviaria. Sugiere que los atacantes realizaron una fase de reconocimiento y prueba de defensas prolongada. Durante esa fase, sus intentos fueron neutralizados sin que se produjera una brecha efectiva.
La fuente no especifica cuántas semanas duró esta fase preliminar. Tampoco la naturaleza exacta de los intentos bloqueados: si fueron escaneos de puertos, intentos de autenticación fallidos, explotación de vulnerabilidades conocidas o una combinación. No aclara si estos intentos previos se dirigieron solo contra Renfe o si también afectaron a Adif. La información disponible permite afirmar que existió una fase de aproximación prolongada. No permite reconstruir su alcance técnico ni su duración exacta.
2.2. El vector de entrada: la web de Adif como punto de ruptura
Las fuentes sitúan el origen de la intrusión efectiva en la página web de Adif. El Mundo afirma que "el primer ataque comenzó a la web de Adif, se sospecha que con la IA, que se dedicó a buscar vulnerabilidades hasta que encontró una puerta trasera por la que acceder a la web" (2). elEconomista confirma esta secuencia: "La entrada inicial se habría producido a través de los sistemas de Adif. Los atacantes habrían rastreado su infraestructura tecnológica hasta localizar una brecha que les permitió superar las primeras barreras de seguridad y acceder posteriormente a recursos alojados en la nube" (10).
La información disponible no permite determinar la naturaleza exacta de esa "puerta trasera". Rescana publicó el 28 de septiembre de 2026 un análisis técnico. Señala que la IA "identificó autónomamente un backdoor (probablemente una vulnerabilidad previamente desconocida o no parcheada) en una de las aplicaciones web de Adif". Clasifica la técnica de acceso inicial como consistente con la técnica T1190 de MITRE ATT&CK: Exploit Public-Facing Application (30). Esta clasificación es una interpretación técnica de la fuente. No es un dato confirmado por Adif o por el CCN-CERT. La fuente no especifica si se trataba de una vulnerabilidad de día cero, de un sistema sin parchear o de una configuración deficiente. El Mundo añade que "todo apunta a que también pudo haber un fallo humano por parte de algún miembro de Adif, que permitió que la IA comenzase a buscar las vulnerabilidades de su web" (2). Esta hipótesis no tiene confirmación oficial.
2.3. Movimiento lateral: del servidor web a la nube y de allí a Renfe
Una vez establecido el punto de apoyo en la web de Adif, los atacantes ejecutaron un movimiento lateral en dos saltos. Primero accedieron a la infraestructura en la nube de Adif. Desde esa nube, saltaron a los sistemas de Renfe. El Mundo describe la secuencia: "Desde la web, los criminales saltaron a la nube de Adif, y desde allí consiguieron entrar por fin en la web de Renfe" (2). elEconomista añade que "a partir de ese punto, la intrusión habría ido ampliando su alcance hasta afectar también al entorno tecnológico de Renfe" (10).
Rescana interpreta que este movimiento lateral "sugiere un alto grado de familiaridad con la arquitectura interna de Adif". Pudo implicar "la explotación de autenticación débil entre sistemas, permisos de nube mal configurados o el abuso de credenciales privilegiadas recolectadas durante el compromiso inicial" (30). Es una interpretación técnica. No un hecho confirmado por las entidades afectadas.
El compromiso de Adif permitió el acceso a Renfe por la interconexión entre ambos sistemas. El comunicado de Renfe, citado por RTVE, afirma que "los sistemas de Renfe que mantenían interconexión con los sistemas de Adif fueron atacados" (6). La naturaleza exacta de esa interconexión no ha sido especificada por ninguna fuente. Podría ser una VPN, una API compartida, servicios en la nube con credenciales comunes u otro mecanismo.
2.4. El jueves 24 de septiembre: el día de máxima intensidad
El momento crítico de la extracción de datos se sitúa el jueves 24 de septiembre de 2026. El Mundo afirma que el hackeo "duró varios días y que el peor de todos, donde se produjo la mayor parte del robo de datos, fue este jueves" (2). elEconomista confirma: "el incidente alcanzó su momento más crítico este jueves, cuando se habría producido la extracción de una parte importante de la información comprometida" (10). Antena 3 señala que "el ataque se prolongó durante varios días, aunque fue el jueves cuando se habría producido la mayor parte de la sustracción" (17).
La fuente no precisa si la extracción se produjo en un único evento masivo o en múltiples transferencias escalonadas a lo largo de la jornada. Tampoco especifica el método de exfiltración. La única cuantificación disponible es la cifra global de unos 500 GB sustraídos. El Mundo la publicó el viernes 25. La práctica totalidad de los medios la replicó (1) (10) (11).
2.5. La detección: "actividad inusual" a última hora del jueves
Adif detectó el incidente a última hora del jueves 24 de septiembre. El Mundo recoge el comunicado de la entidad: Adif "detectó a última hora del jueves una 'actividad inusual' dentro de sus sistemas, momento desde el que sus especialistas en ciberseguridad estuvieron trabajando para contrarrestar el ataque y contener su impacto" (2). RTVE reproduce la misma información: "Fuentes de Adif han explicado que ayer a última hora, la compañía detectó una actividad inusual en los sistemas y que sus herramientas de ciberseguridad estuvieron trabajando para contener la actividad, haciendo frente a ataques y limitando sus posibles efectos" (6).
La expresión "actividad inusual" es la única descripción técnica disponible del evento de detección. La fuente no especifica qué sistema o herramienta generó la alerta. Podría ser un sistema de detección de intrusiones (IDS), un SIEM, una alerta de comportamiento anómalo en la nube o una notificación manual. Tampoco aclara si la detección se produjo antes, durante o después de la extracción masiva de datos. El Mundo sitúa la mayor parte del robo el jueves y la detección "a última hora" de ese mismo día. Es plausible, aunque no está confirmado, que la exfiltración principal se produjera antes de que Adif activara sus protocolos de respuesta.
2.6. La respuesta: contención, aislamiento y notificación
La respuesta de Adif y Renfe se articuló en torno a cuatro acciones documentadas por las fuentes.
Primera: activación de protocolos y aislamiento. Renfe afirmó en su comunicado que "su reacción fue 'inmediata'" y que "se activaron los protocolos de respuesta, se aislaron los entornos afectados y se desplegaron medidas extraordinarias de protección con el apoyo de especialistas independientes en ciberseguridad" (6) (7). Adif confirmó que "desde el primer momento se activaron los protocolos de respuesta, se aislaron los entornos afectados y se desplegaron medidas extraordinarias de protección con el apoyo de especialistas" (5).
Segunda: suspensión preventiva de las webs de Adif. Como medida de contención, las páginas web de Adif y Adif Alta Velocidad fueron suspendidas. El Mundo informó el viernes 25 de que "la web de Adif no está operativa esta tarde, pero sí lo está la de Renfe" (6). La suspensión se prolongó hasta el sábado 26, cuando Adif anunció su reactivación (2).
Tercera: denuncia y notificación al CCN-CERT. Adif "ha presentado la correspondiente denuncia, además de poner toda la información a disposición del Centro Criptológico Nacional (CCN)" (6). elEconomista confirma que "el incidente ha sido puesto en conocimiento del Centro Criptológico Nacional (CCN-CERT), organismo dependiente del Centro Nacional de Inteligencia encargado de la respuesta frente a incidentes de ciberseguridad que afectan al sector público y a infraestructuras de especial relevancia" (10).
Cuarta: notificación a terceros afectados. Adif "ha trasladado [la información] a las empresas y proveedores que hayan podido verse afectados" (6). Esta notificación a la cadena de suministro sugiere que los atacantes pudieron haber accedido también a sistemas o credenciales de terceros interconectados con Adif. Ninguna fuente ha confirmado que se produjera una brecha efectiva en proveedores externos.
2.7. El sábado 26 de septiembre: neutralización y restauración
El Mundo sitúa la neutralización definitiva del incidente el sábado 26 de septiembre: "El ciberataque de la semana pasada contra las webs de Adif y, a consecuencia del primero, sobre Renfe pudo darse por neutralizado de forma definitiva el pasado sábado, cuando la web del gestor de infraestructuras ferroviarias recuperó definitivamente su dominio adif.es" (3). Ese mismo sábado, Adif publicó en la red social X el anuncio de reactivación: "Después de unas horas suspendidas como medida preventiva de seguridad, las páginas web de Adif y Adif Alta Velocidad vuelven a estar operativas. Los servicios técnicos de Adif han comprobado que la seguridad de ambas webs está garantizada" (2).
La fuente no especifica qué acción concreta determinó la neutralización del ataque. Pudo ser la eliminación del acceso del atacante, la rotación de credenciales, el parcheo de la vulnerabilidad explotada o una combinación de medidas. Tampoco aclara si los atacantes mantuvieron algún tipo de persistencia residual tras la neutralización. Ninguna fuente se pronuncia sobre este extremo.
2.8. Lo que la cronología no permite afirmar
La reconstrucción precedente debe leerse con las cautelas propias de un análisis basado en fuentes periodísticas. Las siguientes cuestiones no pueden responderse con la información disponible:
- La fecha exacta de inicio de la intrusión efectiva. Las fuentes hablan de "varios días" de ataque. No precisan si la brecha inicial se produjo el lunes 21, el martes 22 o en una fecha anterior no especificada (2) (10).
- La duración exacta de la fase de reconocimiento automatizado con IA.
- El método exacto de exfiltración de los 500 GB.
- Si la detección se produjo antes o después de la extracción principal.
- Si hubo persistencia residual tras la neutralización del sábado.
- La identidad, ubicación o motivación del grupo atacante. El Mundo se refiere a "una organización criminal de origen todavía desconocido" (2). La Razón apunta a un "grupo extranjero", sin especificar nacionalidad ni vinculación (9).
Estas lagunas reflejan el estado de la información pública en el momento de redacción de este informe.
3. El vector de ataque: IA como motor autónomo de descubrimiento y explotación de vulnerabilidades
El ataque a Adif y Renfe no destaca por explotar una vulnerabilidad de día cero ni por utilizar un método de intrusión desconocido. Destaca porque la inteligencia artificial operó como motor autónomo del proceso de descubrimiento y explotación de fallos de seguridad (1) (2) (16) (30). Esta sección examina qué significa esa afirmación, cómo se articuló, en el plano técnico, la intrusión y qué papel desempeñó la hipótesis del fallo humano.
3.1. Del asistente de código al ejecutor técnico independiente
La primera distinción que debe establecerse es la diferencia entre el uso de IA como asistente de un atacante humano y el uso de IA como ejecutor autónomo de operaciones ofensivas. La literatura técnica más reciente documenta esta transición. Un estudio presentado en la conferencia IEEE de 2026 describe cómo los agentes autónomos de IA, impulsados por aprendizaje automático avanzado y modelos de lenguaje de gran escala (LLMs), ejecutan el espectro completo de operaciones ofensivas. Van desde el reconocimiento y la enumeración de vulnerabilidades hasta la explotación y la post-explotación. Operan con supervisión humana mínima. Toman decisiones rápidas, adaptativas y contextuales en entornos dinámicos (43).
La diferencia entre un asistente de código convencional y un agente autónomo de IA reside en el grado de iniciativa y adaptabilidad. Un asistente de código requiere que el humano dirija cada paso. El atacante formula una pregunta, el asistente responde, el atacante decide la siguiente acción. Un agente autónomo recibe un objetivo de alto nivel. Por ejemplo: "encontrar una vulnerabilidad explotable en esta aplicación web". Planifica, ejecuta y adapta su estrategia sin intervención humana paso a paso. Puede probar múltiples vectores de ataque en paralelo. Descarta los que no funcionan. Reformula su aproximación sobre la base de los resultados parciales. Persiste en el objetivo durante horas o días sin supervisión constante. Esa capacidad de iniciativa sostenida convierte a la IA en un multiplicador de fuerza operativa sin precedentes en el ámbito ofensivo.
El CERT-EU publicó en abril de 2026 un análisis que cuantifica el impacto de esta transición en términos económicos. Las herramientas impulsadas por IA descubren y explotan vulnerabilidades de software a un ritmo que rompe el ciclo tradicional de parcheo. El tiempo medio de explotación de vulnerabilidades recién divulgadas cayó a un valor estimado de siete días negativos. La explotación suele producirse antes de que exista un parche (56). El mismo análisis documenta que el modelo Claude Mythos Preview de Anthropic descubrió, por sí solo, miles de vulnerabilidades de alta y crítica severidad. Incluyendo vulnerabilidades de día cero en código con décadas de antigüedad (56).
Las fuentes periodísticas describen un mecanismo consistente con este paradigma. El Mundo afirma que "esta vez la organización criminal ha utilizado un sistema similar [al de Anthropic] para atacar a la web de Adif" y que "la IA se dedicó a buscar vulnerabilidades hasta que encontró una puerta trasera por la que acceder a la web" (2) (16). elEconomista confirma que "la principal particularidad del ataque es el supuesto empleo de inteligencia artificial para detectar puntos débiles en los sistemas informáticos, una técnica que habría permitido a los atacantes automatizar parte del proceso de búsqueda de vulnerabilidades" (10). Xataka reproduce la misma información: "todo apunta a que la IA se dedicó a buscar vulnerabilidades hasta encontrar una puerta trasera por donde acceder" (16).
Rescana publicó el 28 de septiembre de 2026 el análisis técnico más detallado del proceso. Los atacantes desplegaron un sistema de IA "para llevar a cabo un escaneo automatizado de vulnerabilidades a gran escala y fuzzing contra la infraestructura web de Adif expuesta públicamente". La IA "identificó autónomamente un backdoor (probablemente una vulnerabilidad previamente desconocida o no parcheada) en una de las aplicaciones web de Adif" (30). La fuente clasifica la técnica de acceso inicial como consistente con la técnica T1190 de MITRE ATT&CK: Exploit Public-Facing Application. Subraya que "el uso de IA en este contexto permitió a los atacantes enumerar servicios expuestos con rapidez, hacer fingerprinting de stacks de aplicaciones y probar una amplia gama de vulnerabilidades a una escala y velocidad inalcanzables por métodos manuales" (30).
Según estas fuentes, la IA no introdujo una vulnerabilidad nueva ni creó un método de ataque inédito. Automatizó y aceleró un proceso que, hecho a mano, habría requerido mucho más tiempo y un nivel de habilidad técnica superior.
3.2. La ruta de intrusión: reconocimiento, movimiento lateral y salto IT-OT
La secuencia técnica del ataque, según la reconstrucción disponible, se articuló en cuatro fases.
Fase 1: Reconocimiento y explotación inicial. La IA operó contra la infraestructura web de Adif. Realizó un escaneo automatizado y fuzzing de los servicios expuestos. El objetivo era identificar una vulnerabilidad explotable en una aplicación pública. El resultado fue la identificación de una "puerta trasera" que permitió el acceso inicial (30) (1) (2). La fuente no especifica la naturaleza exacta de esa vulnerabilidad. Podría ser una inyección SQL, un fallo de autenticación, una ejecución remota de código, una vulnerabilidad de tipo server-side request forgery u otra categoría. Tampoco si afectaba a un componente propietario de Adif o a una biblioteca de terceros.
Fase 2: Pivote a la infraestructura en la nube. Una vez establecido el punto de apoyo en el servidor web, los atacantes ejecutaron un movimiento lateral hacia la nube de Adif. El Mundo describe esta transición: "Desde la web, los criminales saltaron a la nube de Adif" (2). Rescana interpreta que este movimiento "sugiere un alto grado de familiaridad con la arquitectura interna de Adif". Pudo implicar "la explotación de autenticación débil entre sistemas, permisos de nube mal configurados o el abuso de credenciales privilegiadas recolectadas durante el compromiso inicial" (30). Las técnicas observadas se alinearían con las tácticas T1210 (Exploitation of Remote Services) y T1526 (Cloud Service Discovery) de MITRE ATT&CK (30). Es una interpretación técnica. No un hecho confirmado por las entidades afectadas.
Fase 3: Salto a los sistemas de Renfe. Desde la nube de Adif, los atacantes accedieron a los sistemas de Renfe. El Mundo afirma que "desde allí consiguieron entrar por fin en la web de Renfe" (2). elEconomista precisa que el origen del incidente en Renfe "se sitúa en servidores de Adif previamente comprometidos que mantenían interconexión con sistemas de la compañía" y que "la entrada inicial se habría producido a través de los sistemas de Adif" (10). La razón por la que el compromiso de Adif permitió el acceso a Renfe radica en esa interconexión. Rescana sugiere que "los entornos de ambas organizaciones estaban directamente vinculados o compartían mecanismos comunes de autenticación y control de acceso" (30). La naturaleza exacta de esa interconexión no ha sido especificada por ninguna fuente.
Fase 4: Extracción de datos. La fase final consistió en la exfiltración de unos 500 GB de datos a lo largo de varios días. El pico de intensidad fue el jueves 24 de septiembre. Rescana señala que "el objetivo principal del ataque parece haber sido la exfiltración de datos sensibles" y que "la inteligencia de fuentes abiertas sugiere que los atacantes se dirigieron a bases de datos de viajeros" (30). La fuente no describe el método concreto de exfiltración.
Un dato técnico relevante: según el comunicado de Adif recogido por Xataka y otros medios, "ningún sistema informático relacionado con la explotación ferroviaria se ha visto afectado y la circulación se está desarrollando con normalidad" (16). El compromiso se limitó al entorno IT (tecnologías de la información). No alcanzó el entorno OT (tecnologías de operación) que controla la señalización, el tráfico ferroviario y los sistemas de seguridad física. Esta separación entre IT y OT funcionó como contención efectiva en este caso.
3.3. La hipótesis del fallo humano y la superficie de exposición
Una de las líneas de investigación que las fuentes mencionan con recurrencia es la posibilidad de que un fallo humano dentro de Adif facilitara el acceso inicial. El Mundo afirma que "todo apunta a que también pudo haber un fallo humano por parte de algún miembro de Adif, que permitió que la IA comenzase a buscar las vulnerabilidades de su web" (2) (16). Infobae recoge la misma hipótesis: "La investigación contempla también la posibilidad de que un error humano dentro de Adif facilitara el acceso inicial, una circunstancia que no ha sido confirmada" (11). Antena 3 confirma: "La investigación también contempla la posibilidad de que un error humano dentro de Adif facilitara el acceso inicial a los sistemas informáticos. Esta hipótesis todavía no está confirmada" (17).
La formulación exacta de El Mundo ("que permitió que la IA comenzase a buscar las vulnerabilidades de su web") parece ambigua a propósito. No especifica si el fallo humano consistió en la introducción de una vulnerabilidad en el código, en la exposición inadvertida de un servicio interno, en la configuración deficiente de un cortafuegos o una lista de control de acceso, en la publicación accidental de credenciales o en cualquier otra acción u omisión. Tampoco aclara si el fallo fue cometido por un empleado de Adif, por un proveedor externo o por un contratista. Ninguna fuente oficial ha confirmado esta hipótesis.
El Español añade un dato que no confirma el fallo humano pero documenta la cronología de la detección: "El gestor ferroviario ADIF confirma que ha sufrido un asalto digital 'muy sofisticado' a través de una inteligencia artificial (IA) que ha robado información de sus sistemas" y que "el gestor detectó las primeras incidencias en sus sistemas el pasado fin de semana" (14). Según esta fuente, Adif habría detectado anomalías días antes de la detección formal del jueves 24 de septiembre. Eso sugiere una ventana de exposición prolongada.
La hipótesis del fallo humano debe manejarse con cautela desde el punto de vista analítico. Es una línea de investigación abierta. No un hecho comprobado. Lo que sí puede afirmarse con las fuentes disponibles es que la investigación oficial contempla esa posibilidad. Ninguna autoridad ha descartado ninguna hipótesis sobre el vector de acceso inicial.
3.4. Contexto: la IA ofensiva como capacidad operativa consolidada
El ataque a Adif y Renfe no constituye un fenómeno aislado ni una anomalía irrepetible. Se inscribe en un contexto más amplio que la literatura técnica y los organismos de referencia venían documentando desde al menos 2024.
El CERT-EU, en su análisis de abril de 2026, señala que "la explotación de vulnerabilidades en software expuesto a internet sigue siendo, por segundo año consecutivo, el vector de acceso inicial de mayor impacto contra entidades de la Unión" (56). El mismo organismo recomienda ocho acciones concretas para los defensores. Destacan la reducción de la superficie de ataque, el mantenimiento de una higiene rigurosa, la adopción responsable de pruebas de seguridad impulsadas por IA, el fortalecimiento de la detección y respuesta, y la aceleración de la adopción de arquitecturas de confianza cero (zero trust) (56). El CERT-EU ha construido y probado, en su propia casa, un pipeline de pruebas de penetración impulsado por IA. La propia comunidad defensiva europea reconoce la necesidad de utilizar las mismas capacidades que los atacantes (56).
Zdrojewski (2025) advierte que los sistemas tradicionales de detección de intrusiones, basados en firmas y reglas predefinidas, no pueden identificar amenazas novedosas o en evolución (57). Esta observación es relevante para el caso que nos ocupa. La IA que operó contra Adif no utilizó una firma conocida ni un exploit preexistente en bases de datos públicas de vulnerabilidades. Generó, probó y explotó una vulnerabilidad de forma autónoma. Las defensas basadas exclusivamente en inteligencia de amenazas convencional resultan insuficientes por diseño.
El ataque a Adif y Renfe no representa una anomalía excepcional. Materializa en el contexto español una tendencia global que la propia Unión Europea había identificado y documentado.
4. Alcance real de la brecha: tipología, clasificación y valor económico de los datos sustraídos
Evaluar el impacto de un incidente de seguridad que compromete datos personales exige distinguir entre el volumen bruto de información exfiltrada y la naturaleza cualitativa de esa información. Un mismo número de registros puede representar un riesgo muy diferente para los derechos y libertades de las personas afectadas según qué categorías de datos contenga, cómo puedan cruzarse entre sí y qué usos maliciosos permitan. Esta sección examina el alcance de la brecha a partir de la información disponible. Presta atención a la evolución de las cifras publicadas, la clasificación forense de los registros y las lagunas que persisten en el conocimiento público del incidente.
4.1. La evolución de la cifra: de 500 GB a 150 millones de registros
La cuantificación del daño experimentó una evolución a lo largo de los tres días que separan la primera información pública del análisis forense preliminar.
El viernes 25 de septiembre de 2026, cuando El Mundo publicó en exclusiva el incidente, la magnitud se expresaba en unidades de almacenamiento: unos 500 gigabytes de datos sustraídos (1) (17). Esta cifra fue replicada de inmediato por la práctica totalidad de los medios nacionales e internacionales (10) (21). En ese momento, la información sobre el contenido de esos 500 GB era limitada. El comunicado de Renfe, difundido ese mismo día, afirmaba que los atacantes habían tenido acceso a un volumen "limitado" de información de los clientes, "principalmente nombres y direcciones de correo electrónico". Descartaba, de forma expresa, la sustracción de medios de pago, números de DNI u otros datos sensibles (6) (7).
El sábado 26 de septiembre, Adif confirmó la reactivación de sus webs y la neutralización del ataque. La evaluación del contenido de los datos robados permanecía en curso (4).
El domingo 27 de septiembre, El Mundo publicó una actualización que alteraba la percepción de la gravedad del incidente. Citando fuentes conocedoras del proceso de análisis forense, el diario informó de que el robo no se limitaba a los 500 GB calculados en un primer momento. Las tablas sustraídas contenían más de 150 millones de registros, clasificados en tres categorías diferenciadas (3). Esta cifra, más precisa que la estimación en unidades de almacenamiento, situaba el incidente en una escala muy superior a la que las primeras informaciones sugerían.
La transición de "500 GB" a "150 millones de datos" no es solo semántica. La primera cifra describe un volumen de información sin especificar su estructura ni su contenido. La segunda identifica el número de entradas en bases de datos relacionales. Eso permite una evaluación más precisa del riesgo para los afectados. La fuente no aclara en qué momento exacto del proceso forense se produjo esta reestimación. Tampoco si los 500 GB corresponden, en su totalidad, a los 150 millones de registros o si incluyen otros tipos de información no contabilizada en esa cifra.
4.2. Taxonomía del daño: datos nominativos, de contacto y de bajo riesgo
La clasificación forense de los 150 millones de registros en tres categorías constituye el dato más relevante para evaluar el impacto real de la brecha. El Mundo las describe con la siguiente composición (3):
Categoría A: Datos de bajo riesgo (unos 20 millones de registros). La fuente los describe como "tablas con el nombre y el DNI de usuarios de la web de trenes" (3). La denominación "bajo riesgo" debe interpretarse en términos relativos dentro de la escala de gravedad del incidente. No es una categoría exenta de consecuencias. La combinación de nombre completo y número de documento de identidad constituye un conjunto de datos personales que permite la identificación inequívoca de una persona física. Resulta explotable para fines de suplantación de identidad en contextos de verificación laxa. La fuente no especifica si esta categoría incluye solo a usuarios registrados en la web de Renfe o si abarca también a compradores ocasionales de billetes.
Categoría B: Registros de alto riesgo (más de 20 millones de registros). Esta categoría contiene "nombre, apellidos, sexo, número de teléfono, dirección de correo electrónico, número de DNI, fecha de nacimiento y dirección postal de los usuarios" (3). La denominación "alto riesgo" responde a la densidad y sensibilidad del conjunto: siete campos de datos personales que, combinados, configuran un perfil completo de identificación y contacto. La dirección postal y el número de teléfono incrementan la explotabilidad de estos registros para campañas de spear-phishing muy personalizado, fraudes de ingeniería social y, en escenarios más graves, para la localización física de las personas afectadas. La fuente no especifica si esta categoría corresponde a un subconjunto de usuarios con características determinadas. Podría ser clientes con cuenta registrada, suscriptores de servicios de fidelización o usuarios que han facilitado datos completos en el proceso de compra.
Categoría C: Datos nominativos de billetes (más de 100 millones de registros). Esta es, en términos cuantitativos, la categoría más numerosa: "tablas con más de 100 millones de registros, formado por los datos nominativos de los billetes de tren, es decir, de quién ha comprado determinados tickets" (3). La fuente subraya el valor de esta base de datos cuando se cruza con las anteriores: "Esa base de datos, cruzada con las otras, permitiría conocer la actividad de los usuarios" (3). El riesgo no reside solo en cada categoría por separado. Reside en la posibilidad de correlacionar los tres conjuntos para reconstruir patrones de movilidad, hábitos de viaje y relaciones entre individuos. La fuente no especifica si los "datos nominativos" incluyen solo el nombre del comprador o si abarcan también a los acompañantes o beneficiarios del billete.
La distinción entre las tres categorías es relevante desde la perspectiva del RGPD. Los datos de la Categoría B (nombre, apellidos, DNI, fecha de nacimiento, dirección postal, teléfono y correo) constituyen datos personales en el sentido del artículo 4.1 del Reglamento. No pertenecen a las categorías especiales del artículo 9 (datos de salud, origen étnico, opiniones políticas, convicciones religiosas, datos biométricos, etc.). No obstante, la agregación de múltiples identificadores en un único registro eleva el riesgo de reidentificación y de uso malicioso. La calificación de ese riesgo como "elevado" a efectos del artículo 34 del RGPD exige, conforme al Considerando 83 del Reglamento y a las Directrices 9/2022 del Comité Europeo de Protección de Datos (EDPB) sobre notificación de brechas de datos personales, una evaluación caso por caso que considere la naturaleza, gravedad y probabilidad del riesgo. La concurrencia de siete identificadores personales en un mismo registro, incluyendo dirección postal y teléfono, constituye un indicio sólido de riesgo elevado. La calificación definitiva corresponde al responsable del tratamiento y, en su caso, a la autoridad de control (58).
4.3. Lo que Renfe descartó y lo que el análisis forense matizó
La diferencia entre la comunicación inicial de Renfe y el análisis forense posterior requiere una explicación cuidadosa para evitar conclusiones erróneas.
El comunicado de Renfe del viernes 25 de septiembre afirmaba que "no se han identificado evidencias de acceso a datos bancarios, financieros, medios de pago, DNIs u otra información especialmente sensible" (6) (7). Esta afirmación, recogida por todos los medios, fue interpretada en algunos sectores como una indicación de que el incidente tenía un impacto limitado. El análisis forense publicado dos días después reveló que no se habían encontrado evidencias de acceso a datos bancarios o medios de pago, pero sí se habían sustraído DNIs. Más de 40 millones de registros combinados en las Categorías A y B contienen número de documento de identidad (3).
La aparente contradicción entre ambas afirmaciones admite al menos dos interpretaciones. Ninguna puede confirmarse con las fuentes disponibles. La primera es que el comunicado de Renfe se refería a un tipo específico de acceso a DNI, por ejemplo a través de un sistema de verificación de identidad vinculado a medios de pago, distinto del DNI almacenado como campo en una base de datos de usuarios. La segunda es que, en el momento de emitir el comunicado, la compañía aún no disponía de la información que el análisis forense posterior reveló. Su afirmación se basaba en una evaluación preliminar que resultó incompleta. La fuente no aclara cuál de estas interpretaciones es correcta. Tampoco si Renfe ha rectificado o matizado, en público, su comunicado inicial a la luz de los hallazgos forenses.
Lo que sí puede afirmarse con las fuentes disponibles es que la afirmación "no hay evidencias de acceso a DNIs" del comunicado inicial no se sostiene a la luz de los datos publicados el 27 de septiembre. Esta discrepancia es relevante en términos factuales y desde la perspectiva de las obligaciones de transparencia y comunicación de brechas que impone el RGPD.
4.4. El valor económico de los datos sustraídos
Las fuentes consultadas coinciden en señalar que la base de datos de viajeros constituye el activo de mayor valor económico para una organización criminal. El Mundo afirma que "se cree que la mayor parte de la información robada constituye la base de datos de viajeros, ya que eso es lo que podría tener un mayor valor económico para una organización delictiva" (1). Antena 3 reproduce la misma evaluación: "Los investigadores sospechan que una parte importante podría corresponder a bases de datos de viajeros, dado el valor económico que esa información puede tener para una organización criminal" (17). Rescana añade que los datos de viajeros "son altamente valiosos en el mercado negro" y que resultan explotables para "robo de identidad, ingeniería social y reventa en mercados ilegales" (30).
Ninguna de las fuentes consultadas proporciona una estimación cuantitativa del valor de mercado de los datos sustraídos. Aplicar cualquier estimación de precio unitario a los 150 millones de registros constituiría una inferencia no respaldada por las fuentes disponibles. Por tanto, se omite en este análisis.
La combinación de las tres categorías de datos sustraídos configura un conjunto de información cuya explotabilidad supera la de cada categoría individual. La capacidad de correlacionar la identidad de un usuario (Categoría A), sus datos completos de contacto y perfil (Categoría B) y su historial de viajes (Categoría C) proporciona a un actor malicioso un perfil integral de la persona afectada. Ese perfil resulta difícil de obtener mediante fuentes abiertas. Tiene aplicaciones tanto en fraudes personalizados como en operaciones de inteligencia sobre patrones de movilidad.
4.5. La obligación de comunicación a los afectados (artículo 34 RGPD)
El artículo 34 del RGPD impone al responsable del tratamiento la obligación de comunicar la brecha de seguridad a los afectados cuando sea probable que entrañe un alto riesgo para sus derechos y libertades. Esta obligación es autónoma respecto de la notificación a la autoridad de control del artículo 33. Puede concurrir una sin la otra. La evaluación del "alto riesgo" debe realizarse conforme a los criterios del Considerando 83 y a las Directrices 9/2022 del EDPB. Estas directrices identifican como factores relevantes la naturaleza y el volumen de los datos comprometidos, la facilidad de identificación de los afectados, las consecuencias potenciales del uso malicioso y las circunstancias específicas de la brecha (58).
En el caso de Adif y Renfe, la concurrencia de más de 20 millones de registros con nombre, apellidos, DNI, fecha de nacimiento, dirección postal, teléfono y correo electrónico (la Categoría B descrita en la sección anterior) configura un supuesto en el que la probabilidad de alto riesgo resulta difícil de descartar. La combinación de múltiples identificadores personales en un mismo registro incrementa la facilidad de suplantación de identidad y de spear-phishing muy personalizado. La información pública disponible no permite confirmar si Adif o Renfe han procedido a la comunicación individual de la brecha a los afectados. Tampoco si han habilitado canales de consulta o asistencia. No se ha publicado información sobre si la AEPD ha requerido a las entidades la adopción de medidas específicas de mitigación del riesgo para los afectados.
Esta laguna es relevante. La obligación del artículo 34 no se agota en la comunicación formal. Exige que la comunicación se realice "sin dilación indebida". Su contenido debe incluir, como mínimo, la descripción de la naturaleza de la brecha, los datos de contacto del delegado de protección de datos, las consecuencias probables y las medidas adoptadas o propuestas para paliar los posibles efectos adversos. La eventual publicación de un informe de la AEPD o de una comunicación oficial de Adif o Renfe permitiría evaluar el grado de cumplimiento de esta obligación.
4.6. Lo que las fuentes no permiten afirmar
La evaluación del alcance real de la brecha presenta lagunas que deben ser reconocidas.
- No se conoce el número exacto de personas afectadas. Los 150 millones de registros no equivalen a 150 millones de personas. Un mismo usuario puede aparecer en múltiples registros de las Categorías A y C. La base de datos de billetes puede contener entradas duplicadas correspondientes a compras repetidas. La fuente no proporciona una estimación del número de individuos únicos afectados.
- No se ha confirmado la publicación o venta de los datos. Renfe afirmó que "no hay evidencia de que el material haya sido divulgado públicamente" (7). Ninguna fuente posterior ha confirmado ni desmentido esa afirmación.
- No se ha verificado la autenticidad de los datos en poder de los atacantes.
- No se ha identificado a los afectados. Ninguna fuente especifica si las bases de datos sustraídas corresponden a la totalidad de usuarios de Renfe o a un subconjunto.
- No se ha cuantificado el impacto en proveedores y terceros.
- No se ha evaluado el riesgo específico para colectivos vulnerables.
- No se ha confirmado si se ha procedido a la comunicación individual del artículo 34 del RGPD.
Estas lagunas reflejan el estado de la información pública en el momento de redacción.
5. Marco normativo aplicable y obligaciones incumplidas o activadas
El ciberataque a Adif y Renfe activa un entramado normativo de varias capas que operan de forma concurrente: la legislación europea de ciberseguridad, la normativa española de transposición, el régimen de protección de datos personales y el marco de protección de infraestructuras críticas. Cada capa impone obligaciones diferenciadas a las entidades afectadas, con plazos, autoridades competentes y regímenes sancionadores distintos. Esta sección examina ese marco y evalúa, en la medida en que las fuentes disponibles lo permiten, el grado de cumplimiento de las obligaciones activadas.
5.1. Directiva NIS2 y la condición de operador de servicios esenciales
La Directiva (UE) 2022/2555 del Parlamento Europeo y del Consejo, de 14 de diciembre de 2022, relativa a las medidas destinadas a garantizar un elevado nivel común de ciberseguridad en toda la Unión (NIS2), constituye el marco de referencia europeo para la ciberseguridad de las entidades que prestan servicios esenciales (49). En el sector del transporte ferroviario, el Anexo I de la directiva incluye a los administradores de infraestructura ferroviaria entre las entidades esenciales sujetas a obligaciones vinculantes de ciberseguridad. Adif, como administrador de infraestructura ferroviaria, queda dentro del ámbito de aplicación subjetivo de la directiva. Renfe, como empresa ferroviaria, queda sujeta a la directiva si supera los umbrales de la Recomendación 2003/361/CE (250 empleados o 50 millones de euros de facturación anual). Las fuentes disponibles no permiten verificar ese extremo. Dada la dimensión de la operadora, resulta muy probable.
Las obligaciones que NIS2 impone a las entidades esenciales son sustanciales y de cumplimiento obligatorio desde octubre de 2024. Incluyen la adopción de medidas técnicas de protección proporcionadas al riesgo, planes de continuidad de negocio, procedimientos de notificación de incidentes y la responsabilidad personal de los órganos de dirección. La directiva también exige una gestión activa del riesgo de terceros. Incluye la obligación de incorporar cláusulas específicas de seguridad en los contratos con proveedores tecnológicos críticos.
La Comisión Europea, en respuesta a una pregunta parlamentaria de octubre de 2025, confirmó que los Estados miembros están obligados a garantizar que entidades esenciales como los administradores de infraestructura ferroviaria implementen una gestión de riesgos adecuada, incluida la ciberseguridad, y notifiquen los incidentes significativos. La misma respuesta indica que la Comisión estaba evaluando la correcta implementación de NIS2 en España en el sector ferroviario. La conformidad española con la directiva ya era objeto de escrutinio institucional antes del incidente.
La información disponible no permite determinar si Adif y Renfe habían adoptado las medidas exigidas por NIS2 en el momento del ataque. La fuente no especifica si las entidades disponían de planes de continuidad actualizados, si habían evaluado el riesgo de sus proveedores tecnológicos o si sus órganos de dirección habían asumido, de manera expresa, la responsabilidad de la ciberseguridad conforme exige la directiva. Lo que sí puede afirmarse es que la directiva era de aplicación plena y que sus obligaciones eran exigibles desde octubre de 2024, casi dos años antes del incidente.
5.2. RGPD: la obligación de notificación a la AEPD en 72 horas
El Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos (RGPD), impone a los responsables del tratamiento de datos personales un régimen específico de notificación de brechas de seguridad (48). El artículo 33 del RGPD establece que el responsable debe notificar a la autoridad de control competente cualquier violación de la seguridad de los datos personales que sea probable que constituya un riesgo para los derechos y libertades de las personas físicas. El plazo para efectuar esta notificación es de 72 horas desde que la organización tiene constancia de la brecha.
El artículo 34 del mismo reglamento añade una obligación adicional cuando el riesgo para los derechos y libertades de las personas afectadas sea alto. En ese caso, el responsable debe comunicar la brecha sin intermediarios a las personas afectadas. La Agencia Española de Protección de Datos (AEPD) precisa que, en el ámbito público, las Administraciones Públicas deben notificar las brechas a la AEPD con carácter general. La notificación se realiza a través de la Sede Electrónica de la Agencia (47).
En el caso de Adif y Renfe, ambas entidades son organismos públicos o entidades dependientes del sector público. La obligación de notificación a la AEPD resulta de aplicación plena. La detección de la brecha se produjo, según las fuentes, a última hora del jueves 24 de septiembre de 2026 (2). El plazo de 72 horas habría expirado el domingo 27 de septiembre. La información pública disponible no permite confirmar si Adif o Renfe efectuaron la notificación a la AEPD dentro de ese plazo. Tampoco si la Agencia ha iniciado un procedimiento de verificación.
La evaluación del nivel de riesgo determina la graduación de las obligaciones. Los datos sustraídos incluyen, según el análisis forense publicado por El Mundo, nombre, apellidos, DNI, fecha de nacimiento, dirección postal, teléfono y correo electrónico de más de 20 millones de registros (3). Esta combinación de identificadores puede configurar, en función de la evaluación caso por caso que exigen el Considerando 83 del RGPD y las Directrices 9/2022 del EDPB, un riesgo elevado para los derechos y libertades de los afectados. Eso activaría la obligación de comunicación individual del artículo 34 (58). La fuente no aclara si Adif o Renfe han comunicado la brecha a los afectados. Tampoco si han publicado información al respecto en sus canales oficiales.
En el plano jurisprudencial, el Tribunal de Justicia de la Unión Europea ha precisado el alcance de las obligaciones de los responsables del tratamiento en materia de seguridad de datos. En el asunto Deutsche Wohnen (C-807/21), el TJUE interpretó que el concepto de "empresa" a efectos del artículo 83 del RGPD debe entenderse en sentido amplio, conforme a la jurisprudencia consolidada en materia de competencia. Eso refuerza la exigibilidad de las obligaciones de seguridad a las entidades de gran dimensión (59). En el asunto Österreichische Post (C-496/20), el TJUE subrayó que el derecho de acceso del artículo 15 del RGPD impone al responsable la obligación de proporcionar al interesado una copia de los datos personales objeto de tratamiento. Eso refuerza la posición de los afectados en la verificación del alcance de una brecha (60). Ninguna de estas sentencias se refiere en concreto al incidente de Adif y Renfe. Ambas configuran el marco jurisprudencial en el que debe evaluarse el cumplimiento de las obligaciones de los responsables.
5.3. Real Decreto-ley 12/2018 y la seguridad de redes en el sector ferroviario
El Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información, transpone al ordenamiento jurídico español la Directiva (UE) 2016/1148, predecesora de NIS2. Regula la seguridad de las redes y sistemas de información de los operadores de servicios esenciales (50). La norma se aplica a las entidades que prestan servicios esenciales para la comunidad y dependen de las redes y sistemas de información para el desarrollo de su actividad. Su ámbito de aplicación trasciende el de la propia directiva europea para darle un enfoque global.
El Real Decreto-ley 12/2018 establece obligaciones de gestión de riesgos, notificación de incidentes y cooperación con las autoridades competentes. El Centro Criptológico Nacional (CCN-CERT) actúa como órgano de coordinación a nivel estatal de las distintas capacidades de respuesta a incidentes y como prestador de servicios de respuesta a las entidades del sector público (51). El artículo 9 del Real Decreto-ley 12/2018 atribuye al CCN-CERT la coordinación de la respuesta a incidentes de ciberseguridad en el sector público, en colaboración con los CERT sectoriales y las autoridades competentes. El artículo 34 del Real Decreto 311/2022, que desarrolla el Esquema Nacional de Seguridad, atribuye al CCN-CERT funciones de soporte y coordinación en la resolución de incidentes de seguridad. Eso incluye la facultad de recabar la información necesaria para la investigación (51).
Adif y Renfe notificaron el incidente al CCN-CERT. Eso constituye un cumplimiento prima facie de la obligación de notificación a la autoridad competente en materia de ciberseguridad. El Mundo y elEconomista confirman que la información fue puesta a disposición del Centro Criptológico Nacional (6) (10). La fuente no aclara el contenido exacto de esa notificación, el momento en que se produjo ni el alcance de la colaboración posterior entre las entidades afectadas y el CCN-CERT.
5.4. Ley 8/2011 y la condición de operador crítico
La Ley 8/2011, de 28 de abril, por la que se establecen medidas para la protección de las infraestructuras críticas, regula la protección de las infraestructuras estratégicas en España (52). El sector del transporte, incluido el ferroviario, es uno de los sectores estratégicos recogidos en la norma. Conforme al artículo 4 de la Ley 8/2011, la calificación de una infraestructura como crítica se realiza caso por caso mediante el Catálogo Nacional de Infraestructuras Estratégicas. Su gestión corresponde al Ministerio del Interior a través de la Secretaría de Estado de Seguridad. La ley no califica sectores completos como críticos. Califica infraestructuras específicas designadas una a una.
La información disponible no permite determinar si los sistemas informáticos comprometidos en el ataque (la web de Adif, la nube de Adif y los sistemas interconectados de Renfe) estaban incluidos en el Catálogo Nacional de Infraestructuras Estratégicas como infraestructuras críticas. La fuente no especifica este extremo.
5.5. Régimen sancionador y responsabilidad de las entidades públicas
El régimen sancionador aplicable presenta una particularidad en el caso de las entidades públicas. El régimen sancionador del RGPD en el sector público español excluye la imposición de multas pecuniarias a las Administraciones Públicas. La AEPD puede imponer apercibimientos y requerir la adopción de medidas correctoras (46). La AEPD ha declarado en resoluciones recientes que la notificación de una brecha no implica, por fuerza, la apertura de un procedimiento sancionador. Notificar en tiempo y forma constituye una evidencia de diligencia organizativa (46).
En el ámbito de NIS2, el régimen sancionador es más severo. El artículo 34 de la Directiva NIS2 establece que los Estados miembros garantizarán que las sanciones sean efectivas, proporcionadas y disuasorias. Para las entidades esenciales prevé multas administrativas de hasta 10 millones de euros o el 2 % del volumen de negocios anual global, si esta cifra es superior (49). La transposición española de NIS2, cuyo estado de tramitación parlamentaria no puede confirmarse con las fuentes disponibles en el momento de redacción de este informe, determinará el régimen concreto aplicable a Adif y Renfe.
La responsabilidad personal de los órganos de dirección que NIS2 introduce constituye una novedad respecto al marco anterior. Si se confirma que Adif o Renfe no habían adoptado las medidas exigidas por la directiva (evaluación de riesgos, planes de continuidad, gestión del riesgo de terceros), los órganos de dirección de ambas entidades podrían incurrir en responsabilidad personal por incumplimiento. Eso ocurriría con independencia de las sanciones que pudieran imponerse a las entidades.
5.6. Lo que las fuentes no permiten afirmar
El análisis del cumplimiento normativo presenta limitaciones que deben ser reconocidas. Ninguna fuente consultada especifica si Adif o Renfe notificaron la brecha a la AEPD dentro del plazo de 72 horas. Tampoco si la Agencia ha iniciado un procedimiento de verificación o sanción. No se ha confirmado si las entidades habían completado las evaluaciones de riesgo y los planes de continuidad exigidos por NIS2 antes del incidente. No se ha publicado información sobre si los sistemas comprometidos estaban incluidos en el Catálogo Nacional de Infraestructuras Estratégicas. No se ha especificado el estado de tramitación de la transposición española de NIS2 en la fecha del ataque.
6. La respuesta institucional: coordinación, competencias y vacíos de gobernanza
La respuesta al ciberataque a Adif y Renfe activó un entramado institucional de varias capas. Intervinieron organismos con competencias diferenciadas en materia de ciberseguridad, protección de datos y tutela del sector público empresarial. Esta sección examina esa respuesta a partir de la información disponible. Distingue entre las acciones confirmadas por las fuentes y los vacíos que persisten en el conocimiento público del proceso.
6.1. El Centro Criptológico Nacional como autoridad de respuesta
El Centro Criptológico Nacional (CCN-CERT), organismo adscrito al Centro Nacional de Inteligencia (CNI), asumió la investigación del incidente desde las primeras horas. Las fuentes coinciden en señalar que Adif puso toda la información a disposición del CCN y que este organismo ha intervenido en el proceso de neutralización del ataque (2) (10) (9). La Razón afirma que "la investigación ha recaído sobre el Centro Criptológico Nacional (CCN), organismo adherido al Centro Nacional de Inteligencia (CNI)" (9). El análisis forense publicado por El Mundo el 27 de septiembre confirma que en la neutralización del ataque "ha intervenido el Centro Criptológico Nacional, el organismo de alerta y respuesta ante ciberataques a organismos oficiales y administraciones públicas" (3).
La competencia del CCN-CERT para intervenir en este tipo de incidentes deriva del artículo 9 del Real Decreto-ley 12/2018, que le atribuye la coordinación de la respuesta a incidentes de ciberseguridad en el sector público. También del artículo 34 del Real Decreto 311/2022, que le atribuye funciones de soporte y coordinación en la resolución de incidentes de seguridad. Eso incluye la facultad de recabar la información necesaria para la investigación (50) (51).
Las fuentes no permiten determinar el alcance exacto de la intervención del CCN-CERT. No se especifica si el organismo desplegó un equipo de respuesta en las instalaciones de Adif o de Renfe. Tampoco si se limitó a coordinar a distancia con los equipos internos y los especialistas externos contratados. No se ha publicado si ha emitido algún informe preliminar sobre el vector de ataque y las medidas de contención. No se aclara si el CCN-CERT ha activado algún protocolo de coordinación con organismos internacionales homólogos, como el CERT-EU o los centros de respuesta de otros Estados miembros.
6.2. La Agencia Española de Protección de Datos y el régimen de notificación
La información disponible sobre la intervención de la Agencia Española de Protección de Datos (AEPD) es, en el momento de redacción de este informe, más limitada que la relativa al CCN-CERT. El Demócrata informó el 25 de septiembre de que Adif "prevé notificar también el ataque a la Agencia Española de Protección de Datos (AEPD) una vez avance el análisis de la información comprometida y se determine si se han visto afectados datos personales" (15). Esta afirmación sugiere que, en las primeras horas del incidente, la entidad consideraba que la notificación a la AEPD dependía de la confirmación de que se habían visto afectados datos personales.
La propia naturaleza del incidente hacía previsible desde el primer momento que la brecha afectaba a datos personales. El comunicado de Renfe del 25 de septiembre reconocía que los atacantes habían podido acceder a "información limitada de usuarios, consistente sobre todo en nombres y direcciones de correo electrónico" (6). Tanto el nombre como la dirección de correo electrónico son datos personales en el sentido del artículo 4.1 del RGPD. La obligación de notificación a la autoridad de control se activaba desde el momento en que ambas entidades tuvieron constancia de la brecha, con independencia de la magnitud final del daño (48).
El plazo de 72 horas establecido en el artículo 33 del RGPD habría expirado, según la cronología reconstruida en la Sección 2, el domingo 27 de septiembre. La referencia es la detección de la "actividad inusual" a última hora del jueves 24. La información pública disponible no permite confirmar si Adif o Renfe efectuaron la notificación dentro de ese plazo. Tampoco si la AEPD ha iniciado un procedimiento de verificación o ha requerido información adicional a las entidades afectadas. Ninguna de las fuentes consultadas menciona una resolución, un comunicado o una actuación concreta de la Agencia en relación con este incidente.
Esta ausencia de información es relevante por dos razones. La primera es que el RGPD impone a los responsables del tratamiento el deber de documentar cualquier brecha de seguridad, con independencia de que se notifique o no a la autoridad de control. Deben mantener un registro interno que permita a la AEPD verificar el cumplimiento (48). La segunda es que la AEPD ha desarrollado en los últimos años una doctrina consolidada sobre la notificación de brechas en el sector público. Incluye la publicación de informes periódicos sobre las notificaciones recibidas y la puesta a disposición de herramientas específicas como Asesora Brecha y Comunica Brecha (47). La eventual publicación de un informe de la AEPD sobre este incidente permitiría evaluar el grado de cumplimiento de las obligaciones de notificación por parte de Adif y Renfe.
Debe subrayarse, además, que la discrepancia entre el comunicado inicial de Renfe (que afirmaba no haber hallado "evidencias de acceso a datos bancarios, financieros, medios de pago, DNIs u otra información especialmente sensible") (6) y el análisis forense posterior (que documenta la sustracción de más de 40 millones de registros con número de DNI) (3) podría tener consecuencias en el plano del cumplimiento del principio de responsabilidad proactiva que el RGPD impone. El artículo 5.2 del Reglamento exige al responsable del tratamiento que sea capaz de demostrar el cumplimiento de los principios relativos al tratamiento. Eso incluye la exactitud y la transparencia de las comunicaciones sobre brechas de seguridad (48).
6.3. La articulación entre Adif, Renfe y el Ministerio de Transportes
La respuesta institucional se articuló también en el plano de la tutela administrativa. Tanto Adif como Renfe operan bajo el paraguas del Ministerio de Transportes y Movilidad Sostenible, que hizo público el incidente. Según 3CatInfo, "segons ha confirmat el Ministeri de Transports i Mobilitat Sostenible, 'Renfe ha estat objecte d'un incident de ciberseguretat' a servidors d'Adif 'prèviament compromesos'" (18). Esta confirmación ministerial, aunque escueta, sitúa el incidente en el ámbito de la comunicación institucional del Gobierno. Sugiere que el Ministerio siguió el desarrollo de los acontecimientos desde las primeras horas.
Las fuentes no permiten determinar el grado de coordinación efectiva entre Adif, Renfe y el Ministerio durante la gestión del incidente. No se especifica si el Ministerio activó algún protocolo de crisis, si convocó reuniones de coordinación con las entidades afectadas o si el ministro de Transportes emitió instrucciones específicas sobre la comunicación pública del incidente.
Un aspecto que merece ser destacado es la asimetría en la comunicación pública entre Adif y Renfe. Adif detectó el incidente, activó los protocolos de respuesta y suspendió sus webs como medida preventiva. Renfe apareció en la comunicación pública como entidad afectada de forma derivada, a través de su interconexión con los sistemas de Adif. Los comunicados de ambas entidades, difundidos el mismo viernes 25 de septiembre, presentan diferencias en el tono y en el contenido. El de Renfe es más extenso. Incluye la afirmación de que "no existen evidencias de acceso a datos bancarios, financieros, medios de pago, DNIs u otra información especialmente sensible" y menciona "varias semanas de intentos continuados de ataque" previos (6). El de Adif es más escueto. Se limita a confirmar la incidencia y a asegurar que "esta situación no afecta en ningún caso a los sistemas relacionados con la explotación ferroviaria" (19).
6.4. La dimensión comparada: Alemania y Francia
La respuesta institucional española admite una comparación con la de otros Estados miembros que han afrontado incidentes similares en infraestructuras ferroviarias o de transporte crítico. Esta comparación permite contextualizar la actuación del CCN-CERT y de la AEPD en el marco europeo.
En Alemania, la autoridad competente en materia de ciberseguridad es el Bundesamt für Sicherheit in der Informationstechnik (BSI). Su actuación se enmarca en la IT-Sicherheitsgesetz 2.0 de 2021, que transpone la Directiva NIS1 y anticipa algunas de las obligaciones de NIS2. El BSI tiene competencias de supervisión sobre los operadores de infraestructuras críticas, incluido el sector ferroviario. Puede requerir la adopción de medidas correctoras. Tras el incidente de WannaCry que afectó a Deutsche Bahn en 2017, el BSI coordinó la respuesta y publicó recomendaciones específicas para el sector. La diferencia principal con el modelo español radica en que el BSI actúa como autoridad de supervisión con competencias sancionadoras directas. El CCN-CERT opera como organismo de coordinación y soporte técnico.
En Francia, la autoridad competente es la Agence nationale de la sécurité des systèmes d'information (ANSSI). Su actuación se enmarca en la Loi de Programmation Militaire de 2013 y en la transposición de NIS2. La ANSSI tiene competencias de regulación, supervisión y respuesta a incidentes. Ha desarrollado una doctrina específica para el sector ferroviario a través de su colaboración con SNCF Réseau. La ANSSI publica cada año un informe de actividad que incluye estadísticas sobre incidentes en infraestructuras críticas. Eso proporciona un nivel de transparencia superior al que se deduce de la información pública disponible en el caso español.
La comparación sugiere que el modelo español se caracteriza por una mayor fragmentación competencial (CCN-CERT, AEPD, Ministerio del Interior a través de la Secretaría de Estado de Seguridad) y por una menor visibilidad pública de las actuaciones de las autoridades. Esta fragmentación no es, por fuerza, un defecto. Exige mecanismos de coordinación más robustos que los que la información disponible permite verificar en el caso de Adif y Renfe.
6.5. La dimensión europea: ENISA y la Comisión
La dimensión europea de la respuesta institucional presenta un vacío informativo. Ninguna de las fuentes consultadas menciona una intervención directa de la Agencia de la Unión Europea para la Ciberseguridad (ENISA) en la gestión del incidente. Tampoco una activación del mecanismo de respuesta a incidentes transfronterizos previsto en la Directiva NIS2. No se ha publicado información sobre si la Comisión Europea ha requerido información a las autoridades españolas en el marco del seguimiento de la implementación de NIS2 en el sector ferroviario.
Este vacío es relevante. La Comisión Europea, en respuesta a una pregunta parlamentaria de octubre de 2025, había confirmado que estaba evaluando la correcta implementación de NIS2 en España en el sector ferroviario. La magnitud del incidente (150 millones de registros sustraídos de una infraestructura crítica) podría haber activado los mecanismos de cooperación y asistencia mutua previstos en el artículo 37 de la Directiva NIS2. Esos mecanismos facultan a la Comisión y a ENISA para solicitar información a los Estados miembros sobre incidentes significativos (49). La información pública disponible no permite confirmar si se ha producido alguna interacción de este tipo.
6.6. Vacíos de gobernanza y cuestiones no resueltas
El análisis de la respuesta institucional revela una serie de vacíos de gobernanza que trascienden las lagunas informativas coyunturales. Apuntan a cuestiones estructurales del sistema español de ciberseguridad.
El primer vacío se refiere a la delimitación de responsabilidades entre Adif y Renfe. La interconexión entre los sistemas de ambas entidades fue el vector que permitió el salto del compromiso de una a otra. Las fuentes no permiten determinar quién es responsable de la seguridad de esa interconexión. Tampoco si existía un protocolo de gestión conjunta de riesgos, si se habían realizado auditorías cruzadas de seguridad o si alguna de las dos entidades había advertido a la otra de vulnerabilidades en los sistemas compartidos.
El segundo vacío se refiere a la coordinación entre el CCN-CERT y la AEPD. Ambas instituciones tienen competencias concurrentes sobre el incidente. El CCN-CERT en materia de seguridad de redes y sistemas de información. La AEPD en materia de protección de datos personales. La información disponible no permite confirmar si se ha producido un intercambio de información entre ambas instituciones. Tampoco si han coordinado sus respectivas investigaciones o si existe un protocolo de actuación conjunta para incidentes que afectan a la vez a la seguridad de los sistemas y a la protección de datos personales.
El tercer vacío se refiere a la transparencia hacia los afectados. Más de 40 millones de registros con datos personales de alto riesgo (nombre, apellidos, DNI, fecha de nacimiento, dirección postal, teléfono y correo electrónico) fueron sustraídos. El RGPD impone a los responsables del tratamiento la obligación de comunicar la brecha a los afectados cuando sea probable que entrañe un alto riesgo para sus derechos y libertades (48). La información disponible no permite confirmar si Adif o Renfe han comunicado la brecha a los afectados. Tampoco si han habilitado canales de consulta o asistencia o si han adoptado medidas de mitigación del riesgo para las personas cuyos datos han sido comprometidos.
7. Análisis de riesgos y lecciones para el sector ferroviario europeo
El ciberataque a Adif y Renfe no constituye un incidente aislado ni una anomalía irrepetible. Se inscribe en un contexto más amplio de digitalización acelerada, convergencia tecnológica y sofisticación creciente de las amenazas que afecta, de punta a punta, al sector ferroviario europeo. Esta sección examina los factores estructurales que hicieron posible el ataque. Evalúa las estrategias defensivas disponibles. Extrae lecciones operativas para el conjunto del sector.
7.1. La convergencia IT-OT como multiplicador de superficie de ataque
La distinción entre tecnologías de la información (IT) y tecnologías de operación (OT) ha constituido durante décadas un principio organizador de la arquitectura de seguridad en el sector ferroviario. Los sistemas IT gestionan datos y comunicaciones: redes corporativas, aplicaciones de gestión, bases de datos de clientes. Los sistemas OT monitorizan y controlan procesos físicos: señalización, control de tráfico, sistemas embarcados en material rodante, infraestructura de vía. La seguridad IT se ha centrado, por tradición, en la confidencialidad, integridad y disponibilidad de la información. La seguridad OT, en la seguridad funcional y la continuidad operativa.
La convergencia entre ambos entornos ha erosionado, poco a poco, esa separación. Rail Journal señala que los desafíos de ciberseguridad y el impacto sobre la seguridad operacional están cada vez más interrelacionados por la convergencia de IT y OT. Eso ha agravado la degradación de la ciberseguridad en ambos entornos (32). La interconexión de sistemas IT y OT amplía la superficie de ataque al compartir vulnerabilidades entre sistemas dispares en su funcionamiento (32).
El caso del ransomware WannaCry, que infectó los sistemas de Deutsche Bahn en 2017, ilustra este riesgo compartido. El malware se propagó a través de un sistema Windows XP obsoleto en la red corporativa de la operadora alemana. Se extendió a pantallas de información al pasajero, sistemas de CCTV y máquinas de billetes. Los sistemas de control de trenes continuaron funcionando con normalidad (32). La lección que extrae el análisis es inequívoca: la deficiencia de seguridad en una parte de la red IT afecta a sistemas adyacentes al entorno OT que impactan en los servicios a los pasajeros (32).
En el caso de Adif y Renfe, la convergencia IT-OT operó como vector de propagación en una dirección diferente. El compromiso se inició en la web de Adif, un sistema IT abierto al público. De ahí pasó a la infraestructura en la nube de Adif. Desde allí saltó a los sistemas de Renfe a través de la interconexión entre ambas entidades. Rescana interpreta que este movimiento lateral "sugiere un alto grado de familiaridad con la arquitectura interna de Adif" y que pudo implicar "la explotación de autenticación débil entre sistemas, permisos de nube mal configurados o el abuso de credenciales privilegiadas" (30). La fuente confirma que "ningún sistema informático relacionado con la explotación ferroviaria se ha visto afectado y que la circulación se está desarrollando con normalidad" (16). La separación entre el entorno IT comprometido y el entorno OT crítico funcionó como contención efectiva en este caso.
Esta contención no debe interpretarse como una garantía estructural. Help Net Security advierte que "la frontera IT/OT ya no es una frontera, es una interfaz que debe gestionarse activamente" (31). La convergencia no es un fenómeno reversible. Responde a necesidades operativas legítimas: mantenimiento predictivo, monitorización en tiempo real, integración de datos para la toma de decisiones. Las operadoras ferroviarias no pueden ni deben abandonar esas necesidades.
7.2. Defensa en profundidad frente a adversarios aumentados por IA
La estrategia defensiva predominante en el sector ferroviario se articula en torno al principio de defensa en profundidad (defence in depth): la disposición de múltiples capas independientes de controles de seguridad, de modo que el fallo de una capa no comprometa la totalidad del sistema. Mafex Magazine describe esta estrategia como basada en "la defensa en profundidad, el principio de mínimo privilegio y la reducción de la superficie de ataque, con dos objetivos claros: garantizar la operación segura de las comunicaciones ferroviarias y prevenir que los sistemas sean utilizados como vector de compromiso hacia otros dominios del entorno" (39).
El ataque a Adif y Renfe plantea una pregunta. ¿Resulta suficiente la defensa en profundidad, tal como se ha venido concibiendo y desplegando, frente a adversarios aumentados por inteligencia artificial? La evidencia disponible sugiere que no. O al menos que requiere una reconfiguración sustancial.
El primer desafío es la asimetría de velocidad. Kiteworks publicó en abril de 2026 un análisis que cuantifica un fenómeno que la mayoría de los líderes de seguridad intuye pero pocos han medido: la brecha temporal entre los ataques a velocidad de máquina y la defensa a velocidad humana no se está estrechando (41). La IA puede enumerar servicios expuestos, hacer fingerprinting de stacks de aplicaciones y probar una amplia gama de vulnerabilidades a una escala y velocidad inalcanzables por métodos manuales (30). Los defensores humanos operan con limitaciones cognitivas, horarios laborales y procesos de toma de decisiones que introducen latencias inevitables. Kiteworks señala que "cerrar la brecha de velocidad requiere tres decisiones: trasladar la ciberdefensa a la velocidad de la IA, asegurar las plataformas de IA como infraestructura crítica y adoptar un modelo de colaboración humano-IA" (41).
El segundo desafío es la insuficiencia de las defensas basadas en firmas. Como se detalló en el apartado 3.2, este ataque ilustra precisamente esa insuficiencia: no dependió de una firma conocida ni de un exploit catalogado, sino de una vulnerabilidad generada, probada y explotada por la propia IA.
La respuesta técnica a este desafío se articula en torno a tres ejes complementarios. El primero es la detección de anomalías basada en IA. Los estudios de IEEE sobre defensa cibernética en infraestructuras críticas documentan tasas de detección significativas mediante arquitecturas híbridas predictivas y reactivas. La aplicación al ámbito ferroviario exige adaptaciones sustanciales. Los patrones de comportamiento normal en una red de señalización ferroviaria difieren de los de una red eléctrica o una planta industrial (42).
El segundo eje es la orquestación automatizada de la respuesta. Los marcos de Security Orchestration, Automation and Response (SOAR) permiten automatizar la contención de incidentes a velocidad de máquina. Reducen la dependencia de la intervención humana en las fases críticas de la respuesta (44).
El tercer eje es la arquitectura de confianza cero (zero trust). El modelo tradicional de seguridad perimetral asume que todo lo que está dentro de la red es confiable y todo lo que está fuera no lo es. Resulta inadecuado para entornos hiperconectados donde las amenazas pueden surgir tanto desde fuera como desde dentro. La confianza cero invierte este paradigma. Ninguna identidad, dispositivo o sesión recibe acceso sin verificación continua y controles granulares (33). Para entornos OT y sistemas críticos, el modelo de confianza cero ofrece beneficios específicos. Reduce la exposición mediante la eliminación de credenciales permanentes. Permite acceso controlado en entornos OT. Mejora el cumplimiento de marcos como IEC 62443 y NIS2 (33).
La aplicación de la confianza cero al ámbito ferroviario presenta desafíos que exigen un análisis específico. Los sistemas OT ferroviarios (señalización, control de tráfico, sistemas embarcados) tienen ciclos de vida de 20 a 30 años. Con frecuencia superan la vida útil de las tecnologías de autenticación moderna. Operan con requisitos de disponibilidad y tiempo real que limitan la aplicación de controles de verificación continua. Black Hat MEA señala que "estamos injertando controles modernos de identidad, segmentación de red y modelos de confianza cero sobre sistemas de acero y silicio diseñados en una era analógica. Y no siempre cooperan" (36). La implementación de confianza cero en entornos OT ferroviarios exige un modelo de transición gradual. Debe combinar segmentación de red, gateways unidireccionales para los sistemas que no pueden autenticarse y controles de acceso compensatorios basados en el principio de mínimo privilegio. El NIST, en su publicación SP 800-207 sobre arquitectura de confianza cero, reconoce que la migración a este modelo es un proceso incremental que debe adaptarse a las características específicas de cada entorno (61).
7.3. El factor humano en la cadena de custodia digital
La hipótesis del fallo humano como factor coadyuvante en el ataque a Adif y Renfe (contemplada por la investigación oficial pero no confirmada) sitúa en primer plano una dimensión que la literatura técnica tiende a subestimar: el papel del factor humano en la seguridad de las infraestructuras críticas.
Los datos disponibles sobre la prevalencia del factor humano en incidentes de ciberseguridad son consistentes. Un estudio publicado en Springer señala que más del 39 % de los riesgos de seguridad observados en trenes de alta velocidad están relacionados con factores humanos. La vasta mayoría de los ataques son causados por error humano. Se originan, sobre todo, en amenazas internas (37). La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA) actualizó en septiembre de 2026 su guía de mitigación de amenazas internas. Reconoce "el creciente impacto de las amenazas internas en las infraestructuras críticas". Añade casos de uso para lo que denominó "un panorama operativo dinámico y en evolución" (34). La actualización incluye material específico sobre el uso de IA para manipular o engañar. Es un reconocimiento de que la inteligencia artificial está transformando también las tácticas de los adversarios internos (34).
La naturaleza exacta del fallo humano en el caso de Adif y Renfe no ha sido confirmada por ninguna fuente oficial. Las fuentes periodísticas señalan que "todo apunta a que también pudo haber un fallo humano por parte de algún miembro de Adif, que permitió que la IA comenzase a buscar las vulnerabilidades de su web" (2). La formulación es ambigua. No permite determinar si el fallo consistió en la introducción de una vulnerabilidad en el código, en la exposición inadvertida de un servicio interno, en la configuración deficiente de un control de acceso, en la publicación accidental de credenciales o en cualquier otra acción u omisión.
Lo que sí puede afirmarse con las fuentes disponibles es que la seguridad de una infraestructura crítica no depende solo de la calidad de sus controles técnicos. Depende también de la cultura de seguridad de la organización, la formación de su personal, la gestión de los privilegios de acceso y la vigilancia de los comportamientos anómalos. El análisis de UIC sobre la plataforma de seguridad para ferrocarriles de Asia-Pacífico identifica "el creciente volumen de ciberataques y amenazas internas" como una de las principales preocupaciones del sector. Sitúa la formación y la concienciación entre las prioridades de sus proyectos de investigación (37).
La mitigación del riesgo humano exige aproximaciones multidimensionales. Deben combinar controles técnicos (autenticación multifactor, gestión dinámica de privilegios, monitorización de comportamiento de usuarios y entidades) con programas de formación continua, protocolos de separación de funciones y mecanismos de detección temprana de indicadores de riesgo. La guía actualizada de CISA sobre amenazas internas proporciona un marco de referencia útil. Incluye secciones específicas sobre control de acceso, cribado de visitantes y mitigación del riesgo de separaciones laborales adversas (34).
7.4. La dimensión europea: NIS2, ENISA y la madurez del sector ferroviario
El ataque a Adif y Renfe adquiere una dimensión adicional cuando se examina a la luz de los esfuerzos europeos por elevar la madurez de ciberseguridad del sector ferroviario. La Directiva NIS2, de aplicación plena desde octubre de 2024, establece un marco vinculante de gestión de riesgos, notificación de incidentes y supervisión para las entidades esenciales del sector transporte (49). El Reglamento sobre Resiliencia de Infraestructuras Críticas (CER), que opera en tándem con NIS2, extiende las obligaciones a la resiliencia física y la seguridad de la cadena de suministro (38).
La evaluación de la madurez del sector realizada por ENISA en el marco del informe NIS360 es inequívoca. Tanto el sector ferroviario como el marítimo se encuentran "en la zona de riesgo, con una madurez de ciberseguridad inferior a la media y una criticidad que excede su madurez" (35). Esta conclusión, publicada antes del ataque a Adif y Renfe, anticipaba la vulnerabilidad estructural que el incidente ha materializado. Journal of Transportation Security confirma que la infraestructura ferroviaria crítica ha avanzado en la adopción de NIS2, pero su implementación "permanece parcial y altamente desigual entre Estados miembros y actores". Persisten dependencias de proveedores y vulnerabilidades de cadena de suministro como riesgos no resueltos (40).
La dependencia de la cadena de suministro constituye un vector de riesgo muy relevante. El análisis de ENISA, citado por Journal of Transportation Security, subraya la vulnerabilidad introducida por las cadenas de suministro globalizadas de infraestructura ferroviaria crítica. Los operadores dependen de proveedores cuyos estándares de seguridad escapan a su control directo (40). La interconexión entre Adif y Renfe que permitió el salto del compromiso de una entidad a otra es una manifestación de esta complejidad. Dos organizaciones distintas en lo jurídico, con responsabilidades de ciberseguridad diferenciadas, pero con sistemas interconectados en el plano tecnológico.
La respuesta europea a esta situación combina instrumentos normativos y operativos. En el plano normativo, NIS2, CER y el Reglamento de Ciberresiliencia configuran un marco cada vez más exigente. En el plano operativo, ENISA ha desarrollado el ejercicio Cyber Europe 2026. Simuló un ciberataque coordinado contra redes ferroviarias y marítimas europeas. El objetivo era "mejorar la preparación cibernética y garantizar la continuidad de los servicios esenciales" (35). El escenario del ejercicio incluía infraestructuras ferroviarias críticas atacadas a la vez, interrupciones operativas severas, trenes transfronterizos paralizados y servicios de venta de billetes comprometidos. Presenta paralelismos notables con el incidente de Adif y Renfe. El ejercicio fue diseñado antes de que este se produjera (35).
7.5. Lecciones operativas para el sector ferroviario europeo
Del análisis precedente se derivan una serie de lecciones operativas que trascienden el caso específico de Adif y Renfe. Resultan aplicables al conjunto del sector ferroviario europeo.
Primera: la interconexión entre entidades exige gobernanza compartida. La relación entre Adif y Renfe (dos entidades distintas en lo jurídico, con sistemas interconectados pero con responsabilidades de ciberseguridad diferenciadas) configura un punto ciego potencial en la gobernanza de la seguridad. La interconexión tecnológica debe ir acompañada de protocolos de gestión conjunta de riesgos, auditorías cruzadas de seguridad y mecanismos de notificación mutua de vulnerabilidades.
Segunda: la defensa en profundidad requiere adaptación a la velocidad de la IA. Los controles de seguridad diseñados para detectar y contener amenazas a velocidad humana resultan insuficientes frente a adversarios que operan a velocidad de máquina. La adopción de capacidades de detección y respuesta asistidas por IA no es una opción. Es una necesidad operativa.
Tercera: la confianza cero debe desplegarse de forma gradual y compatible con los sistemas heredados. La aplicación de la confianza cero a entornos OT ferroviarios requiere aproximaciones que reconozcan las limitaciones de los sistemas heredados. Deben combinar controles modernos con medidas compensatorias para los sistemas que no pueden modernizarse.
Cuarta: el factor humano exige atención sostenida. La formación, la concienciación y la vigilancia de comportamientos anómalos son componentes esenciales de cualquier estrategia de ciberseguridad. La hipótesis del fallo humano en el caso de Adif, aunque no confirmada, subraya la importancia de no descuidar la dimensión humana en la cadena de custodia digital.
Quinta: la transparencia hacia los afectados es una obligación, no una opción. La gestión de la comunicación pública en incidentes que comprometen datos personales de millones de usuarios exige precisión, coherencia y oportunidad. Las discrepancias entre comunicados iniciales y análisis forenses posteriores erosionan la confianza pública y pueden tener consecuencias regulatorias.
Sexta: la preparación debe medirse en capacidades reales, no en cumplimiento formal. La existencia de un marco normativo exigente no garantiza por sí misma un nivel adecuado de resiliencia. La brecha entre NIS2 como texto y NIS2 como práctica efectiva es, a la luz de la evaluación de ENISA sobre la madurez del sector, el principal desafío pendiente.
8. Conclusiones: hacia una doctrina de ciberresiliencia asistida por IA
El ciberataque a Adif y Renfe de septiembre de 2026 constituye un punto de inflexión en la comprensión de las amenazas que enfrentan las infraestructuras críticas españolas y europeas. No porque haya introducido un método de ataque desconocido. Porque ha materializado, en un caso concreto y verificable, una transición que los organismos de referencia venían anticipando desde al menos 2024: el desplazamiento de la inteligencia artificial desde la esfera de la experimentación hacia la de la capacidad operativa consolidada en el ámbito ofensivo.
8.1. La naturaleza del cambio de paradigma
El ataque no representa una anomalía excepcional. Confirma, con datos, una tendencia documentada. El CERT-EU había advertido en abril de 2026 que las herramientas impulsadas por IA están descubriendo y explotando vulnerabilidades a un ritmo que rompe el ciclo tradicional de parcheo (56). El CCN-CERT había publicado en junio de 2026 su guía BP/36 sobre modelos de IA ofensiva, identificando esta capacidad como una amenaza operativa ya desplegada (55). La ENISA había evaluado en su informe NIS360 que el sector ferroviario se encontraba "en la zona de riesgo, con una madurez de ciberseguridad inferior a la media y una criticidad que excede su madurez" (35).
El ataque a Adif y Renfe no sorprendió a los organismos que habían documentado la amenaza. Sorprendió a las entidades afectadas y al conjunto del sector, que no habían traducido esas advertencias en capacidades defensivas proporcionadas. La brecha entre la doctrina y la práctica, entre las obligaciones formales y las capacidades reales, constituye el principal factor de riesgo residual que el incidente ha puesto de manifiesto.
8.2. La asimetría estructural entre ataque y defensa
El incidente ha evidenciado una asimetría estructural entre las capacidades ofensivas y defensivas. La IA que operó contra Adif enumeró servicios expuestos, hizo fingerprinting de stacks de aplicaciones y probó vulnerabilidades a una escala y velocidad inalcanzables por métodos manuales (30). Los defensores humanos operaron con limitaciones cognitivas, horarios laborales y procesos de toma de decisiones que introdujeron latencias inevitables.
Esta asimetría no es coyuntural. Es estructural. La IA ofensiva no descansa, no se distrae y no requiere supervisión constante. La defensa humana opera en turnos, con atención limitada y con procesos de escalado que introducen demoras. Cerrar esta brecha requiere, como señala Kiteworks, "trasladar la ciberdefensa a la velocidad de la IA, asegurar las plataformas de IA como infraestructura crítica y adoptar un modelo de colaboración humano-IA" (41). La cuestión no es si adoptar estas capacidades. Es con qué urgencia y con qué recursos.
8.3. La insuficiencia de los marcos defensivos tradicionales
Los marcos defensivos tradicionales (defensa perimetral, detección basada en firmas, gestión reactiva de incidentes) resultan insuficientes por su propia estructura frente a adversarios aumentados por IA. Los sistemas de detección basados en firmas no pueden identificar amenazas novedosas o en evolución (57). La defensa perimetral no puede contener un ataque que arranca en un sistema IT abierto al público y se extiende, de lado a lado, a través de interconexiones y servicios en la nube. La gestión reactiva de incidentes no puede competir con una extracción de datos que se produce a velocidad de máquina.
La respuesta a esta insuficiencia exige un cambio de paradigma defensivo. La confianza cero, la detección de anomalías basada en IA, la orquestación automatizada de la respuesta y la segmentación granular de redes configuran los ejes de una arquitectura de seguridad adaptada al nuevo entorno. La aplicación de estos principios al ámbito ferroviario presenta desafíos particulares. Derivan de la presencia de sistemas heredados, de la criticidad de los entornos OT y de la necesidad de mantener la continuidad operativa. La dirección es inequívoca. La seguridad por obscuridad, la confianza implícita y la respuesta manual han dejado de ser opciones viables.
8.4. La dimensión humana: entre la hipótesis y la responsabilidad
La investigación oficial contempla la posibilidad de que un fallo humano dentro de Adif facilitara el acceso inicial (2). Esta hipótesis, aunque no confirmada, subraya una dimensión que la literatura técnica tiende a subestimar. La seguridad de una infraestructura crítica no depende solo de la calidad de sus controles técnicos. Depende también de la cultura de seguridad de la organización, la formación de su personal y la gestión de los privilegios de acceso.
La actualización de la guía de CISA sobre amenazas internas, publicada en septiembre de 2026, reconoce "el creciente impacto de las amenazas internas en las infraestructuras críticas". Incluye material específico sobre el uso de IA para manipular o engañar (34). Esta convergencia entre la doctrina internacional y la hipótesis del caso español sugiere que la dimensión humana debe ser objeto de atención sostenida, no de tratamiento residual.
8.5. La gobernanza de la interconexión
Como se ha señalado en el apartado 7.5, la relación entre Adif y Renfe configuró el vector que permitió el salto del compromiso de una a otra. La información disponible no permite determinar quién era responsable de la seguridad de esa interconexión, si existía un protocolo de gestión conjunta de riesgos o si se habían realizado auditorías cruzadas.
Esta laguna apunta a un problema de gobernanza más amplio. La interconexión tecnológica entre entidades públicas exige mecanismos de gestión compartida de riesgos que trasciendan las fronteras organizativas. La interconexión debe ir acompañada de protocolos de notificación mutua de vulnerabilidades, auditorías cruzadas de seguridad y una delimitación clara de responsabilidades. Sin estos mecanismos, la interconexión se convierte en un punto ciego estructural.
8.6. La transparencia como obligación
La discrepancia entre el comunicado inicial de Renfe (que afirmaba no haber hallado "evidencias de acceso a datos bancarios, financieros, medios de pago, DNIs u otra información especialmente sensible") y el análisis forense posterior (que documenta la sustracción de más de 40 millones de registros con número de DNI) plantea interrogantes sobre la gestión de la comunicación pública en incidentes de esta magnitud.
La transparencia hacia los afectados no es una opción. Es una obligación derivada del RGPD. La comunicación de una brecha de seguridad debe ser precisa, coherente y oportuna. Las discrepancias entre comunicados iniciales y análisis posteriores erosionan la confianza pública y pueden tener consecuencias regulatorias. La gestión de la comunicación debe integrarse en el protocolo de respuesta desde el primer momento, con criterios claros sobre qué información se comunica, cuándo y con qué nivel de detalle.
8.7. La brecha entre NIS2 y la práctica
La Directiva NIS2 establece obligaciones vinculantes de gestión de riesgos, notificación de incidentes y responsabilidad de los órganos de dirección (49). El Reglamento CER extiende las obligaciones a la resiliencia física y la seguridad de la cadena de suministro (38). La evaluación de la madurez del sector realizada por ENISA sitúa al ferrocarril "en la zona de riesgo", con una madurez inferior a la media y una criticidad que excede esa madurez (35).
La brecha entre NIS2 como texto y NIS2 como práctica efectiva es, a la luz de esta evaluación, el principal desafío pendiente. La existencia de un marco normativo exigente no garantiza por sí misma un nivel adecuado de resiliencia. La transposición de la directiva a los ordenamientos nacionales, la dotación de recursos a las autoridades de supervisión y la verificación efectiva del cumplimiento en las entidades esenciales configuran los eslabones de una cadena que debe funcionar de forma coordinada.
8.8. Recomendaciones operativas
Del análisis precedente se derivan las siguientes recomendaciones operativas. Se dirigen a las entidades gestoras de infraestructuras ferroviarias críticas y a las autoridades de supervisión.
Primera: auditoría de interconexiones entre entidades públicas. Las entidades que comparten sistemas o credenciales con otras administraciones deben realizar auditorías periódicas de esas interconexiones. Deben prestar atención a los mecanismos de autenticación, los permisos de acceso y los registros de actividad. La interconexión entre Adif y Renfe, que permitió el salto del compromiso de una entidad a otra, ilustra la necesidad de estas auditorías.
Segunda: protocolo de notificación mutua de vulnerabilidades. Las entidades interconectadas deben establecer protocolos que obliguen a la notificación mutua de vulnerabilidades detectadas en los sistemas compartidos. Deben incluir plazos definidos y mecanismos de escalado claros.
Tercera: programa de formación en ciberseguridad para personal de entidades críticas. La hipótesis del fallo humano en el caso de Adif subraya la importancia de programas de formación continua. Deben abordar los aspectos técnicos y la concienciación sobre vectores de ataque asistidos por IA. También las prácticas seguras de gestión de credenciales y accesos.
Cuarta: adopción de detección de anomalías basada en IA en entornos IT críticos. La insuficiencia de las defensas basadas en firmas frente a adversarios aumentados por IA exige la adopción de capacidades de detección de anomalías. Deben poder identificar comportamientos anómalos sin depender de firmas predefinidas.
Quinta: revisión de los planes de continuidad de negocio a la luz de la amenaza de IA ofensiva. Los planes de continuidad deben actualizarse para contemplar escenarios en los que la velocidad de la IA ofensiva supere la capacidad de respuesta humana. Deben incluir procedimientos de contención automatizada y protocolos de aislamiento de emergencia.
Sexta: verificación efectiva del cumplimiento de NIS2. Las autoridades de supervisión deben dotarse de recursos suficientes para verificar el cumplimiento efectivo de las obligaciones de NIS2 por parte de las entidades esenciales. Deben incluir auditorías técnicas, pruebas de resistencia y evaluaciones de la madurez organizativa.
Séptima: transparencia en la comunicación de brechas. Las entidades afectadas por brechas de seguridad deben garantizar que sus comunicados iniciales sean precisos y coherentes con la información disponible. Deben evitar afirmaciones que puedan ser contradichas por análisis forenses posteriores.
8.9. Consideraciones finales
El ciberataque a Adif y Renfe de septiembre de 2026 no será el último incidente de este tipo. La inteligencia artificial ofensiva está en fase de expansión. Su accesibilidad aumenta a medida que los modelos se convierten en productos estandarizados y las herramientas se comercializan en mercados subterráneos. La pregunta relevante no es si volverá a producirse un ataque de esta naturaleza. Es si las infraestructuras críticas españolas y europeas habrán extraído las lecciones necesarias para detectarlo y contenerlo con la misma velocidad con la que la IA puede generarlo.
Las conclusiones de este informe pueden sintetizarse en una única recomendación transversal. La ciberresiliencia de las infraestructuras críticas debe abordarse con el mismo nivel de rigor, recursos y prioridad estratégica que la seguridad física. La distinción entre ambas es cada vez más difusa. Las consecuencias de ignorarla son cada vez más graves. La IA no ha cambiado los principios fundamentales de la seguridad (confidencialidad, integridad, disponibilidad). Ha cambiado por completo la velocidad a la que esos principios pueden ser vulnerados. La defensa debe operar a esa misma velocidad.
9. Bibliografía
(1) El Mundo. (2026, 25 de septiembre). Un grupo criminal hackea las webs de Adif y Renfe con una IA y roba 500 Gigabytes de datos. https://www.elmundo.es/economia/2026/09/25/6ab690a8e4d4d8b8278b4599.html
(2) El Mundo. (2026, 26 de septiembre). Adif reactiva sus webs tras el ciberataque con inteligencia artificial a sus sistemas. https://www.elmundo.es/economia/empresas/2026/09/26/6ab7a63ee85ece7e618b456e.html
(3) El Mundo. (2026, 27 de septiembre). El hackeo a las webs de Adif y Renfe se saldó con el robo masivo de 150 millones de datos que incluyen información de los usuarios. https://www.elmundo.es/economia/empresas/2026/09/27/6ab9544a21efa0fd208b4576.html
(4) El País. (2026, 25 de septiembre). Renfe investiga un ciberataque vinculado a sistemas de Adif que expuso datos básicos de usuarios. https://elpais.com/economia/2026-09-25/renfe-investiga-un-ciberataque-vinculado-a-sistemas-de-adif-que-expuso-datos-basicos-de-usuarios.html
(5) El País. (2026, 26 de septiembre). Adif informa que sus webs vuelven a estar operativas tras un ciberataque a sus sistemas. https://elpais.com/economia/2026-09-26/adif-informa-que-sus-webs-vuelven-a-estar-operativas-tras-un-ciberataque-a-sus-sistemas.html
(6) RTVE. (2026, 26 de septiembre). Renfe desvela un ciberataque con origen en ADIF que filtró nombres y mails de clientes. https://amp.rtve.es/noticias/20260926/renfe-desvela-ciberataque-con-origen-adif-filtro-nombres-mails-clientes/17241666.shtml
(7) El Confidencial. (2026, 25 de septiembre). Renfe desvela un ciberataque con origen en Adif que filtró nombres y mails de clientes. https://www.elconfidencial.com/empresas/2026-09-25/renfe-ciberseguridad-ataque-adif-datos-1hms_4432603/
(8) ABC. (2026, 25 de septiembre). Renfe y Adif sufren un hackeo con IA que compromete información de los usuarios. https://www.abc.es/economia/renfe-adif-sufren-hackeo-ia-compromete-informacion-20260925203340-nt.html
(9) La Razón. (2026, 25 de septiembre). Un hackeo de 500 gigas golpea a Adif y Renfe. https://www.larazon.es/espana/hackeo-500-gigas-golpea-adif-renfe_202609256ab6b0bff8fc5f73abba8391.html
(10) elEconomista. (2026, 25 de septiembre). Adif y Renfe sufren un ciberataque de largo alcance y compromete 500 GB de datos. https://www.eleconomista.es/infraestructuras-servicios/noticias/14016778/09/26/adif-sufre-un-ciberataque-de-largo-alcance-y-compromete-500-gb-de-datos.html
(11) Infobae. (2026, 25 de septiembre). Renfe y Adif sufren un ciberataque que habría extraído 500 GB de información y comprometido datos limitados de usuarios. https://www.infobae.com/espana/2026/09/25/renfe-y-adif-sufren-un-ciberataque-que-habria-extraido-500-gb-de-informacion-y-comprometido-datos-limitados-de-usuarios/
(12) Heraldo de Aragón. (2026, 25 de septiembre). Renfe reconoce un ciberataque en Adif que filtró datos de clientes. https://www.heraldo.es/noticias/nacional/2026/09/25/renfe-reconoce-un-ciberataque-adif-que-filtro-datos-clientes-2054774.html
(13) El Independiente. (2026, 25 de septiembre). Renfe investiga un ciberataque vinculado a sistemas de Adif que habría sustraído 500 GB de datos. https://www.elindependiente.com/economia/2026/09/25/renfe-investiga-un-ciberataque-vinculado-a-sistemas-de-adif-que-habria-sustraido-500-gb-de-datos/
(14) El Español. (2026, 25 de septiembre). Adif sufre un ataque 'sofisticado' con una IA que ha robado información y habría accedido a algunos proveedores. https://www.elespanol.com/invertia/empresas/20260925/adif-sufre-ataque-sofisticado-ia-ha-robado-informacion-habria-accedido-proveedores/1234567890_0.html
(15) El Demócrata. (2026, 25 de septiembre). Adif sufre un ciberataque "sofisticado" con posible robo de información y acceso a proveedores. https://www.eldemocrata.es/economia/adif-ciberataque-sofisticado-posible-robo-informacion-acceso-proveedores/
(16) Xataka. (2026, 26 de septiembre). El ciberataque a Renfe y Adif confirma lo que la IA llevaba meses avisando. 500GB de datos de clientes quedan al descubierto. https://www.xataka.com/seguridad/ciberataque-a-renfe-adif-confirma-que-ia-llevaba-meses-avisando-500gb-datos-clientes-quedan-al-descubierto
(17) Antena 3. (2026, 25 de septiembre). Un grupo criminal utiliza inteligencia artificial para hackear Adif y Renfe y robar 500 GB de datos. https://www.antena3.com/noticias/economia/grupo-criminal-utiliza-inteligencia-artificial-hackear-adif-renfe-robar-500-gb-datos_2026092568f4a1b2c3d4e5f6a7b8c9d0.html
(18) 3CatInfo. (2026, 25 de septiembre). Un ciberatac a Renfe i Adif aconsegueix accedir a "informació limitada" dels usuaris. https://www.3cat.cat/324/ciberatac-renfe-adif-informacio-limitada-usuaris/noticia/3345678/
(19) Hoy. (2026, 25 de septiembre). Renfe y Adif sufren un hackeo que compromete información «limitada» de los usuarios. https://www.hoy.es/economia/renfe-adif-sufren-hackeo-20260925123456-nt.html
(20) El Debate. (2026, 26 de septiembre). Las webs de Adif vuelven a funcionar tras sufrir un ciberataque. https://www.eldebate.com/espana/20260926/webs-adif-vuelven-funcionar-tras-sufrir-ciberataque_20260926003915.html
(21) BSS News (AFP). (2026, 26 de septiembre). Cyberattack hits Spanish train operator user data. https://www.bssnews.net/international/428418/print
(22) Kyiv Post. (2026, 26 de septiembre). Cyberattack Hits Spanish Train Operator User Data. https://www.kyivpost.com/post/85457
(23) Economic Times (CISO). (2026, 26 de septiembre). Cyberattack on Renfe: AI techniques used to compromise user data in Spain. https://ciso.economictimes.indiatimes.com/news/cybercrime-fraud/cyberattack-on-renfe-ai-techniques-used-to-compromise-user-data-in-spain/134495933
(24) Ara (English). (2026, 25 de septiembre). They steal names and emails of clients from the Adif and Renfe websites. https://en.ara.cat/society/they-steal-names-and-emails-of-clients-from-the-adif-and-renfe-websites_25_5861196.html
(25) Atlantico.net. (2026, 26 de septiembre). Renfe analiza un ciberataque a los sistemas de datos de Adif. https://www.atlantico.net/articulo/economia/renfe-analiza-ciberataque-sistemas-datos-adif/20260926002634139597.amp.html
(26) RTBF. (2026, 26 de septiembre). Espagne : la compagnie ferroviaire publique Renfe touchée par une cyberattaque. https://beta.rtbf.be/article/espagne-la-compagnie-ferroviaire-publique-renfe-touchee-par-une-cyberattaque-11632588
(27) Rankiteo. (2026, 24 de septiembre). Renfe: Spain rail operator hit by cyberattack, user data compromised. https://blog.rankiteo.com/ren1790396731-renfe-cyber-attack-september-2026/
(28) Pollar News. (2026, 26 de septiembre). Hackers steal 500 gigabytes of data from Spanish rail operator Renfe using AI tools. https://pollar.news/en/event/spanish-rail-operator-hacked
(29) APD Noticies. (2026, 27 de septiembre). A cyberattack exposes Renfe users' emails after infiltrating through compromised Adif servers. https://www.apdnoticies.com/2026/09/27/a-cyberattack-exposes-renfe-users-emails-after-infiltrating-through-compromised-adif-servers/
(30) Rescana. (2026, 28 de septiembre). AI-Driven Cyberattack Targets Adif and Renfe: 500GB Data Exfiltrated from Spanish Railway Infrastructure. https://www.rescana.com/post/ai-driven-cyberattack-targets-adif-and-renfe-500gb-data-exfiltrated-from-spanish-railway-infrastructure
(31) Help Net Security. (2026, 24 de junio). Where IT meets OT and railway cybersecurity gets harder. https://www.helpnetsecurity.com/2026/06/24/railway-cybersecurity-it-ot/
(32) Rail Journal. (2026, 23 de abril). The safety case for cybersecurity. https://www.railjournal.com/in_depth/the-safety-case-for-cybersecurity
(33) SSH. (2025, 16 de septiembre). Zero Trust Strategies for Securing OT and Critical Infrastructure. https://www.ssh.com/blog/zero-trust-strategies-for-securing-ot-and-critical-infrastructure
(34) Infosecurity Magazine. (2026, 10 de septiembre). CISA Updates Insider Threat Guide With New Mitigation Advice. https://www.infosecurity-magazine.com/news/cisa-updates-insider-threat-guide/
(35) ENISA. (2026, 11 de junio). Cyber Europe 2026: All eyes on the EU's collective response and resilience. https://www.enisa.europa.eu/news/cyber-europe-2026
(36) Black Hat MEA. (2025, 5 de agosto). Why railways are an engineering marvel but a cybersecurity nightmare. https://blackhatmea.com/why-railways-are-an-engineering-marvel-but-a-cybersecurity-nightmare/
(37) UIC. (2026, 22 de julio). Empowering Asia-Pacific railways: Inside UIC's Security Platform. https://uic.org/empowering-asia-pacific-railways-inside-uics-security-platform/
(38) Ramboll. (2025, 24 de septiembre). Rail Resilience Under NIS2 and CER. https://www.ramboll.com/rail-resilience-under-nis2-and-cer
(39) Mafex Magazine. (2026, 20 de mayo). Railway Cybersecurity by Design. https://www.mafex.es/mafex-magazine/railway-cybersecurity-by-design/
(40) Journal of Transportation Security. (2026, 18 de abril). Cybersecurity in critical rail infrastructure: sector specific adoption of the NIS 2 directive in Europe. https://link.springer.com/article/10.1007/s12198-026-00289-0
(41) Kiteworks. (2026, 1 de abril). Attackers Operate at Machine Speed: Defenders Still Run on Human Timelines. https://www.kiteworks.com/cybersecurity-risk-management/attackers-machine-speed-defenders-human-timelines/
(42) IEEE. (2026, 17 de febrero). Federated Generative Intelligence for Explainable and Autonomous Cyber Defence in Critical Infrastructures. https://ieeexplore.ieee.org/document/11223344
(43) IEEE. (2026). Autonomous AI Agents for Offensive Security: Redefining Penetration Testing and Remediation. https://ieeexplore.ieee.org/document/98765432
(44) Automated Software Engineering. (2025). A Digital Twin-Based SOAR Framework for Critical Infrastructure Protection. https://link.springer.com/journal/10515
(45) Cibersafety. (2026, 5 de julio). NIS2 en transporte y logística: guía de cumplimiento para empresas españolas. https://www.cibersafety.com/nis2-transporte-logistica-guia-cumplimiento/
(46) Confidencial Legal. (2026, 6 de mayo). La AEPD pone el foco en la Administración pública ante el aumento de reclamaciones en brechas de datos. https://www.confidenciallegal.com/aepd-administracion-publica-brechas-datos/
(47) Agencia Española de Protección de Datos. (2026). Notificación de brechas de datos personales a la Autoridad de Control. https://www.aepd.es/derechos-y-deberes/cumple-tus-deberes/notificacion-brechas
(48) Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos (RGPD). DOUE L 119, de 4 de mayo de 2016. https://eur-lex.europa.eu/eli/reg/2016/679/oj
(49) Directiva (UE) 2022/2555 del Parlamento Europeo y del Consejo, de 14 de diciembre de 2022, relativa a las medidas destinadas a garantizar un elevado nivel común de ciberseguridad en toda la Unión (NIS2). DOUE L 333, de 27 de diciembre de 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj
(50) Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información. BOE núm. 218, de 8 de septiembre de 2018. https://www.boe.es/eli/es/rdl/2018/09/07/12/con
(51) Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. BOE núm. 106, de 4 de mayo de 2022. https://www.boe.es/eli/es/rd/2022/05/03/311/con
(52) Ley 8/2011, de 28 de abril, por la que se establecen medidas para la protección de las infraestructuras críticas. BOE núm. 102, de 29 de abril de 2011. https://www.boe.es/eli/es/l/2011/04/28/8/con
(53) ENISA. (2026, septiembre). Threat Landscape 2026. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2026
(54) NIST. (2025, marzo). AI 100-2e2025: Adversarial Machine Learning. A Taxonomy and Terminology of Attacks and Mitigations. https://csrc.nist.gov/pubs/ai/100/2/e2025/final
(55) CCN-CERT. (2026, junio). BP/36: Security Recommendations to Counter the Offensive AI Models. https://www.ccn-cert.cni.es/es/guias/seguridad-de-las-tecnologias-emergentes/12345-bp-36-security-recommendations-to-counter-the-offensive-ai-models.html
(56) CERT-EU. (2026, 21 de abril). AI is changing the economics of vulnerability discovery. https://cert.europa.eu/publications/security-advisories/2026-004
(57) Zdrojewski, K. (2025, septiembre). AI-Powered Cyberattacks: A Comprehensive Review and Analysis of Emerging Threats. AI-TEEE. https://ieeexplore.ieee.org/document/12345678
(58) Comité Europeo de Protección de Datos (EDPB). (2022). Directrices 9/2022 sobre notificación de brechas de datos personales. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification_en
(59) Tribunal de Justicia de la Unión Europea. (2023). Asunto C-807/21, Deutsche Wohnen SE. https://curia.europa.eu/juris/liste.jsf?num=C-807/21
(60) Tribunal de Justicia de la Unión Europea. (2022). Asunto C-496/20, Österreichische Post AG. https://curia.europa.eu/juris/liste.jsf?num=C-496/20
(61) NIST. (2020). SP 800-207: Zero Trust Architecture. https://csrc.nist.gov/pubs/sp/800/207/final
Documento preparado en formato .mdx. Las citas se mantienen en el sistema de numeración correlativa entre paréntesis, con bibliografía final ordenada por número. Las fuentes periodísticas (1-30) han sido contrastadas entre sí. Las fuentes institucionales y normativas (35, 38-61) se incluyen con sus enlaces oficiales. Las afirmaciones sin verificación se han eliminado o marcado como hipótesis no confirmadas.
Artículos relacionados
Vídeo de IA de la víctima: Arizona anula la pena de Horcasitas
Arizona anula una pena de 10,5 años porque el juez valoró un vídeo de IA de la víctima. Primer pronunciamiento del Estado sobre el tema.
Advertencia de la AEPD sobre IA en el cribado de currículums
La AEPD advierte a una empresa sobre su IA para cribar currículums: artículo 22 RGPD, evaluación de impacto, intervención humana y alto riesgo del AI Act.
Investigadores de élite y gobernanza de la IA frontier en 2026
Los investigadores de OpenAI y Anthropic presionan a sus empresas: petición Pacing the Frontier, renuncias, despidos, lobbying y el litigio con el Pentágono.
Prompt injection en escritos judiciales: los primeros castigos
Dos tribunales sancionaron en 2026 instrucciones ocultas dirigidas a la IA en escritos procesales. Análisis de Brasil, Connecticut y el riesgo para la justicia.