Durante la Guerra Fría, la Unión Soviética construyó un sistema llamado Perimeter, conocido en Occidente como la «Mano Muerta». Fue diseñado para lanzar automáticamente todo el arsenal nuclear ruso si los sensores detectaban un ataque nuclear y se perdía la comunicación con el liderazgo militar.[s] La lógica era sencilla: si los humanos no pueden responder, que decidan las máquinas. Era aterrador entonces. Lo que debería aterrorizarnos ahora es que estamos construyendo algo análogo en los cimientos de la civilización moderna, excepto que nadie votó por ello y la mayoría de la gente no sabe que existe.
La fragilidad de la infraestructura de IA no es una preocupación hipotética. Es un patrón que ya ha producido fracasos de miles de millones de dólares, y las condiciones que lo crean se están acelerando. Los sistemas automatizados ahora administran las plataformas en la nube, redes y servicios digitales que sustentan la banca, atención médica, transporte y gobierno. Cuando esos administradores automatizados fallan, lo hacen a una escala y velocidad que los operadores humanos no pueden igualar.
Fragilidad de la infraestructura de IA: Lo que realmente pasó
El 19 de julio de 2024, la empresa de ciberseguridad CrowdStrike desplegó una actualización rutinaria de software a su sensor Falcon. Un error en el sistema de pruebas automatizadas de la empresa permitió que pasara un archivo defectuoso. En aproximadamente 80 minutos, alrededor de 8.5 millones de computadoras Windows en todo el mundo se bloquearon con pantallas azules de la muerte.[s] Las aerolíneas cancelaron vuelos. Los hospitales perdieron acceso a los registros de pacientes. Los bancos se congelaron. Los servicios de emergencia se desconectaron.
El daño financiero solo a las empresas Fortune 500 superó los $5 mil millones en pérdidas directas.[s] Muchas máquinas afectadas requirieron remediación manual en el sitio—a menudo arrancando en modo seguro o recuperación de Windows y eliminando el archivo defectuoso del sensor CrowdStrike; algunos endpoints se recuperaron tras reinicios repetidos o con herramientas automatizadas de recuperación.[s] El despliegue automatizado causó el problema; gran parte de la recuperación siguió dependiendo de trabajo manual.
Luego pasó de nuevo, diferente. El 20 de octubre de 2025, Amazon Web Services sufrió una interrupción importante cuando una condición de carrera en el sistema de gestión DNS automatizado de DynamoDB eliminó un registro de endpoint crítico.[s] DynamoDB en sí estaba saludable, pero nadie podía alcanzarlo. La falla se propagó a través de muchos servicios dependientes de AWS durante más de 15 horas, interrumpiendo a millones de usuarios en todo el mundo.[s] Las solicitudes fallidas generaron reintentos automatizados, que crearon una «tormenta de reintentos» que abrumó la infraestructura interna de AWS, haciendo la recuperación aún más difícil.[s]
Estos no fueron ataques exóticos o accidentes extraños. Fueron las consecuencias predecibles de un tipo específico de fragilidad de infraestructura automatizada—planos de control en la nube y cadenas de actualización de endpoints que administran otros sistemas automatizados—con modos de falla que se propagan más rápido de lo que cualquier humano puede intervenir.
Por qué la automatización empeora las cosas, no las mejora
El atractivo de la gestión automatizada de infraestructura es obvio. Las máquinas no se cansan, escalan sin esfuerzo y pueden reaccionar en milisegundos. Pero esas mismas propiedades se vuelven responsabilidades cuando algo sale mal.
La agencia de calificación crediticia Fitch advirtió después del incidente de CrowdStrike que los puntos únicos de falla «probablemente aumentarán a medida que las empresas busquen consolidación para aprovechar la escala y experiencia, resultando en menos proveedores con participaciones de mercado más altas.»[s] Privacy International lo expresó más directamente: «La consolidación del poder en empresas de Big Tech crea dependencia excesiva en puntos únicos de falla. La diversidad crea fortaleza.»[s]
El problema no es que cualquier sistema automatizado individual sea poco confiable. Individualmente, estos sistemas funcionan bien casi todo el tiempo. El problema está en lo que pasa cuando interactúan. Una falla en un sistema impulsado por IA puede propagarse en cascada a otros, amplificando el impacto mucho más allá del fallo original.[s] La interrupción de AWS lo demostró perfectamente: un error de DNS se convirtió en una falla de endpoint se convirtió en un colapso del plano de control se convirtió en una interrupción global del servicio.
El respaldo humano que no está ahí
La tranquilidad estándar para los sistemas automatizados es «humano en el bucle», la idea de que una persona siempre tiene supervisión y puede anular la máquina. La investigación muestra cada vez más que esto es una ficción consoladora.
El Supervisor Europeo de Protección de Datos publicó un análisis detallado en 2025 concluyendo que «simplemente agregar un humano dentro del proceso de toma de decisiones no garantiza inherentemente mejores resultados.» El informe encontró que «solo incluir un humano es poco probable que prevenga que los sistemas produzcan resultados erróneos o dañinos.»[s]
El Centro para Seguridad y Tecnología Emergente de Georgetown estudió el sesgo de automatización, la tendencia a confiar en sistemas automatizados incluso cuando están equivocados, en los dominios de aviación, automotriz y militar. Su conclusión: «humano-en-el-bucle no puede prevenir todos los accidentes o errores», porque el sesgo opera a un nivel psicológico que el entrenamiento por sí solo no puede abordar completamente.[s]
Peor aún, las habilidades que los humanos necesitan para intervenir durante una crisis se están atrofiando. La descualificación, la erosión de la competencia por el desuso, está bien documentada en medicina, donde las herramientas de diagnóstico de IA ya están degradando el juicio clínico de los profesionales que se supone deben supervisarlas.[s] El patrón se generaliza: mientras la IA toma el control de las tareas rutinarias de infraestructura, los ingenieros que una vez administraron esos sistemas manualmente pierden las intuiciones y experiencia necesarias para intervenir cuando la automatización se rompe.
La brecha de gobernanza
Para finales de 2026, se espera que las identidades de IA no humanas y agénticas superen los 45 mil millones, más de doce veces la fuerza laboral global humana. Sin embargo, solo el 10% de las organizaciones reportan tener una estrategia para administrar estos sistemas autónomos.[s] Esa brecha entre la velocidad de despliegue y la madurez de gobernanza es donde prolifera este problema sistémico.
La IA no solo hereda riesgos existentes. Crea nuevos encima. Como notó un investigador de política de infraestructura, la IA «amplifica y potencia» los riesgos tradicionales, «expandiendo el radio de explosión de la falla del sistema» introduciendo «riesgos impulsados por interacción, impulsados por datos y adversarios a velocidad y escala de máquina.»[s]
Algunas jurisdicciones están comenzando a actuar. La AB 316 de California, vigente desde enero de 2026, prohíbe a los demandados usar la operación autónoma de un sistema de IA como defensa contra reclamos de responsabilidad.[s] La Ley de IA de Colorado, vigente desde junio de 2026, requerirá evaluaciones anuales de impacto para sistemas de IA de alto riesgo. La Ley de IA de la UE ahora aplica reglas a modelos de IA de propósito general. Pero ¿la automatización de infraestructura que realmente opera Internet, la nube y la red eléctrica? Opera en gran medida fuera de estos marcos.
Lo que necesita cambiar
La lección de CrowdStrike y AWS no es que la automatización sea mala. Es que la automatización sin disyuntores, sin experiencia humana mantenida y sin diversidad real en proveedores de infraestructura es una receta para el tipo de fallas sistémicas en cascada que ponen de rodillas a las economías.
Tres principios importan. Primero, despliegue escalonado: ninguna actualización automatizada debería alcanzar todos los sistemas simultáneamente. CrowdStrike se ha comprometido desde entonces a un enfoque escalonado, desplegando actualizaciones a un subconjunto de clientes primero antes del lanzamiento más amplio.[s] Esto debería ser un estándar de la industria, no una lección post-desastre. Segundo, diversidad de infraestructura: cuando una sola región de nube que falla puede derribar servicios en 60 países, la arquitectura es la vulnerabilidad. Tercero, competencia humana preservada: las personas destinadas a anular sistemas automatizados deben practicar hacerlo regularmente, no solo saber que es teóricamente posible.
La fragilidad de la infraestructura de IA no es un riesgo futuro. Es una condición presente. Cada interrupción en cascada es un recordatorio de que hemos construido sistemas optimizados para eficiencia en condiciones normales y catastróficamente frágiles en condiciones anormales. La Mano Muerta fue diseñada para un escenario que sus creadores esperaban que nunca llegara. Estamos construyendo la nuestra en los sistemas de los que dependemos todos los días.
En 1985, la Unión Soviética activó Perimeter, un sistema de comando nuclear semi-autónomo que la inteligencia occidental denominó la «Mano Muerta». El sistema monitoreaba actividad sísmica, niveles de radiación, presión del aire y enlaces de comunicación. Si detectaba firmas consistentes con un ataque nuclear y no podía alcanzar al liderazgo militar, podía transferir autoridad de lanzamiento a oficiales de turno en búnkeres endurecidos, o en algunas configuraciones, iniciar el lanzamiento autónomamente.[s] El sistema encarnaba una filosofía específica: cuando las apuestas son existenciales, remover la latencia de decisión humana del camino crítico. Esa filosofía ahora impregna cómo administramos la infraestructura digital, y está produciendo un patrón reconocible de fragilidad de la infraestructura de IA.
Fragilidad de la infraestructura de IA a través de la lente de la teoría del accidente normal
En 1984, el sociólogo Charles Perrow publicó Accidentes Normales, argumentando que los sistemas con dos propiedades, complejidad interactiva y acoplamiento estrecho, inevitablemente producirán fallas catastróficas independientemente de las medidas de seguridad. Un sistema es «complejo interactivo» cuando los componentes interactúan de maneras no lineales e inesperadas. Está «estrechamente acoplado» cuando las fallas se propagan más rápido de lo que los operadores pueden intervenir.[s]
La infraestructura moderna administrada por IA exhibe ambas propiedades en forma extrema. Investigadores en Stanford y la Universidad Bocconi aplicaron el marco de Perrow directamente a sistemas de IA y concluyeron que «bajo el paradigma actual, los accidentes normales de Perrow se aplican a los sistemas de IA y es solo cuestión de tiempo antes de que ocurra uno.»[s] El mecanismo es directo: a medida que los sistemas de IA se vuelven más ubicuos, «diferentes algoritmos interactuarán directamente, llevando a sistemas estrechamente acoplados cuya capacidad de causar daño no podremos predecir.»[s]
Un análisis complementario de la Universidad de Louisville extiende este marco, notando que «aumentar la complejidad y ampliar el papel de los componentes de IA en un sistema disminuye la comprensibilidad del sistema, llevando a un aumento en accidentes normales.»[s] La percepción clave de esta investigación es que la IA no meramente agrega componentes a sistemas existentes; cambia fundamentalmente cómo esos sistemas fallan. Las fallas de componentes tradicionales son lineales y rastreables. Las fallas mediadas por IA son no lineales y a menudo incomprensibles para los operadores en tiempo real.
Anatomía de dos fallas en cascada
El incidente de CrowdStrike del 19 de julio de 2024 es una ilustración de libro de texto. El sensor Falcon de CrowdStrike opera a nivel del kernel de Windows, con acceso privilegiado al núcleo del sistema operativo. Channel File 291, una actualización de configuración del sensor, pasó la validación automatizada debido a un error en el sistema de verificación de contenido. El archivo desencadenó una lectura de memoria fuera de límites en el analizador del sensor Falcon, colapsando el kernel de Windows.[s] Dentro de 80 minutos del despliegue, aproximadamente 8.5 millones de dispositivos estaban inutilizados. La recuperación requirió intervención manual en cada máquina: acceso físico, arranque en modo seguro, eliminación del archivo defectuoso.
El daño a las empresas Fortune 500 superó los $5 mil millones en pérdidas directas, con atención médica y banca llevando el impacto más pesado en $1.94 mil millones y $1.15 mil millones respectivamente.[s] Fitch Ratings notó que este incidente «destaca un riesgo creciente de puntos únicos de falla» y advirtió que tal concentración «probablemente aumentará a medida que las empresas busquen consolidación.»[s]
La interrupción de AWS del 20 de octubre de 2025 demostró un modo de falla diferente con las mismas dinámicas subyacentes. AWS usa dos subsistemas automatizados para gestión DNS: un Planificador DNS (que rastrea la salud del balanceador de carga y propone cambios) y un Ejecutor DNS (que aplica cambios vía Route 53). Una condición de carrera latente entre instancias redundantes del Ejecutor causó que un trabajo de limpieza eliminara el registro DNS activo para el endpoint DynamoDB US-EAST-1, dejándolo apuntando a ninguna dirección IP.[s]
DynamoDB en sí permaneció internamente saludable, pero su inalcanzabilidad DNS se propagó en cascada a través del plano de control de AWS. EC2, Lambda, CloudWatch y las verificaciones de salud de NLB dependían todas de DynamoDB. Los SDK de clientes, al encontrar solicitudes fallidas, iniciaron reintentos automatizados que crearon una tormenta de reintentos, abrumando aún más la infraestructura del resolvedor interno. Las verificaciones de salud de NLB comenzaron a rechazar instancias EC2 recién lanzadas, lo que ralentizó la recuperación. La falla persistió por más de 15 horas y desencadenó interrupciones de servicio downstream generalizadas, con cientos de proveedores SaaS atribuyendo sus fallas a AWS.[s]
Ambos incidentes comparten un patrón característico de fragilidad de la infraestructura de IA: sistemas de gestión automatizados operando a velocidades que superan la comprensión humana, interactuando con dependencias estrechamente acopladas de maneras que amplifican en lugar de contener las fallas.
Sesgo de automatización y la erosión de la capacidad de anulación humana
La teoría de Organización de Alta Confiabilidad (HRO) sugiere que el problema del accidente normal puede mitigarse a través de prácticas organizacionales específicas: toma de decisiones descentralizada, cultura de seguridad fuerte, redundancia y entrenamiento continuo a través de simulación.[s] El requisito crítico es que los operadores humanos mantengan tanto la autoridad como la competencia para anular sistemas automatizados. Las tendencias actuales están socavando ambos.
El Centro para Seguridad y Tecnología Emergente de Georgetown estudió el sesgo de automatización en tres dominios (incidentes de autopiloto de Tesla, incidentes de aviación Boeing/Airbus y sistemas militares de defensa aérea) y encontró que «humano-en-el-bucle no puede prevenir todos los accidentes o errores.» El sesgo de automatización causa «errores de comisión (actuar sobre sugerencias incorrectas de IA) y errores de omisión (fallar en actuar porque la IA no indicó acción).»[s]
El análisis de 2025 del Supervisor Europeo de Protección de Datos identificó un problema más fundamental con la supervisión humana de sistemas automatizados: «las salidas del sistema enmarcan las opciones disponibles, empujando sutilmente a los usuarios hacia conclusiones específicas.» El EDPS concluyó que «simplemente agregar un humano dentro del proceso de toma de decisiones no garantiza inherentemente mejores resultados» porque la supervisión a menudo se implementa como «una formalidad meramente procesal, o gesto simbólico.»[s]
Agravando esto, la descualificación está degradando activamente la experiencia humana de la que depende la supervisión. En atención médica, donde las herramientas de diagnóstico de IA se han proliferado, los investigadores describen dos mecanismos distintos: descualificación técnica, la erosión de capacidades prácticas cuando los sistemas toman el control de la ejecución, y descualificación cognitiva, la externalización de procesos mentales centrales incluyendo interpretación, pensamiento crítico y aprendizaje iterativo.[s] Las mismas dinámicas se aplican a la ingeniería de infraestructura. Cuando la IA gestiona DNS, balanceo de carga, escalado y despliegue, los ingenieros nominalmente supervisando esos sistemas pierden la intuición operacional construida de la práctica práctica.
La escala del déficit de gobernanza
El desajuste entre el despliegue de IA y la gobernanza de IA es cuantificable. Se proyecta que las identidades de IA no humanas y agénticas superen los 45 mil millones para finales de 2026, más de doce veces la fuerza laboral humana global, mientras que solo el 10% de las organizaciones reportan tener una estrategia de gestión para sistemas autónomos.[s] La investigación demuestra que «las fallas en cascada se propagan más rápido de lo que la respuesta tradicional a incidentes puede contenerlas», con entornos simulados mostrando que un solo agente comprometido envenena el 87% de la toma de decisiones downstream dentro de cuatro horas.[s]
La IA crea lo que los investigadores de política llaman «riesgo incremental», nuevas capas de vulnerabilidad que no existían antes del despliegue de IA. Esto no es IA reemplazando riesgos existentes sino potenciándolos: «la IA los amplifica y potencia, expandiendo el radio de explosión de la falla del sistema» a través de «riesgos impulsados por interacción, impulsados por datos y adversarios a velocidad y escala de máquina.»[s]
Las respuestas regulatorias están emergiendo pero permanecen fragmentadas. La AB 316 de California excluye la defensa de responsabilidad «la IA lo hizo». La Ley de IA de Colorado obliga evaluaciones de impacto. La Ley de IA de la UE cubre modelos de propósito general. NIST lanzó un borrador de Perfil de Marco de Ciberseguridad para IA en diciembre de 2025, aunque sus autores explícitamente reconocieron brechas alrededor de sistemas de IA agénticos donde múltiples agentes coordinan y toman acción autónoma.[s] Ninguno de estos marcos aborda específicamente los sistemas de gestión de infraestructura automatizados que operan la nube, enrutan tráfico de internet o balancean redes eléctricas.
Fragilidad de la infraestructura de IA: Remediación estructural
Abordar la fragilidad de la infraestructura de IA requiere cambios a nivel arquitectónico, no solo a nivel de política. Cuatro intervenciones son esenciales.
Despliegues canarios obligatorios. Ninguna actualización automatizada debería propagarse a toda una base de clientes simultáneamente. CrowdStrike se ha comprometido a un enfoque escalonado para liberar actualizaciones de contenido, desplegando a un subconjunto de clientes y monitoreando antes del lanzamiento más amplio.[s] Esto debería ser un requisito regulatorio para cualquier software operando a nivel del kernel o gestionando infraestructura crítica.
Requisitos de diversidad arquitectónica. La interrupción de AWS reveló que las estrategias de zona de disponibilidad no pueden abordar dependencias en servicios fundamentales cuya falla se propaga en cascada a través de todo el plano de control.[s] La evaluación de Privacy International es correcta: «internet no debería estar confinado a caminos estrechos y jardines amurallados.»[s] Los servicios críticos necesitan redundancia genuina multi-proveedor, no solo despliegue multi-región dentro de un solo vendedor.
Competencia de anulación mantenida. Basándose en principios HRO, las organizaciones deben invertir en lo que los educadores médicos llaman «práctica deliberada», ejercicios regulares donde los operadores humanos gestionan infraestructura sin asistencia automatizada.[s] La analogía con la aviación es precisa: los pilotos aún vuelan aproximaciones manualmente a pesar de la capacidad del piloto automático, específicamente para prevenir la atrofia de habilidades.
Disyuntores automatizados con límites de radio de explosión. La tormenta de reintentos que amplificó la interrupción de AWS es un patrón de falla conocido. Los sistemas automatizados deben incluir disyuntores que detengan los reintentos en cascada y hagan cumplir la contención del radio de explosión. La propia respuesta post-incidente de AWS, deshabilitando y reevaluando los sistemas de automatización responsables, es el instinto correcto aplicado después del hecho en lugar de antes.[s]
El paralelo de la Mano Muerta
La Mano Muerta soviética fue construida para remover el juicio humano de un sistema donde la respuesta retrasada significaba aniquilación. Sus diseñadores entendían el intercambio: velocidad y certeza de respuesta a cambio del riesgo de catástrofe autónoma. La fragilidad de la infraestructura de IA moderna incrusta el mismo intercambio en sistemas que usamos todos los días, pero sin la misma claridad sobre lo que estamos renunciando.
Perimeter al menos tenía un paso de activación explícito; un oficial superior tenía que encenderlo durante una crisis. Nuestros sistemas de gestión de infraestructura automatizados están siempre encendidos, siempre propagando cambios, siempre estrechamente acoplados a dependencias downstream. Cuando fallan, lo hacen a velocidad de red. La pregunta no es si la próxima falla en cascada sucederá, sino si habremos construido los disyuntores, la experiencia humana y la diversidad arquitectónica para contenerla cuando lo haga.
